On Tue, Apr 19, 2016 at 4:41 PM, Patrick Kelsey <pkel...@freebsd.org> wrote:
> > > > On Tue, Apr 19, 2016 at 4:38 PM, Adrian Chadd <adrian.ch...@gmail.com> > wrote: > >> On 19 April 2016 at 13:37, Patrick Kelsey <pkel...@freebsd.org> wrote: >> > >> > >> > On Tue, Apr 19, 2016 at 4:21 PM, Ian Lepore <i...@freebsd.org> wrote: >> >> >> >> On Tue, 2016-04-19 at 13:17 -0700, Juli Mallett wrote: >> >> > Patrick Kelsey offered an mmcspi driver for FreeBSD, but nobody >> >> > seemed >> >> > interested. I know of one proprietary branch of FreeBSD using it. >> >> > You might poke him if you want to know how he dealt with this, and if >> >> > you want to commit his driver. >> >> > >> >> >> >> Patrick is a committer, maybe he should just commit it. :) >> > >> > >> > What I believe originally held up that driver being committed (by >> others - >> > this was before my commit bit) was that I relied on some out-of-tree >> spibus >> > changes Luiz had made (as I recall, mainly being able to reserve the >> SPI bus >> > for multiple transactions), and getting those into the tree would have >> > required updating/testing other existing SPI drivers, based on feedback >> I >> > received at the time. All I had was the RB450G that I developed and >> tested >> > the driver with, so I really couldn't address that issue, and then work >> took >> > me in some other direction entirely. Some or all of these spibus >> changes >> > that I relied on might now be in the tree, I'm not sure offhand. I am >> sure >> > though that a huge stack of other things I need to get through has >> > chronically kept me from updating that driver to current and retesting. >> > >> > When I wrote that driver, I put a lot of effort into testing it against >> as >> > many different cards as I could obtain at the time - I believe 30 or so >> in >> > total, all the details are in the code that was posted to the list back >> > then. I encountered a number of strange/unexpected behaviors in that >> set of >> > cards, and all of that hard-won knowledge is in that driver, including a >> > much less complex fix for a shifted-response-data issue than you will >> see if >> > you look at the Linux mmcpsi driver (as I recall, the Linux driver has >> code >> > to arbitrarily bit-shift card response data, and to detect when that >> should >> > be done, but it turns out that can be avoided entirely by inserting idle >> > cycles in the right place when sending the command). >> >> Well, we should add the SPI bus reservation code and churn stuff as >> needed. I think that'd be a great addition. >> >> Do you have a patchset somewhere? >> >> > > Just going from memory here - there is what I posted to the list, then at > some point Luiz took a stab at updating it to then-current (I should have a > copy of those somewhere - not sure where else they went, if anywhere), and > beyond that, I think there's a harmless but unnecessary conditional in the > original code that could be removed. > > > For reference, my original patchset and the work-in-progress update Luiz sent me a few months later are now available at https://people.freebsd.org/~pkelsey/mmcspi/ -Patrick _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
