From Zero to FBTFT - How to configure a new kernel

[ctshh]

I am having a lot of trouble seeing clearly through the new fog that is Device Trees.
May I request a rewrite of the whole process of how to get from one of the "naked" Raspberry Pi's kernel branches at https://github.com/raspberrypi/linux to a kernel that is FBTFT enabled, please?

I have read through the documentation you kindly offer, yet the concept of how to get the device tree overlays working with a newly created kernel (I need a few modules that are not included in the custom install, yet would very much like to have my FBTFT display working) somehow eludes me.

If I can be of any help in writing something I'd be glad to accept any scraps you can throw at me and will try to turn them into something that everyone can follow.

Again, thanks for your work!

[flav1972]

Hello,

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

Regards

[notro]

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

[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. 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,...)

[msperl]

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).

[notro]

@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.

[msperl]

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?

[msperl]

@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?

[msperl]

@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...

[ctshh]

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?

[ctshh]

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!