platform_data when using of?

platform_data when using of?

[Wolfram Sang]

[-- Attachment #1.1: Type: text/plain, Size: 1212 bytes --]

Hello,

I finally could get the work started with I2C on a MPC8260-based
platform. I applied Jochen's series on top of 2.6.25 and it seems I
could get the i2c-cpm and the rtc-rs5c372 driver working (except that it
doesn't autoload as a module, but I think this is my fault somewhere).
I have not checked all yet, but at least some reasonable things do happen.

I now wanted to test the latest at24-driver on top of that and stumbled
over the fact, that I can't directly add platform_data to the dts-file.
(As at24 shall be a generic driver, data about the eeprom type needs to
be provided.) If I understood of correctly, I need to create another
child node and put all necessary data in there (what also means one
cannot use the predefined macros for known chips in at24.h). After that
I use of_get_property and collect the data.

So, at the end, every driver using platform_data has to cope with two
mechanisms to get the desired data? This sounds questionable to me, but
maybe I just got something wrong as this is my first contact with of.

Kind regards,

   Wolfram

-- 
  Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: [i2c] platform_data when using of?

[Jochen Friedrich]

Hi Wolfram,

> Hello,
> 
> I finally could get the work started with I2C on a MPC8260-based
> platform. I applied Jochen's series on top of 2.6.25 and it seems I
> could get the i2c-cpm and the rtc-rs5c372 driver working (except that it
> doesn't autoload as a module, but I think this is my fault somewhere).
> I have not checked all yet, but at least some reasonable things do happen.
> 
> I now wanted to test the latest at24-driver on top of that and stumbled
> over the fact, that I can't directly add platform_data to the dts-file.
> (As at24 shall be a generic driver, data about the eeprom type needs to
> be provided.) If I understood of correctly, I need to create another
> child node and put all necessary data in there (what also means one
> cannot use the predefined macros for known chips in at24.h). After that
> I use of_get_property and collect the data.
> 
> So, at the end, every driver using platform_data has to cope with two
> mechanisms to get the desired data? This sounds questionable to me, but
> maybe I just got something wrong as this is my first contact with of.
> 
> Kind regards,
> 
>    Wolfram

You should probably send this question to the Powerpc list (added to cc)

Thanks,
Jochen

Re: platform_data when using of?

[Jean Delvare]

Hi Wolfram,

On Wed, 23 Apr 2008 18:45:23 +0200, Wolfram Sang wrote:
> (As at24 shall be a generic driver, data about the eeprom type needs to
> be provided.)

Each i2c driver can support many different devices, which are
differentiated simply by their name. So the driver can behave
differently for each device type as needed.

But of course this doesn't cover the way the chip is wired, e.g.
interrupt setup, pin polarities etc. For that you really need platform
data, carried in a driver-specific structure.

-- 
Jean Delvare

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: platform_data when using of?

[Wolfram Sang]

[-- Attachment #1.1: Type: text/plain, Size: 919 bytes --]

On Wed, Apr 23, 2008 at 08:30:12PM +0200, Jean Delvare wrote:

Hello Jean,

> Each i2c driver can support many different devices, which are
> differentiated simply by their name. So the driver can behave
> differently for each device type as needed.
We exactly threw this out of at24 in the new revision, as name-matching
stored quite some data in the driver which was needed only once during
initialization. Also, it was not very flexible; what if you want to mark
this chip as read-only, your variant has bigger page size and could be
faster... The list of device names would grow too fast IMHO, adding a
new feature which is selectable by a flag could easily double it.

Then again: If Jochen's patches get applied, then I have to use
MODULE_DEVICE_TABLE anyhow, or?

   Wolfram

-- 
  Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: platform_data when using of?

[Jean Delvare]

On Thu, 24 Apr 2008 11:00:45 +0200, Wolfram Sang wrote:
> On Wed, Apr 23, 2008 at 08:30:12PM +0200, Jean Delvare wrote:
> > Each i2c driver can support many different devices, which are
> > differentiated simply by their name. So the driver can behave
> > differently for each device type as needed.
>
> We exactly threw this out of at24 in the new revision, as name-matching
> stored quite some data in the driver which was needed only once during
> initialization. Also, it was not very flexible; what if you want to mark
> this chip as read-only, your variant has bigger page size and could be
> faster... The list of device names would grow too fast IMHO, adding a
> new feature which is selectable by a flag could easily double it.

The interest of separate chip names depend on the variety of devices
your driver support. I am not suggesting to have one name for every
different device the at24 driver will support, that would obviously be
way too many. But if you could come up with families (e.g. one name per
EEPROM size) with sane default settings, and then you can adjust
parameters through platform data, for example to maximize performance
if your actual EEPROM can handle larger page, or to enable write
access. So you probably have to find the right balance between one name
for all devices, and a separate name for each device.

> Then again: If Jochen's patches get applied, then I have to use
> MODULE_DEVICE_TABLE anyhow, or?

If you want your driver to load automatically, yes. But this doesn't
have much to do with the problem discussed above.

-- 
Jean Delvare

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c