"cell-index" vs. "index" vs. no index in I2C device nodes

[Grant Likely]

On Thu, Jun 5, 2008 at 12:27 PM, Josh Boyer <jwboyer at linux.vnet.ibm.com> wrote:
> On Thu, 05 Jun 2008 11:25:23 -0500
> Timur Tabi <timur at freescale.com> wrote:
>
>> Josh Boyer wrote:
>>
>> > And it does.  It does so by the unique "regs" properties and
>> > unit-names.  You can assign the index that the i2c subsystem needs
>> > based on probe order, like I already said.
>>
>> The probe order is not sufficient on platforms that specifically enumerate their
>> I2C (or whatever) devices.  For instance, in order to do audio playback on an
>> MPC8610, SSI1 needs to use DMA channel 0.  The SSI driver specifically needs to
>> find the register addresses for DMA channel 0.
>
> I don't understand this statement.  Are your I2C macros hot-pluggable?
> Can you dynamically add/remove an I2C engine on your hardware somehow?
> Are you mucking about with the DTB and randomly moving around the I2C
> node blobs so they probe order differs from boot to boot?
>
> If not, then the probe order will be static for every boot.  You can
> assign the index using a static int that is incremented after each node
> is discovered and the ordering of the devices will never change.  Can
> you explain why something like that isn't possible or sufficient?
>
> (And I'm talking about I2C, not DMA.  I don't care about DMA because
> this conversation will go off into the weeds if we start talking about
> cell-index and every possible device out there.)

I need to disagree here.  Behavior should never be dependent on device
tree order.  It should be absolutely fine for devices to be probed in
a different order and different bus ids to be assigned.

In Timur's case, it is absolutely appropriate to use cell-index and/or
a phandle to make sure it gets the correct DMA registers (which is
what cell-index is intended to solve).  It is not appropriate to
depend on that same number to also be the logical i2c bus number.

Cheers,
g.
>
> josh
>



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