> > Doesn't look particularly evil, except I don't much > like the notion of > > needing a "stack" if it's not being used > like an MFD where numerous > > functions are accessed concurrently, > better IMO to just have each function's driver bind exclusively to the chip > (and > drive it in the > > mode it supports -- SPI, GPIO etc). > > SPI and GPIO are not the only modes that > this hardware can be programmed
I know; ergo the "etc". This is common for serial engines. Many have enough flexibility to hook up to several flavors of audio codec too. > to behave in. In future, other functions may be added > as needed. And each one would have its own driver. > I thought it would be best to keep the > shared stuff reusable. The way I've seen that done in the past is to keep the register decls clean enough so most drivers use them directly ... and in a few cases, provide some library code (if there is a a good reason to share any logic). (But it often turned out that the functions couldn't share much beyond the register layouts, since behaviors of each function differ so widely. > > there's not a > > thing "virtual" about this. _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
