svn commit: r298274 - head/sys/dev/spibus

[Patrick Kelsey]

On Tue, Apr 19, 2016 at 4:41 PM, Patrick Kelsey <pkelsey at freebsd.org> wrote:

>
>
>
> On Tue, Apr 19, 2016 at 4:38 PM, Adrian Chadd <adrian.chadd at gmail.com>
> wrote:
>
>> On 19 April 2016 at 13:37, Patrick Kelsey <pkelsey at freebsd.org> wrote:
>> >
>> >
>> > On Tue, Apr 19, 2016 at 4:21 PM, Ian Lepore <ian at 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