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.
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.
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.
I don't know when I would ever do this. The two SSI devices are completely independent. Why would I bind them together into one "device"?
If there is no use case for binding them together, then you're right. The current binding is probably just fine. I cannot comment on whether or not it will be used that way by platform designers.
Although the 8610 has two SSI devices, the reference board we ship only has one wired up. I have a prototype board in the lab that has both wired up, but even then, I don't think I can get the two SSIs synchronized in any meaningful fashion. Mark suggested a technique, but even if I could get that to work, the driver code would need to be rewritten to handle two SSI devices in concert. In short, it might be theoretically possible, but I'm not going to try to make it work.
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.