On Fri, 23 Sep 2016 10:48:11 +0300 Maxime Ripard <[email protected]> wrote:
> On Fri, Sep 23, 2016 at 04:03:57AM +0300, Siarhei Siamashka wrote: > > On Thu, 22 Sep 2016 23:52:52 +0200 > > Danny Milosavljevic <[email protected]> wrote: > > > > > Hello, > > > > > > when using SPI on Allwinner A20 with CPOL=1 and CPHA=1 with Linux > > > 4.8.0-rc6 Psychotic Stoned Sheep I see a weird dip in the beginning > > > (which also confuses the slave) on the SCLK line right when SSEL goes low > > > - see attachment. > > > > > > The lines are, starting from the top, SCLK MOSI MISO SSEL. > > > > > > I'm using spidev. > > > > > > Did anyone see this problem before? > > > > Hi, > > > > I'm not sure, but something like this might be somehow related: > > https://patchwork.kernel.org/patch/7960811/ > > > > As a random thing to check, I would also advise to verify the > > pull-up/pull-down settings for the SCLK pin. > > > > And maybe as another test, change the driver to automatically > > drive the SSEL pin instead of doing this manually. > > We cannot do that Well, of course we can do that. At least for the troubleshooting purposes. And it's somewhat better than giving up and just going to cry in a corner ;-) > this would break the framework's expectations with > the behaviour you're suposed to have in set_cs (which is why we ended > up using the manual mode), and especially that it's supposed to happen > right away and control the logical level of the CS line. My understanding is that the framework is probably designed this way in order to be able to use any *arbitrary* GPIO pin for the chip select role. But the SPI controller itself can take care of the *dedicated* chip select pin and assert/deassert it before/after doing SPI message transfers. Patching the driver (again, only as a troubleshooting experiment) should be relatively easy: the code that changes the CS pin state just needs to be commented out and the manual mode disabled. My random guess about what might be happening is the following: The SoC has a weak pull-up for the SCLK pin. And the slave device has this pin in a high impedance state when the chip select pin is deasserted. But after the SPI driver manually asserts the chip select pin, the slave device probably changes the SCLK pin to a strong pull-down state, overpowering the SoC pull-up for a while. Then the SPI message transfer gets started by the SPI driver and the SPI controller starts driving the SCLK pin for real. Again, this is only a random guess and it definitely needs to be verified. Only Danny is lucky enough to have the right tools and a perfectly reproducible test case. We can think about a proper fix (compatible with the framework expectations) after we figure out what is actually going on. -- Best regards, Siarhei Siamashka -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
