dri-devel January 2022

dri-devel@lists.freedesktop.org

373 participants
842 discussions

[PATCH v3 00/13] drm/msm: Add Display Stream Compression Support
by Vinod Koul 23 Mar '22

23 Mar '22

Display Stream Compression (DSC) compresses the display stream in host which is later decoded by panel. This series enables this for Qualcomm msm driver. This was tested on Google Pixel3 phone which use LGE SW43408 panel. The changes include DSC data and hardware block enabling for DPU1 then support in encoder. We also add support in DSI and introduce required topology changes. In order for panel to set the DSC parameters we add dsc in drm_panel and set it from the msm driver. We still have dsc as a globabl entity. I think while doing DP + DSC we should be able to update it, right now comprehending the requirements are bit difficult. Complete changes which enable this for Pixel3 along with panel driver (not part of this series) and DT changes can be found at: git.linaro.org/people/vinod.koul/kernel.git pixel/dsc_v3 Comments welcome! Changes since v2: - Fix comments by Dimitry except the dsc being global. - Move RM patch later for dependency on topology now - Add patch for mode valid callback for dsi_mgr - Add missing structure documentation patch - Fix errors in mode_3d changes - Rebase on v5.16-rc1 and test Changes since v1: - Fix various issues spotted by kbuildbot - Rebase to v5.15-rc3 - Remove unused fields and duplicate defines - Enable DSC blocks only when DSC is enabled - remove sdm845 feature mask, use 0 - Check for DSC in hw_ctl Changes since RFC: - Drop the DT binding patch as we derive the configuration from panel - Drop the drm api patch as we no longer need it (use pps drm api) - Fix comments raised by Dimitry - Add dsc parameters calculation from downstream Vinod Koul (13): drm/msm/dsi: add support for dsc data drm/msm/disp/dpu1: Add support for DSC drm/msm/disp/dpu1: Add support for DSC in pingpong block drm/msm/disp/dpu1: Add DSC for SDM845 to hw_catalog drm/msm/disp/dpu1: Don't use DSC with mode_3d drm/msm/disp/dpu1: Add DSC support in hw_ctl drm/msm/disp/dpu1: Add support for DSC in encoder drm/msm: Add missing structure documentation drm/msm/disp/dpu1: Add support for DSC in topology drm/msm/disp/dpu1: Add DSC support in RM drm/msm/dsi: add mode valid callback for dsi_mgr drm/msm/dsi: Add support for DSC configuration drm/msm/dsi: Pass DSC params to drm_panel drivers/gpu/drm/msm/Makefile | 1 + drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 158 +++++++++- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 11 + .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 2 + .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 20 ++ .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 13 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 14 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 2 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 210 +++++++++++++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h | 77 +++++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 13 + .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 32 ++ .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h | 14 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 + drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 66 ++++ drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 1 + drivers/gpu/drm/msm/dsi/dsi.h | 2 + drivers/gpu/drm/msm/dsi/dsi.xml.h | 10 + drivers/gpu/drm/msm/dsi/dsi_host.c | 285 +++++++++++++++++- drivers/gpu/drm/msm/dsi/dsi_manager.c | 12 + drivers/gpu/drm/msm/msm_drv.h | 23 ++ include/drm/drm_panel.h | 7 + 22 files changed, 970 insertions(+), 4 deletions(-) create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h -- 2.31.1

5 40

[PATCH 0/2] drm/imx/lcdc: drm driver for imx21/25/27
by Uwe Kleine-König 22 Mar '22

22 Mar '22

Hello, this patchset was created mostly by Marian Cichy, who in the meantime left Pengutronix. I still kept his name and email address as author, but note that the email address doesn't reach Marian any more. There is already a maintainer entry for imx DRM drivers that matches good enough. This was tested on an i.MX25 based customer machine. Best regards Uwe Marian Cichy (2): dt-bindings: display: imx: Add fsl,imx21-lcdc docs drm/imx/lcdc: Implement DRM driver for imx21 .../bindings/display/imx/fsl,imx21-lcdc.yaml | 79 +++ drivers/gpu/drm/imx/Kconfig | 9 + drivers/gpu/drm/imx/Makefile | 2 + drivers/gpu/drm/imx/imx21-lcdc/imx21-lcdc.c | 631 ++++++++++++++++++ 4 files changed, 721 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx21-lcdc.yaml create mode 100644 drivers/gpu/drm/imx/imx21-lcdc/imx21-lcdc.c -- 2.34.1

5 12

[PATCH 0/6] dma-buf: Add an API for exporting sync files (v12)
by Jason Ekstrand 22 Mar '22

22 Mar '22

Modern userspace APIs like Vulkan are built on an explicit synchronization model. This doesn't always play nicely with the implicit synchronization used in the kernel and assumed by X11 and Wayland. The client -> compositor half of the synchronization isn't too bad, at least on intel, because we can control whether or not i915 synchronizes on the buffer and whether or not it's considered written. The harder part is the compositor -> client synchronization when we get the buffer back from the compositor. We're required to be able to provide the client with a VkSemaphore and VkFence representing the point in time where the window system (compositor and/or display) finished using the buffer. With current APIs, it's very hard to do this in such a way that we don't get confused by the Vulkan driver's access of the buffer. In particular, once we tell the kernel that we're rendering to the buffer again, any CPU waits on the buffer or GPU dependencies will wait on some of the client rendering and not just the compositor. This new IOCTL solves this problem by allowing us to get a snapshot of the implicit synchronization state of a given dma-buf in the form of a sync file. It's effectively the same as a poll() or I915_GEM_WAIT only, instead of CPU waiting directly, it encapsulates the wait operation, at the current moment in time, in a sync_file so we can check/wait on it later. As long as the Vulkan driver does the sync_file export from the dma-buf before we re-introduce it for rendering, it will only contain fences from the compositor or display. This allows to accurately turn it into a VkFence or VkSemaphore without any over- synchronization. This patch series actually contains two new ioctls. There is the export one mentioned above as well as an RFC for an import ioctl which provides the other half. The intention is to land the export ioctl since it seems like there's no real disagreement on that one. The import ioctl, however, has a lot of debate around it so it's intended to be RFC-only for now. Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4037 IGT tests: https://patchwork.freedesktop.org/series/90490/ v10 (Jason Ekstrand, Daniel Vetter): - Add reviews/acks - Add a patch to rename _rcu to _unlocked - Split things better so import is clearly RFC status v11 (Daniel Vetter): - Add more CCs to try and get maintainers - Add a patch to document DMA_BUF_IOCTL_SYNC - Generally better docs - Use separate structs for import/export (easier to document) - Fix an issue in the import patch v12 (Daniel Vetter): - Better docs for DMA_BUF_IOCTL_SYNC v12 (Christian König): - Drop the rename patch in favor of Christian's series - Add a comment to the commit message for the dma-buf sync_file export ioctl saying why we made it an ioctl on dma-buf Cc: Christian König <christian.koenig(a)amd.com> Cc: Michel Dänzer <michel(a)daenzer.net> Cc: Dave Airlie <airlied(a)redhat.com> Cc: Bas Nieuwenhuizen <bas(a)basnieuwenhuizen.nl> Cc: Daniel Stone <daniels(a)collabora.com> Cc: mesa-dev(a)lists.freedesktop.org Cc: wayland-devel(a)lists.freedesktop.org Test-with: 20210524205225.872316-1-jason(a)jlekstrand.net Christian König (1): dma-buf: Add dma_fence_array_for_each (v2) Jason Ekstrand (5): dma-buf: Add dma_resv_get_singleton (v6) dma-buf: Document DMA_BUF_IOCTL_SYNC (v2) dma-buf: Add an API for exporting sync files (v12) RFC: dma-buf: Add an extra fence to dma_resv_get_singleton_unlocked RFC: dma-buf: Add an API for importing sync files (v7) Documentation/driver-api/dma-buf.rst | 8 ++ drivers/dma-buf/dma-buf.c | 103 +++++++++++++++++++++++++ drivers/dma-buf/dma-fence-array.c | 27 +++++++ drivers/dma-buf/dma-resv.c | 110 +++++++++++++++++++++++++++ include/linux/dma-fence-array.h | 17 +++++ include/linux/dma-resv.h | 2 + include/uapi/linux/dma-buf.h | 103 ++++++++++++++++++++++++- 7 files changed, 369 insertions(+), 1 deletion(-) -- 2.31.1

8 31

[PATCH 1/2] drm: mediatek: mtk_drm_plane: Use kmalloc in mtk_plane_duplicate_state
by AngeloGioacchino Del Regno 16 Mar '22

16 Mar '22

There is no need to zero out the newly allocated memory because we are duplicating all members of struct mtk_plane_state: switch to kmalloc to save some overhead. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> --- drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm/mediatek/mtk_drm_plane.c index c74cb94e445e..39cb9a80d976 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c @@ -57,7 +57,7 @@ static struct drm_plane_state *mtk_plane_duplicate_state(struct drm_plane *plane struct mtk_plane_state *old_state = to_mtk_plane_state(plane->state); struct mtk_plane_state *state; - state = kzalloc(sizeof(*state), GFP_KERNEL); + state = kmalloc(sizeof(*state), GFP_KERNEL); if (!state) return NULL; -- 2.33.1

2 5

[PATCH] drm/bridge: synopsys/dw-hdmi: set cec clock rate
by Peter Geis 14 Mar '22

14 Mar '22

The hdmi-cec clock must be 32khz in order for cec to work correctly. Ensure after enabling the clock we set it in order for the hardware to work as expected. Warn on failure, in case this is a static clock that is slighty off. Fixes hdmi-cec support on Rockchip devices. Fixes: ebe32c3e282a ("drm/bridge: synopsys/dw-hdmi: Enable cec clock") Signed-off-by: Peter Geis <pgwipeout(a)gmail.com> --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index 54d8fdad395f..1a96da60e357 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -48,6 +48,9 @@ #define HDMI14_MAX_TMDSCLK 340000000 +/* HDMI CEC needs a clock rate of 32khz */ +#define HDMI_CEC_CLK_RATE 32768 + enum hdmi_datamap { RGB444_8B = 0x01, RGB444_10B = 0x03, @@ -3347,6 +3350,10 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev, ret); goto err_iahb; } + + ret = clk_set_rate(hdmi->cec_clk, HDMI_CEC_CLK_RATE); + if (ret) + dev_warn(hdmi->dev, "Cannot set HDMI cec clock rate: %d\n", ret); } /* Product and revision IDs */ -- 2.25.1

5 8

[RFC 00/28] Add RZ/G2L Display support
by Biju Das 14 Mar '22

14 Mar '22

RZ/G2L LCD controller composed of Frame compression Processor(FCPVD), Video signal processor (VSPD) and Display unit(DU). The output of LCDC is connected to Display parallel interface and MIPI link video interface. This patch series aims to add basic display support on RZ/G2L SMARC EVK platform. The output from DSI is connected to ADV7535. Implemntation details:- Clock:- PLL5 generates 2 clock sources, FOUTPOSTDIV and FOUT1PH0 and vclk is sourced through DSI divider which is connected to a mux with the above clock sources. Pll5-->Mux->DSI divider--> vclk. The parameters used for generating PLL5 frequency is based on a LUT[1] from the bsp release. DSI mode and DPI mode needs different set of PLL5 parameters for generating the video clock. Currently we support only DSI mode. later extend this to support DPI mode. LCDC: DU shares same clocks and reset line with VSPD and FCPVD. it does not have DU group and plane registers like R-Car. it supports FHD@60 for DSI interface. VSPD: VSPD does not have version register, so a new compatible introduced to get version string. Please share your valuable comments on this patch series. [1]https://github.com/renesas-rz/rz_linux-cip/tree/rzg2l-cip41/drivers/gpu/d… Biju Das (28): clk: renesas: rzg2l: Add FOUTPOSTDIV clk support clk: renesas: rzg2l: Add PLL5_4 clk mux support clk: renesas: rzg2l: Add DSI divider clk support clk: renesas: r9a07g044: Add M1 clock support clk: renesas: r9a07g044: Add {M2, M2_DIV2} Clocks support clk: renesas: r9a07g044: Add M3 Clock support clk: renesas: r9a07g044: Add M4 Clock support clk: renesas: r9a07g044: Add LCDC clock and reset entries clk: renesas: r9a07g044: Add DSI clock and reset entries drm: rcar-du: of: Increase buff size for compatible variable drm: rcar-du: Add num_rpf to struct rcar_du_device_info drm: rcar-du: Add max_width and max_height to struct rcar_du_device_info drm: rcar-du: Add RCAR_DU_FEATURE_PLANE feature bit drm: rcar-du: Allow DU plane feature based on DU feature bit drm: rcar_du: Add RCAR_DU_FEATURE_GROUP feature bit drm: rcar-du: Allow DU group feature based on feature bit dt-bindings: display: renesas,du: Document r9a07g044l bindings drm: rcar-du: Add RZ/G2L LCDC Support media: dt-bindings: media: renesas,vsp1: Document RZ/{G2L,V2L} VSPD bindings media: vsp1: Add support for the RZ/G2L VSPD dt-bindings: display: bridge: Document RZ/G2L MIPI DSI TX bindings drm: rcar-du: Add RZ/G2L DSI driver arm64: dts: renesas: r9a07g044: Add fcpvd node arm64: dts: renesas: r9a07g044: Add vspd node arm64: dts: renesas: r9a07g044: Add DU node arm64: dts: renesas: r9a07g044: Add dsi node arm64: dts: renesas: r9a07g044: Link DSI with DU node arm64: dts: renesas: rzg2l-smarc: Enable Display on carrier board .../bindings/display/bridge/renesas,dsi.yaml | 143 ++++ .../bindings/display/renesas,du.yaml | 54 ++ .../bindings/media/renesas,vsp1.yaml | 4 +- arch/arm64/boot/dts/renesas/r9a07g044.dtsi | 94 +++ arch/arm64/boot/dts/renesas/rzg2l-smarc.dtsi | 61 ++ drivers/clk/renesas/r9a07g044-cpg.c | 57 ++ drivers/clk/renesas/rzg2l-cpg.c | 426 +++++++++++ drivers/clk/renesas/rzg2l-cpg.h | 31 + drivers/gpu/drm/rcar-du/Kconfig | 7 + drivers/gpu/drm/rcar-du/Makefile | 1 + drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 151 +++- drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 + drivers/gpu/drm/rcar-du/rcar_du_drv.c | 144 +++- drivers/gpu/drm/rcar-du/rcar_du_drv.h | 9 + drivers/gpu/drm/rcar-du/rcar_du_group.c | 15 +- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 17 +- drivers/gpu/drm/rcar-du/rcar_du_of.c | 2 +- drivers/gpu/drm/rcar-du/rcar_du_regs.h | 52 ++ drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 9 +- drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c | 676 ++++++++++++++++++ drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi_regs.h | 151 ++++ drivers/media/platform/vsp1/vsp1.h | 1 + drivers/media/platform/vsp1/vsp1_drv.c | 31 +- drivers/media/platform/vsp1/vsp1_lif.c | 7 +- drivers/media/platform/vsp1/vsp1_regs.h | 1 + 25 files changed, 2070 insertions(+), 76 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi_regs.h -- 2.17.1

5 32

[PATCH 0/4] drm/tiny: Add driver for Solomon SSD1307 OLED displays
by Javier Martinez Canillas 14 Mar '22

14 Mar '22

This patch series adds a DRM driver for the Solomon OLED SSD1305, SSD1306, SSD1307 and SSD1309 displays. It is a port of the ssd1307fb fbdev driver. Using the DRM fb emulation, all the tests from Geert Uytterhoeven's fbtest (https://git.kernel.org/pub/scm/linux/kernel/git/geert/fbtest.git) passes: ./fbtest -f /dev/fb1 Using drawops cfb32 (32 bpp packed pixels) Available visuals: Monochrome Grayscale 256 Truecolor 8:8:8:0 Using visops truecolor Running all tests test001: PASSED test002: PASSED test003: PASSED test004: PASSED test005: PASSED test006: PASSED test008: PASSED test009: PASSED test010: PASSED Benchmarking... 10x10 squares: 412.99 Mpixels/s Benchmarking... 20x20 squares: 857.46 Mpixels/s Benchmarking... 50x50 squares: 1593.51 Mpixels/s test012: PASSED Benchmarking... R5 circles: 237.07 Mpixels/s Benchmarking... R10 circles: 501.24 Mpixels/s Benchmarking... R25 circles: 947.86 Mpixels/s test013: PASSED Patch #1 adds an I2C connector type since currently there isn't one and I2C drivers use DRM_MODE_CONNECTOR_Unknown or DRM_MODE_CONNECTOR_VIRTUAL. Patch #2 adds a drm_fb_gray8_to_mono_reversed() DRM format helper since most DRM/KMS user-space don't support bpp 1 displays, so drivers expose a common format that's converted to greyscale and then to monochrome. Patch #3 adds the driver. The name ssd1307 was used instead of ssd130x (which would be more accurate) to avoid confusion for users who want to migrate from the existing ssd1307fb fbdev driver. Patch #4 just adds a MAINTAINERS entry for this new DRM driver. Best regards, Javier Javier Martinez Canillas (4): drm: Add I2C connector type drm/format-helper: Add drm_fb_gray8_to_mono_reversed() drm/tiny: Add driver for Solomon SSD1307 OLED displays MAINTAINERS: Add entry for Solomon SSD1307 OLED displays DRM driver MAINTAINERS | 7 + drivers/gpu/drm/drm_connector.c | 1 + drivers/gpu/drm/drm_format_helper.c | 35 + drivers/gpu/drm/tiny/Kconfig | 12 + drivers/gpu/drm/tiny/Makefile | 1 + drivers/gpu/drm/tiny/ssd1307.c | 976 ++++++++++++++++++++++++++++ include/drm/drm_format_helper.h | 2 + include/uapi/drm/drm_mode.h | 1 + 8 files changed, 1035 insertions(+) create mode 100644 drivers/gpu/drm/tiny/ssd1307.c -- 2.34.1

9 55

[PATCH] drm: bridge: it66121: Added it66121 chip external screen status judgment
by Yunlongli 10 Mar '22

10 Mar '22

In the actual tests, the IT66121 chip sometimes misjudged whether it had an external screen, so, reference the it66121_user_guid.pdf about Audio/Video data is stable or not A typical initialization of HDMI link should be based on interrupt signal and appropriate register probing. Recommended flow is detailed in IT66121 Programming Guide. Simply put, the microcontroller should monitor the HPD status first. Upon valid HPD event, move on to check RxSENDetect register to see if the receiver chip is ready for further handshaking. When RxSENDetect is asserted, start reading EDID data through DDC channels and carry on the rest of the handshaking subsequently.If the micro-controller makes no use of the interrupt signal as well as the above-mentioned status registers, the link establishment might fail. Please do follow the suggested initialization flow recommended in IT66121 Programming Guide. So, I add the IT66121_SYS_STATUS_SENDECTECT register status detection. Signed-off-by: Yunlongli <liyunlonga(a)uniontech.com> --- drivers/gpu/drm/bridge/ite-it66121.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/ite-it66121.c b/drivers/gpu/drm/bridge/ite-it66121.c index 2f2a09adb4bc..9ed4fa298d11 100644 --- a/drivers/gpu/drm/bridge/ite-it66121.c +++ b/drivers/gpu/drm/bridge/ite-it66121.c @@ -523,7 +523,7 @@ static bool it66121_is_hpd_detect(struct it66121_ctx *ctx) if (regmap_read(ctx->regmap, IT66121_SYS_STATUS_REG, &val)) return false; - return val & IT66121_SYS_STATUS_HPDETECT; + return ((val & IT66121_SYS_STATUS_HPDETECT) && (val & IT66121_SYS_STATUS_SENDECTECT)); } static int it66121_bridge_attach(struct drm_bridge *bridge, -- 2.20.1

3 2

[PATCH 0/6] drm/tiny/st7735r: Match up with staging/fbtft driver
by Noralf Trønnes 09 Mar '22

09 Mar '22

Hi, This patchset adds a missing piece for decommissioning the staging/fbtft/fb_st7735r.c driver namely a way to configure the controller from Device Tree. All fbtft drivers have builtin support for one display panel and all other panels using that controller are configured using the Device Tree 'init' property. This property is supported by all fbtft drivers and provides a generic way to set register values or issue commands (depending on the type of controller). It is common for these types of displays to have a datasheet listing the necessary controller settings/commands or some example code doing the same. This is how the panel directly supported by the fb_st7735r staging driver is described using Device Tree with that driver: width = <160>; height = <128>; init = <0x1000001 0x2000096 0x1000011 0x20000ff 0x10000B1 0x01 0x2C 0x2D 0x10000B4 0x07 0x10000C0 0xA2 0x02 0x84 0x10000C1 0xC5 0x10000C2 0x0A 0x00 0x10000C5 0x0E 0x100003a 0x55 0x1000036 0x60 0x10000E0 0x0F 0x1A 0x0F 0x18 0x2F 0x28 0x20 0x22 0x1F 0x1B 0x23 0x37 0x00 0x07 0x02 0x10 0x10000E1 0x0F 0x1B 0x0F 0x17 0x33 0x2C 0x29 0x2E 0x30 0x30 0x39 0x3F 0x00 0x07 0x03 0x10 0x1000029 0x2000064>; This is how the same panel is described using the st7735r drm driver and this patchset: width = <160>; height = <128>; frmctr1 = [ 01 2C 2D ]; invctr = [ 07 ]; pwctr1 = [ A2 02 84 ]; pwctr2 = [ C5 ]; pwctr3 = [ 0A 00 ]; vmctr1 = [ 0E ]; madctl = [ 60 ]; gamctrp1 = [ 0F 1A 0F 18 2F 28 20 22 1F 1B 23 37 00 07 02 10 ]; gamctrn1 = [ 0F 1B 0F 17 33 2C 29 2E 30 30 39 3F 00 07 03 10 ]; Back when the fbtft drivers were added to staging I asked on the DT mailinglist if it was OK to use the 'init' property but it was turned down. In this patchset I'm trying the same approach used by the solomon,ssd1307fb.yaml binding in describing the attached panel. That binding prefixes the properties with the vendor name, not sure why that is and I think it looks strange so I try without it. Noralf. Noralf Trønnes (6): dt-bindings: display: sitronix,st7735r: Fix backlight in example dt-bindings: display: sitronix,st7735r: Make reset-gpios optional dt-bindings: display: sitronix,st7735r: Remove spi-max-frequency limit dt-bindings: display: sitronix,st7735r: Add initialization properties drm/mipi-dbi: Add device property functions drm: tiny: st7735r: Support DT initialization of controller .../bindings/display/sitronix,st7735r.yaml | 122 ++++++++++++++- drivers/gpu/drm/drm_mipi_dbi.c | 139 ++++++++++++++++++ drivers/gpu/drm/tiny/st7735r.c | 87 +++++++++-- include/drm/drm_mipi_dbi.h | 3 + 4 files changed, 334 insertions(+), 17 deletions(-) -- 2.33.0

5 25

[PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan
by Thierry Reding 07 Mar '22

07 Mar '22

From: Thierry Reding <treding(a)nvidia.com> Hi, this is an alternative proposal to fix panel support on Venice 2 and Nyan. Dmitry had proposed a different solution that involved reverting the I2C/DDC registration order and would complicate things by breaking the encapsulation of the driver by introducing a global (though locally scoped) variable[0]. This set of patches avoids that by using the recently introduced DP AUX bus infrastructure. The result is that the changes are actually less intrusive and not a step back. Instead they nicely remove the circular dependency that previously existed and caused these issues in the first place. To be fair, this is not perfect either because it requires a device tree change and hence isn't technically backwards-compatible. However, given that the original device tree was badly broken in the first place, I think we can make an exception, especially since it is not generally a problem to update device trees on the affected devices. Secondly, this relies on infrastructure that was introduced in v5.15 and therefore will be difficult to backport beyond that. However, since this functionality has been broken since v5.13 and all of the kernel versions between that and v5.15 are EOL anyway, there isn't much that we can do to fix the interim versions anyway. Adding Doug and Laurent since they originally designed the AUX bus patches in case they see anything in here that would be objectionable. Thierry [0]: https://lore.kernel.org/dri-devel/20211130230957.30213-1-digetx@gmail.com/ Thierry Reding (2): drm/tegra: dpaux: Populate AUX bus ARM: tegra: Move panels to AUX bus arch/arm/boot/dts/tegra124-nyan-big.dts | 15 +++++++++------ arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------ arch/arm/boot/dts/tegra124-venice2.dts | 14 +++++++------- drivers/gpu/drm/tegra/Kconfig | 1 + drivers/gpu/drm/tegra/dpaux.c | 7 +++++++ 5 files changed, 33 insertions(+), 19 deletions(-) -- 2.34.1

3 24

← Newer
1
2
3
4
5
6
7
8
9
...
85
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2022