SPI, _sz fields in struct spi_command

Fri Feb 22 00:05:34 UTC 2013

On Thu, 21 Feb 2013 16:17:55 -0700
Ian Lepore <ian at FreeBSD.org> wrote:

> On Fri, 2013-02-22 at 00:59 +0200, Aleksandr Rybalko wrote:
> > On Thu, 21 Feb 2013 15:39:45 -0700
> > Ian Lepore <ian at FreeBSD.org> wrote:
> > 
> > > On Fri, 2013-02-22 at 00:02 +0200, Aleksandr Rybalko wrote:
> > > > On Thu, 21 Feb 2013 17:30:03 +0100
> > > > Bernd Walter <ticso at cicely7.cicely.de> wrote:
> > > > 
> > > > > On Thu, Feb 21, 2013 at 10:21:00AM -0500, Patrick Kelsey
> > > > > wrote:
> > > > > > >On Thu, Feb 21, 2013 at 9:30 AM, Aleksandr Rybalko
> > > > > > ><ray at freebsd.org> wrote:
> > > > > > >> On Thu, 21 Feb 2013 02:44:33 +0100
> > > > > > >> Bernd Walter <ticso at cicely7.cicely.de> wrote:
> > > > > > >>
> > > > > > >> On Thu, Feb 21, 2013 at 02:26:55AM +0200, Aleksandr
> > > > > > >> Rybalko wrote:
> > > > > > >> > 2. teach consumers to give only correct numbers (very
> > > > > > >> > nice we have only two SPI devices in tree)
> > > > > > >> >
> > > > > > >> > After that we will be able to make drivers for some
> > > > > > >> > (potential) devices which will require bidirectional
> > > > > > >> > communication. And controllers which can't do that,
> > > > > > >> > will just report error in that. I believe peoples
> > > > > > >> > thinks before attach such devices to controllers, so
> > > > > > >> > we will not have such incompatibility.
> > > > > > >>
> > > > > > >> I don't think there are many devices requiring RX/TX at
> > > > > > >> the same time.
> > > > > > >
> > > > > > > Anyway, we will be able to do that, and we don't care now
> > > > > > > because don't have such drivers yet.
> > > > > > >
> > > > > > 
> > > > > > Taking the view that "RX/TX at the same time" means that one
> > > > > > wants to send meaningful data to the slave device at the
> > > > > > same time one is interested in what data is returned during
> > > > > > that transmission, there are such devices in use out
> > > > > > there.  Linear Technologies has several ADCs, such as the
> > > > > > LTC2446, for which you obtain the previous conversion
> > > > > > result while sending the configuration bits for the next
> > > > > > conversion to be performed.
> > > > > 
> > > > > Forgot about ADC with channel selection.
> > > > > 
> > > > > > Although this is slightly out of focus for the specific
> > > > > > issue originally raised, while on the topic of things that
> > > > > > need to get done on SPI in real systems, there are also
> > > > > > devices out there that require specific data or some number
> > > > > > of clocks to be provided while chip select is deasserted.
> > > > > > One example of the former is the LTC2404, which is a
> > > > > > multichannel ADC for which the input channel for the next
> > > > > > conversion is selected by the last four bits clocked in
> > > > > > *before* chip select is asserted. One example of the latter
> > > > > > is the spec for SPI access to MMC/SD cards, which requires
> > > > > > a certain number of clocks to be applied with chip select
> > > > > > deasserted in order to initialize the card. If you ever
> > > > > > find yourself wondering why an SPI software interface
> > > > > > provides independent bus acquisition and chip select
> > > > > > control, the reason is to support these types of devices.
> > > > > 
> > > > > With many ADC you also want probing support.
> > > > > Assign CS and GPIO-read MISO for ready without clocking.
> > > > > Some flash chips also work this way.
> > > > > Not sure if AT45DB support this and how our driver works.
> > > > > With own projects I usually ask AT45DB about ready state by
> > > > > transfering a status word.
> > > > > 
> > > > > -- 
> > > > > B.Walter <bernd at bwct.de> http://www.bwct.de
> > > > > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD
> > > > > Rechner uvm.
> > > > 
> > > > Guys, I don't said it will not be supported. :)
> > > > I said drivers of controllers who can't will return error in
> > > > that case, but other might be ok.
> > > > 
> > > > So, conclusion: go-go-go ray! do it please!
> > > > :-D
> > > > 
> > > 
> > > One other little thought to consider... since tx and rx size must
> > > be the same if they're both non-zero, then could we change to
> > > having a single io_size field, and pass a NULL pointer for rx or
> > > tx buffer if that part of the transfer isn't needed?
> > > 
> > > -- Ian
> > > 
> > > 
> > 
> > Yeah, very-very good idea! That how my uncommited driver for i.MX515
> > SPI works :)
> > 
> > Objections?
> > 
> > WBW
> 
> So just to be clear... if a device driver passes a NULL tx pointer to
> the controller driver, it's saying "My device doesn't care what it
> receives during this transfer."  If the device needs zeroes or ones
> then the buffer full of them has to be provided, right?

One letter will change whole world :-D
You said:
if (tx == NULL) { drain_rx_to_dev_null(); }

cmd_sz - how much to transfer;

cmd_tx - TX buffer pointer, or NULL (NULL mean "transmit anything you
like or use /etc/master.passwd for that " :) )

cmd_rx - RX buffer pointer, or NULL (NULL mean "I will not read that
sucks after transfer, read it if you want" )

Same with data_sz, data_tx, data_rx.

> 
> I'm thinking for the controller that does dma, this simplifies things
> down to making a bus_dmamem_alloc() call (which is fast these days
> because of the zone allocator) and it doesn't bother to set the
> contents of that buffer to anything before starting the dma.

Think it will be ok if we alloc one page on start (for those who need
it) and then realloc to bigger block if somebody request.

> 
> -- Ian
> 
> 

Thanks Ian! Thanks Warner!

WBW
-- 
Aleksandr Rybalko <ray at freebsd.org>