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.) josh _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev