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

[Adrian Chadd]

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?



-adrian