Hi,
I'm in the process of porting my Epson 8564 RTC chip from 2.4 to
2.6.6-rc2. This is a RTC chip sitting on a I2C bus.
The code is here:
http://213.239.196.168/~seletz/patches/2.6.6-rc2/i2c-rtc8564.patch
http://213.239.196.168/~seletz/patches/2.6.6-rc2/machine-raalpha-rtc.patch
In order to split up functionality (I2C bus access and RTC misc device
stuff) I wrote two separate modules. In the rtc code module I did a i2c_get_client()
with the ID of my RTC chip to get a struct i2c_client which I think I need to
talk to the chip. I've implemented the command callback in my I2C module, which
I want to call from my RTC module.
Now I find that in 2.6.6-rc2 the i2c_get_client() implementation is missing (the prototype
is still in linux/i2c.h). Even the docs for i2c_use_client() refer to that function.
Most probably I'm missing something, but how is one supposed to access a i2c-client's
command function when i2c_get_client() is missing?
Of course I could just merge these two drivers and forget about separating i2c chip
access and rtc stuff, but ...
Thanks,
Stefan E.
--
Eletztrick Computing - Customized Linux Development
Stefan Eletzhofer, Marktstrasse 43, DE-88214 Ravensburg
http://www.eletztrick.de
On Tue, Apr 27, 2004 at 05:01:44PM +0200, [email protected] wrote:
> Hi,
> I'm in the process of porting my Epson 8564 RTC chip from 2.4 to
> 2.6.6-rc2. This is a RTC chip sitting on a I2C bus.
>
> The code is here:
> http://213.239.196.168/~seletz/patches/2.6.6-rc2/i2c-rtc8564.patch
> http://213.239.196.168/~seletz/patches/2.6.6-rc2/machine-raalpha-rtc.patch
>
> In order to split up functionality (I2C bus access and RTC misc device
> stuff) I wrote two separate modules. In the rtc code module I did a i2c_get_client()
> with the ID of my RTC chip to get a struct i2c_client which I think I need to
> talk to the chip. I've implemented the command callback in my I2C module, which
> I want to call from my RTC module.
>
> Now I find that in 2.6.6-rc2 the i2c_get_client() implementation is missing (the prototype
> is still in linux/i2c.h). Even the docs for i2c_use_client() refer to that function.
It was removed as there were no users of it from what I remember. I
should go and delete that prototype too...
> Most probably I'm missing something, but how is one supposed to access a i2c-client's
> command function when i2c_get_client() is missing?
Where do you need to access it from? Why do all of the current drivers
not need it?
> Of course I could just merge these two drivers and forget about
> separating i2c chip access and rtc stuff, but ...
If you always need both drivers to get the system to work, and there's
no real reason to split them up...
thanks,
greg k-h
On Tue, Apr 27, 2004 at 08:35:12AM -0700, Greg KH wrote:
> On Tue, Apr 27, 2004 at 05:01:44PM +0200, [email protected] wrote:
> > Hi,
> > I'm in the process of porting my Epson 8564 RTC chip from 2.4 to
> > 2.6.6-rc2. This is a RTC chip sitting on a I2C bus.
> >
> > The code is here:
> > http://213.239.196.168/~seletz/patches/2.6.6-rc2/i2c-rtc8564.patch
> > http://213.239.196.168/~seletz/patches/2.6.6-rc2/machine-raalpha-rtc.patch
> >
> > In order to split up functionality (I2C bus access and RTC misc device
> > stuff) I wrote two separate modules. In the rtc code module I did a i2c_get_client()
> > with the ID of my RTC chip to get a struct i2c_client which I think I need to
> > talk to the chip. I've implemented the command callback in my I2C module, which
> > I want to call from my RTC module.
> >
> > Now I find that in 2.6.6-rc2 the i2c_get_client() implementation is missing (the prototype
> > is still in linux/i2c.h). Even the docs for i2c_use_client() refer to that function.
>
> It was removed as there were no users of it from what I remember. I
> should go and delete that prototype too...
>
> > Most probably I'm missing something, but how is one supposed to access a i2c-client's
> > command function when i2c_get_client() is missing?
>
> Where do you need to access it from? Why do all of the current drivers
> not need it?
Well, in my RTC module I want to access the chip driver's command function, because I
encapsulated all I2C and low-level RTC chip access there.
Basically I want to do something like:
------------------------------------------------
struct i2c_client client = NULL;
client = i2c_get_client( I2C_DRIVERID_RTC8564, 0, NULL );
...
ret = client->driver->command(client, cmd, data);
------------------------------------------------
Where cmd, data are commands and data for the RTC chip driver. The above code
is in my rtc driver module, which does all the misc /dev/rtc driver stuff.
I don't know why all other drivers don't need them. It may well be that most of the drivers
in drives/i2c/chips are sensors-like drivers, which have sysfs/proc userspace interfaces and are
never called/used by other modules.
The drivers/media/video tree contains some cards which apparently have their own I2C bus on it,
and they do som nasty (?) stuff to get similar functionality. They have implicit access to their i2c adapters,
and thus can walk the adapter's client list.
In my case I haven't access to the i2c adapter, and I dont want to be dependent on the
I2C adapter my chip sits on. Therefore I think i2c_get_client() is needed.
>
> > Of course I could just merge these two drivers and forget about
> > separating i2c chip access and rtc stuff, but ...
>
> If you always need both drivers to get the system to work, and there's
> no real reason to split them up...
Well, I thought that maybe not everyone wants to implement a full-blown /dev/rtc style
interface, for example some ppl might implement a sensors-like /sysfs userspace interface
for that RTC chip. On embedded systems (where I do all this) some ppl might not be interested
in the RTC functionality of that chip but may be interested to use it as low-power counting
device, which even sends IRQs using a separate IRQ line.
>
> thanks,
>
> greg k-h
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Eletztrick Computing - Customized Linux Development
Stefan Eletzhofer, Marktstrasse 43, DE-88214 Ravensburg
http://www.eletztrick.de
On Tue, Apr 27, 2004 at 08:35:12AM -0700, Greg KH wrote:
> Where do you need to access it from? Why do all of the current drivers
> not need it?
The "traditional Linux" i2c model is one where the i2c bus is local to
the card, so the overall driver knows where the bus is, and what devices
to expect, and it's all nicely encapsulated.
The variant on that is the i2c sensor stuff, where the individual i2c
bus device drivers export data to userspace themselves.
However, there's another class, where the i2c bus contains things like
RTC and system control stuff, which can be found on embedded devices.
Such an i2c bus is often shared between multiple parts of the system,
and lumping them all together into one massive driver does not make
sense.
For instance, one platform I have here has an i2c bus with a RTC on,
and optionally a couple of EEPROMs giving the dimentions of the memory
on a couple of expansion boards. It doesn't make sense to lump the
RTC code along side the memory controller configuration code, along
with the i2c bus driver.
I2C is much much more than sensors and graphics capture chips.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Tue, Apr 27, 2004 at 07:21:19PM +0100, Russell King wrote:
> On Tue, Apr 27, 2004 at 08:35:12AM -0700, Greg KH wrote:
> > Where do you need to access it from? Why do all of the current drivers
> > not need it?
>
> The "traditional Linux" i2c model is one where the i2c bus is local to
> the card, so the overall driver knows where the bus is, and what devices
> to expect, and it's all nicely encapsulated.
>
> The variant on that is the i2c sensor stuff, where the individual i2c
> bus device drivers export data to userspace themselves.
>
> However, there's another class, where the i2c bus contains things like
> RTC and system control stuff, which can be found on embedded devices.
> Such an i2c bus is often shared between multiple parts of the system,
> and lumping them all together into one massive driver does not make
> sense.
Thats exactly what I tried to say with my other post. Thanks for spelling
it more precisely.
>
> For instance, one platform I have here has an i2c bus with a RTC on,
> and optionally a couple of EEPROMs giving the dimentions of the memory
> on a couple of expansion boards. It doesn't make sense to lump the
> RTC code along side the memory controller configuration code, along
> with the i2c bus driver.
Again, exatly what I thought when I split up I2C RTC chip access and
higher level RTC device handling stuff.
>
> I2C is much much more than sensors and graphics capture chips.
Definitely.
> --
> Russell King
> Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
> maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
> 2.6 Serial core
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Eletztrick Computing - Customized Linux Development
Stefan Eletzhofer, Marktstrasse 43, DE-88214 Ravensburg
http://www.eletztrick.de
Hi,
here's a patch that adds back i2c_get_client(). I tried to
implement such that it behaves the same way as it used to do.
As Russell King did point out already, I believe that this function
is needed for those I2C chip drivers which provide functions which
are used by other modules, like EEPROM I2C chips and RTC I2C chips.
Please see also my other post for the patch which adds support for the
Epson 8564 I2C RTC chip.
Patch URL:
http://213.239.196.168/~seletz/patches/2.6.6-rc2/i2c-get-client.patch
Please comment,
Stefan E.
Add back missing i2c_get_client() call.
#
# Patch managed by http://www.mn-logistik.de/unsupported/pxa250/patcher
#
--- linux-ra_alpha-update/drivers/i2c/i2c-core.c~i2c-get-client
+++ linux-ra_alpha-update/drivers/i2c/i2c-core.c
@@ -412,6 +412,57 @@
return res;
}
+struct i2c_client *i2c_get_client(int driver_id, int adapter_id,
+ struct i2c_client *prev)
+{
+ struct list_head *adap_list;
+ struct list_head *item, *_n;
+ struct i2c_adapter *adap;
+ struct i2c_client *client;
+ int found;
+
+ down(&core_lists);
+
+ adap_list = &adapters;
+ if ( prev ) {
+ /* we start searching at the previous clients adapter */
+ adap_list = &prev->adapter->list;
+ }
+
+ found = 0;
+ client = NULL;
+ list_for_each_entry(adap, adap_list, list) {
+ dev_dbg(&adap->dev, "examining adapter id=%08x\n", adap->id);
+
+ if ( adapter_id && adap->id != adapter_id )
+ continue; /* not the adapter id we want */
+
+ list_for_each_safe(item, _n, &adap->clients) {
+ client = list_entry(item, struct i2c_client, list);
+ dev_dbg(&client->dev, "examining client\n");
+ dev_dbg(&client->dev, "driver id=%08x\n", client->driver->id);
+
+ if ( prev && prev == client ) {
+ prev = NULL;
+ continue;
+ }
+
+ if (client->driver->id != driver_id)
+ continue; /* not the driver id we want */
+
+ if ( client->flags & I2C_CLIENT_ALLOW_USE ) {
+ dev_dbg(&client->dev, "found client\n");
+ found = 1;
+ goto out_unlock;
+ }
+ }
+ }
+
+out_unlock:
+ up(&core_lists);
+ return found?client:NULL;
+}
+
static int i2c_inc_use_client(struct i2c_client *client)
{
@@ -1261,6 +1312,7 @@
EXPORT_SYMBOL(i2c_del_driver);
EXPORT_SYMBOL(i2c_attach_client);
EXPORT_SYMBOL(i2c_detach_client);
+EXPORT_SYMBOL(i2c_get_client);
EXPORT_SYMBOL(i2c_use_client);
EXPORT_SYMBOL(i2c_release_client);
EXPORT_SYMBOL(i2c_clients_command);
--
Eletztrick Computing - Customized Linux Development
Stefan Eletzhofer, Marktstrasse 43, DE-88214 Ravensburg
http://www.eletztrick.de