[PATCH 05/10] drm/tinydrm: Clean up tinydrm_spi_transfer()

Noralf Trønnes noralf at tronnes.org
Wed Jul 17 16:18:39 UTC 2019



Den 17.07.2019 15.09, skrev Sam Ravnborg:
> On Wed, Jul 17, 2019 at 01:58:12PM +0200, Noralf Trønnes wrote:
>> Prep work before moving the function to mipi-dbi.
>>
>> tinydrm_spi_transfer() was made to support one class of drivers in
>> drivers/staging/fbtft that has not been converted to DRM yet, so strip
>> away the unused functionality:
>> - Start byte (header) is not used.
>> - No driver relies on the automatic 16-bit byte swapping on little endian
>>   machines with SPI controllers only supporting 8 bits per word.
> 
> Keeping unused code around is never a good idea.
> On the other hand, should we not try to get the driver in questions
> ported so we have a user and we do not need to re-add this later?
> What driver/display needs this?

At least drivers/staging/fbtft/fb_ili932{0,5}.c and maybe another one, I
don't remember. I haven't worked on fbtft after I did tinydrm.
It looks like they still sell the hy28b:
https://www.hotmcu.com/28-touch-screen-tft-lcd-with-all-interface-p-63.html

I'm not sure what the future of fbtft is. The idea was that the drivers
should get cleaned up and move out of staging, but then fbdev was closed
for new drivers and I did tinydrm. Only two drivers have been converted
apart from mi0283qt that I did and that is hx8357 which Eric did and
st7735 that David did. Those 3 covers a lot of the tiny SPI display
marked, Adafruit sells them.
It's a chicken and egg problem, as long as the fbtft drivers are there
and working, there's no incentive to convert them.

There's another challenge with these drivers since it is possible to
override the init sequence in Device Tree, meaning they can work with
all kinds of displays without writing a new driver.
I was not allowed to keep that functionality outside of staging.

When I'm done with the tinydrm cleanup, I'm going to work on an idea I
have: turn the Raspberry Pi Zero into a $5 USB to
HDMI/SDTV/DSI/DPI/SPI-display adapter. I'm planning to write a generic
USB host display driver with a matching Linux OTG device driver.
I plan to make it easy to do the display OTG side on a microcontroller
as well. This way it will be possible for manufacturers to do USB
connected displays of (nearly) all sizes without having to write a Linux
driver.

It's difficult to predict the future, but powerful microcontrollers are
cheap nowadays so maybe these SPI displays will be fased out by cheap
USB displays. The uC can replace the touch controller cutting some of
the uC cost.

Noralf.


More information about the dri-devel mailing list