Re: [RFC][PATCH] SPI subsystem

[Mark Underwood]

--- David Brownell <david-b@xxxxxxxxxxx> wrote:

> > _Only_ the core uses the work queue. This is what
> > happens: 
> >  
> > 1) SPI device driver creates message. 
> > 2) SPI device passes this message to the core. 
> > 3) The core puts this message on the work queue. 
> > 4) When the controller is ready to receive the
> next
> > message the message is passed to the adapter
> driver. 
> >  
> > The work queue is used to isolate and serializes
> the
> > transfer calls from the SPI driver to the adapter.
> 
> I see what's going on.  You're assuming there even
> IS a core!
> 
> Where I assumed otherwise ... drivers that want a
> workqueue should
> allocate their own.  The cost of that task shouldn't
> be inflicted on
> drivers that are happy just having their IRQ
> handlers start the next
> transfer right from the driver's request queue.  (I
> tend to avoid
> layers -- like a "core" -- unless they're
> unavoidable.  That helps
> code stay smaller, faster, and more comprehensible
> code.)
> 

I think my explanation is getting there! I'll
hopefully post the transfer routines this weekend
which will shine some light on this, but I keep having
to work on other things :( ).
 
The workqueue belongs to an adapter as you _will_ have
several SPI device drivers all trying trying send
messages through that _one_ adapter. Unless you only
allow blocking I/O which I _don't_ want to do then the
core has to handle the fact that _different_ SPI
device drivers will be trying to transfer messages
while the adapter is already in the middle of a
transfer.

ASCII art time :)

SPI device drivers|    Core    |   Adapter driver
----------   msg  |            |
| EEPROM |------> |-           |
----------        | |          |
------------ msg  | | -------  | msg ------
| ETHERNET |----> |-->|Queue|->|---->|xfer|
------------      | | -------  |     ------
---------    msg  | |    ^     |       |
| FLASH |-------> |-     ------|<------- Next/done
---------         |            |

> 
> > > >    You have to
> > > > have such a mechanism as you may have several
> SPI
> > > > devices on an adapter doing asynchronous IO at
> the
> > > > same time (i.e. giving an adapter that is in
> the
> > > > middle of doing work more work).
> > > 
> > > No, you do not "have" to have such a mechanism. 
> You
> > > can look at the USB
> > > stack  for a counterexample.  Both host and
> > > peripheral/gadget side adapter
> > > drivers manage request queues just fine without
> > > requiring such a task.
> > > 
> >
> > First, quoting from urb.c 
> > "Host Controller Drivers (HCDs) place all the URBs
> for
> > a particular endpoint in a queue." 
> > So USB does use queues. 
> 
> Exactly as I wrote ...  the issue isn't having
> request queues.
> The point of the example is that USB doesn't require
> workqueues.
> In fact, they're normally not used by HCDs.
> 

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?

> 
> > > Well, I've repeatedly given examples of cases
> where
> > > that is the
> > > wrong model ... where the devices are associated
> > > with an expansion
> > > card, so any reliance on platform data (that's
> set
> > > up by and coupled
> > > to the baseboard) causes lots of problems.
> > > 
> >
> > I know! I agree that you can't always use the cs
> table
> > as you don't always know what devices are
> connected to
> > it. The problem that I have with your solution is
> how
> > can I deal with a hotplugable adapter? I don't
> know
> > what is bus number will be as I don't know what
> order
> > the adapters will be registered in. How else can I
> > solve this problem?
> 
> A hot pluggable adapter is going into some bus, and
> its driver will
> be bound through that bus.  Its probe routine will
> then create and
> register the "struct spi_master".  Output of that
> step includes the bus
> number assigned to the adapter ... which is pretty
> much The Linux Way,
> I can't think of a bus that works any other way.
> 

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 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? 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.

> 
> > > OR ... for the very common case that the
> hardware
> > > supports such things
> > > directly, you could also add some fast paths. 
> So
> > > folk wanting quick
> > > audio control, or sensor access, could get that.
> 
> > > 
> >
> > I'm not quite sure what your trying to achieve
> here.
> 
> Trying to derail some confusion of yours,
> unsuccessfully.  :(
> 
> The original observation was just that fast pathing
> _could_ be done
> that way.  I'd hope to avoid needing it, but
> experience suggests it's
> good to explore that design space before settling on
> one approach.
> 

I agree. The problem is, as far as I can see, every
message will have to be placed in a queue and then
passed to an adapter if several devices are going to
be living on the same adapter.

> 
> > > SPI over PCI is reasonably exotic.  Seems to me
> as
> > > if the best way
> > > to solve that kind of problem would involve
> > > specialized SPI-over-PCI
> > > code, matching that one board.
> >
> > No, no, no and no! For a start many manufactures
> > producing SPI devices don't have a OMAP board to
> test
> > there device but they all have a PC :)
> 
> Actually they can use any of hundreds of different
> Linux-equipped
> embedded boards.  Their _target_ environment is
> rarely a PC, and that
> means most of the development cycle won't run there
> either.  Ergo the
> framework shouldn't be stretching _too_ much to
> handle issues that
> only appear with one particular vendor's PCI-based
> eval hardware.

OK.

> 
> 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!).

> 
> > > > Not if you treat GPO pins as chip selects and
> let
> > > > the adapter abstract them for you :).
> > > 
> > > That assumes the GPIO pin is being used as a
> chip
> > > select, not as an input or output.  :)
> >
> > The point is that you can pass GPIO pins and
> routines
> > to handle them to the adapter (after first setting
> > them to output) as platform data this means that
> you
> > don't have to do any nasty platform specific hacks
> in
> > the SPI device driver, which can only be a good
> thing :).
> 
> Sure, I've certainly done that.  And that'd be the
> best way 
> to build a bitbanging SPI adapter too ... every
> platform
> will bang the bits differently (GPIOs, parport,
> etc).

More common ground :)!

Mark

> 
> - Dave
> 
> 
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/