On Tue, Nov 09, 2010 at 10:16:22PM -0800, David Brownell wrote: > > > I thought the point of this device was that a single [SSP] device > > hosted a > > pair of multi-function serial interfaces, with each > > implementing a > > separate function. > > function chosen based on what the board needs. > Codec interface, SPI, GPIO, etc. > > If so, then it makes sense for the > > base driver to > > register child devices of the appropriate kinds. > > I'd normally say board setup registers them; a > "core"driver can't know what children would be needed. > > But the point I was making was about code factoring > not driver setup. When the functions don't have > much commonality, they might as well just write to > the relevant registers instead of expecting to have > a non-register programming interface (of dubious > generality of a "core" driver, but much complexity). > > Easier just to have children use registers directly, > in several similar cases. Less overhead, too.
I guess it depends on how much overlap/interlock there is between the multiple channels. If there is shared context, then that is a stronger argument for a shared api. Cyril, what say you? g. _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
