Date: Mon, 20 May 2019 09:32:06 -0700 From: Adrian Chadd <adrian.chadd@gmail.com> To: Ian Lepore <ian@freebsd.org> Cc: Mori Hiroki <yamori813@yahoo.co.jp>, Emmanuel Vadot <manu@bidouilliste.com>, "freebsd-mips@freebsd.org" <freebsd-mips@freebsd.org> Subject: Re: spigen problem Message-ID: <CAJ-VmomaYZ2cLWPMDrjuMJt21ZQnCda50kvSsXX-MOUKvf06Mw@mail.gmail.com> In-Reply-To: <14cc3dfbfc7d7eb317129da8fe91485cf77b05af.camel@freebsd.org> References: <1991993923.530828.1556558314174.JavaMail.yahoo.ref@jws704008.mail.kks.yahoo.co.jp> <1991993923.530828.1556558314174.JavaMail.yahoo@jws704008.mail.kks.yahoo.co.jp> <22b68b094cbe7ab1b07673e43f6473906bd2d648.camel@freebsd.org> <20190429195750.409e9d13aea2ff1654a20d3c@bidouilliste.com> <c05a6d77563c5d332a108272654ef75f74c88067.camel@freebsd.org> <20190429202357.79ac2d8dba8d0bed1caa8203@bidouilliste.com> <130153476.2287928.1556589558764.JavaMail.yahoo@jws700105.mail.ssk.yahoo.co.jp> <CAJ-Vmo=dHVde2Ojqj=wOCJFp=2-iQtcOyuoDRy=6Smbq0_qKEA@mail.gmail.com> <ab39bb99ac13541ced71df599430ae9f87bf1af6.camel@freebsd.org> <CAJ-Vmo=SFcLx8fXFkvSAB9nDqMEUDNHO40x2eavTFjv3p-zqRw@mail.gmail.com> <14cc3dfbfc7d7eb317129da8fe91485cf77b05af.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 May 2019 at 07:43, Ian Lepore <ian@freebsd.org> wrote: > > On Sun, 2019-05-19 at 23:36 -0700, Adrian Chadd wrote: > > On Sun, 19 May 2019 at 09:41, Ian Lepore <ian@freebsd.org> wrote: > > > > > > On Sun, 2019-05-19 at 09:03 -0700, Adrian Chadd wrote: > > > > hi! > > > > > > > > this looks ok to me. I'll go commit this tonight. > > > > > > > > > > > > -a > > > > > > > > > > I actually think it's horrible and we should fix the real problem > > > of > > > supporting hardware that can only do unidirectional > > > transfers. But, > > > doing so is a pretty big job. I've got some ideas on it, but it's > > > not > > > something that's going to get finished in a week or two. > > > > Do you mind if I commit this for now anyway? That at least unblocks > > Mori to do other interesting hacks. > > > > What are your ideas? > > > > > > Sorry, I should have been more specific that my whining didn't amount > to a blocking request, because I just don't have the spare time right > now to even try to address the underlying problem. > > There probably should have been a rule for spi from day one that the > controller driver has to supply a dummy buffer if the caller doesn't > supply a buffer for one of the directions and the controller must do > bidirectional transfers (like if dma is involved). Instead we went the > other way and said callers always must supply bidirectional buffers > even though the case of using both input and output data in one > transfer is exceedingly rare. > > I think a minimal-changes idea that may work is to say that the callers > must supply a buffer for both directions like they do now, but they are > allowed to set either the tx or the rx length to zero to provide a clue > to the controller driver that a transfer in that direction isn't needed > if the hardware can't do it (or if not doing it speeds things up or > makes things easier). We still have to examine and change every > existing controller driver, but the changes would be minimal. Hi! Ok. That makes sense. I can make the AR71xx SPI controller do this with little effort. I don't think we have a lot of SPI drivers in the tree though, so yeah, hopefully it shouldn't be too bad. I think establishing that moving forward as an SPI driver requirement would be great. That way we don't accumulate extra debt. -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomaYZ2cLWPMDrjuMJt21ZQnCda50kvSsXX-MOUKvf06Mw>