DomainKey-Signature: a=rsa-sha1; s=sbc01; d=pacbell.net; c=nofws; q=dns;
	h=received:date:from:to:subject:cc:references:in-reply-to:
	mime-version:content-type:content-transfer-encoding:message-id;
	b=pX+JbH+vSD2ML5WdRxC/5oahxh5ssJKCJe7tBqKqXt+3OEuNi0aUEtiL2lJGGlel2
	npByr89MaHaBXS3S+PAYQ==
Date: Thu, 15 Sep 2005 15:14:45 -0700
From: David Brownell <david-b@pacbell.net>
To: linux-kernel@vger.kernel.org, basicmark@yahoo.com
Subject: Re: [RFC][PATCH] SPI subsystem
Cc: dpervushin@ru.mvista.com
References: <20050915192408.7378.qmail@web30311.mail.mud.yahoo.com>
In-Reply-To: <20050915192408.7378.qmail@web30311.mail.mud.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20050915221445.06473C10B9@adsl-69-107-32-110.dsl.pltn13.pacbell.net>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 4982
Lines: 131

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


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


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


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


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

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.


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

- Dave


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