Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 1 Mar 2013 00:48:28 +0200
From:      Aleksandr Rybalko <ray@freebsd.org>
To:        Ian Lepore <ian@FreeBSD.org>
Cc:        Aleksandr Rybalko <ray@FreeBSD.org>, Bernd Walter <ticso@cicely7.cicely.de>, freebsd-arm@FreeBSD.org, freebsd-mips@FreeBSD.org, ticso@cicely.de
Subject:   Re: SPI, _sz fields in struct spi_command
Message-ID:  <20130301004828.e0727064.ray@freebsd.org>
In-Reply-To: <1361488675.1185.42.camel@revolution.hippie.lan>
References:  <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <CAD44qMXkFH9iR=ym1XBtD88HRadpGkO=WRYvz5xhAVucEuoLEA@mail.gmail.com> <20130220174449.GB6976@cicely7.cicely.de> <CAD44qMXsdrhuNRbpA1a9ikj4BGffVfhv1WY6hsqCxHwVzQAdsg@mail.gmail.com> <20130221022655.6f693eb6.ray@freebsd.org> <20130221014433.GA12189@cicely7.cicely.de> <20130221163026.dbeb03f9c38de3d24a7ab30f@freebsd.org> <CAD44qMU6-GUDy%2BTUJ1Ndtcy7S42BCeSsFis0dMtj9LDOeDLwGA@mail.gmail.com> <20130221163003.GC12189@cicely7.cicely.de> <20130222000207.d1478231.ray@freebsd.org> <1361486385.1185.38.camel@revolution.hippie.lan> <20130222005926.2aa6db7f.ray@freebsd.org> <1361488675.1185.42.camel@revolution.hippie.lan>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 21 Feb 2013 16:17:55 -0700
Ian Lepore <ian@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@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@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@freebsd.org> wrote:
> > > > > > >> On Thu, 21 Feb 2013 02:44:33 +0100
> > > > > > >> Bernd Walter <ticso@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@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?
> 
> 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.
> 
> -- Ian
> 
> 

Hi hackers!

Instead of implementation, new thoughts is coming :)
Well, after few days of stabilization of ideas I'm beginning new
round of talks. :)

So, two days ago we had discussion with Ian on IRC.
Things we decide:
1. Don't remove current transfer method
2. Add acquire/release methods
3. Add cs control methods
4. Add new transfer method, it will do only one xfer, and as described
previously will have only size/txbuf/rxbuf fields in transfer struct.
Tx and/or rx can be NULL, so even clocking without data possible.
5. Update old transfer method(spibus_transfer) to do:
* acquire
* enable cs
* transfer cmd
* transfer data
* disable cs
* release bus
6. Add some method which will expose hw ability (one direction at a
time, independent cs control, etc.)
7. Maybe some other special methods (Ian said for SD on spi we need
ability to xfer w/o CS asserted)

That how I see new xfer structure: 
struct spi_xfer {
    size_t  size;       /* Transfer size (bytes) */
    void    *tx_buf;    /* Buffer with TX data (NULL to not tx) */
    void    *rx_buf;    /* Buffer for RX data (NULL for ignore) */
};

Simple and clear :)

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130301004828.e0727064.ray>