Re: [PATCH V4 00/19] net: ks8851: Unify KS8851 SPI and MLL drivers

On 4/15/20 5:12 PM, Lukas Wunner wrote:

On Wed, Apr 15, 2020 at 04:51:39PM +0200, Marek Vasut wrote:

quoted

On 4/15/20 4:39 PM, Lukas Wunner wrote:
I reinstated the indirect access, so things did change. Besides, there
performance for the parallel option is back where it was with the old
driver, which is important for me.

Okay, I see.

quoted

quoted

We're using CONFIG_PREEMPT_RT_FULL=y.  I'm sorry for not mentioning this
earlier, I didn't assume it would make such a big difference but
apparently it does.

Do you also have the RT patch applied ?

Yes, the branch I linked to also contains the RT patches.

OK, I see. I am only testing against latest linux-next with no extra
patches. Can you do that as well ?

Here is all you need:
https://git.kernel.org/pub/scm/linux/kernel/git/marex/linux-2.6.git/log/?h=ks8851-v5

quoted

quoted

This is the branch I've tested today:
https://github.com/l1k/linux/commits/revpi-4.19-marek-v4

You seem to have quite a few more patches in that repository than just
this series, some of them even touching the RPi SPI driver and it's DMA
implementation.

Those are just the patches I mainlined, but backported to v4.19.
This branch is based on the Raspberry Pi Foundation's downstream
repository, they still ship v4.19.  Their repo has more performant
drivers for USB, SD/MMC etc. which haven't been mainlined yet.
But the SPI portion is the same as in mainline because I always
submit to mainline and let the patches percolate down to their repo.

Above I linked current linux-next with KS8851 patches applied (plus
fixes for the next version of this series, including the RPi3 DT patch
and config I used to test the SPI version), so please use that.

quoted

quoted

quoted

I used two different drivers -- the iMX SPI and the STM32 SPI -- I would
say that if both show the same behavior, it's unlikely to be the driver.

Hm, so why did it work with the RasPi but not with the others?

I didn't have a chance to debug this yet.

I was just curious if those drivers don't work as well as the one
for the RasPi. :-)  That would be funny because the RasPi is generally
considered a toy in the embedded space and the platforms you've
mentioned are taken more seriously I think.

My guess would be that the SPI in the RPi is just ignoring various
non-critical transmission errors to cater for all the "toy" hardware,
but that's just pure speculation.

[...]