[i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.

[Matt Sealey]

Kumar Gala wrote:
> On May 18, 2007, at 11:35 AM, Scott Wood wrote:
> 
>> device tree isn't worthwhile for i2c devices, why is it worthwhile  
>> for soc devices?  It seems to me that non-probable chips like i2c  
>> devices are precisely the kind of thing that the device tree is  
>> useful for.
> 
> I dont believe anyone has ever said that platform devices have to be  
> in the device tree.  We've been putting them their because we are  
> going to act as the registry for the devices.  The number of devices  
> on all the various Freescale/AMCC/IBM PPC SoCs is likely a very small  
> number compared to all I2C devices.
> 
> For I2C specifically we already have both a dynamic way (kernel cmd  
> line) and static (i2c_board_info) to specify the i2c devices, why do  
> we need yet another?

Linux doesn't but it might be nice to specify this kind of thing in a
way that other operating systems might or may support.

Essentially I think since there are a lot of ways to support I2C
(including bitbanging a GPIO pair), the only real way to support it
is to do something like;

i2c at blah {
	name = "i2c"
	compatible = "mpc52xx-i2c,someother-i2c"
	regs = "address:range"
}

The PURPOSE of this node is not to describe how the i2c controller
works, but to advertise it's presence and AUTHORIZE it's use. If a
node is not in the device tree, a driver author should probably
think twice about using it, especially on chips where pin muxing
is the modus operandii.

If it's in the device tree, then the chances of it being a wildly
crazy type of device external to the board design is probably very
low. If you have an SPI controller on - for example - an MPC52xx
chip, there are only 2 or 3 ways to have it implemented. Either
the inbuilt SPI, a PSC-based SPI, or perhaps using a bunch of GPIOs
to mimic an SPI interface very closely. The same applies to i2c.

You're not ever going to be able to specify in the device tree
exactly how to handle a driver, encompassing both implementation,
bugs in revisions, quirks of board design, but you can specify
for a driver a very accurate, very educated guess on it (any
quirks, bugs or implementation differences would be board/chip
specific, and are easily derived from the other device nodes
like the cpu node, soc node, and so on)

To carry on from the previous paragraph, with that in mind, if
it is an external device (perhaps bridged through another
chip or bus) it will be a child of the external bus. This also
gives a big clue about it's operation. If it is USB, or PCI,
or i2c based device, it will be marked with vendor/device/subsystem
ids or even an i2c slave address. Also very, very big clues.

(the only way you can accurately do all of the above and take
out all of the guesswork, is provide the driver in the firmware.
U-Boot and FDT's, you can forget it!)

-- 
Matt Sealey <matt at genesi-usa.com>
Genesi, Manager, Developer Relations