> > ASCII art time :)> > ASCII also works for English and C, but this is good> too. ;)> > > > > SPI device drivers| Core | Adapter driver> > Or in my terminology, with no core/midlayer> expectation:> > SPI Master | SPI Master> Protocol Driver | Controller Driver> > > ---------- msg | |> > | EEPROM |------> |- |> > ---------- | | |> > ------------ msg | | ------- | msg ------> > | ETHERNET |----> |-->|Queue|->|---->|xfer|> > ------------ | | ------- | ------> > --------- msg | | ^ | |> > | FLASH |-------> |- ------|<------- Next/done> > --------- | |> > And the workqueue usage you're describing (to manage> that queue)> is what I'd call just one of many implementation> strategies; one> that wouldn't be universally appropriate.> > You don't NEED a separate "core" to hold the queue;> the driver> can just as easily manage a list_head itself.> > - A PIO driver running with IRQs blocked wouldn't> need a queue.> (And that might be fine for low volume usage,> since it might> take all of an hour to write and debug.)> > - A DMA driver might build the queue out of DMA> descriptors, so> that the hardware would process many> transactions back-to-back> without needing intermediate attention from the> CPU. (Great> for high volume usage, but likely takes more> than an hour.)> > You don't NEED to allocate a task ("workqueue") to> handle the> movement of requests from the queue to the hardware.> > - Drivers are often written so that the "next"> transaction is> started from an IRQ handler ... it's a lot less> I/O latency> than if you need the workqueue's task to> schedule before that> transaction can start, and better throughput> too.> > That's three more implementation strategies ... ones> that don't need> or want to have a "workqueue" task, and can easily> manage a list_head.> But you want them all to not just have a workqueue,> but not be able> to work unless they interact with it!! Why?>

Thank you! I have seen the light. Yes, I can see nowthat the workqueue should really be in my adapterdriver not the core. The only thing about having awork queue in the core is that it means adapterdrivers don't have to do the sleep for blockingtransfers, but I guess that's just laziness creepingin ;).Thinking about it, for blocking transfers the corecould call the adapters transfer routine and thenstart a wait on completeion. When the message has beensent the adapter would finish the completeion and thecall to the core would then return (I think this ishow the mmc core layer does it). How do you feel aboutthat sugguestion?

How would you feel about having a list head formessages in the adapter structure? I think everyadapter driver would at least need this.

> > > > If you don't have a queue of some sort how do you> > handle the fact that one or more devices will want> to> > send asynchronous messages through one adapter> while> > that adapter is still busy transferring a previous> > message?> > You seem to have been replying to someone else's> posts! The> examples I gave _included_ queues. Queues that> advanced using> IRQs, and didn't need to schedule a workqueue's task> before> starting another transaction.>

Sorry I must have had a blind spot :(.

> > > OK. But you also need to see what else is in the> cs> > table, namely the default level of the cs's. The> issue> > which we have to solve is that all the cs's have> to be> > put into their non-active state before any> transfer> > can be done.> > If you observed the code I sent by, you'll observe> comments about that> issue in the declaration of both "spi_device" and> "spi_board_info".> > There are other protocol tweaks to be dealt with> over time too. As one> person commented off-line, there are multiple> protocols to fit into this> API (SPI, MicroWire, SSI, SSP, and more) that differ> in only minor ways.> The controller driver may need to know about some of> those tweaks in> order to talk properly with a given chip.>

Yes, at some time I was thinking about how you mightcreate a serial bus subsystem that would evenincorporate I2C :O.

> > > If devices are added into a running SPI> > adapter (I mean registration of devices not> physical> > plugging) then how do you know what their idle> state> > is at the beginning (when the first SPI device> does a> > transfer?> > Until someone has to hook up hardware that acts> atypically, it's the> normal SPI convention: chipselect is "active low". > When someone> needs that, I've already identified where to record> "active high".> > > > To me the only solution seems to be to pass> > the idle state of all the devices that will be on> that> > device (be they hardwire, plugged or what ever)> when> > then adapter gets registered which is why I put it> in> > as part of platform data.> > Much like I did with "spi_board_info", but on a> per-chip basis. It's> possible to hook an "active low" chip to one> chipselect while another> uses "active high" signaling. It's just an> inverter. :)> > > > > > I can certainly understand how, say, Philips> might> > > want to support> > > evaluation boards in PC environments. It can> be> > > easier to debug on> > > PCs; not everyone has JTAG tools; and so on.> > > > >> > That's my thinking. Plus I was planning on writing> a> > parallel port bit-banging adapter as a sweetnear> for> > the PC Linux folk and later a SPI MMC driver so> your> > PC could have a MMC slot :) (even old 386's &> 486's> > which don't have USB and thus no card readers!).> > Yes, I expect an SPI bitbanger will be useful to> some folk.> As for MMC ... it'll be interesting to watch that> play out;> won't the mmc_block code need to change?>

I don't know, I would hope not. If the mmc core iscompletely generic then I think I should only have towrite a driver like mmci and not have to change themmc_block or mmc core layers.

> > I attach the latest snapshot of my code. You'll> notice two changes:> (a) suspend/resume calls; this code seems pretty> complete except for> the protocol tweaking options; (b) a new method> that'll be handy> when doing things like hotplugging a card with an> SPI controller> and a few soldered-on SPI devices. (Like that USB> prototype.)