Re: [PATCH 05/10] drm/tinydrm: Clean up tinydrm_spi_transfer()
On 7/17/19 6:58 AM, 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. Other changes: - No need to initialize ret - No need for the WARN since mipi-dbi only uses 8 and 16 bpw. - Use spi_message_init_with_transfers() Cc: David Lechner Signed-off-by: Noralf Trønnes --- Acked-by: : David Lechner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/10] drm/tinydrm: Clean up tinydrm_spi_transfer()
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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/10] drm/tinydrm: Clean up tinydrm_spi_transfer()
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. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/10] drm/tinydrm: Clean up tinydrm_spi_transfer()
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? Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel