[PATCH] SPI: bcm2835: move to the transfer_one driver model

Martin Sperl kernel at martin.sperl.org
Sat Mar 28 11:11:59 PDT 2015

> On 28.03.2015, at 05:09, Stephen Warren <swarren at wwwdotorg.org> wrote:
> Can you expand on that a bit more?
> Are you planning on implementing code in the driver so it always uses
> GPIO CS even when GPIOs aren't specified in the DT, or disabling those
> optimizations when native CS is in use?

>> So the question is if we should depreciate native chip-selects for this
>> driver with one of those future improvements listed below.
> Only if you can make the driver transparently use GPIO CS mode even when
> no GPIOs are specified in the DT. DT is an ABI, and old DTs need to
> continue to work on newer kernels.
No I think I will just have a case where some optimization only get used
when using gpio - even though it adds a bit of complexity/code to maintain.

The code to alter the pin-mode from ALT1 to OUT is probably more complex
than just adding a "dev_warn" during probe to indicate that it is 
depreciated/no longer recommended and an if statement to discriminate the

If you know how to change the Mode of a pin on the fly, then we can add
that at a some point.

>> As for testing: I have also tried to test with mmc_spi, but I have not
>> been able to make that driver work reliably in any recent kernel
>> versions.
>> Most of the time I see timeouts - and with lots of different SD-cards...
>> IIRC the last time I tested it successfully was with 3.12.
> It'd be great if you could use "git bisect" to track down the change
> that broke this.

The problem is that it is a lot of kernel-versions I would have to test
to figure out why and with the rpi used for compiling the kernel it 
becomes a prohibitive long exercise...

Also I may have a slightly different setup now compared to when I did
the test initially, so this may be the trigger as well. 
Hence I was asking if someone had similar issues/has a working setup 
with an up to date kernel. (Also I think the last time I tried it was
still based on the foundation kernels before an upstream kernel existed)

I will give it a try running an old kernel, but it may take some time...

More information about the linux-rpi-kernel mailing list