FDT bindings for I2C devices

FDT bindings for I2C devices

[Wolfgang Grandegger]

Hello,

is it forseen to define and configure devices like RTC, temperature 
sensors or EEPROM on the I2C bus with the Flat Device Tree? If yes, how 
would the DTS entries look like?

Thanks.

Wolfgang.

Re: FDT bindings for I2C devices

[Grant Likely]

On 10/19/07, Wolfgang Grandegger <wg@grandegger.com> wrote:
> Hello,
>
> is it forseen to define and configure devices like RTC, temperature
> sensors or EEPROM on the I2C bus with the Flat Device Tree? If yes, how
> would the DTS entries look like?

booting-without-of.txt has some information about describing the controller.

Scott Wood made an attempt at defining a device binding for I2C
devices, but it has not been merged into booting-without-of.txt yet.
I've copied what he wrote below.  I would add to his definition the
following:
- If compatible is missing, driver should *not* fall back to the device name.
- 'compatible' list should include the exact device in the form "<mfg>,<part>"

Cheers,
g.

Here's the thread and an excerpt from Scott's original post:

http://patchwork.ozlabs.org/linuxppc/patch?id=11223

+   e2) I2C Devices
+
+   Required properties :
+
+    - reg : Unshifted 7-bit I2C address for the device
+
+   Recommended properties :
+
+    - compatible : The name of the Linux device driver that
+      handles this device.  If unspecified, the name of the
+      node will be used.
+    - interrupts : <a b> where a is the interrupt number and b is a
+      field that represents an encoding of the sense and level
+      information for the interrupt.  This should be encoded based on
+      the information in section 2) depending on the type of interrupt
+      controller you have.
+    - interrupt-parent : the phandle for the interrupt controller that
+      services interrupts for this device.
+
+   Example :
+
+       rtc@68 {
+               device_type = "rtc";
+               compatible = "ds1374";
+               reg = <68>;
+               interrupts = <13 8>;
+               interrupt-parent = <700>;
+       };

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: FDT bindings for I2C devices

[Guennadi Liakhovetski]

(it was suggested to deprecate -embedded in favour of -dev, so, added to 
cc:)

On Fri, 19 Oct 2007, Grant Likely wrote:

> On 10/19/07, Wolfgang Grandegger <wg@grandegger.com> wrote:
> > Hello,
> >
> > is it forseen to define and configure devices like RTC, temperature
> > sensors or EEPROM on the I2C bus with the Flat Device Tree? If yes, how
> > would the DTS entries look like?
> 
> booting-without-of.txt has some information about describing the controller.
> 
> Scott Wood made an attempt at defining a device binding for I2C
> devices, but it has not been merged into booting-without-of.txt yet.
> I've copied what he wrote below.  I would add to his definition the
> following:
> - If compatible is missing, driver should *not* fall back to the device name.
> - 'compatible' list should include the exact device in the form "<mfg>,<part>"

There are also already working examples in powerpc: look at 
arch/powerpc/sysdev/fsl_soc.c at the i2c_devices[] array and how it is 
used below. There are also some .dts examples upstream already, e.g., 
arch/powerpc/boot/dts/kuroboxH[GD].dts. There also have been more patches 
recently to add further devices to the table and further .dts entries. 
Notice however, it would be good to move the generic code out of 
fsl_soc.c, as there seems to be increasing interest in describing i2c 
buses in .dts.

Thanks
Guennadi
---
Guennadi Liakhovetski

Re: FDT bindings for I2C devices

[Wolfgang Grandegger]

Hi Guennadi,

Guennadi Liakhovetski wrote:
> (it was suggested to deprecate -embedded in favour of -dev, so, added to 
> cc:)
> 
> On Fri, 19 Oct 2007, Grant Likely wrote:
> 
>> On 10/19/07, Wolfgang Grandegger <wg@grandegger.com> wrote:
>>> Hello,
>>>
>>> is it forseen to define and configure devices like RTC, temperature
>>> sensors or EEPROM on the I2C bus with the Flat Device Tree? If yes, how
>>> would the DTS entries look like?
>> booting-without-of.txt has some information about describing the controller.
>>
>> Scott Wood made an attempt at defining a device binding for I2C
>> devices, but it has not been merged into booting-without-of.txt yet.
>> I've copied what he wrote below.  I would add to his definition the
>> following:
>> - If compatible is missing, driver should *not* fall back to the device name.
>> - 'compatible' list should include the exact device in the form "<mfg>,<part>"
> 
> There are also already working examples in powerpc: look at 
> arch/powerpc/sysdev/fsl_soc.c at the i2c_devices[] array and how it is 
> used below. There are also some .dts examples upstream already, e.g., 
> arch/powerpc/boot/dts/kuroboxH[GD].dts. There also have been more patches 
> recently to add further devices to the table and further .dts entries. 
> Notice however, it would be good to move the generic code out of 
> fsl_soc.c, as there seems to be increasing interest in describing i2c 
> buses in .dts.

Ah, nice. I checked a few dts files but obviously missed the one for the 
kuroboxH[GD].

Thanks,

Wolfgang.

Re: FDT bindings for I2C devices

[Scott Wood]

Grant Likely wrote:
> Scott Wood made an attempt at defining a device binding for I2C
> devices, but it has not been merged into booting-without-of.txt yet.
> I've copied what he wrote below.  I would add to his definition the
> following:
> - If compatible is missing, driver should *not* fall back to the device name.
> - 'compatible' list should include the exact device in the form "<mfg>,<part>"

Those are good recommendations for any node, but I don't see why i2c in 
particular should mandate it.

-Scott

Re: FDT bindings for I2C devices

[Grant Likely]

On 10/23/07, Scott Wood <scottwood@freescale.com> wrote:
> Grant Likely wrote:
> > Scott Wood made an attempt at defining a device binding for I2C
> > devices, but it has not been merged into booting-without-of.txt yet.
> > I've copied what he wrote below.  I would add to his definition the
> > following:
> > - If compatible is missing, driver should *not* fall back to the device name.
> > - 'compatible' list should include the exact device in the form "<mfg>,<part>"
>
> Those are good recommendations for any node, but I don't see why i2c in
> particular should mandate it.

I only mention it because the example given doesn't show that.

g.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195