From Zero to FBTFT - How to configure a new kernel about rpi-firmware HOT 10 CLOSED

Hello,

I'm also interested in getting the FBTFT module in a plain raspberry pi kernel.

Regards

from rpi-firmware.

FBTFT is waiting to be include in the official Pi kernel: raspberrypi/linux#836
But there is no SPI DMA support there. I will continue to release a FBTFT kernel until that is resolved.
Maybe this can help you: https://github.com/notro/fbtft/wiki/FBTFT-RPI-overlays

from rpi-firmware.

I am back into looking into the SPI drivers and I guess I will do a "short" patch to fix some low-hanging fruit (especially with regards to latencies) before handling the "bigger" task of adding DMA. But there are some questions around it (especially your requirements/use-cases for long transfers).

I fear that this approach is what will more likely get accepted than a full blown rewrite with lots of new infrastructure to make it DMA only with minimal interrupts... (things like dmaengine would need to get extended,...)

from rpi-firmware.

BTW: if you patch the spi-bcm2835 driver to include also
{ .compatible = "brcm,bcm2708-spi", },
then you can also compile and load that one and it is MUCH cleaner from the code perspective than the 2708 version (and it is already in upstream).

from rpi-firmware.

@msperl

I am back into looking into the SPI drivers and I guess I will do a "short" patch to fix some low-hanging fruit (especially with regards to latencies) before handling the "bigger" task of adding DMA.

Actually I have it on my list to look into spi-bcm2835 and DMA.
raspberrypi/linux has scatter/gather support in dmaengine now: raspberrypi/linux#652
I have looked at a commit for another SPI driver that implemented can_dma, and it didn't look very complicated.

But there are some questions around it (especially your requirements/use-cases for long transfers).

I have contemplated on that, and the transfers can't be too long if there's a touch controller on the same SPI bus.
I haven't done any testing to determine how often the touch controller has to be available to keep smooth handling.
But the fastest SPI display I have seen (@128mhz) does a 300kB update in 25ms.
And if the DMA buffer is max 64kB, and I send 64kB per message, touch should be more than fine.
Latency wise, how much time can I save by doing one message with 4 transfers, versus 4 transfers with one message each?
And will the Pi2 with it's 4 cores help with latencies?

BTW: if you patch the spi-bcm2835 driver to include also
{ .compatible = "brcm,bcm2708-spi", },

I think it's better to change the Device Tree compatible property instead, using an overlay: https://github.com/notro/fbdbi/blob/master/dts/overlays/rpi/hy28aX-overlay.dts#L15
I did that while testing a new I/O path for FBTFT. The SPI DMA driver froze when I sent it a DMA multi transfer message, with only one byte in the first transfer.
CONFIG_SPI_BCM2835 isn't set in the official build though.

from rpi-firmware.

There are a few thing:
You are right: for all practical purposes it is not possible to run than 32k (0xffff seems stupid) and would require multiple adjacent pages in physical space - possible, but hard...
So it seems you will have to have multiple transfers in a spi message one per page.

As for latency for touch: either you separate the transfers into multiple sections (if possible) so that you can interleave calls to query touch, but I guess that could lead to display artifacts like tearing and possibly color mismatches on the "border" - unless you align them on a pixel boundary...

That trick with device-tree is nice - I did not think of that - but under some circumstances it would be helpfull to load multiple devices. But then, maybe we could go the other way: implement a compatibility in the old driver and ask the foundation to start using spi-bcm2835 in the dt overlays they provide.

The big advantage of the spi-bcm2835 is that it ist already upstream, so we get the official review from kernel and have less of a fight when we incorporate it officially...

So what are my low-hanging fruit:

• Latency between CS-low and the first byte sent (3us) due to the comment saying that it is not possible as the first irq triggers immediately (which is not true)
• transfer as many bytes in/out as the chipset says it can handle - not stopping after 12 to 16 bytes while we could feed it more. This would reduce the number of interrupts
• add lossi/9bit mode (so that it becomes easier to move to the new driver in all situations) - I hear you have a device that supports that so maybe you could test it?
• move multiple transfers into the interrupt handler without having to wake up a thread and the corresponding late cues, which will speed up transfers that are write then read (so your touch controller)
• fix CS polarity issues - this may mean any gpio can do CS!

Those are easier and a necessity for the cleanup. Then we can address dma for long transfers.
This still means lots of interrupts for my use-case of a can controller (more than 9 interrupts/can message)

Finally I might get back to my vision of a fully dma-pipelined dma-driver that would trigger one irq per spi-message and only for completion..

Your thought?

from rpi-firmware.

@notro: do you have an idea where the foundation hides their dt-overlay sources, so that I can provide a merge request to prepare the move to spi-bcm2835?

from rpi-firmware.

@notro: I restarted on my spi-bcm2835 branch with now some wiki pages that now also include observations (and in the near future logic analyzer screenshots to prove the statements)
I believe we should move the discussion there...

from rpi-firmware.

I find all the above quite interesting - yet I am unable to follow you ;)

Coming back to my initial request (which, I assume, is valid for everyone else not deeply into the device tree situation either): Could you please post a commandline walkthrough (which I'd be very happy to turn into a documentation for you) on how to compile FBTFT as a module for the current kernels?

from rpi-firmware.

I noticed a very good, yet very (very very) hidden walkthrough within the staging area as it has just been issued by notro - https://github.com/torvalds/linux/blob/master/drivers/staging/fbtft/README .

Thank you!

from rpi-firmware.