SPI, _sz fields in struct spi_command

Aleksandr Rybalko ray at freebsd.org
Thu Feb 21 22:59:42 UTC 2013


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
-- 
Aleksandr Rybalko <ray at freebsd.org>


More information about the freebsd-arm mailing list