--- David Brownell <[EMAIL PROTECTED]> wrote: > > Date: Wed, 7 Sep 2005 19:38:43 +0100 (BST) > > From: Mark Underwood <[EMAIL PROTECTED]> > > ... > > > > I see several posabiltiys of how SPI devices could > be > > connected to an adapter. > > Certainly, and all are addressed cleanly by the kind > of > configuration scheme I showed.
And by my scheme :) > > > > 1) All SPI devices are hardwired to the adapter. I > > think this would be the most common. > > For custom hardware, not designed for expansion, > yes. Zaurus Corgi > models, for example, keep three SPI devices busy. > > But in that category I'd also include custom > hardware that happens to > be packaged by connecting boards, which is also the > territory of #2 or > #3 below. "Hard wired" can include connectors that > are removable by > breaking the warranty. :) > > > > 2) Some SPI devices are hardwired and some are > > removable. > > Development/Evaluation boards -- the reference > implementations in most > environments, not just Linux -- seem to all but > universally choose this > option (or, more rarely, #3). There might be some > domain-specific chips > hardwired (touchscreen or CAN controller, ADC/DAC, > etc), but expansion > connectors WILL expose SPI. > > That makes sense; one goal is to support system > prototyping, and it's > hard to do that if for any reason one of the major > hardware connectivity > options is hard to get at! > > > > 3) All SPI devices are removable. > > This is common for the sort of single board > computers that get sold > to run Linux (or whatever) as part of semicustom > hardware: maybe not > much more than a few square inches packed with an > SOC CPU, FLASH, RAM, > and expansion connectors providing access to a few > dozen SOC peripherals. > (There might be 250 or so SOC pins, with expansion > connectors providing > access to some big portion of those pins ... > including some for SPI.) > > It'd be nice to be able to support those SBCs with a > core Linux port, > and then just layer support for addon boards on top > of that without > needing to touch a line of arch code. And > convenient for folk who > are adding value through those addons. :) > And with my subsystem you don't can to change any arch code, yay again! :) > > > > When you plug a card in you use > > spi_device_register to add that device to the > system > > and when you remove the card you call > > spi_device_unregister. You can then do the same > for a > > different card and at no time have you changed the > > declaration of the controller. > > That implies whoever is registering is actually > going and creating the > SPI devices ... and doing it AFTER the controller > driver is registered. > I actually have issues with each of those > implications. But how can you have a device that has no connection to the system (i.e. no registered adapter) :(. Why would you want to add SPI devices to adapters which aren't yet in the system? > > However, I was also aiming to support the model > where the controller > drivers are modular, and the "add driver" and > "declare hardware" steps > can go in any order. That way things can work "just > like other busses" My subsystem does that. Once you have registered the core layer you can add SPI device drivers before or after registering SPI devices the only restriction is the you have to register a SPI adapter before registering any SPI devices which use that adapter. I think this is sensible as otherwise you have to keep a list of all SPI devices that have been registered and didn't have an adapter at that time and go through this list every time you register an adapter. This sounds like putting the cart before the horse ;). > when you load the controller drivers ... and the > approach is like the > familiar "boot firmware gives hardware description > tables to the OS" > approach used by lots of _other_ hardware that > probes poorly. (Except > that Linux is likely taking over lots of that "boot > firmware" role.) > > > > > I'll post a refresh of my patch that seems to me > to be > > > a much better match for those goals. The > refresh includes > > > some tweaks based on what you sent, but it's > still just > > > one KByte of overhead in the target ROM. :) > > Grr. I added sysfs attributes and an I/O utility > function, > and now it's a bit bigger than 1KByte. Especially > with > debugging enabled, it's nearer 1.5KB. The curse of > actually > trying to hook up to hardware and its quirks. :( > I have built your spi_init.c for an ARM946EJS and I get a .ko object of 5.1K this compares to my spi_core, with transfer routines, of 10.6. I think there is still some fat to trim from my core layer so I might be able to get it smaller :). > > > OK. I will post an updated version of my SPI > subsystem > > within the next few days with the transfer stuff > added > > and maybe the interrupt and GPO abstraction as > well. > > OK. > > > > I haven't seen any replies to my SPI patch :( did > you > > reply to it? > > No, I was going to sent it when I sent that refresh; > it's helped > focus my thoughts a bit. :) Glad to help :). > > Several of the comments (like "get rid of algorithm > layer!") you'll have > heard before in response to the RFC from MontaVista. > It seems both > approaches are still trying to make SPI seem like > I2C, and not taking > the opportunity to _fix_ very much of the I2C > oddness. OK. The only reason I had keept the algo layer is for bitbashing, but thinking about it the pin set/clear routines could be passed in as platform data. So I'll remove the lago layer, cheers for the input. Just to let you know I have been, my testing my subsystem with a simple eeprom driver and a SPI network device. So my subsystem is being tested under heavy loads with transfers in size from 32K to 2 bytes! Mark > > - Dave > > - > To unsubscribe from this list: send the line > "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at > http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
