Date: Thu, 21 Feb 2013 16:17:55 -0700 From: Ian Lepore <ian@FreeBSD.org> To: Aleksandr Rybalko <ray@FreeBSD.org> Cc: freebsd-arm@FreeBSD.org, Bernd Walter <ticso@cicely7.cicely.de>, ticso@cicely.de, freebsd-mips@FreeBSD.org Subject: Re: SPI, _sz fields in struct spi_command Message-ID: <1361488675.1185.42.camel@revolution.hippie.lan> In-Reply-To: <20130222005926.2aa6db7f.ray@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1361488675.1185.42.camel>