Hi, On Mon, Apr 08, 2013 at 03:59:00PM -0500, Daniel Santos wrote: > My bother & I are working on a project where we're planning on using > these inexpensive Microchip MCP2210 USB to SPI bridge w/ GPIO > devices. Mathew King at Trilithic started a driver and kindly > released it on github (https://github.com/MathewKing/mcp2210-linux), > but he wont be using the chip or developing the driver further, so > I'm picking it up (and with his blessings even! :) However, rather > than a driver written specifically for our product, I would like a > generic or abstract MCP2210 driver that can be re-used by others. So > how do I go about this? I'm not sure you can. There is no standardization wrt USB to SPI bridges, so your device implements a proprietary protocol (even if simple). > I'm still pretty new to Linux device drivers & the device driver > model, so there may be existing abstractions & libraries that I'm > just not yet aware of. We're not planning on changing the USB > vendor/product ID (as I'm sure many users of this chip will opt) and > each or our devices can have different hardware & wirings attached to > the MCP2210. Since SPI devices cannot be auto-configured, we plan to this might cause problems. If everybody has the same idVendor/idProduct pair but functionality is different... ugh > probe as follows: > > * In the USB probe, examine the iProduct string to match our specific > product (maybe iManufacturer as well) and if it matches, to bind to > the device. no, you want to match idVendor and idProduct. No need to match strings. > * The MCP2210 has 9 GP pins that can each be used as either an SPI > chip select, GPIO or a "dedicated function" (power LED, interrupt > input line, etc.). Once bound, we can examine the "power-up chip > settings" (section 3.1.7 in the datasheet -- > http://ww1.microchip.com/downloads/en/DeviceDoc/22288A.pdf) and treat > that as the specification as to how each GP pin is used in this > device. oh, so this is actually a multifunction device. What you might be looking for is a core driver which registers itself with the MFD layer (drivers/mfd) and exposes clients based on some parameters passed to it through e.g. pinctrl framework. You can have at least three children: . an SPI bus . a GPIO/IRQ chip . LED Your core driver would instantiate each of those children devices based on what's the requested state of the pin. > * Finally, retrieve the (previously stored) data from the 256 bytes > of user non-volatile EEPROM. On this, we plan to store the device > information that each of the GP pins configured for SPI CS lines are > connected as well as the use for any GPIO lines. (Pins configured > for "dedicated function" need no other information.) is this mandatory, or something you decided to do ? If it's mandatory to program pin assignment like that, then you can very easily figure out how to use that information to instantiate proper children during your core driver's probe routine. If it's not mandatory, then it gets tricky to support multiple users. Can users write whatever they want to EEPROM or is there a specified format ? In any case, there are ways to make it work, just some are easier to code then the others ;-) -- balbi
Attachment:
signature.asc
Description: Digital signature
