linux-stable.git/drivers/gpu/drm/tiny, branch v6.2.4

drm/tiny: ili9486: Do not assume 8-bit only SPI controllers

2023-03-10T08:29:15+00:00

[ Upstream commit 77772e607522daa61f3af74df018559db75c43d6 ]

The pixel data for the ILI9486 is always 16-bits wide and it must be
sent over the SPI bus. When the controller is only able to deal with
8-bit transfers, this 16-bits data needs to be swapped before the
sending to account for the big endian bus, this is on the contrary not
needed when the SPI controller already supports 16-bits transfers.

The decision about swapping the pixel data or not is taken in the MIPI
DBI code by probing the controller capabilities: if the controller only
suppors 8-bit transfers the data is swapped, otherwise it is not.

This swapping/non-swapping is relying on the assumption that when the
controller does support 16-bit transactions then the data is sent
unswapped in 16-bits-per-word over SPI.

The problem with the ILI9486 driver is that it is forcing 8-bit
transactions also for controllers supporting 16-bits, violating the
assumption and corrupting the pixel data.

Align the driver to what is done in the MIPI DBI code by adjusting the
transfer size to the maximum allowed by the SPI controller.

Reviewed-by: Neil Armstrong 
Signed-off-by: Carlo Caione 
Reviewed-by: Kamlesh Gurudasani 
Signed-off-by: Neil Armstrong 
Link: https://patchwork.freedesktop.org/patch/msgid/20221116-s905x_spi_ili9486-v4-2-f86b4463b9e4@baylibre.com
Signed-off-by: Sasha Levin

drm/fb-helper: Move generic fbdev emulation into separate source file

2022-11-05T16:12:04+00:00

Move the generic fbdev implementation into its own source and header
file. Adapt drivers. No functional changes, but some of the internal
helpers have been renamed to fit into the drm_fbdev_ naming scheme.

v3:
	* rename drm_fbdev.{c,h} to drm_fbdev_generic.{c,h}
	* rebase onto vmwgfx changes
	* rebase onto xlnx changes
	* fix include statements in amdgpu

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
Link: https://patchwork.freedesktop.org/patch/msgid/20221103151446.2638-22-tzimmermann@suse.de

drm/ofdrm: Cast error pointers to void __iomem *

2022-11-04T13:44:12+00:00

Cast error pointers when returning them as void __iomem *. Fixes
a number of Sparse warnings, such as the ones shown below.

../drivers/gpu/drm/tiny/ofdrm.c:439:31: warning: incorrect type in return expression (different address spaces)
../drivers/gpu/drm/tiny/ofdrm.c:439:31:    expected void [noderef] __iomem *
../drivers/gpu/drm/tiny/ofdrm.c:439:31:    got void *
../drivers/gpu/drm/tiny/ofdrm.c:442:31: warning: incorrect type in return expression (different address spaces)
../drivers/gpu/drm/tiny/ofdrm.c:442:31:    expected void [noderef] __iomem *
../drivers/gpu/drm/tiny/ofdrm.c:442:31:    got void *

See [1] for the bug report.

v3:
	* use IOMEM_ERR_PTR() (Javier)

Reported-by: kernel test robot 
Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
Link: https://lore.kernel.org/dri-devel/202210200016.yiQzPIy0-lkp@intel.com/ # [1]
Link: https://patchwork.freedesktop.org/patch/msgid/20221103101627.32502-3-tzimmermann@suse.de

drm/ofdrm: Convert PCI IDs to CPU endianness for comparing

2022-11-04T13:44:02+00:00

Properties of 32-bit integers are returned from the OF device tree
as type __be32. Convert PCI vendor and device IDs from __be32 to host
endianness before comparing them to constants. All relevant machines
are old, big-endian Macintosh systems; hence the bug never happened
in practice.

Fixes sparse warnings shown below.

  drivers/gpu/drm/tiny/ofdrm.c:237:17: warning: restricted __be32 degrades to integer
  drivers/gpu/drm/tiny/ofdrm.c:238:18: warning: restricted __be32 degrades to integer
  drivers/gpu/drm/tiny/ofdrm.c:238:54: warning: restricted __be32 degrades to integer

See [1] for the bug report.

v2:
	* convert endianness (Alex)

Reported-by: kernel test robot 
Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
Link: https://lore.kernel.org/dri-devel/202210192208.D888I6X7-lkp@intel.com/ # [1]
Link: https://patchwork.freedesktop.org/patch/msgid/20221103101627.32502-2-tzimmermann@suse.de

drm/ofdrm: Depend on CONFIG_MMU

2022-11-03T09:17:53+00:00

Add a dependency on CONFIG_MMU to ofdrm. The driver uses GEM SHMEM
helpers, which require MMU support. A reported error message [1] is
shown below.

   arm-linux-gnueabi-ld: drivers/gpu/drm/drm_gem_shmem_helper.o: in function `drm_gem_shmem_fault':
   >> drivers/gpu/drm/drm_gem_shmem_helper.c:562: undefined reference to `vmf_insert_pfn'

Reported-by: kernel test robot 
Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
Fixes: c8a17756c425 ("drm/ofdrm: Add ofdrm for Open Firmware framebuffers")
Cc: Thomas Zimmermann 
Cc: Javier Martinez Canillas 
Cc: Sam Ravnborg 
Cc: Maxime Ripard 
Cc: "Noralf Trønnes" 
Cc: Danilo Krummrich 
Cc: Michal Suchanek 
Cc: Daniel Vetter 
Link: https://lore.kernel.org/dri-devel/202210192029.ZFeJvqjv-lkp@intel.com/ # [1]
Link: https://patchwork.freedesktop.org/patch/msgid/20221101104049.15601-1-tzimmermann@suse.de

drm: Remove drm_mode_config::fb_base

2022-10-20T01:46:16+00:00

The fb_base in struct drm_mode_config has been unused for a long time.
Some drivers set it and some don't leading to a very confusing state
where the variable can't be relied upon, because there's no indication
as to which driver sets it and which doesn't.

The only usage of fb_base is internal to two drivers so instead of trying
to force it into all the drivers to get it into a coherent state
completely remove it.

Signed-off-by: Zack Rusin 
Reviewed-by: Laurent Pinchart 
Reviewed-by: Thomas Zimmermann 
Acked-by: Christian König 
Link: https://patchwork.freedesktop.org/patch/msgid/20221019024401.394617-1-zack@kde.org

drm/ofdrm: Support big-endian scanout buffers

2022-10-14T07:51:12+00:00

All DRM formats assume little-endian byte order. On big-endian systems,
it is likely that the scanout buffer is in big endian as well. Update
the format accordingly and add endianness conversion to the format-helper
library. Also opt-in to allocated buffers in host format by default.

Suggested-by: Geert Uytterhoeven 
Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
Link: https://patchwork.freedesktop.org/patch/msgid/20221011150712.3928-6-tzimmermann@suse.de

drm/ofdrm: Support color management

2022-10-14T07:50:25+00:00

Support the CRTC's color-management property and implement each model's
palette support.

The OF hardware has different methods of setting the palette. The
respective code has been taken from fbdev's offb and refactored into
per-model device functions. The device functions integrate this
functionality into the overall modesetting.

As palette handling is a CRTC property that depends on the primary
plane's color format, the plane's atomic_check helper now updates the
format field in ofdrm's custom CRTC state. The CRTC's atomic_flush
helper updates the palette for the format as needed.

v4:
	* use cpu_to_be32() (Geert)
v3:
	* lookup CRTC state with drm_atomic_get_new_crtc_state()
	* access HW palette with writeb(), writel(), and readl() (Ben)
	* declare register values as u32

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
Link: https://patchwork.freedesktop.org/patch/msgid/20221011150712.3928-5-tzimmermann@suse.de

drm/ofdrm: Add per-model device function

2022-10-14T07:50:13+00:00

Add a per-model device-function structure in preparation of adding
color-management support. Detection of the individual models has been
taken from fbdev's offb.

v3:
	* define constants for PCI ids (Javier)

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
Link: https://patchwork.freedesktop.org/patch/msgid/20221011150712.3928-4-tzimmermann@suse.de

drm/ofdrm: Add CRTC state

2022-10-14T07:50:04+00:00

Add a dedicated CRTC state to ofdrm to later store information for
palette updates.

v3:
	* rework CRTC state helpers (Javier)

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
Link: https://patchwork.freedesktop.org/patch/msgid/20221011150712.3928-3-tzimmermann@suse.de