On Wed, Apr 28, 2010 at 7:35 AM, Timur Tabi timur@freescale.com wrote:
On Wed, Apr 28, 2010 at 12:37 AM, Grant Likely grant.likely@secretlab.ca wrote:
Why not? Just have the ssi driver probe routine register the fabric device based on the existence of the codec-handle property. It is the best way to go about things with the data that you've got available, and it is no big deal. The relevant fabric driver can then bind against that. You should probably also stuff the ssi device node pointer into the fabric device of_node pointer.
And then where do I put the board-specific initialization code that's currently in the fabric driver? The programming information for that initialization is not in the device tree.
In the fabric driver; where it is right now. I'm saying *instantiate* the device when the ssi driver gets probed. Use the top level board name when assigning the name so that the correct asoc machine driver gets bound to it.
It sounds to me like you're saying I should take all the code from the fabric driver and shove it into the SSI driver, just so that I can avoid instantiating a platform driver.
Nope.
Keep in mind that asoc likes to have a different struct device for the fabric driver and the SSI nodes, so I would need to manually create a struct device for the fabric device anyway.
You can do it this way too, but this is not what I'm saying.
Linux struct device registrations are cheap, and every struct device has a device_node pointer available. It is totally fine to have both the ssi device and the fabric device point to the same device node if that helps solve your problem of finding references to the right things in each driver. (Just as long as only one of them is an of_platform driver).
But I already have it set up like that. The SSI driver is an OF driver, and the fabric driver is a platform driver. I might be able to move some code from the fabric driver into the SSI driver to make it the fabric driver less obnoxious about scanning the device tree.
I'm just saying move the registration of the machine device out of arch/powerpc platform code and into the ssi driver. Then you've got a reasonable place to pass shared data (either the ssi device node or device instance or name. Whatever you need) to the machine driver.
g.