Re: Device tree configuration for I2C eeprom

Re: Device tree configuration for I2C eeprom

[Grant Likely]

On Thu, Sep 18, 2008 at 06:21:36PM -0400, Jon Smirl wrote:
> On Thu, Sep 18, 2008 at 6:13 PM, Sebastian Siewior
> <linuxppc-embedded-tbOqE5TproD1e3ktjv5YCg@public.gmane.org> wrote:
> >>                                eeprom@50 {
> >>                                        compatible = "?????";
> >>                                                   something
> >>                                        something;
> >>                                };
> >
> > This should look like:
> > |                                eeprom@50 {
> > |                                        compatible = "eeprom";
> 
> 
> The new eeprom driver is at24, eeprom is the old one. at24 has write support.
> 
> EEPROMs from most vendors (AT24)
> 
> Enable this driver to get read/write support to most I2C EEPROMs,
> after you configure the driver to know about each EEPROM on
> your target board. Use these generic chip names, instead of
> vendor-specific ones like at24c64 or 24lc02:
> 
> 24c00, 24c01, 24c02, spd (readonly 24c02), 24c04, 24c08,
> 24c16, 24c32, 24c64, 24c128, 24c256, 24c512, 24c1024

No, don't use the generic chip names.  Device tree convention is to be
specific and prefix the part number with the vendor name.  ie. You should
be using "at,at24c64", not "24c64".

g.

Re: Device tree configuration for I2C eeprom

[Sebastian Siewior]

* Grant Likely | 2008-09-18 22:04:41 [-0700]:

>No, don't use the generic chip names.  Device tree convention is to be
>specific and prefix the part number with the vendor name.  ie. You should
>be using "at,at24c64", not "24c64".

What about the i2c drivers which don't have any prefix like the m41t80?
Prior commit 0d1cde2 aka "powerpc/i2c: Convert i2c-mpc into an
of_platform driver" the ids were converted.

>
>g.
>

Sebastian

Re: Device tree configuration for I2C eeprom

[Grant Likely]

On Fri, Sep 19, 2008 at 09:12:38AM +0200, Sebastian Siewior wrote:
> * Grant Likely | 2008-09-18 22:04:41 [-0700]:
> 
> >No, don't use the generic chip names.  Device tree convention is to be
> >specific and prefix the part number with the vendor name.  ie. You should
> >be using "at,at24c64", not "24c64".
> 
> What about the i2c drivers which don't have any prefix like the m41t80?
> Prior commit 0d1cde2 aka "powerpc/i2c: Convert i2c-mpc into an
> of_platform driver" the ids were converted.

Important Concept:  If the driver can't match with nodes that conform with
the device tree binding conventions, then it is a *Linux/device driver* bug;
not a device tree bug.  The device tree describes hardware.  It does not
describe the device driver implementation.

Do not fall into the temptation of writing the device tree to reflect
the current implementation of the operating system.  Stick to
established conventions and documented bindings.

That being said, it is a non-issue in this case.  The current Linux OF
support code automagically strips off the manufacturer prefix when
registering I2C devices.  Take a look at of_modalias_node() in
drivers/of/base.c for details.

g.

Re: Device tree configuration for I2C eeprom

[Sebastian Siewior]

* Grant Likely | 2008-09-19 00:44:58 [-0700]:

>Do not fall into the temptation of writing the device tree to reflect
>the current implementation of the operating system.  Stick to
>established conventions and documented bindings.
>
>That being said, it is a non-issue in this case.  The current Linux OF
>support code automagically strips off the manufacturer prefix when
>registering I2C devices.  Take a look at of_modalias_node() in
>drivers/of/base.c for details.
Thanks for this information.

>
>g.

Sebastian

Re: Device tree configuration for I2C eeprom

[Grant Likely]

On Fri, Sep 19, 2008 at 12:12 AM, Sebastian Siewior
<linuxppc-embedded@ml.breakpoint.cc> wrote:
> * Grant Likely | 2008-09-18 22:04:41 [-0700]:
>
>>No, don't use the generic chip names.  Device tree convention is to be
>>specific and prefix the part number with the vendor name.  ie. You should
>>be using "at,at24c64", not "24c64".
>
> What about the i2c drivers which don't have any prefix like the m41t80?
> Prior commit 0d1cde2 aka "powerpc/i2c: Convert i2c-mpc into an
> of_platform driver" the ids were converted.

That is the *driver* not the device tree description.  The OF i2c code
is still converts the name.  By default it does this by simply
stripping off the manufacturer prefix, but the match table does still
exist when the default behavior needs to be overridden.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: Device tree configuration for I2C eeprom

[Grant Likely]

On Tue, Nov 4, 2008 at 9:28 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Fri, Sep 19, 2008 at 12:12 AM, Sebastian Siewior
> <linuxppc-embedded@ml.breakpoint.cc> wrote:
>> * Grant Likely | 2008-09-18 22:04:41 [-0700]:
>>
>>>No, don't use the generic chip names.  Device tree convention is to be
>>>specific and prefix the part number with the vendor name.  ie. You should
>>>be using "at,at24c64", not "24c64".
>>
>> What about the i2c drivers which don't have any prefix like the m41t80?
>> Prior commit 0d1cde2 aka "powerpc/i2c: Convert i2c-mpc into an
>> of_platform driver" the ids were converted.
>
> That is the *driver* not the device tree description.  The OF i2c code
> is still converts the name.  By default it does this by simply
> stripping off the manufacturer prefix, but the match table does still
> exist when the default behavior needs to be overridden.

Oops, I already replied to this one.  Sorry for the duplicate response.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: Device tree configuration for I2C eeprom

[Sebastian Andrzej Siewior]

* Grant Likely | 2008-11-04 09:29:09 [-0700]:

>Oops, I already replied to this one.  Sorry for the duplicate response.

No worries. You haven't been that detailed like the last time :)

>g.

Sebastian

RE: Device tree configuration for I2C eeprom

[Ayman El-Khashab]

Grant Likely <> said on :
>>>>                                };
>>> 
>>> This should look like:
>>>>                                eeprom@50 {
>>>>                                        compatible = "eeprom";
>> 
>> 
>> The new eeprom driver is at24, eeprom is the old one. at24 has write
>> support. 
>> 
>> EEPROMs from most vendors (AT24)
>> 
>> Enable this driver to get read/write support to most I2C EEPROMs,
>> after you configure the driver to know about each EEPROM on your
>> target board. Use these generic chip names, instead of
>> vendor-specific ones like at24c64 or 24lc02: 
>> 
>> 24c00, 24c01, 24c02, spd (readonly 24c02), 24c04, 24c08, 24c16,
>> 24c32, 24c64, 24c128, 24c256, 24c512, 24c1024
> 
> No, don't use the generic chip names.  Device tree convention
> is to be specific and prefix the part number with the vendor
> name.  ie. You should be using "at,at24c64", not "24c64".
> 

Ok, here is what I used.  I see the nodes created in /sys/bus/i2c/... 
but I see four of them at address 0x50,0x51,0x52,0x53.  That surprised
me since I only have 3 of them in the device tree.  However, in any case
I did not see a way to read or write them.  In one case I was able to
cat the file "eeprom", but it was only 256 bytes and did not exist for
the other 3 devices.  Here is the section of my device tree ... I do 
see the controller being initialized in dmesg, it is just the read and
write that is eluding me.

One question I did have was within another sample device tree, there was
a comment that "this makes address 0x50 and 0x51"?  Does that mean that
large eeproms are spread over several nodes?  I searched around but
could
not find an example of how to use this at24 to access my E2 from
userspace.

Thanks
Ayman


                        IIC0: i2c@ef600700 {
                                compatible = "ibm,iic-460ex", "ibm,iic";
                                reg = <0xef600700 0x00000014>;
                                interrupt-parent = <&UIC0>;
                                interrupts = <0x2 0x4>;
                                #address-cells = <1>;
                                #size-cells = <0>;

                                at24@50 {
                                        compatible = "at24,at24c128";
                                        reg = <0x50>;
                                };
                                at24@52 {
                                        compatible = "at24,at24c128";
                                        reg = <0x52>;
                                };
                                at24@53 {
                                        compatible = "at24,at24c128";
                                        reg = <0x53>;
                                };
				}