> On 28.03.2015, at 05:09, Stephen Warren <swarren@xxxxxxxxxxxxx> 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 situation. 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... -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html