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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Noralf.

On Wed, Jul 17, 2019 at 06:18:39PM +0200, Noralf Trønnes wrote:
> 
> 
> 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 ordered one, then we will see if I also find time to port the driver
and test it.

> 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.
I follow the average joe user here. If it works then why worry.
But if I get HW and time I can at least port over a few of them.
It looks like it takes more time to test than to do the porting.

> 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 will be interesting to follow this, keep us posted.

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

Yep, it is impressive what one can get for USD 5 these days.

	Sam
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux