Re: (subset) [PATCH 00/13] rockchip: Enable 4K@60Hz mode on RK3228, RK3328, RK3399 and RK356x
On Sat, 15 Jun 2024 17:03:51 +, Jonas Karlman wrote: > This prepares and enable use of HDMI2.0 modes, e.g. 4K@60Hz, on RK3228, > RK3328, RK3399 and RK356x. > > Patch 1-3 fixes some issues to help support use of high-resolution modes. > > Patch 4 fixes reading of EDID on RK3328 when using a forced mode. > > [...] Applied, thanks! [02/13] clk: rockchip: Set parent rate for DCLK_VOP clock on RK3228 commit: 1d34b9757523c1ad547bd6d040381f62d74a3189 Best regards, -- Heiko Stuebner
[PATCH RESEND] drm: bridge: dw-mipi-dsi: Allow sync-pulses to override the burst vid-mode
From: Heiko Stuebner
The state right now is that if the panel has the burst-mode flag it
will take precedence over the sync-pulses mode.
While sync-pulses are only relevant for the video-mode, the burst-mode
flag affects both the video-mode as well as the calculated lane_mbps.
Looking at drivers like the nwl-dsi [0] it only enables burst mode when
the panel's flags do not contain the sync_pulse flag.
So handle things similar for dw-dsi in that it selects the video-mode
with sync-pulses if that flag is set and only after that, checks for
the burst-mode. So panels selecting a combination of both burst and
sync-pulses get the sync-pulse mode.
The case this fixes can be found on the ltk050h3148w . It does need the
lane-rate to be calculated according to burst formulas [1], but without
sync-pulses we see the output shifted around 20 pixels to the right,
meaning that the last 20 pixels from each line appear at the start of
the next display line.
[0]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/bridge/nwl-dsi.c#n301
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6c9dbee84cd005bed5f9d07b3a2797ae6414b435
Fixes: 93e82bb4de01 ("drm/bridge: synopsys: dw-mipi-dsi: Fix hcomponent lbcc
for burst mode")
Signed-off-by: Heiko Stuebner
---
resend, because I messed up and somehow forgot to include _all_
mailing lists.
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 824fb3c65742e..28dd858a751bd 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -605,10 +605,10 @@ static void dw_mipi_dsi_video_mode_config(struct
dw_mipi_dsi *dsi)
*/
val = ENABLE_LOW_POWER;
- if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
- val |= VID_MODE_TYPE_BURST;
- else if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
+ if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
val |= VID_MODE_TYPE_NON_BURST_SYNC_PULSES;
+ else if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
+ val |= VID_MODE_TYPE_BURST;
else
val |= VID_MODE_TYPE_NON_BURST_SYNC_EVENTS;
--
2.39.2
Re: (subset) [PATCH 00/13] rockchip: Enable 4K@60Hz mode on RK3228, RK3328, RK3399 and RK356x
On Sat, 15 Jun 2024 17:03:51 +, Jonas Karlman wrote: > This prepares and enable use of HDMI2.0 modes, e.g. 4K@60Hz, on RK3228, > RK3328, RK3399 and RK356x. > > Patch 1-3 fixes some issues to help support use of high-resolution modes. > > Patch 4 fixes reading of EDID on RK3328 when using a forced mode. > > [...] Applied, thanks! [01/13] arm64: dts: rockchip: Increase VOP clk rate on RK3328 commit: 0f2ddb128fa20f8441d903285632f2c69e90fae1 Best regards, -- Heiko Stuebner
Re: [PATCH v3 1/2] drm/rockchip: vop: clear DMA stop bit upon vblank on RK3066
Am Sonntag, 2. Juni 2024, 05:35:36 CEST schrieb Val Packett:
>
> On Mon, May 27 2024 at 20:11:49 -03:00:00, Val Packett
> wrote:
> > The RK3066 VOP sets a dma_stop bit when it's done scanning out a frame
> > and needs the driver to acknowledge that by clearing the bit.
> >
> > So unless we clear it "between" frames, the RGB output only shows
> > noise
> > instead of the picture. vblank seems to be the most appropriate place
> > to
> > do it, since it indicates exactly that: that the hardware is done
> > with the frame.
> >
> > This seems to be a redundant synchronization mechanism that was
> > removed
> > in later iterations of the VOP hardware block.
> >
> > Fixes: f4a6de8 ("drm: rockchip: vop: add rk3066 vop definitions")
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Val Packett
> > ---
> > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 6 ++
> > drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
> > drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 1 +
> > 3 files changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > index a13473b2d..2731fe2b2 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > @@ -1766,6 +1766,12 @@ static void vop_handle_vblank(struct vop *vop)
> > }
> > spin_unlock(>event_lock);
> >
> > + if (VOP_HAS_REG(vop, common, dma_stop)) {
> > + spin_lock(>reg_lock);
> > + VOP_REG_SET(vop, common, dma_stop, 0);
> > + spin_unlock(>reg_lock);
> > + }
> > +
>
> Oops… so doing it here actually causes deadlocks, unless we also
> change all other reg_lock usages to be spin_lock_irq/spin_unlock_irq.
>
> Not sure if doing that or going back to v1 would be better.
then please go back to v1 (as v4) :-) .
I.e. regular spinlock vs. spin_lock_irq will have performance
implications and this "feature" is a one-time only thing used
only on a more than 10 year old soc, so it really must not affect
stuff coming after it.
Heiko
Re: [PATCH 00/14] Add initial support for the Rockchip RK3588 HDMI TX Controller
Am Montag, 3. Juni 2024, 14:14:17 CEST schrieb Andy Yan: > Hi Neil: > > On 6/3/24 16:55, Neil Armstrong wrote: > > Hi Christian, > > > > On 01/06/2024 15:12, Cristian Ciocaltea wrote: > >> The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the > >> Synopsys DesignWare HDMI TX controller used in the previous SoCs. > >> > >> It is HDMI 2.1 compliant and supports the following features, among > >> others: > >> > > . > > > > .. > > > >> * SCDC I2C DDC access > >> * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4 > >> * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds > >> * Multi-stream audio > >> * Enhanced Audio Return Channel (EARC) > > -> Those features were already supported by the HDMI 2.0a compliant HW, just > > list the _new_ features for HDMI 2.1 > > > > I did a quick review of your patchset and I don't understand why you need > > to add a separate dw-hdmi-qp.c since you only need simple variants of the > > I2C > > bus, infoframe and bridge setup. > > > > Can you elaborate further ? isn't this Quad-Pixel (QP) TX controller version > > detectable at runtime ? > > > > I would prefer to keep a single dw-hdmi driver if possible. > > > > The QP HDMI controller is a completely different variant with totally > different > registers layout, see PATCH 13/14. > I think make it a separate driver will be easier for development and > maintenance. I'm with Andy here. Trying to navigate a driver for two IP blocks really sounds taxing especially when both are so different. Synopsis also created a new dsi controller for the DSI2 standard, with a vastly different registers layout. I guess at some point there is time to say this really is a new IP ;-) . Though while on that thought, I don't fully understand why both a compiled under the dw_hdmi kconfig symbol. People going for a minimal kernel might want one or the other, but not both for their specific board. Heiko
Re: (subset) [PATCH v3 0/7] Add DSI support for RK3128
On Thu, 9 May 2024 16:06:46 +0200, Alex Bee wrote: > This series aims to add support for the DesignWare MIPI DSI controller and > the Innoslicon D-PHY found in RK3128 SoCs. The code additions are rather > tiny: It only need some code in the Rockchip dw-mipi-dsi glue layer for > this SoC and do some changes in the SoC's clock driver. Support for the phy > was already added when the Innosilicon D-PHY driver was initially > submitted. I tested it with a 800x1280 DSI panel where all 4 lanes that are > supported are used. > > [...] Applied, thanks! [2/7] dt-bindings: clock: rk3128: Add PCLK_MIPIPHY commit: 14a1d1dc35d346a1523f38f6517c349dfa447a58 [3/7] clk: rockchip: rk3128: Export PCLK_MIPIPHY commit: 577c04fbf255f81f26507a7ffb2477fce50c214d [4/7] clk: rockchip: rk3128: Add hclk_vio_h2p to critical clocks commit: e745698209837a952d4515bc02cddd5a31a644b9 [6/7] ARM: dts: rockchip: Add D-PHY for RK3128 commit: 45b22b83e00b1ec36d5de53b797cd9d8545a0d34 [7/7] ARM: dts: rockchip: Add DSI for RK3128 commit: 73fc389129dfe22b5706b4b6cbc1a4f86d1fbc1b Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v3 0/7] Add DSI support for RK3128
On Thu, 9 May 2024 16:06:46 +0200, Alex Bee wrote: > This series aims to add support for the DesignWare MIPI DSI controller and > the Innoslicon D-PHY found in RK3128 SoCs. The code additions are rather > tiny: It only need some code in the Rockchip dw-mipi-dsi glue layer for > this SoC and do some changes in the SoC's clock driver. Support for the phy > was already added when the Innosilicon D-PHY driver was initially > submitted. I tested it with a 800x1280 DSI panel where all 4 lanes that are > supported are used. > > [...] Applied, thanks! [1/7] dt-bindings: display: rockchip,dw-mipi-dsi: Document RK3128 DSI commit: 9bb3d9ad3e19f16efc34f427a58e480424c56a16 [5/7] drm/rockchip: dsi: Add support for RK3128 commit: 62545c719e26ec9f62efab7e9582deb73265b6d0 Best regards, -- Heiko Stuebner
[PATCH 0/2] drm/rockchip: vop2: two fixes from working on DSI enablement
While working on enabling DSI support on rk3588 I stumbled across the issue of the display staying black while both the vop2 and dsi drivers were claiming to be running just fine. After a bit of checking I found that I got DSI output on VP3 when HDMI on VP0 was at least associated in the DTS, but not without. Andy's patch [0] helped and is definitly necessary, but did not fix the problem completely. The missing thing was that VP3 is rk3588-specific (rk3568 only has 3 video-ports, not 4 like rk3588) and the layers of VP3 never got configured. Patch2 fixes this. [0] https://lore.kernel.org/dri-devel/20240422101905.32703-2-andys...@163.com/ Heiko Stuebner (2): drm/rockchip: vop2: fix rk3588 dp+dsi maxclk verification drm/rockchip: vop2: configure layers for vp3 on rk3588 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 16 ++-- drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 1 + 2 files changed, 15 insertions(+), 2 deletions(-) -- 2.39.2
[PATCH 1/2] drm/rockchip: vop2: fix rk3588 dp+dsi maxclk verification
From: Heiko Stuebner
The clock is in Hz while the value checked against is in kHz, so
actual frequencies will never be able to be below to max value.
Fix this by specifying the max-value in Hz too.
Fixes: 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588")
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index 9bee1fd88e6a2..523880a4e8e74 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -1719,7 +1719,7 @@ static unsigned long rk3588_calc_cru_cfg(struct
vop2_video_port *vp, int id,
else
dclk_out_rate = v_pixclk >> 2;
- dclk_rate = rk3588_calc_dclk(dclk_out_rate, 60);
+ dclk_rate = rk3588_calc_dclk(dclk_out_rate, 6);
if (!dclk_rate) {
drm_err(vop2->drm, "DP dclk_out_rate out of range,
dclk_out_rate: %ld KHZ\n",
dclk_out_rate);
@@ -1736,7 +1736,7 @@ static unsigned long rk3588_calc_cru_cfg(struct
vop2_video_port *vp, int id,
* dclk_rate = N * dclk_core_rate N = (1,2,4 ),
* we get a little factor here
*/
- dclk_rate = rk3588_calc_dclk(dclk_out_rate, 60);
+ dclk_rate = rk3588_calc_dclk(dclk_out_rate, 6);
if (!dclk_rate) {
drm_err(vop2->drm, "MIPI dclk out of range,
dclk_out_rate: %ld KHZ\n",
dclk_out_rate);
--
2.39.2
[PATCH 2/2] drm/rockchip: vop2: configure layers for vp3 on rk3588
From: Heiko Stuebner
The rk3588 VOP2 has 4 video-ports, yet the driver currently only
configures the first 3, as used on the rk3568.
Add another block to configure the vp3 as well, if applicable.
Fixes: 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588")
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 12
drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 1 +
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index 523880a4e8e74..1a327a9ed7ee4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -2303,6 +2303,7 @@ static void vop2_setup_alpha(struct vop2_video_port *vp)
static void vop2_setup_layer_mixer(struct vop2_video_port *vp)
{
struct vop2 *vop2 = vp->vop2;
+ const struct vop2_data *vop2_data = vop2->data;
struct drm_plane *plane;
u32 layer_sel = 0;
u32 port_sel;
@@ -2344,6 +2345,17 @@ static void vop2_setup_layer_mixer(struct
vop2_video_port *vp)
else
port_sel |= FIELD_PREP(RK3568_OVL_PORT_SET__PORT2_MUX, 8);
+ /* configure vp3 */
+ if (vop2_data->soc_id == 3588) {
+ struct vop2_video_port *vp3 = >vps[3];
+
+ if (vp3->nlayers)
+ port_sel |= FIELD_PREP(RK3588_OVL_PORT_SET__PORT3_MUX,
+ (vp3->nlayers + vp2->nlayers + vp1->nlayers +
vp0->nlayers - 1));
+ else
+ port_sel |= FIELD_PREP(RK3588_OVL_PORT_SET__PORT3_MUX,
8);
+ }
+
layer_sel = vop2_readl(vop2, RK3568_OVL_LAYER_SEL);
ofs = 0;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
index 615a16196aff6..f46fb795414e1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
@@ -489,6 +489,7 @@ enum dst_factor_mode {
#define RK3588_OVL_PORT_SEL__CLUSTER2 GENMASK(21, 20)
#define RK3568_OVL_PORT_SEL__CLUSTER1 GENMASK(19, 18)
#define RK3568_OVL_PORT_SEL__CLUSTER0 GENMASK(17, 16)
+#define RK3588_OVL_PORT_SET__PORT3_MUX GENMASK(15, 12)
#define RK3568_OVL_PORT_SET__PORT2_MUX GENMASK(11, 8)
#define RK3568_OVL_PORT_SET__PORT1_MUX GENMASK(7, 4)
#define RK3568_OVL_PORT_SET__PORT0_MUX GENMASK(3, 0)
--
2.39.2
Re: [PATCH 0/1] Fix the port mux of VP2
On Mon, 22 Apr 2024 18:19:04 +0800, Andy Yan wrote: > From: Andy Yan > > > The port mux bits of VP2 should be defined by RK3568_OVL_PORT_SET__PORT2_MUX, > this maybe a copy and paste error when this driver first introduced. > Hi Heiko: >Maybe thi is the problem you met when you porting the dsi2 driver. > I previously sent you this patch when you ask me about this issue on > email,but I'm not sure if you received it. > > [...] Applied, thanks! [1/1] drm/rockchip: vop2: Fix the port mux of VP2 commit: 2bdb481bf7a93c22b9fea8daefa2834aab23a70f Best regards, -- Heiko Stuebner
Re: [PATCH] drm: vop2: Do not divide height twice for YUV
On Sun, 14 Apr 2024 14:27:06 -0400, Detlev Casanova wrote: > For the cbcr format, gt2 and gt4 are computed again after src_h has been > divided by vsub. > > As src_h as already been divided by 2 before, introduce cbcr_src_h and > cbcr_src_w to keep a copy of those values to be used for cbcr gt2 and > gt4 computation. > > [...] Applied, thanks! [1/1] drm: vop2: Do not divide height twice for YUV commit: e80c219f52861e756181d7f88b0d341116daac2b But changed the subject to drm/rockchip: vop2: ..... Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: cdn-dp: drop driver owner assignment
On Sat, 30 Mar 2024 21:27:54 +0100, Krzysztof Kozlowski wrote: > Core in platform_driver_register() already sets the .owner, so driver > does not need to. Whatever is set here will be anyway overwritten by > main driver calling platform_driver_register(). > > Applied, thanks! [1/1] drm/rockchip: cdn-dp: drop driver owner assignment commit: 0e353133816b3e3e4bf8a682de01506ebc2b1dee Best regards, -- Heiko Stuebner
Re: [PATCH v1 1/3] dt-bindings: display: add #sound-dai-cells property to rockchip dw hdmi
On Sat, 13 Apr 2024 17:38:05 +0200, Johan Jonker wrote: > The Rockchip DWC HDMI TX Encoder can take one I2S input and transmit it > over the HDMI output. Add #sound-dai-cells (= 0) to the binding for it. > > Applied, thanks! [1/3] dt-bindings: display: add #sound-dai-cells property to rockchip dw hdmi commit: e58414e44b5315230de829ed88a63611646907ac [2/3] dt-bindings: display: add #sound-dai-cells property to rockchip rk3066 hdmi commit: 9be3eb5d6ee57662a22b56153c7ee39265685455 [3/3] dt-bindings: display: add #sound-dai-cells property to rockchip inno hdmi commit: b1ee6bd3ea954d081bfb1d5559ce3e78ef40443a Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: lvds: Remove include of drm_dp_helper.h
On Sun, 14 Apr 2024 20:08:41 +0800, Andy Yan wrote: > From: Andy Yan > > drm_dp_helper.h is not used by lvds driver > > Applied, thanks! [1/1] drm/rockchip: lvds: Remove include of drm_dp_helper.h commit: 685ba01ebedb8f87673f587f540ba84c42d4 Best regards, -- Heiko Stuebner
Re: [PATCH v3 31/43] drm/rockchip: Use fbdev-dma
Am Freitag, 19. April 2024, 10:29:24 CEST schrieb Thomas Zimmermann: > Implement fbdev emulation with fbdev-dma. Fbdev-dma now supports > damage handling, which is required by rockchip. Avoids the overhead of > fbdev-generic's additional shadow buffering. No functional changes. > > Signed-off-by: Thomas Zimmermann > Cc: Sandy Huang > Cc: "Heiko Stübner" > Cc: Andy Yan > Reviewed-by: Javier Martinez Canillas Acked-by: Heiko Stuebner
Re: [PATCH 15/15] drm/rockchip: rk3066_hdmi: switch to struct drm_edid
Am Dienstag, 16. April 2024, 15:22:29 CEST schrieb Jani Nikula: > Prefer struct drm_edid based functions over struct edid. > > Signed-off-by: Jani Nikula Acked-by: Heiko Stuebner
Re: [PATCH 14/15] drm/rockchip: inno_hdmi: switch to struct drm_edid
Am Dienstag, 16. April 2024, 15:22:28 CEST schrieb Jani Nikula: > Prefer struct drm_edid based functions over struct edid. > > Signed-off-by: Jani Nikula Acked-by: Heiko Stuebner
Re: [PATCH 13/15] drm/rockchip: cdn-dp: switch to struct drm_edid
Am Dienstag, 16. April 2024, 15:22:27 CEST schrieb Jani Nikula: > Prefer struct drm_edid based functions over struct edid. > > Signed-off-by: Jani Nikula Acked-by: Heiko Stuebner
Re: (subset) [PATCH 0/5] Add Support for RK3326 GameForce Chi
On Mon, 25 Mar 2024 08:49:54 -0500, Chris Morgan wrote: > From: Chris Morgan > > Add support for the GameForce Chi [1]. > > The GameForce Chi has the following hardware: > Tested: > - 3.5" dual lane 640x480 DSI display. > - 15 GPIO based face buttons. > - 2 ADC based face buttons. > - 1 ADC joystick (left) connected to internal SARADC. > - RGB LED arrays for key backlighting > - Dual internal speakers. > - Realtek RTL8723BS SDIO WiFi. > - Single SDMMC slot. > > [...] Applied, thanks! [4/5] dt-bindings: arm: rockchip: Add GameForce Chi commit: c1bc09960d05cfbfb94cfdfb66b4733e3ddf1638 [5/5] arm64: dts: rockchip: Add GameForce Chi commit: ad59da1ab997e81061ec980300fb7ce2d5e4bc5d Best regards, -- Heiko Stuebner
[PATCH] dt-bindings: display: rockchip: add missing #sound-dai-cells to dw-hdmi
The #sound-dai-cells DT property is required to describe link between the HDMI IP block and the SoC's audio subsystem. Signed-off-by: Heiko Stuebner --- .../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml index af638b6c0d21..3768df80ca7a 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml @@ -124,6 +124,9 @@ properties: description: phandle to the GRF to mux vopl/vopb. + "#sound-dai-cells": +const: 0 + required: - compatible - reg -- 2.39.2
Re: [PATCH 1/2] drm/panel: ltk050h3146w: add MIPI_DSI_MODE_VIDEO to LTK050H3148W flags
On Wed, 20 Mar 2024 14:12:31 +0100, Heiko Stuebner wrote: > From: Heiko Stuebner > > Similar to other variants, the LTK050H3148W wants to run in video mode > when displaying data. So far only the Synopsis DSI driver was using this > panel and it is always switching to video mode, independent of this flag > being set. > > [...] Applied, thanks! [1/2] drm/panel: ltk050h3146w: add MIPI_DSI_MODE_VIDEO to LTK050H3148W flags commit: 80cc8c0d09e6bab3bd016ddaccd0570cadbe1891 [2/2] drm/panel: ltk050h3146w: drop duplicate commands from LTK050H3148W init commit: 55679cc22e60e8ec23b2340248389022798416cd Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: vop2: Remove AR30 and AB30 format support
On Mon, 4 Mar 2024 18:09:52 +0800, Andy Yan wrote: > From: Andy Yan > > The Alpha blending for 30 bit RGB/BGR are not > functioning properly for rk3568/rk3588, so remove > it from the format list. > > > [...] Applied, thanks! [1/1] drm/rockchip: vop2: Remove AR30 and AB30 format support commit: 905f7d53a1bc105b22d9ffd03dc11b6b42ec6ba6 Best regards, -- Heiko Stuebner
[PATCH 2/2] drm/panel: ltk050h3146w: drop duplicate commands from LTK050H3148W init
From: Heiko Stuebner
The init sequence specifies the 0x11 and 0x29 dsi commands, which are
the exit-sleep and display-on commands.
In the actual prepare step the driver already uses the appropriate
function calls for those, so drop the duplicates.
Fixes: e5f9d543419c ("drm/panel: ltk050h3146w: add support for Leadtek
LTK050H3148W-CTA6 variant")
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
b/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
index a50f5330a661..8e0f5c3e3b98 100644
--- a/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
+++ b/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
@@ -295,8 +295,6 @@ static int ltk050h3148w_init_sequence(struct ltk050h3146w
*ctx)
mipi_dsi_dcs_write_seq(dsi, 0xbd, 0x00);
mipi_dsi_dcs_write_seq(dsi, 0xc6, 0xef);
mipi_dsi_dcs_write_seq(dsi, 0xd4, 0x02);
- mipi_dsi_dcs_write_seq(dsi, 0x11);
- mipi_dsi_dcs_write_seq(dsi, 0x29);
ret = mipi_dsi_dcs_set_tear_on(dsi, 1);
if (ret < 0) {
--
2.39.2
[PATCH 1/2] drm/panel: ltk050h3146w: add MIPI_DSI_MODE_VIDEO to LTK050H3148W flags
From: Heiko Stuebner
Similar to other variants, the LTK050H3148W wants to run in video mode
when displaying data. So far only the Synopsis DSI driver was using this
panel and it is always switching to video mode, independent of this flag
being set.
Other DSI drivers might handle this differently, so add the flag.
Fixes: e5f9d543419c ("drm/panel: ltk050h3146w: add support for Leadtek
LTK050H3148W-CTA6 variant")
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
b/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
index 30919c872ac8..a50f5330a661 100644
--- a/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
+++ b/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
@@ -326,7 +326,8 @@ static const struct drm_display_mode ltk050h3148w_mode = {
static const struct ltk050h3146w_desc ltk050h3148w_data = {
.mode = _mode,
.init = ltk050h3148w_init_sequence,
- .mode_flags = MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
MIPI_DSI_MODE_VIDEO_BURST,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+ MIPI_DSI_MODE_VIDEO_BURST,
};
static int ltk050h3146w_init_sequence(struct ltk050h3146w *ctx)
--
2.39.2
Re: [PATCH 0/3] drm/panel: add one more Leadtek panel, the ltk101b4029w
On Thu, 15 Feb 2024 10:05:12 +0100, Heiko Stuebner wrote: > Similar in setup to the ltk500hd1829, group it with this driver. > > Heiko Stuebner (3): > drm/panel: ltk500hd1829: make room for more similar panels > dt-bindings: display: ltk500hd1829: add variant compatible for > ltk101b4029w > drm/panel: ltk500hd1829: add panel type for ltk101b4029w > > [...] Applied, thanks! Adapted the commit message in the binding patch to show where the panels are similar but also different (init-sequence) [1/3] drm/panel: ltk500hd1829: make room for more similar panels commit: f9488c160d6e8e5e548452a0d36057a1f8c04045 [2/3] dt-bindings: display: ltk500hd1829: add variant compatible for ltk101b4029w commit: c71efc6337135670164334404ef11506b31b7a81 [3/3] drm/panel: ltk500hd1829: add panel type for ltk101b4029w commit: 239cce651ea617002ff26f068f2568b2baf6421a Best regards, -- Heiko Stuebner
Re: [PATCH 1/2] dt-bindings: vendor-prefixes: add prefix for admatec GmbH
On Thu, 15 Feb 2024 10:04:41 +0100, Heiko Stuebner wrote: > From: Heiko Stuebner > > admatec GmbH is a german supplier for industrial displays. > > Applied, thanks! Adding the link to the manufacturer Conor suggested. [1/2] dt-bindings: vendor-prefixes: add prefix for admatec GmbH commit: 9de552935b6ceaa113d205232fde70e5345bdf29 [2/2] dt-bindings: display: panel-lvds: Add compatible for admatec 9904370 panel commit: c530379a6876eb4c9c4a83f1b65d8cd9d66ee229 Best regards, -- Heiko Stuebner
[PATCH 0/3] drm/panel: add one more Leadtek panel, the ltk101b4029w
Similar in setup to the ltk500hd1829, group it with this driver. Heiko Stuebner (3): drm/panel: ltk500hd1829: make room for more similar panels dt-bindings: display: ltk500hd1829: add variant compatible for ltk101b4029w drm/panel: ltk500hd1829: add panel type for ltk101b4029w .../display/panel/leadtek,ltk500hd1829.yaml | 4 +- .../drm/panel/panel-leadtek-ltk500hd1829.c| 265 -- 2 files changed, 244 insertions(+), 25 deletions(-) -- 2.39.2
[PATCH 3/3] drm/panel: ltk500hd1829: add panel type for ltk101b4029w
From: Heiko Stuebner
The ltk101b4029w ist a 10.1 inch DSI panel and shares the same supplies
and startup timings with the existing ltk500hd1829.
So simply add it as a variant with its own init sequence and display-mode.
Signed-off-by: Heiko Stuebner
---
.../drm/panel/panel-leadtek-ltk500hd1829.c| 196 ++
1 file changed, 196 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
index 42f4e2584af18..7bc538b7c6b7c 100644
--- a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
+++ b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
@@ -43,6 +43,198 @@ struct ltk500hd1829 {
bool prepared;
};
+static const struct ltk500hd1829_cmd ltk101b4029w_init[] = {
+ /* Page0 */
+ { 0xE0, 0x00 },
+ /* PASSWORD */
+ { 0xE1, 0x93 },
+ { 0xE2, 0x65 },
+ { 0xE3, 0xF8 },
+ { 0x80, 0x03 }, /* 0X03:4-LANE; 0X02:3-LANE; 0X01:2-LANE */
+ /* Page1 */
+ { 0xE0, 0x01 },
+ /* Set VCOM */
+ { 0x00, 0x00 },
+ { 0x01, 0x6F },
+ /* Set Gamma Power, VGMP,VGMN,VGSP,VGSN */
+ { 0x17, 0x00 },
+ { 0x18, 0xAF }, /* 4.3V */
+ { 0x19, 0x01 }, /* 0.3V */
+ { 0x1A, 0x00 },
+ { 0x1B, 0xAF }, /* 4.3V */
+ { 0x1C, 0x01 }, /* 0.3V */
+ /* Set Gate Power */
+ { 0x1F, 0x3E }, /* VGH_R = 15V */
+ { 0x20, 0x28 }, /* VGL_R = -12V */
+ { 0x21, 0x28 }, /* VGL_R2 = -12V */
+ { 0x22, 0x7E },
+ /* SETPANEL */
+ { 0x35, 0x26 },
+ { 0x37, 0x09 },
+ /* SET RGBCYC */
+ { 0x38, 0x04 },
+ { 0x39, 0x00 },
+ { 0x3A, 0x01 },
+ { 0x3C, 0x7C },
+ { 0x3D, 0xFF },
+ { 0x3E, 0xFF },
+ { 0x3F, 0x7F },
+ /* Set TCON */
+ { 0x40, 0x06 }, /* RSO = 800 RGB */
+ { 0x41, 0xA0 }, /* LN = 640->1280 line */
+ { 0x42, 0x81 },
+ { 0x43, 0x08 }, /* VFP = 8 */
+ { 0x44, 0x0B }, /* VBP = 12 */
+ { 0x45, 0x28 }, /* HBP = 40 */
+ /* power voltage */
+ { 0x55, 0x0F }, /* DCDCM = 0001, JD PWR_IC */
+ { 0x57, 0x69 },
+ { 0x59, 0x0A }, /* VCL = -2.9V */
+ { 0x5A, 0x28 }, /* VGH = 15V */
+ { 0x5B, 0x14 }, /* VGL = -11V */
+ /* Gamma */
+ { 0x5D, 0x7C },
+ { 0x5E, 0x65 },
+ { 0x5F, 0x55 },
+ { 0x60, 0x47 },
+ { 0x61, 0x43 },
+ { 0x62, 0x32 },
+ { 0x63, 0x34 },
+ { 0x64, 0x1C },
+ { 0x65, 0x33 },
+ { 0x66, 0x31 },
+ { 0x67, 0x30 },
+ { 0x68, 0x4E },
+ { 0x69, 0x3C },
+ { 0x6A, 0x44 },
+ { 0x6B, 0x35 },
+ { 0x6C, 0x31 },
+ { 0x6D, 0x23 },
+ { 0x6E, 0x11 },
+ { 0x6F, 0x00 },
+ { 0x70, 0x7C },
+ { 0x71, 0x65 },
+ { 0x72, 0x55 },
+ { 0x73, 0x47 },
+ { 0x74, 0x43 },
+ { 0x75, 0x32 },
+ { 0x76, 0x34 },
+ { 0x77, 0x1C },
+ { 0x78, 0x33 },
+ { 0x79, 0x31 },
+ { 0x7A, 0x30 },
+ { 0x7B, 0x4E },
+ { 0x7C, 0x3C },
+ { 0x7D, 0x44 },
+ { 0x7E, 0x35 },
+ { 0x7F, 0x31 },
+ { 0x80, 0x23 },
+ { 0x81, 0x11 },
+ { 0x82, 0x00 },
+/* Page2, for GIP */
+ { 0xE0, 0x02 },
+ /* GIP_L Pin mapping */
+ { 0x00, 0x1E },
+ { 0x01, 0x1E },
+ { 0x02, 0x41 },
+ { 0x03, 0x41 },
+ { 0x04, 0x43 },
+ { 0x05, 0x43 },
+ { 0x06, 0x1F },
+ { 0x07, 0x1F },
+ { 0x08, 0x35 },
+ { 0x09, 0x1F },
+ { 0x0A, 0x15 },
+ { 0x0B, 0x15 },
+ { 0x0C, 0x1F },
+ { 0x0D, 0x47 },
+ { 0x0E, 0x47 },
+ { 0x0F, 0x45 },
+ { 0x10, 0x45 },
+ { 0x11, 0x4B },
+ { 0x12, 0x4B },
+ { 0x13, 0x49 },
+ { 0x14, 0x49 },
+ { 0x15, 0x1F },
+ /* GIP_R Pin mapping */
+ { 0x16, 0x1E },
+ { 0x17, 0x1E },
+ { 0x18, 0x40 },
+ { 0x19, 0x40 },
+ { 0x1A, 0x42 },
+ { 0x1B, 0x42 },
+ { 0x1C, 0x1F },
+ { 0x1D, 0x1F },
+ { 0x1E, 0x35 },
+ { 0x1F, 0x1F },
+ { 0x20, 0x15 },
+ { 0x21, 0x15 },
+ { 0x22, 0x1f },
+ { 0x23, 0x46 },
+ { 0x24, 0x46 },
+ { 0x25, 0x44 },
+ { 0x26, 0x44 },
+ { 0x27, 0x4A },
+ { 0x28, 0x4A },
+ { 0x29, 0x48 },
+ { 0x2A, 0x48 },
+ { 0x2B, 0x1F },
+ /* GIP Timing */
+ { 0x58, 0x40 },
+ { 0x5B, 0x30 },
+ { 0x5C, 0x03 },
+ { 0x5D, 0x30 },
+ { 0x5E, 0x01 },
+ { 0x5F, 0x02 },
+ { 0x63, 0x14 },
+ { 0x64, 0x6A },
+ { 0x67, 0x73 },
+ { 0x68, 0x05 },
+ { 0x69, 0x14 },
+ { 0x6A, 0x6A },
+ { 0x6B, 0x08 },
+ { 0x6C, 0x00 },
+ { 0x6D, 0x00 },
+ { 0x6E, 0x00 },
+ { 0x6F, 0x88 },
+ { 0x77, 0xDD },
+ { 0x79, 0x0E },
+ { 0x7A, 0x03 },
+ { 0x7D, 0x14 },
+ { 0x7E, 0x6A },
+ /* Page4 */
+ { 0xE0, 0x04 },
+ { 0x09, 0
[PATCH 1/3] drm/panel: ltk500hd1829: make room for more similar panels
From: Heiko Stuebner
There exist more dsi-panels from Leadtek sharing supplies and timings
with only the panel-mode and init commands differing.
So make room in the driver to also keep variants here instead of
requiring additional drivers per panel.
Signed-off-by: Heiko Stuebner
---
.../drm/panel/panel-leadtek-ltk500hd1829.c| 73 ---
1 file changed, 47 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
index 39e408c9f762f..42f4e2584af18 100644
--- a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
+++ b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
@@ -21,25 +22,32 @@
#include
#include
+struct ltk500hd1829_cmd {
+ char cmd;
+ char data;
+};
+
+struct ltk500hd1829_desc {
+ const struct drm_display_mode *mode;
+ const struct ltk500hd1829_cmd *init;
+ unsigned int num_init;
+};
+
struct ltk500hd1829 {
struct device *dev;
struct drm_panel panel;
struct gpio_desc *reset_gpio;
struct regulator *vcc;
struct regulator *iovcc;
+ const struct ltk500hd1829_desc *panel_desc;
bool prepared;
};
-struct ltk500hd1829_cmd {
- char cmd;
- char data;
-};
-
/*
* There is no description in the Reference Manual about these commands.
* We received them from the vendor, so just use them as is.
*/
-static const struct ltk500hd1829_cmd init_code[] = {
+static const struct ltk500hd1829_cmd ltk500hd1829_init[] = {
{ 0xE0, 0x00 },
{ 0xE1, 0x93 },
{ 0xE2, 0x65 },
@@ -260,6 +268,26 @@ static const struct ltk500hd1829_cmd init_code[] = {
{ 0x35, 0x00 },
};
+static const struct drm_display_mode ltk500hd1829_mode = {
+ .hdisplay = 720,
+ .hsync_start= 720 + 50,
+ .hsync_end = 720 + 50 + 50,
+ .htotal = 720 + 50 + 50 + 50,
+ .vdisplay = 1280,
+ .vsync_start= 1280 + 30,
+ .vsync_end = 1280 + 30 + 4,
+ .vtotal = 1280 + 30 + 4 + 12,
+ .clock = 69217,
+ .width_mm = 62,
+ .height_mm = 110,
+};
+
+static const struct ltk500hd1829_desc ltk500hd1829_data = {
+ .mode = _mode,
+ .init = ltk500hd1829_init,
+ .num_init = ARRAY_SIZE(ltk500hd1829_init),
+};
+
static inline
struct ltk500hd1829 *panel_to_ltk500hd1829(struct drm_panel *panel)
{
@@ -324,8 +352,8 @@ static int ltk500hd1829_prepare(struct drm_panel *panel)
/* tRT: >= 5ms */
usleep_range(5000, 6000);
- for (i = 0; i < ARRAY_SIZE(init_code); i++) {
- ret = mipi_dsi_generic_write(dsi, _code[i],
+ for (i = 0; i < ctx->panel_desc->num_init; i++) {
+ ret = mipi_dsi_generic_write(dsi, >panel_desc->init[i],
sizeof(struct ltk500hd1829_cmd));
if (ret < 0) {
dev_err(panel->dev, "failed to write init cmds: %d\n",
ret);
@@ -359,31 +387,17 @@ static int ltk500hd1829_prepare(struct drm_panel *panel)
return ret;
}
-static const struct drm_display_mode default_mode = {
- .hdisplay = 720,
- .hsync_start= 720 + 50,
- .hsync_end = 720 + 50 + 50,
- .htotal = 720 + 50 + 50 + 50,
- .vdisplay = 1280,
- .vsync_start= 1280 + 30,
- .vsync_end = 1280 + 30 + 4,
- .vtotal = 1280 + 30 + 4 + 12,
- .clock = 69217,
- .width_mm = 62,
- .height_mm = 110,
-};
-
static int ltk500hd1829_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
{
struct ltk500hd1829 *ctx = panel_to_ltk500hd1829(panel);
struct drm_display_mode *mode;
- mode = drm_mode_duplicate(connector->dev, _mode);
+ mode = drm_mode_duplicate(connector->dev, ctx->panel_desc->mode);
if (!mode) {
dev_err(ctx->dev, "failed to add mode %ux%u@%u\n",
- default_mode.hdisplay, default_mode.vdisplay,
- drm_mode_vrefresh(_mode));
+ ctx->panel_desc->mode->hdisplay,
ctx->panel_desc->mode->vdisplay,
+ drm_mode_vrefresh(ctx->panel_desc->mode));
return -ENOMEM;
}
@@ -413,6 +427,10 @@ static int ltk500hd1829_probe(struct mipi_dsi_device *dsi)
if (!ctx)
return -ENOMEM;
+ ctx->panel_desc = of_device_get_match_data(dev);
+ if (!ctx->panel_desc)
+ return -EINVAL;
+
ctx->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(ctx->reset_gpio)) {
dev_err(dev, &
[PATCH 2/3] dt-bindings: display: ltk500hd1829: add variant compatible for ltk101b4029w
From: Heiko Stuebner Add the compatible for the ltk101b4029w panel, that is really similar to the ltk500hd1829. Signed-off-by: Heiko Stuebner --- .../bindings/display/panel/leadtek,ltk500hd1829.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml b/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml index c5944b4d636c5..d589f16772145 100644 --- a/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml +++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml @@ -14,7 +14,9 @@ allOf: properties: compatible: -const: leadtek,ltk500hd1829 +enum: + - leadtek,ltk101b4029w + - leadtek,ltk500hd1829 reg: true backlight: true reset-gpios: true -- 2.39.2
[PATCH 1/2] dt-bindings: vendor-prefixes: add prefix for admatec GmbH
From: Heiko Stuebner admatec GmbH is a german supplier for industrial displays. Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 1a0dc04f1db47..fef2e12b504ee 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -61,6 +61,8 @@ patternProperties: description: Analog Devices, Inc. "^adieng,.*": description: ADI Engineering, Inc. + "^admatec,.*": +description: admatec GmbH "^advantech,.*": description: Advantech Corporation "^aeroflexgaisler,.*": -- 2.39.2
[PATCH 2/2] dt-bindings: display: panel-lvds: Add compatible for admatec 9904370 panel
From: Heiko Stuebner The 9904379 is a 10.1" 1024x600 LVDS display using the standard lvds properties. Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/display/panel/panel-lvds.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml index 3fb24393529cd..155d8ffa8f6ef 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml @@ -39,6 +39,8 @@ properties: compatible: items: - enum: + # Admatec 9904379 10.1" 1024x600 LVDS panel + - admatec,9904379 - auo,b101ew05 # Chunghwa Picture Tubes Ltd. 7" WXGA (800x1280) TFT LCD LVDS panel - chunghwa,claa070wp03xg -- 2.39.2
Re: [PATCH] drm/rockchip: vop2: add a missing unlock in vop2_crtc_atomic_enable()
On Fri, 19 Jan 2024 11:08:40 -0800, Harshit Mogalapalli wrote: > Unlock before returning on the error path. > > Applied, thanks! [1/1] drm/rockchip: vop2: add a missing unlock in vop2_crtc_atomic_enable() commit: b6ddaa63f728d26c12048aed76be99c24f435c41 Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v2 1/6] dt-bindings: display: rockchip: rockchip, dw-hdmi: remove port property
On Wed, 31 Jan 2024 22:14:29 +0100, Johan Jonker wrote: > The hdmi-connector nodes are now functional and the new way to model > hdmi ports nodes with both in and output port subnodes. Unfortunately > with the conversion to YAML the old method with only an input port node > was used. Later the new method was also added to the binding. > A binding must be unambiguously, so remove the old port property > entirely and make port@0 and port@1 a requirement as all > upstream dts files are updated as well and because checking > deprecated stuff is a bit pointless. > Update the example to avoid use of the removed property. > > [...] Applied, thanks! [3/6] ARM: dts: rockchip: fix rk3288 hdmi ports node commit: 585e4dc07100a6465b3da8d24e46188064c1c925 [4/6] ARM: dts: rockchip: fix rk322x hdmi ports node commit: 15a5ed03000cf61daf87d14628085cb1bc8ae72c [5/6] arm64: dts: rockchip: fix rk3328 hdmi ports node commit: 1d00ba4700d1e0f88ae70d028d2e17e39078fa1c [6/6] arm64: dts: rockchip: fix rk3399 hdmi ports node commit: f051b6ace7ffcc48d6d1017191f167c0a85799f6 Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v2 1/6] dt-bindings: display: rockchip: rockchip, dw-hdmi: remove port property
On Wed, 31 Jan 2024 22:14:29 +0100, Johan Jonker wrote: > The hdmi-connector nodes are now functional and the new way to model > hdmi ports nodes with both in and output port subnodes. Unfortunately > with the conversion to YAML the old method with only an input port node > was used. Later the new method was also added to the binding. > A binding must be unambiguously, so remove the old port property > entirely and make port@0 and port@1 a requirement as all > upstream dts files are updated as well and because checking > deprecated stuff is a bit pointless. > Update the example to avoid use of the removed property. > > [...] Applied, thanks! [1/6] dt-bindings: display: rockchip: rockchip,dw-hdmi: remove port property commit: 0d192c4c72ce00ab07a6b27f068607e21f754a46 [2/6] dt-bindings: display: rockchip,dw-hdmi: add power-domains property commit: 6b1f93ea345947c94bf3a7a6e668a2acfd310918 Best regards, -- Heiko Stuebner
Re: (subset) [PATCH 0/7] Add Support for RK3566 Powkiddy RGB10MAX3
On Mon, 12 Feb 2024 12:49:43 -0600, Chris Morgan wrote: > From: Chris Morgan > > Add support for the Powkiddy RGB10MAX3 handheld gaming console. > > [1] > https://powkiddy.com/products/pre-sale-powkiddy-rgb10max3-handheld-game-console > > Chris Morgan (7): > dt-bindings: display: st7703: Add Powkiddy RGB10MAX3 panel > drm/panel: st7703: Add Powkiddy RGB10MAX3 Panel Support > dt-bindings: display: Document ST7703 panel rotation > drm/panel: st7703: Add Panel Rotation Support > arm64: dts: rockchip: Update powkiddy rk2023 dtsi for RGB10MAX3 > dt-bindings: arm: rockchip: Add Powkiddy RGB10MAX3 > arm64: dts: rockchip: Add Powkiddy RGB10MAX3 > > [...] Applied, thanks! [5/7] arm64: dts: rockchip: Update powkiddy rk2023 dtsi for RGB10MAX3 commit: 039a03c377d64ec832a8fb1b8f8b5badd404989f [6/7] dt-bindings: arm: rockchip: Add Powkiddy RGB10MAX3 commit: fbe7823623a8c02759afdfb521709f4fa216849a [7/7] arm64: dts: rockchip: Add Powkiddy RGB10MAX3 commit: 4b325c0d4f539b553a4529f16476f08757779293 Best regards, -- Heiko Stuebner
Re: [PATCH v6 31/36] drm/rockchip: inno_hdmi: Switch to HDMI connector
Am Montag, 12. Februar 2024, 14:13:14 CET schrieb Maxime Ripard:
> The new HDMI connector infrastructure allows to remove some boilerplate,
> especially to generate infoframes. Let's switch to it.
>
> Signed-off-by: Maxime Ripard
Acked-by: Heiko Stuebner
> ---
> drivers/gpu/drm/rockchip/inno_hdmi.c | 123
> ---
> 1 file changed, 42 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
> b/drivers/gpu/drm/rockchip/inno_hdmi.c
> index 1d2261643743..d59947679042 100644
> --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
> @@ -67,9 +67,7 @@ struct inno_hdmi {
>
> struct inno_hdmi_connector_state {
> struct drm_connector_state base;
> - unsigned intenc_out_format;
> unsigned intcolorimetry;
> - boolrgb_limited_range;
> };
>
> static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder *encoder)
> @@ -257,26 +255,29 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi)
> inno_hdmi_standby(hdmi);
> }
>
> -static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi,
> - enum hdmi_infoframe_type type)
> +static int inno_hdmi_disable_frame(struct drm_connector *connector,
> +enum hdmi_infoframe_type type)
> {
> - struct drm_connector *connector = >connector;
> + struct inno_hdmi *hdmi = connector_to_inno_hdmi(connector);
>
> if (type != HDMI_INFOFRAME_TYPE_AVI) {
> drm_err(connector->dev,
> "Unsupported infoframe type: %u\n", type);
> - return;
> + return 0;
> }
>
> hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, INFOFRAME_AVI);
> +
> + return 0;
> }
>
> -static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi,
> - union hdmi_infoframe *frame, enum
> hdmi_infoframe_type type)
> +static int inno_hdmi_upload_frame(struct drm_connector *connector,
> + enum hdmi_infoframe_type type,
> + const u8 *buffer, size_t len)
> {
> - struct drm_connector *connector = >connector;
> + struct inno_hdmi *hdmi = connector_to_inno_hdmi(connector);
> u8 packed_frame[HDMI_MAXIMUM_INFO_FRAME_SIZE];
> - ssize_t rc, i;
> + ssize_t i;
>
> if (type != HDMI_INFOFRAME_TYPE_AVI) {
> drm_err(connector->dev,
> @@ -284,59 +285,19 @@ static int inno_hdmi_upload_frame(struct inno_hdmi
> *hdmi,
> return 0;
> }
>
> - inno_hdmi_disable_frame(hdmi, type);
> + inno_hdmi_disable_frame(connector, type);
>
> - rc = hdmi_infoframe_pack(frame, packed_frame,
> - sizeof(packed_frame));
> - if (rc < 0)
> - return rc;
> -
> - for (i = 0; i < rc; i++)
> + for (i = 0; i < len; i++)
> hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_ADDR + i,
> packed_frame[i]);
>
> return 0;
> }
>
> -static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
> - struct drm_display_mode *mode)
> -{
> - struct drm_connector *connector = >connector;
> - struct drm_connector_state *conn_state = connector->state;
> - struct inno_hdmi_connector_state *inno_conn_state =
> - to_inno_hdmi_conn_state(conn_state);
> - union hdmi_infoframe frame;
> - int rc;
> -
> - rc = drm_hdmi_avi_infoframe_from_display_mode(,
> - >connector,
> - mode);
> - if (rc) {
> - inno_hdmi_disable_frame(hdmi, HDMI_INFOFRAME_TYPE_AVI);
> - return rc;
> - }
> -
> - if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444)
> - frame.avi.colorspace = HDMI_COLORSPACE_YUV444;
> - else if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV422)
> - frame.avi.colorspace = HDMI_COLORSPACE_YUV422;
> - else
> - frame.avi.colorspace = HDMI_COLORSPACE_RGB;
> -
> - if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_RGB) {
> - drm_hdmi_avi_infoframe_quant_range(,
> -connector, mode,
> -
> inno_conn_state->rgb_limited_range ?
> -
> HDMI_QUANTI
Re: (subset) [PATCH 0/7] Add Support for RK3566 Powkiddy RGB10MAX3
On Mon, 12 Feb 2024 12:49:43 -0600, Chris Morgan wrote: > From: Chris Morgan > > Add support for the Powkiddy RGB10MAX3 handheld gaming console. > > [1] > https://powkiddy.com/products/pre-sale-powkiddy-rgb10max3-handheld-game-console > > Chris Morgan (7): > dt-bindings: display: st7703: Add Powkiddy RGB10MAX3 panel > drm/panel: st7703: Add Powkiddy RGB10MAX3 Panel Support > dt-bindings: display: Document ST7703 panel rotation > drm/panel: st7703: Add Panel Rotation Support > arm64: dts: rockchip: Update powkiddy rk2023 dtsi for RGB10MAX3 > dt-bindings: arm: rockchip: Add Powkiddy RGB10MAX3 > arm64: dts: rockchip: Add Powkiddy RGB10MAX3 > > [...] Applied, thanks! [1/7] dt-bindings: display: st7703: Add Powkiddy RGB10MAX3 panel commit: 9913a60f318b6c88ea8385048952e3557464bb84 [2/7] drm/panel: st7703: Add Powkiddy RGB10MAX3 Panel Support commit: e0c732291250e205fb834881ad7ecf9ee3ffef45 [3/7] dt-bindings: display: Document ST7703 panel rotation commit: 20b18c2be4f3dcb5448ecc122484bef6c2852fdd [4/7] drm/panel: st7703: Add Panel Rotation Support commit: 762195e5c26936b891fb54ba0183aa3ef366b41e I've adapted the binding subjects to poin to the rocktech,jh057n00900 panel that gets changed and also dropped the one added newline as requested by Guido. Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v4 0/4] arm64: rockchip: Pine64 PineTab2 support
On Sat, 27 Jan 2024 10:48:41 +0100, Manuel Traut wrote: > This adds support for the BOE TH101MB31IG002 LCD Panel used in PineTab2 [1] > and > PineTab-V [2] as well as the devictrees for the PineTab2 v0.1 and v2.0. > > The BOE LCD Panel patch was retrieved from [3]. The function-name prefix has > been adapted and the LCD init section was simplified. > > The PineTab2 devicetree patch was retrieved from [4]. Some renaming was needed > to pass the dtb-checks, the brightness-levels are specified as range and steps > instead of a list of values. > > [...] Applied, thanks! [3/4] dt-bindings: arm64: rockchip: Add Pine64 PineTab2 commit: 6a0a5a2a71b3e3c4ae1ee0b34a496cbf2d980832 [4/4] arm64: dts: rockchip: Add devicetree for Pine64 PineTab2 commit: 1b7e19448f8fbeee23111795f67a003431c40b27 Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v4 00/29] Add HDMI support for RK3128
On Fri, 22 Dec 2023 18:41:51 +0100, Alex Bee wrote: > This is version 4 of my series that aims to add support for the display > controller (VOP) and the HDMI controller block of RK3128 (which is very > similar to the one found in RK3036). The original intention of this series > was to add support for this slightly different integration but is by now, > driven by maintainer's feedback, exploded to be a rework of inno-hdmi > driver in large parts. It is, however, a change for the better. > > [...] Applied, thanks! [27/29] ARM: dts: rockchip: Add display subsystem for RK3128 commit: 695b9b57443d88a1c8e0567c88a79d1a4532c75e [28/29] ARM: dts: rockchip: Add HDMI node for RK3128 commit: 3fd6e33f8fde16869d4cd9cef71ca964b2b0789b [29/29] ARM: dts: rockchip: Enable HDMI output for XPI-3128 commit: 5aab66e319df2a6fc4ab06bcb4bd974c1ac4927e Best regards, -- Heiko Stuebner
Re: [PATCH v2] drm/rockchip: vop2: Drop unused if_dclk_rate variable
On Fri, 5 Jan 2024 19:40:06 +0200, Cristian Ciocaltea wrote:
> Commit 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588")
> introduced a variable which ended up being unused:
>
> rockchip_drm_vop2.c:1688:23: warning: variable ‘if_dclk_rate’ set but not
> used [-Wunused-but-set-variable]
>
> This has been initially used as part of a formula to compute the clock
> dividers, but eventually it has been replaced by static values.
>
> [...]
Applied, thanks!
[1/1] drm/rockchip: vop2: Drop unused if_dclk_rate variable
commit: 196da3f3f76a46905f7daab29c56974f1aba9a7a
Best regards,
--
Heiko Stuebner
Re: [PATCH 0/2] drm/panel: ltk050h3146w: error-path debug message improvements
On Thu, 4 Jan 2024 13:41:56 +0100, Quentin Schulz wrote: > This hides an error message if EPROBE_DEFER was returned when trying to > get the reset GPIO. > > This also makes use of dev_err_probe in lieu of hand-crafted logic > inside the driver. > > Thanks, > Quentin > > [...] Applied, thanks! [1/2] drm/panel: ltk050h3146w: only print message when GPIO getting is not EPROBE_DEFER commit: 65afd91e8d70e10c7f99126d61bf0045ef52d271 [2/2] drm/panel: ltk050h3146w: use dev_err_probe wherever possible commit: 056a9965e58e47928e8afd4dc017221f9221b3d3 Best regards, -- Heiko Stuebner
Re: [PATCH v2 0/2] drm/rockchip: lvds: improve erroring out when drm_of_find_panel_or_bridge fails
On Mon, 20 Nov 2023 13:29:47 +0100, Quentin Schulz wrote: > drm_of_find_panel_or_bridge may return a different error code than > EPROBE_DEFER so let's not overwrite it. > > At the same time, let's demote the DRM_DEV_ERROR message to > dev_err_probe so that the scary message isn't shown (by default) > whenever EPROBE_DEFER is returned to not mislead users. > > [...] Applied, thanks! [1/2] drm/rockchip: lvds: do not overwrite error code commit: 79b09453c4e369ca81cfb670d0136d089e3b92f0 [2/2] drm/rockchip: lvds: do not print scary message when probing defer commit: 52d11c863ac92e36a0365249f7f6d27ac48c78bc Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v4 00/29] Add HDMI support for RK3128
On Fri, 22 Dec 2023 18:41:51 +0100, Alex Bee wrote: > This is version 4 of my series that aims to add support for the display > controller (VOP) and the HDMI controller block of RK3128 (which is very > similar to the one found in RK3036). The original intention of this series > was to add support for this slightly different integration but is by now, > driven by maintainer's feedback, exploded to be a rework of inno-hdmi > driver in large parts. It is, however, a change for the better. > > [...] Applied, thanks! [23/29] drm/rockchip: inno_hdmi: Add variant support commit: 5f2e93e6719701a91307090f8f7696fd6b3bffdf [24/29] drm/rockchip: inno_hdmi: Add RK3128 support commit: aa54f334c291effe321aa4b9ac0e67a895fd7b58 [25/29] drm/rockchip: inno_hdmi: Add basic mode validation commit: 701029621d4141d0c9f8b81a88a37b95ec84ce65 [26/29] drm/rockchip: inno_hdmi: Drop custom fill_modes hook commit: 50a3c772bd927dd409c484832ddd9f6bf00b7389 For reference, Rob has applied the rk3128 compatible in https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git/commit/?id=21960bda59852ca961fcd27fba9f92750caccd06 Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: analogix_dp: get encoder port ID from DT
On Wed, 3 Jan 2024 19:13:01 +0100, Lucas Stach wrote: > The VOP2 driver needs this port ID to properly configure the > display data routing. > > Applied, thanks! [1/1] drm/rockchip: analogix_dp: get encoder port ID from DT commit: bb056046c2139c72e20a5b6fc39c9caaf9eac2b8 Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v4 00/29] Add HDMI support for RK3128
On Fri, 22 Dec 2023 18:41:51 +0100, Alex Bee wrote: > This is version 4 of my series that aims to add support for the display > controller (VOP) and the HDMI controller block of RK3128 (which is very > similar to the one found in RK3036). The original intention of this series > was to add support for this slightly different integration but is by now, > driven by maintainer's feedback, exploded to be a rework of inno-hdmi > driver in large parts. It is, however, a change for the better. > > [...] Applied, thanks! [13/29] drm/rockchip: inno_hdmi: Drop HDMI Vendor Infoframe support commit: aa4f96e2de82f5e0dfc0102d08f66918c5e3637f [14/29] drm/rockchip: inno_hdmi: Move infoframe disable to separate function commit: cc9ec38cb2cd32518fe02615d004e96ce2fd0348 [15/29] drm/rockchip: inno_hdmi: Switch to infoframe type commit: 4278ff62b73936a9138b60cc0610381003132b77 [16/29] drm/rockchip: inno_hdmi: Remove unused drm device pointer commit: 153fe8dbd866869846af3a359ecf82d5ad9fe247 [17/29] drm/rockchip: inno_hdmi: Drop irq struct member commit: 073aa696f8cbc170a2c3502c2165aeb835be0156 [18/29] drm/rockchip: inno_hdmi: Remove useless include commit: f68a68fe9d9197ea6aa9cb461270685f370b165e [19/29] drm/rockchip: inno_hdmi: Subclass connector state commit: ceeb0f0104a62c867656c2730a51df47e7350b8f [20/29] drm/rockchip: inno_hdmi: Correctly setup HDMI quantization range commit: 164abbd2b7ef62aae6fc80450a2d085acdc3da3e [21/29] drm/rockchip: inno_hdmi: Don't power up the phy after resetting commit: 71892cee6ceb3e1b88e0bb44b05c8397d8261a85 [22/29] drm/rockchip: inno_hdmi: Split power mode setting commit: f01e33cb586b5fd354cba73052f82c3b4246109d Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v4 00/29] Add HDMI support for RK3128
On Fri, 22 Dec 2023 18:41:51 +0100, Alex Bee wrote: > This is version 4 of my series that aims to add support for the display > controller (VOP) and the HDMI controller block of RK3128 (which is very > similar to the one found in RK3036). The original intention of this series > was to add support for this slightly different integration but is by now, > driven by maintainer's feedback, exploded to be a rework of inno-hdmi > driver in large parts. It is, however, a change for the better. > > [...] Applied, thanks! [02/29] drm/rockchip: vop: Add output selection registers for RK312x commit: 407eaa4aa64a8429094fa75fac00fff5e471138d [03/29] drm/rockchip: inno_hdmi: Fix video timing commit: 47a145c03484d33e65d773169d5ca1b9fe2a492e [04/29] drm/rockchip: inno_hdmi: Remove useless mode_fixup commit: 099be7b6718685ebafb417e74bb637abf992474a [05/29] drm/rockchip: inno_hdmi: Remove useless copy of drm_display_mode commit: 8f0df2012b8a94aed0cc450016f7592c24e92cfb [06/29] drm/rockchip: inno_hdmi: Switch encoder hooks to atomic commit: ff4d4fa76fcc19f7d5d261f717121f0a88ec4e30 [07/29] drm/rockchip: inno_hdmi: Get rid of mode_set commit: d3e040f450ec8e46ff42fa495a433b976ab47686 [08/29] drm/rockchip: inno_hdmi: no need to store vic commit: d7ba3d711cf537ef0ece14cd85d2113ca338a00b [09/29] drm/rockchip: inno_hdmi: Remove unneeded has audio flag commit: f8723484e045ff2d176124484907ec0199c55a0c [10/29] drm/rockchip: inno_hdmi: Remove useless input format commit: c1ceee3248742149d1a602fd913bd88857da1d52 [11/29] drm/rockchip: inno_hdmi: Remove YUV-based csc coefficents commit: 139771b8239c43ad1bd6c2976aa12788096a5483 [12/29] drm/rockchip: inno_hdmi: Remove tmds rate from structure commit: 5f92474844a4fcb7997da20dd1de2031aed1d794 Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: vop2: Avoid use regmap_reinit_cache at runtime
On Sun, 17 Dec 2023 16:44:15 +0800, Andy Yan wrote:
> From: Andy Yan
>
> Marek Report a possible irq lock inversion dependency warning when
> commit 81a06f1d02e5 ("Revert "drm/rockchip: vop2: Use regcache_sync()
> to fix suspend/resume"") lands linux-next.
>
> I can reproduce this warning with:
> CONFIG_PROVE_LOCKING=y
> CONFIG_DEBUG_LOCKDEP=y
>
> [...]
Applied, thanks!
[1/1] drm/rockchip: vop2: Avoid use regmap_reinit_cache at runtime
commit: 3ee348eb36f14e9303a7e9757efb91b0bbf3f7a9
Best regards,
--
Heiko Stuebner
Re: [PATCH] drm/rockchip: vop2: clean up some inconsistent indenting
On Tue, 19 Dec 2023 14:26:35 +0800, Jiapeng Chong wrote: > No functional modification involved. > > drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:1708 rk3588_calc_cru_cfg() warn: > inconsistent indenting. > > Applied, thanks! [1/1] drm/rockchip: vop2: clean up some inconsistent indenting commit: f40e61eb538d35661d6dda1de92867954d776c4a Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v5 00/16] Add VOP2 support on rk3588
On Mon, 11 Dec 2023 19:55:47 +0800, Andy Yan wrote: > From: Andy Yan > > This patch sets aims at enable the VOP2 support on rk3588. > > Main feature of VOP2 on rk3588: > Four video ports: > VP0 Max 4096x2160 > VP1 Max 4096x2160 > VP2 Max 4096x2160 > VP3 Max 2048x1080 > > [...] Applied, thanks! [15/16] arm64: dts: rockchip: Add vop on rk3588 commit: d895dbef3f3a31ab50491bb48552e798cf555987 Best regards, -- Heiko Stuebner
Re: [PATCH] drm/panel: ltk050h3146w: Set burst mode for ltk050h3148w
On Wed, 13 Dec 2023 15:50:45 +0100, Farouk Bouabid wrote:
> The ltk050h3148w variant expects the horizontal component lane byte clock
> cycle(lbcc) to be calculated using lane_mbps (burst mode) instead of the
> pixel clock.
> Using the pixel clock rate by default for this calculation was introduced
> in commit ac87d23694f4 ("drm/bridge: synopsys: dw-mipi-dsi: Use pixel clock
> rate to calculate lbcc") and starting from commit 93e82bb4de01
> ("drm/bridge: synopsys: dw-mipi-dsi: Fix hcomponent lbcc for burst mode")
> only panels that support burst mode can keep using the lane_mbps. So add
> MIPI_DSI_MODE_VIDEO_BURST as part of the mode_flags for the dsi host.
>
> [...]
Applied, thanks!
[1/1] drm/panel: ltk050h3146w: Set burst mode for ltk050h3148w
commit: 6c9dbee84cd005bed5f9d07b3a2797ae6414b435
Best regards,
--
Heiko Stuebner
Re: (subset) [PATCH v5 00/16] Add VOP2 support on rk3588
On Mon, 11 Dec 2023 19:55:47 +0800, Andy Yan wrote: > From: Andy Yan > > This patch sets aims at enable the VOP2 support on rk3588. > > Main feature of VOP2 on rk3588: > Four video ports: > VP0 Max 4096x2160 > VP1 Max 4096x2160 > VP2 Max 4096x2160 > VP3 Max 2048x1080 > > [...] Applied, thanks! [10/16] dt-bindings: display: vop2: Add rk3588 support commit: 4ccdc92c1fea732fac8f3438d6288719055fa141 [11/16] dt-bindings: rockchip,vop2: Add more endpoint definition commit: dc7226acacc6502291446f9e33cf96246ec49a30 [12/16] drm/rockchip: vop2: Add support for rk3588 commit: 5a028e8f062fc862f051f8e62a0d5a1abac91955 [13/16] drm/rockchip: vop2: rename VOP_FEATURE_OUTPUT_10BIT to VOP2_VP_FEATURE_OUTPUT_10BIT commit: 9d7fe7704d534c2d043aff2987f10671a8b4373d [16/16] MAINTAINERS: Add myself as a reviewer for rockchip drm commit: 6c3ab21f37a97a868193ccbeb8a492e51210ff31 I skipped the debugfs patch for now, as I need to look at that separately and of course the dts patch as that needs to wait for iommu maintainers to pick up the binding addition. Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v5 00/16] Add VOP2 support on rk3588
On Mon, 11 Dec 2023 19:55:47 +0800, Andy Yan wrote: > From: Andy Yan > > This patch sets aims at enable the VOP2 support on rk3588. > > Main feature of VOP2 on rk3588: > Four video ports: > VP0 Max 4096x2160 > VP1 Max 4096x2160 > VP2 Max 4096x2160 > VP3 Max 2048x1080 > > [...] Applied, thanks! [01/16] drm/rockchip: move output interface related definition to rockchip_drm_drv.h commit: 8c8546546f256f834e9c7cab48e5946df340d1a8 [02/16] Revert "drm/rockchip: vop2: Use regcache_sync() to fix suspend/resume" commit: 81a06f1d02e588cfa14c5e5953d9dc50b1d404be [03/16] drm/rockchip: vop2: set half_block_en bit in all mode commit: bebad6bd4fbdc448ad3b337ad281b813e68f6f53 [04/16] drm/rockchip: vop2: clear afbc en and transform bit for cluster window at linear mode commit: 20529a68307feed00dd3d431d3fff0572616b0f2 [05/16] drm/rockchip: vop2: Add write mask for VP config done commit: d1f8face0fc1298c88ef4a0479c3027b46ca2c77 [06/16] drm/rockchip: vop2: Set YUV/RGB overlay mode commit: dd49ee4614cfb0b1f627c4353b60cecfe998a374 [07/16] drm/rockchip: vop2: set bg dly and prescan dly at vop2_post_config commit: 075a5b3969becb1ebc2f1d4fa1a1fe9163679273 [08/16] drm/rockchip: vop2: rename grf to sys_grf commit: c408af1afc4b74ea6df69e0313be97f1f83e981a Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v5 00/16] Add VOP2 support on rk3588
On Mon, 11 Dec 2023 19:55:47 +0800, Andy Yan wrote: > From: Andy Yan > > This patch sets aims at enable the VOP2 support on rk3588. > > Main feature of VOP2 on rk3588: > Four video ports: > VP0 Max 4096x2160 > VP1 Max 4096x2160 > VP2 Max 4096x2160 > VP3 Max 2048x1080 > > [...] Applied, thanks! [09/16] dt-bindings: soc: rockchip: add rk3588 vop/vo syscon commit: 1a648f8b7994dca4c323911607cf28d1eb44c198 Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v1 1/3] dt-bindings: drm: rockchip: convert inno_hdmi-rockchip.txt to yaml
On Mon, 4 Dec 2023 18:39:03 +0100, Johan Jonker wrote: > Convert inno_hdmi-rockchip.txt to yaml. > > Applied, thanks! [2/3] ARM: dts: rockchip: rk3036: fix hdmi ports node commit: 27ded76ef0fcfcf939914532aae575cf23c221b4 [3/3] ARM: dts: rockchip: rk3036-kylin: add hdmi-connector node commit: 569b26af7919c15a8ce231b4fae29cfbd811f144 And changed the connector-type to "a" :-) Best regards, -- Heiko Stuebner
Re: [PATCH 00/31] Fix and improve Rockchip RK3128 support
Hi Alex, Am Dienstag, 29. August 2023, 19:16:16 CET schrieb Alex Bee: > this series fixes some issues I found when testing my "new" RK3128 board > with the mainline kernel and adds some core functionality like SMP bringup, > usb and networking. before I discard this thread, is everything from here migrated to separate serieses or are there patches in this big pile that are still relevant on their own, that haven't been applied? [I lost track of what did go where ;-) ] Thanks Heiko
Re: (subset) [PATCH V2 00/10] rockchip: Add Powkiddy X55
On Mon, 4 Dec 2023 12:57:09 -0600, Chris Morgan wrote: > From: Chris Morgan > > Add support for the Rockchip RK3566 based Powkiddy X55 handheld gaming > console. > > Changes since V1: > - Corrected a bug with the DRM mode flags for the video driver. > - Adjusted panel front and back porch and pixel clock to fix >issues with display that occurred after correcting DRM mode >flag bug. > - Add a new clk frequency for PLL_VPLL to get panel to run at ~60hz. > > [...] Applied, thanks! [09/10] dt-bindings: arm: rockchip: Add Powkiddy X55 commit: b7d755653790b5f5497df8bfb146c38beeb33b74 [10/10] arm64: dts: rockchip: Add Powkiddy X55 commit: 009e2d0c224913eb4f44e9c2efe7a15789fc0c18 Best regards, -- Heiko Stuebner
Re: (subset) [PATCH V2 00/10] rockchip: Add Powkiddy X55
On Mon, 4 Dec 2023 12:57:09 -0600, Chris Morgan wrote: > From: Chris Morgan > > Add support for the Rockchip RK3566 based Powkiddy X55 handheld gaming > console. > > Changes since V1: > - Corrected a bug with the DRM mode flags for the video driver. > - Adjusted panel front and back porch and pixel clock to fix >issues with display that occurred after correcting DRM mode >flag bug. > - Add a new clk frequency for PLL_VPLL to get panel to run at ~60hz. > > [...] Applied, thanks! [07/10] clk: rockchip: Mark pclk_usb as critical on rk3568 commit: 721bf080f249ab2adcc4337abe164230bfb8594f [08/10] clk: rockchip: rk3568: Add PLL rate for 126.4MHz commit: 685da6972647b486980c0cc8fd6bb5d3863fd6b7 Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v2 0/5] Add power-controller and gpu for RK3128
On Sat, 2 Dec 2023 13:51:39 +0100, Alex Bee wrote: > The first patch in this series fixes the pm-domain driver and adds > power-domains which are currently missing. This touches the ABI which is > not and was never used until now. Not all of them are used yet, but when > the power-controller is added to the DT in patch 2 the ABI should not > be changed again. > Patch 3-5 are adding the the gpu compatible to dt-bindings, adding the gpu > node and the respective operating points to SoC DT and finally enabling it > for XPI-3128 board. > > [...] Applied, thanks! [3/5] dt-bindings: gpu: mali-utgard: Add Rockchip RK3128 compatible commit: 5d86c15c3171c3ecebd84d53e30d9812b5591c84 Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: rk3066_hdmi: include drm/drm_atomic.h
On Wed, 22 Nov 2023 23:18:29 +0100, Arnd Bergmann wrote: > From: Arnd Bergmann > > Without this header, the newly added code fails to build: > > drivers/gpu/drm/rockchip/rk3066_hdmi.c: In function > 'rk3066_hdmi_encoder_enable': > drivers/gpu/drm/rockchip/rk3066_hdmi.c:397:22: error: implicit declaration of > function 'drm_atomic_get_new_connector_state'; did you mean > 'drm_atomic_helper_connector_reset'? [-Werror=implicit-function-declaration] > 397 | conn_state = drm_atomic_get_new_connector_state(state, > >connector); > | ^~ > | drm_atomic_helper_connector_reset > drivers/gpu/drm/rockchip/rk3066_hdmi.c:397:20: error: assignment to 'struct > drm_connector_state *' from 'int' makes pointer from integer without a cast > [-Werror=int-conversion] > 397 | conn_state = drm_atomic_get_new_connector_state(state, > >connector); > |^ > drivers/gpu/drm/rockchip/rk3066_hdmi.c:401:22: error: implicit declaration of > function 'drm_atomic_get_new_crtc_state'; did you mean > 'drm_atomic_helper_swap_state'? [-Werror=implicit-function-declaration] > 401 | crtc_state = drm_atomic_get_new_crtc_state(state, > conn_state->crtc); > | ^ > | drm_atomic_helper_swap_state > drivers/gpu/drm/rockchip/rk3066_hdmi.c:401:20: error: assignment to 'struct > drm_crtc_state *' from 'int' makes pointer from integer without a cast > [-Werror=int-conversion] > 401 | crtc_state = drm_atomic_get_new_crtc_state(state, > conn_state->crtc); > |^ > > [...] Applied, thanks! [1/1] drm/rockchip: rk3066_hdmi: include drm/drm_atomic.h commit: f4814c20d14ca168382e8887c768f290e4a2a861 Very puzzling, I did testbuild with the atomic conversion in place and also re-did it again to before applying this patch and didn't get the mentioned error - not sure what I might have done differently to create a dufferent reszkt, In any case, I applied the fix. Best regards, -- Heiko Stuebner
Re: [PATCH v1 3/4] drm/rockchip: rk3066_hdmi: Remove useless output format
Hi Johan,
Am Donnerstag, 2. November 2023, 14:42:19 CET schrieb Johan Jonker:
> The Rk3066 hdmi output format is hard coded to RGB. Remove
> all useless code related to colorimetry and enc_out_format.
>
> Signed-off-by: Johan Jonker
I guess my first question is, is the hardcoding happening just because
of missing functionality in the driver, or does the hardware only
support RGB?
> ---
> drivers/gpu/drm/rockchip/rk3066_hdmi.c | 20 +---
> 1 file changed, 1 insertion(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> index 0e7aae341960..f2b1b2faa096 100644
> --- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> +++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> @@ -23,8 +23,6 @@
>
> struct hdmi_data_info {
> int vic; /* The CEA Video ID (VIC) of the current drm display mode. */
> - unsigned int enc_out_format;
> - unsigned int colorimetry;
> };
>
> struct rk3066_hdmi_i2c {
> @@ -200,14 +198,7 @@ static int rk3066_hdmi_config_avi(struct rk3066_hdmi
> *hdmi,
> rc = drm_hdmi_avi_infoframe_from_display_mode(,
> >connector, mode);
>
> - if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV444)
> - frame.avi.colorspace = HDMI_COLORSPACE_YUV444;
> - else if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV422)
> - frame.avi.colorspace = HDMI_COLORSPACE_YUV422;
> - else
> - frame.avi.colorspace = HDMI_COLORSPACE_RGB;
> -
> - frame.avi.colorimetry = hdmi->hdmi_data.colorimetry;
> + frame.avi.colorspace = HDMI_COLORSPACE_RGB;
> frame.avi.scan_mode = HDMI_SCAN_MODE_NONE;
>
> return rk3066_hdmi_upload_frame(hdmi, rc, ,
> @@ -329,15 +320,6 @@ static int rk3066_hdmi_setup(struct rk3066_hdmi *hdmi,
> struct drm_display_info *display = >connector.display_info;
>
> hdmi->hdmi_data.vic = drm_match_cea_mode(mode);
> - hdmi->hdmi_data.enc_out_format = HDMI_COLORSPACE_RGB;
> -
> - if (hdmi->hdmi_data.vic == 6 || hdmi->hdmi_data.vic == 7 ||
> - hdmi->hdmi_data.vic == 21 || hdmi->hdmi_data.vic == 22 ||
> - hdmi->hdmi_data.vic == 2 || hdmi->hdmi_data.vic == 3 ||
> - hdmi->hdmi_data.vic == 17 || hdmi->hdmi_data.vic == 18)
> - hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_601;
> - else
> - hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709;
while I can understand the RGB output format, why does the colorimetry
also get removed? This looks like it is dependent on the mode itself
and not the output format?
Thanks
Heiko
Re: [PATCH] drm/rockchip: vop2: Add NV20 and NV30 support
On Wed, 25 Oct 2023 21:32:46 +, Jonas Karlman wrote: > Add support for the 10-bit 4:2:2 and 4:4:4 formats NV20 and NV30. > > These formats can be tested using modetest [1]: > > modetest -P @:1920x1080@ > > e.g. on a ROCK 3 Model A (rk3568): > > [...] Applied, thanks! [1/1] drm/rockchip: vop2: Add NV20 and NV30 support commit: 5fc6aa7db080fd90ef00846aac04e8a211088132 Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v1 0/4] Rockchip rk3066_hdmi update
On Thu, 2 Nov 2023 14:40:13 +0100, Johan Jonker wrote: > Update the Rockchip rk3066_hdmi driver in a somewhat similar way > to what is proposed for the inno_hdmi driver. > > Johan Jonker (4): > drm/rockchip: rk3066_hdmi: Remove useless mode_fixup > drm/rockchip: rk3066_hdmi: Switch encoder hooks to atomic > drm/rockchip: rk3066_hdmi: Remove useless output format > drm/rockchip: rk3066_hdmi: Remove unused drm device pointer > > [...] Applied, thanks! [1/4] drm/rockchip: rk3066_hdmi: Remove useless mode_fixup commit: 1044f4a31734eef000f42cdaaf35bb2f76286be5 [2/4] drm/rockchip: rk3066_hdmi: Switch encoder hooks to atomic commit: ae3436a5e7c2ef4f92938133bd99f92fc47ea34e Best regards, -- Heiko Stuebner
Re: [PATCH v2] drm/rockchip: vop: Fix color for RGB888/BGR888 format on VOP full
On Thu, 26 Oct 2023 19:14:58 +, Jonas Karlman wrote: > Use of DRM_FORMAT_RGB888 and DRM_FORMAT_BGR888 on e.g. RK3288, RK3328 > and RK3399 result in wrong colors being displayed. > > The issue can be observed using modetest: > > modetest -s @:1920x1080-60@RG24 > modetest -s @:1920x1080-60@BG24 > > [...] Applied, thanks! [1/1] drm/rockchip: vop: Fix color for RGB888/BGR888 format on VOP full commit: bb0a05acd6121ff0e810b44fdc24dbdfaa46b642 Best regards, -- Heiko Stuebner
Re: (subset) [PATCH V4 0/6] rockchip: Add Powkiddy RK2023
On Fri, 17 Nov 2023 14:25:30 -0600, Chris Morgan wrote: > From: Chris Morgan > > Add support for the Powkiddy RK2023, which is extremely similar to > existing Powkiddy RGB30 device. > > Changes since V3: > - Corrected commit subject lines. > > [...] Applied, thanks! [4/6] dt-bindings: arm: rockchip: Add Powkiddy RK2023 commit: 213615d742f0c039ab73f8946ae18000cf2c7b65 [5/6] arm64: dts: rockchip: Update powkiddy,rgb30 include to rk2023 DTSI commit: 46d84ceb7eec85b60e8a5eb0dfb2fae6a1bf4166 [6/6] arm64: dts: rockchip: Add Powkiddy RK2023 commit: e926380ea2a2b10d01069917e6d678ca818f6ad8 Best regards, -- Heiko Stuebner
Re: [PATCH v5 0/2] drm/rockchip: vop: Add NV15, NV20 and NV30 support
On Mon, 23 Oct 2023 17:37:13 +, Jonas Karlman wrote: > This series add support for displaying 10-bit 4:2:0 and 4:2:2 formats produced > by the Rockchip Video Decoder on RK322X, RK3288, RK3328, RK3368 and RK3399. > Also include 10-bit 4:4:4 support since VOP can support that also. > > First patch adds new fourcc 10-bit YUV formats with 4:2:2/4:4:4 sub-sampling. > Second patch adds support for displaying the new fourcc formats. > > [...] Applied, thanks! [1/2] drm/fourcc: Add NV20 and NV30 YUV formats commit: 728c15b4b5f3369cbde73d5e0f14701ab370f985 [2/2] drm/rockchip: vop: Add NV15, NV20 and NV30 support commit: d4b384228562848e4b76b608a5876c92160e993c Best regards, -- Heiko Stuebner
Re: [PATCH] drm/bridge: synopsys: dw-mipi-dsi: Fix hcomponent lbcc for burst mode
On Wed, 18 Oct 2023 11:52:12 +0800, Liu Ying wrote: > In order to support burst mode, vendor drivers set lane_mbps higher than > bandwidth through DPI interface. So, calculate horizontal component lane > byte clock cycle(lbcc) based on lane_mbps instead of pixel clock rate for > burst mode. > > Applied, thanks! [1/1] drm/bridge: synopsys: dw-mipi-dsi: Fix hcomponent lbcc for burst mode commit: 93e82bb4de0196c4caeca1d8a6eef67863981d8f Best regards, -- Heiko Stuebner
Re: [PATCH v3 0/4] Add more format for vop2 driver
On Wed, 18 Oct 2023 17:41:22 +0800, Andy Yan wrote: > From: Andy Yan > > > This is a preparation for the upcoming support for rk3588 vop. > > Patch 1 make the bpp calculation covery more format > Patch 2 remove formats that are unsupported by cluster windows > Patch 3 add more formats > Patch 4 is a format table rename > > [...] Applied, thanks! [1/4] drm/rockchip: fix vop format bpp calculation commit: 45ad07c7053df0b67e13d8deb574920d11651fb2 [2/4] drm/rockchip: remove the unsupported format of vop2 cluster window commit: 01d5a75370a60c3a8d691347ae6ebb2a9f8dc44a [3/4] drm/rockchip: Add more format supported by vop2 commit: bfd8a5c228fa3bb97884f77529c09e8745da08b9 [4/4] drm/rockchip: rename windows format for vop2 commit: 215737e37d07ade8952048339e37aec6c6f82223 I've adapted the patch subjects slightly to match the current drm/rockchip: vop: ... drm/rockchip: vop2: ... formats. Best regards, -- Heiko Stuebner
Re: (subset) [PATCH 0/5] rockchip: Add Powkiddy RK2023
On Wed, 18 Oct 2023 11:18:43 -0500, Chris Morgan wrote: > From: Chris Morgan > > Add support for the Powkiddy RK2023, which is extremely similar to > existing devices from Anbernic. > > Chris Morgan (5): > dt-bindings: display: panel: Update NewVision NV3051D compatibles > drm/panel: nv3051d: Add Powkiddy RK2023 Panel Support > clk: rockchip: rk3568: Add PLL rate for 115.2MHz > dt-bindings: arm: rockchip: Add Powkiddy RK2023 > arm64: dts: rockchip: add Powkiddy RK2023 > > [...] Applied, thanks! [3/5] clk: rockchip: rk3568: Add PLL rate for 115.2MHz commit: ccf59682a0287b81015dc1939203fac70b818c6b I've gone forward and grabbed the PLL rate already, so it can go together with the other rate addition from the fixes series. Best regards, -- Heiko Stuebner
Re: (subset) [PATCH 0/5] Add Support for RK3566 Powkiddy RGB30
On Fri, 13 Oct 2023 13:39:13 -0500, Chris Morgan wrote: > From: Chris Morgan > > Add support for the Powkiddy RGB30 handheld gaming console. > > Chris Morgan (5): > dt-bindings: vendor-prefixes: document Powkiddy > dt-bindings: panel: Add Powkiddy RGB30 panel compatible > drm/panel: st7703: Add Powkiddy RGB30 Panel Support > dt-bindings: arm64: rockchip: add Powkiddy RGB30 > arm64: dts: rockchip: add support for Powkiddy RGB30 > > [...] Applied, thanks! [4/5] dt-bindings: arm64: rockchip: add Powkiddy RGB30 commit: 64d0de4f65c2951ccdc7a7aebe8a7e3455946f5f [5/5] arm64: dts: rockchip: add support for Powkiddy RGB30 commit: 1e9ac3e8a6a9d4da9efbad2d8e95cc1140e0e23f Best regards, -- Heiko Stuebner
Re: (subset) [PATCH 0/5] Add Support for RK3566 Powkiddy RGB30
On Fri, 13 Oct 2023 13:39:13 -0500, Chris Morgan wrote: > From: Chris Morgan > > Add support for the Powkiddy RGB30 handheld gaming console. > > Chris Morgan (5): > dt-bindings: vendor-prefixes: document Powkiddy > dt-bindings: panel: Add Powkiddy RGB30 panel compatible > drm/panel: st7703: Add Powkiddy RGB30 Panel Support > dt-bindings: arm64: rockchip: add Powkiddy RGB30 > arm64: dts: rockchip: add support for Powkiddy RGB30 > > [...] Applied, thanks! [1/5] dt-bindings: vendor-prefixes: document Powkiddy commit: 00e395c8edf7fb6fa0830125d91c2b4bc381eefd [2/5] dt-bindings: panel: Add Powkiddy RGB30 panel compatible commit: daee0320a13724e5a584726b693eee87bbd96172 [3/5] drm/panel: st7703: Add Powkiddy RGB30 Panel Support commit: 636a989eb4d022e1756009592445aedaaf7424d8 Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: Fix type promotion bug in rockchip_gem_iommu_map()
On Wed, 11 Oct 2023 11:01:48 +0300, Dan Carpenter wrote: > The "ret" variable is declared as ssize_t and it can hold negative error > codes but the "rk_obj->base.size" variable is type size_t. This means > that when we compare them, they are both type promoted to size_t and the > negative error code becomes a high unsigned value and is treated as > success. Add a cast to fix this. > > > [...] Applied, thanks! [1/1] drm/rockchip: Fix type promotion bug in rockchip_gem_iommu_map() commit: 6471da5ee311d53ef46eebcb7725bc94266cc0cf Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v2 0/4] Some cleanup of vop2 driver
On Fri, 13 Oct 2023 20:20:01 +0800, Andy Yan wrote: > From: Andy Yan > > This is a preparation for the upcoming support for rk3588 vop. > Patch 1 remove unused struct > Patch 2 remove NR_LAYERS macro to support more layers on rk3588 > Patch 3 are plane format fix > Patch 4 is a format rename > > [...] Applied, thanks! [1/4] drm/rockchip: remove unused struct in vop2 commit: ac1c11c23fc51c1ba51a3ed586df40ffe6b1de35 [2/4] drm/rockchip: remove NR_LAYERS macro on vop2 commit: dc00748adcf03d754bf43035c668bc5b20fb6597 So I've picked up the pretty straight-forward patches for now. Best regards, -- Heiko Stuebner
Re: [PATCH 1/3] drm/panel: ltk050h3146w: add mipi_dsi_device.mode_flags to of_match_data
On Mon, 31 Jan 2022 17:47:21 +0100, quentin.sch...@theobroma-systems.com wrote: > From: Quentin Schulz > > To prepare for a new display to be supported by this driver which has a > slightly different set of DSI mode related flags, let's move the > currently hardcoded mode flags to the .data field of of_device_id > structure. > > [...] Applied, thanks! [1/3] drm/panel: ltk050h3146w: add mipi_dsi_device.mode_flags to of_match_data commit: 99403d747ae8c7b3bfb5cd14c8908930ec6801c6 [2/3] drm/panel: ltk050h3146w: add support for Leadtek LTK050H3148W-CTA6 variant commit: e5f9d543419c78ac58f3b3557bc5a76b20ff600b [3/3] dt-bindings: ltk050h3146w: add compatible for LTK050H3148W-CTA6 variant commit: 29d8e38c36cb662331a833699c359ec1af1edbec Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: vop2: Convert to use maple tree register cache
On Sun, 01 Oct 2023 01:42:50 +0200, Mark Brown wrote: > The maple tree register cache is based on a much more modern data structure > than the rbtree cache and makes optimisation choices which are probably > more appropriate for modern systems than those made by the rbtree cache. > > Applied, thanks! [1/1] drm/rockchip: vop2: Convert to use maple tree register cache commit: 3d59c22bbb8d03f3f14e6d0845d44c146fb48f35 Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: cdn-dp: Fix some error handling paths in cdn_dp_probe()
On Sat, 2 Sep 2023 19:34:31 +0200, Christophe JAILLET wrote: > cdn_dp_audio_codec_init() can fail. So add some error handling. > > If component_add() fails, the previous cdn_dp_audio_codec_init() call > should be undone, as already done in the remove function. > > Applied, thanks! [1/1] drm/rockchip: cdn-dp: Fix some error handling paths in cdn_dp_probe() commit: 44b968d0d0868b7a9b7a5c64464ada464ff4d532 Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: vop2: Demote message in mod_supported to drm_dbg_kms
On Mon, 9 Oct 2023 12:37:53 +0200, Michael Tretter wrote: > Checking if a modifier is supported by a plane is normal behavior. It is > normal that a plane may not support certain modifiers. Failing the check > doesn't justify an error message in the kernel log and may mislead > users. > > Demote the error message to drm_dbg_kms to only print the message if the > respective debug messages are enabled. This is similar to the behavior > in rockchip_drm_vop.c. > > [...] Applied, thanks! [1/1] drm/rockchip: vop2: Demote message in mod_supported to drm_dbg_kms commit: eb23cffdd7f085149799e5eda12a9aff792cc34d Best regards, -- Heiko Stuebner
Re: [PATCH -next] drm/rockchip: dsi: Use devm_platform_get_and_ioremap_resource()
On Fri, 21 Apr 2023 16:13:03 +0800, Yang Li wrote: > Convert platform_get_resource(), devm_ioremap_resource() to a single > call to devm_platform_get_and_ioremap_resource(), as this is exactly > what this function does. > > Applied, thanks! [1/1] drm/rockchip: dsi: Use devm_platform_get_and_ioremap_resource() commit: 253a1d33e5cfdf62525f5d6ed2bf03acbadd1582 Best regards, -- Heiko Stuebner
Re: [PATCH -next] drm/rockchip: remove redundant of_match_ptr
On Mon, 31 Jul 2023 20:53:04 +0800, Zhu Wang wrote: > The driver depends on CONFIG_OF, so it is not necessary to use > of_match_ptr here. > > Even for drivers that do not depend on CONFIG_OF, it's almost always > better to leave out the of_match_ptr(), since the only thing it can > possibly do is to save a few bytes of .text if a driver can be used both > with and without it. Hence we remove of_match_ptr. > > [...] Applied, thanks! [1/1] drm/rockchip: remove redundant of_match_ptr commit: 63a06c9fe30bf84d1ab6f07d0e408bd1d4ccaf85 Best regards, -- Heiko Stuebner
Re: [PATCH v2 0/5] drm/rockchip: Fix crtc duplicate state and crtc reset funcs
On Wed, 21 Jun 2023 22:33:15 + (UTC), Jonas Karlman wrote: > This series fixes a reset of state in duplicate state crtc funcs for VOP > driver, a possible crash and ensure crtc reset helper is called in VOP2 > driver. > > Patch 1 use kmemdup instead of kzalloc to duplicate the crtc state. > Patch 2 change to use crtc and plane cleanup helpers directly. > Patch 3 adds a null guard for allocation failure. > Patch 4 adds a crash guard for empty crtc state. > Patch 5 adds a missing call to crtc reset helper. > > [...] Applied, thanks! [1/5] drm/rockchip: vop: Fix reset of state in duplicate state crtc funcs commit: 13fc28804bf10ca0b7bce3efbba95c534836d7ca [2/5] drm/rockchip: vop: Use cleanup helper directly as destroy funcs commit: 800f7c332df7cd9614c416fd005a6bb53f96f13c [3/5] drm/rockchip: vop: Fix call to crtc reset helper commit: 5aacd290837828c089a83ac9795c74c4c9e2c923 [4/5] drm/rockchip: vop2: Don't crash for invalid duplicate_state commit: 342f7e4967d02b0ec263b15916304fc54841b608 [5/5] drm/rockchip: vop2: Add missing call to crtc reset helper commit: 4d49d87b3606369c6e29b9d051892ee1a6fc4e75 Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: Don't spam logs in atomic check
On Tue, 8 Aug 2023 11:44:05 +0100, Daniel Stone wrote: > Userspace should not be able to trigger DRM_ERROR messages to spam the > logs; especially not through atomic commit parameters which are > completely legitimate for userspace to attempt. > > Applied, thanks! [1/1] drm/rockchip: Don't spam logs in atomic check commit: 43dae319b50fac075ad864f84501c703ef20eb2b Best regards, -- Heiko Stuebner
Re: [PATCH v2 1/2] pwm: Manage owner assignment implicitly for drivers
Am Freitag, 4. August 2023, 16:27:06 CEST schrieb Uwe Kleine-König: > Instead of requiring each driver to care for assigning the owner member > of struct pwm_ops, handle that implicitly using a macro. Note that the > owner member has to be moved to struct pwm_chip, as the ops structure > usually lives in read-only memory and so cannot be modified. > > The upside is that new lowlevel drivers cannot forget the assignment and > save one line each. The pwm-crc driver didn't assign .owner, that's not > a problem in practise though as the driver cannot be compiled as a > module. > > Signed-off-by: Uwe Kleine-König > --- > drivers/pwm/pwm-rockchip.c | 1 - Acked-by: Heiko Stuebner #pwm-rockchip
Re: [PATCH] drm: Explicitly include correct DT includes
Am Freitag, 14. Juli 2023, 19:45:34 CEST schrieb Rob Herring: > The DT of_device.h and of_platform.h date back to the separate > of_platform_bus_type before it as merged into the regular platform bus. > As part of that merge prepping Arm DT support 13 years ago, they > "temporarily" include each other. They also include platform_device.h > and of.h. As a result, there's a pretty much random mix of those include > files used throughout the tree. In order to detangle these headers and > replace the implicit includes with struct declarations, users need to > explicitly include the correct includes. > > Signed-off-by: Rob Herring > --- [...] > diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c > b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c > index 917e79951aac..2744d8f4a6fa 100644 > --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c > +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c > @@ -12,7 +12,9 @@ > #include > #include > #include > +#include > #include > +#include > #include > #include I'm not sure if I'm just misreading something, but in all other places of_device.h gets removed while here is stays as an include. Is this correct this way? Thanks Heiko
Re: [PATCH] phy: Explicitly include correct DT includes
Am Freitag, 14. Juli 2023, 19:48:35 CEST schrieb Rob Herring: > The DT of_device.h and of_platform.h date back to the separate > of_platform_bus_type before it as merged into the regular platform bus. > As part of that merge prepping Arm DT support 13 years ago, they > "temporarily" include each other. They also include platform_device.h > and of.h. As a result, there's a pretty much random mix of those include > files used throughout the tree. In order to detangle these headers and > replace the implicit includes with struct declarations, users need to > explicitly include the correct includes. > > Signed-off-by: Rob Herring > --- > drivers/phy/rockchip/phy-rockchip-dphy-rx0.c | 1 - > drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c | 2 +- > drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 1 - > drivers/phy/rockchip/phy-rockchip-naneng-combphy.c| 3 ++- > drivers/phy/rockchip/phy-rockchip-snps-pcie3.c| 3 ++- Acked-by: Heiko Stuebner
Re: [PATCH] drm/rockchip: vop2: Use regcache_sync() to fix suspend/resume
On Mon, 17 Apr 2023 14:37:47 +0200, Sascha Hauer wrote:
> afa965a45e01 ("drm/rockchip: vop2: fix suspend/resume") uses
> regmap_reinit_cache() to fix the suspend/resume issue with the VOP2
> driver. During discussion it came up that we should rather use
> regcache_sync() instead. As the original patch is already applied
> fix this up in this follow-up patch.
>
>
> [...]
Applied, thanks!
[1/1] drm/rockchip: vop2: Use regcache_sync() to fix suspend/resume
commit: b63a553e8f5aa6574eeb535a551817a93c426d8c
Best regards,
--
Heiko Stuebner
Re: [PATCH] drm/rockchip: vop2: fix suspend/resume
On Thu, 13 Apr 2023 16:43:47 +0200, Sascha Hauer wrote: > During a suspend/resume cycle the VO power domain will be disabled and > the VOP2 registers will reset to their default values. After that the > cached register values will be out of sync and the read/modify/write > operations we do on the window registers will result in bogus values > written. Fix this by re-initializing the register cache each time we > enable the VOP2. With this the VOP2 will show a picture after a > suspend/resume cycle whereas without this the screen stays dark. > > [...] Applied, thanks! [1/1] drm/rockchip: vop2: fix suspend/resume commit: afa965a45e01e541cdbe5c8018226eff117610f0 Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v6 01/17] dt-bindings: display: rockchip: convert rockchip-lvds.txt to YAML
On Thu, 22 Dec 2022 15:22:14 +0100, Johan Jonker wrote: > Convert rockchip-lvds.txt to YAML. > > Changed: > Add power-domains property. > Requirements between PX30 and RK3288 > > > [...] Applied, thanks! [09/17] ARM: dts: rockchip: rk3288: fix dsi node commit: ea2d16f90629e3158307d0183cad5c40aa55c995 [10/17] ARM: dts: rockchip: rk3288: fix lvds node commit: 8a19e4c74d17ed8d1e6bc06b32c5b7b7c3b9fcfb [11/17] ARM: dts: rockchip: rk3288: fix dp node commit: 95e2ac6ae9f2330557a6aef70bf15173e1dd9714 [12/17] arm64: dts: rockchip: px30: fix lvds node commit: 0d5e24918976edee006e07730434a36d264a [13/17] arm64: dts: rockchip: px30: fix dsi node commit: 30322f812d4e0e75e2488c1d45aba94e51dd19bb [14/17] arm64: dts: rockchip: rk3399: fix dsi node commit: f82fe7ad31530b38d2f61aa6ae68bd35c33f4ad0 [15/17] arm64: dts: rockchip: rk3399: fix dp node commit: d94024bd6342c6f3e88c5fac785a685c1974d48e [16/17] arm64: dts: rockchip: rename vbus-supply to phy-supply in rk3566-box-demo.dts commit: fc440ea1732abb714150bb8f3d90672ccc679e2d [17/17] arm64: dts: rockchip: rk356x: remove hclk from dsi node commit: cadda005961cd6a202ae6f8ff99f2bba35a31dc8 Best regards, -- Heiko Stuebner
Re: [PATCH V2] drm/rockchip: vop2: Add error check to devm_regmap_init_mmio
Am Mittwoch, 22. März 2023, 23:44:11 CET schrieb Alfredo Cruz: > devm_regmap_init_mmio() may return an invalid pointer in case of an error. > This patch adds the corresponding IS_ERR check to vop2->map. > > Signed-off-by: Alfredo Cruz applied to drm-misc Thanks for the refresh Heiko
Re: [PATCH] drm/rockchip: vop2: add error check to devm_regmap_init_mmio
Hi Alfredo, while I do agree with the patch content, there are missing: a patch description ... just a customary thing for a change like this but more importantly the Signed-off-by line . Heiko Am Dienstag, 14. März 2023, 20:15:32 CET schrieb Alfredo Cruz: > --- > drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > index 03ca32cd2050..4bde2d354462 100644 > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > @@ -2680,6 +2680,8 @@ static int vop2_bind(struct device *dev, struct device > *master, void *data) > vop2->len = resource_size(res); > > vop2->map = devm_regmap_init_mmio(dev, vop2->regs, _regmap_config); > + if (IS_ERR(vop2->map)) > + return PTR_ERR(vop2->map); > > ret = vop2_win_init(vop2); > if (ret) >
Re: [PATCH] drm/rockchip: vop2: fix uninitialized variable possible_crtcs
On Thu, 16 Mar 2023 09:23:02 -0400, Tom Rix wrote:
> clang reportes this error
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2322:8: error:
> variable 'possible_crtcs' is used uninitialized whenever 'if'
> condition is false [-Werror,-Wsometimes-uninitialized]
> if (vp) {
> ^~
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2336:36: note:
> uninitialized use occurs here
> ret = vop2_plane_init(vop2, win, possible_crtcs);
> ^~
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2322:4:
> note: remove the 'if' if its condition is always true
> if (vp) {
> ^~~~
>
> [...]
Applied, thanks!
[1/1] drm/rockchip: vop2: fix uninitialized variable possible_crtcs
commit: e88adb4ac27a37de4167150b8a6a736d40cf7018
Best regards,
--
Heiko Stuebner
Re: [PATCH] drm/rockchip: vop2: fix uninitialized variable possible_crtcs
Am Donnerstag, 16. März 2023, 14:23:02 CET schrieb Tom Rix:
> clang reportes this error
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2322:8: error:
> variable 'possible_crtcs' is used uninitialized whenever 'if'
> condition is false [-Werror,-Wsometimes-uninitialized]
> if (vp) {
> ^~
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2336:36: note:
> uninitialized use occurs here
> ret = vop2_plane_init(vop2, win, possible_crtcs);
> ^~
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2322:4:
> note: remove the 'if' if its condition is always true
> if (vp) {
> ^~~~
>
> The else-statement changes the win->type to OVERLAY without setting the
> possible_crtcs variable. Rework the block, initialize possible_crtcs to
> 0 to remove the else-statement. Split the else-if-statement out to its
> own if-statement so the OVERLAY check will catch when the win-type has
> been changed.
>
> Fixes: 368419a2d429 ("drm/rockchip: vop2: initialize possible_crtcs properly")
> Signed-off-by: Tom Rix
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> index 03ca32cd2050..fce992c3506f 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> @@ -2301,7 +2301,7 @@ static int vop2_create_crtcs(struct vop2 *vop2)
> nvp = 0;
> for (i = 0; i < vop2->registered_num_wins; i++) {
> struct vop2_win *win = >win[i];
> - u32 possible_crtcs;
> + u32 possible_crtcs = 0;
>
> if (vop2->data->soc_id == 3566) {
> /*
> @@ -2327,12 +2327,11 @@ static int vop2_create_crtcs(struct vop2 *vop2)
> /* change the unused primary window to overlay
> window */
> win->type = DRM_PLANE_TYPE_OVERLAY;
> }
> - } else if (win->type == DRM_PLANE_TYPE_OVERLAY) {
> - possible_crtcs = (1 << nvps) - 1;
> - } else {
> - possible_crtcs = 0;
> }
>
> + if (win->type == DRM_PLANE_TYPE_OVERLAY)
> + possible_crtcs = (1 << nvps) - 1;
> +
After a long hard stare at the code in question, I think doing it this
way looks like the correct one, as as you mention in the commit message
the first "if" will change the win->type to OVERLAY in one case, but this
then will never be added.
Michael, do you agree/disagree?
Thanks
Heiko
https://lore.kernel.org/r/20230315090158.2442771-1-michael.rie...@wolfvision.net
> ret = vop2_plane_init(vop2, win, possible_crtcs);
> if (ret) {
> drm_err(vop2->drm, "failed to init plane %s: %d\n",
>
Re: [PATCH] drm/rockchip: vop2: add polarity flags to RGB output
On Thu, 2 Mar 2023 13:39:49 +0100, Gerald Loacker wrote: > Use h/v-sync and pixel clock polarity flags for RGB output. For all other > outputs this is already implemented. > > Applied, thanks! [1/1] drm/rockchip: vop2: add polarity flags to RGB output commit: 66ab57574f2c8233550f641ecdc34fd0ef61341d Best regards, -- Heiko Stuebner
Re: [PATCH v6 0/4] drm/rockchip: dw_hdmi: Add 4k@30 support
On Thu, 16 Feb 2023 11:24:43 +0100, Sascha Hauer wrote: > One small fix compared to the last version, when checking for valid > resolutions I accidently compared the current mode width with the > maximum allowed height which resulted in wrong resolutions being > discarded. > > Changes since v5: > - Fix wrong check width vs. height > > [...] Applied, thanks! [1/4] drm/rockchip: vop: limit maximium resolution to hardware capabilities commit: 8e140cb60270ee8b5b41e80806323c668d8d4da9 Dropped the height check from the mode_valid function and adding a suitable comment to the commit message. [2/4] drm/rockchip: dw_hdmi: relax mode_valid hook commit: de13db32b0f89a040b50a51d129b9443159a660a [3/4] drm/rockchip: dw_hdmi: Add support for 4k@30 resolution commit: 83b61f817f43ed67572d1e241c9f552e0a8bfff4 [4/4] drm/rockchip: dw_hdmi: discard modes with unachievable pixelclocks commit: d13b10ec6696b0c523fa21b65c7ff6f246a49560 Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: use struct_size() in vop2_bind
On Wed, 22 Feb 2023 17:35:33 -0800, Jacob Keller wrote: > Use the overflow-protected struct_size() helper macro to compute the > allocation size of the vop2 data structure. > > Applied, thanks! [1/1] drm/rockchip: use struct_size() in vop2_bind commit: 3b4db36c4cd9e7e49babe931d7117cdba0d04ce0 Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: dsi: Remove the unused function dsi_read()
On Wed, 8 Feb 2023 10:34:29 +0800, Jiapeng Chong wrote: > The function dsi_read is defined in the dw-mipi-dsi-rockchip.c file, but > not called elsewhere, so remove this unused function. > > drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c:362:19: warning: unused > function 'dsi_read'. > > Applied, thanks! [1/1] drm/rockchip: dsi: Remove the unused function dsi_read() commit: 59585c79f87794c92f040c264b274e86d8522e22 Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: avoid duplicate mappings for IOMMU devices
On Thu, 10 Nov 2022 17:24:14 +, John Keeping wrote: > If a buffer is allocated with alloc_kmap, then it is vmap'd on creation > and there is no reason to map it again in rockchip_gem_prime_vmap() when > the existing mapping can be used. > > Applied, thanks! [1/1] drm/rockchip: avoid duplicate mappings for IOMMU devices commit: 0020d4cfa3eea0e5fad23af49411217da854fc83 Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v3 0/6] drm/rockchip: vop2: add support for the rgb output block
On Tue, 24 Jan 2023 06:47:00 +0100, Michael Riesch wrote:
> This series adds support for the RGB output block that can be found in the
> Rockchip Video Output Processor (VOP) 2. Version 2 of this series
> incorporates the feedback by Dan Carpenter and Sascha Hauer. Version 3
> fixes a dumb mistake pointed out by Sascha :-) Thanks for your comments!
>
> Patches 1-4 clean up the code and make it more general.
>
> [...]
Applied, thanks!
[1/6] drm/rockchip: vop2: initialize possible_crtcs properly
commit: 368419a2d429e2438bef333959732c640310bdc7
[2/6] drm/rockchip: rgb: embed drm_encoder into rockchip_encoder
commit: f8a852f1f86391127ab57b1c41fe0e62bc14f27c
[3/6] drm/rockchip: rgb: add video_port parameter to init function
commit: 03db8f25cf16c579fe75fd2230bbe64c221bfe25
[4/6] drm/rockchip: vop2: use symmetric function pair
vop2_{create,destroy}_crtcs
commit: cc066b056e7bb629a8c4d99c9c4a8ca70a6a
[5/6] drm/rockchip: vop2: add support for the rgb output block
commit: c66c6d7c47058a72a00b50d7f5c4538e3fa49b1c
Best regards,
--
Heiko Stuebner
Re: [PATCH] drm/rockchip: Drop unbalanced obj unref
On Thu, 19 Jan 2023 15:17:34 -0800, Rob Clark wrote: > From: Rob Clark > > In the error path, rockchip_drm_gem_object_mmap() is dropping an obj > reference that it doesn't own. > > Applied, thanks! [1/1] drm/rockchip: Drop unbalanced obj unref commit: 8ee3b0e85f6ccd9e6c527bc50eaba774c3bb18d0 Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: vop: Quiet always-warning AFBC log
On Mon, 31 Oct 2022 10:16:01 -0700, Brian Norris wrote: > The downstream code from which this was derived didn't ever run through > this 'switch' block with non-AFBC formats, but the upstream code does -- > we use this function to probe whether a given format is supported. > > Demote the warning to eliminate this sort of warning seen on every > boot: > > [...] Applied, thanks! [1/1] drm/rockchip: vop: Quiet always-warning AFBC log commit: 582212ee1611f77e0360d249f11c0f703ed723dc Best regards, -- Heiko Stuebner
