Hi Grant, Thanks for the feedback, I will send out an updated v2 with the proposed changes.
[...] >> +EXPORT_SYMBOL(ti_ssp_open); > > I'm not thrilled with the ti_ssp_open()/ti_ssp_close() usage model. > It appears that the usage model is the board code registers an pile > of platform_devices, one for the ssp, and one for each of the > behaviours on top of it. Then the various driver instances have to > figure out how to find each other and whether or not they are related. > Am I correct? > > Rather than doing an end-run around the Linux driver model, I strongly > recommend using the model to solve your problem. Register only the > ssp platform_device in the board support code and pass it data about > the intended behaviour (via platform data). When it gets probed, it > can then register additional platform devices which will get probed by > the requested driver. That way the specific ssp device instance data > can be passed reliably to the spi/i2c/whatever driver without any > ambiguity, without any uncertainty about whether a port is 'busy', and > without the need of these open/close routines. > > (Hint: The trick is to set the platform_device's pdev->dev.parent > pointer to make use of the Linux device model's hierarchy). I am not very thrilled with this approach either :-) I had looked at a few other instances where something similar was being done (spi, i2c, mdio, etc.), but felt that defining a new bus type would be an overkill for this. For reference, could you please point me to some other place where something similar is being done? Regards Cyril. _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
