> > 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. ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
