On Thu, Jun 5, 2008 at 12:27 PM, Josh Boyer <[EMAIL PROTECTED]> wrote: > On Thu, 05 Jun 2008 11:25:23 -0500 > Timur Tabi <[EMAIL PROTECTED]> 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. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
