From: "Heiko Stübner" <heiko@sntech.de>
To: Andy Yan <andyshrk@163.com>, Andy Yan <andy.yan@rock-chips.com>
Cc: hjc@rock-chips.com, dri-devel@lists.freedesktop.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
krzysztof.kozlowski+dt@linaro.org, robh+dt@kernel.org,
devicetree@vger.kernel.org, sebastian.reichel@collabora.com,
kever.yang@rock-chips.com, chris.obbard@collabora.com,
s.hauer@pengutronix.de
Subject: Re: [PATCH v2 10/12] drm/rockchip: vop2: Add support for rk3588
Date: Tue, 28 Nov 2023 10:44:33 +0100 [thread overview]
Message-ID: <4339687.HovnAMPojK@diego> (raw)
In-Reply-To: <f179e9ae-b2cd-4f6c-badc-4d76d8a3ba0d@rock-chips.com>
Hi Andy,
Am Dienstag, 28. November 2023, 10:32:55 CET schrieb Andy Yan:
> On 11/27/23 23:29, Heiko Stübner wrote:
> > Am Mittwoch, 22. November 2023, 13:55:44 CET schrieb Andy Yan:
> >> From: Andy Yan <andy.yan@rock-chips.com>
> >>
> >> VOP2 on rk3588:
> >>
> >> Four video ports:
> >> VP0 Max 4096x2160
> >> VP1 Max 4096x2160
> >> VP2 Max 4096x2160
> >> VP3 Max 2048x1080
> >>
> >> 4 4K Cluster windows with AFBC/line RGB and AFBC-only YUV support
> >> 4 4K Esmart windows with line RGB/YUV support
> >>
> >> Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
> >>
> >> ---
> >>
> >> Changes in v2:
> >> - add rk3588_ prefix for functions which are rk3588 only
> >> - make some calculation as fixed value and keep calculation formula as
> >> comment
> >> - check return value for some cru calculation functions.
> >> - check return value for syscon_regmap_lookup_by_phandle
> >> - add NV20/NV30 for esmart plane
> >>
> >> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 381 ++++++++++++++++++-
> >> drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 66 ++++
> >> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 221 +++++++++++
> >> 3 files changed, 660 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> >> index 4bcc405bcf11..9eecbe1f71f9 100644
> >> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> >> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> >> @@ -271,9 +282,12 @@ static bool vop2_cluster_window(const struct vop2_win *win)
> >> static void vop2_cfg_done(struct vop2_video_port *vp)
> >> {
> >> struct vop2 *vop2 = vp->vop2;
> >> + u32 val;
> >> +
> >> + val = BIT(vp->id) | (BIT(vp->id) << 16) |
> >> + RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN;
> >>
> >> - regmap_set_bits(vop2->map, RK3568_REG_CFG_DONE,
> >> - BIT(vp->id) | RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN);
> >> + regmap_set_bits(vop2->map, RK3568_REG_CFG_DONE, val);
> > I don't fully understand that code:
> > (1) the write mask is also present on the rk3568, so should this change
> > be a separate patch with a fixes tag?
>
> The write mask of VP config done on rk356x is missing, that means
> you can write the corresponding mask bit, but it has no effect.
>
> I once considered making it a separate patch, I can split it as a separate patch if
> you like.
I think I'd like it to be a separate patch please.
> > (2) RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN does not contain the part for
> > the write-mask
> >
> > #define RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN BIT(15)
> >
> > why is this working then?
>
>
> Actually this bit has no write-mask bit. 🙂
when doing that separate patch mentioned above, could you also add a
comment to the code stating that RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN
doesn't have a write mask bit please?
Because the TRM is not clear and ideally I'd not forget this fact for
the future :-) .
> >> }
> >>
> >> static void vop2_win_disable(struct vop2_win *win)
> > [...]
> >
> >> @@ -1298,7 +1346,11 @@ static void vop2_plane_atomic_update(struct drm_plane *plane,
> >> vop2_win_write(win, VOP2_WIN_AFBC_ENABLE, 1);
> >> vop2_win_write(win, VOP2_WIN_AFBC_FORMAT, afbc_format);
> >> vop2_win_write(win, VOP2_WIN_AFBC_UV_SWAP, uv_swap);
> >> - vop2_win_write(win, VOP2_WIN_AFBC_AUTO_GATING_EN, 0);
> >> + if (vop2->data->soc_id == 3566 || vop2->data->soc_id == 3568)
> >> + vop2_win_write(win, VOP2_WIN_AFBC_AUTO_GATING_EN, 0);
> >> + else
> >> + vop2_win_write(win, VOP2_WIN_AFBC_AUTO_GATING_EN, 1);
> >> +
> > I think this at least warrants a comment, what is happening here. Also,
> > can you already see how future vop2-users are behaving - aka are all new
> > socs in the "else" part of the conditional, or would a switch-case better
> > represent future socs?
>
>
> On rk356x, this bit is auto gating enable, but this function is not work well so
> we need to disable this function.
> On rk3588, and the following new soc(rk3528/rk3576), this bit is gating disable,
> we should write 1 to disable gating when enable a cluster window.
>
>
> Maybe i add some comments in next version ?
Yep that comment would be helpful. And with your explanation the code
itself can stay as it is :-)
Thanks
Heiko
> >> vop2_win_write(win, VOP2_WIN_AFBC_BLOCK_SPLIT_EN, 0);
> >> transform_offset = vop2_afbc_transform_offset(pstate, half_block_en);
> >> vop2_win_write(win, VOP2_WIN_AFBC_HDR_PTR, yrgb_mst);
> >
> >> @@ -1627,9 +1937,17 @@ static void vop2_crtc_atomic_enable(struct drm_crtc *crtc,
> >> drm_for_each_encoder_mask(encoder, crtc->dev, crtc_state->encoder_mask) {
> >> struct rockchip_encoder *rkencoder = to_rockchip_encoder(encoder);
> >>
> >> - rk3568_set_intf_mux(vp, rkencoder->crtc_endpoint_id, polflags);
> >> + /*
> >> + * for drive a high resolution(4KP120, 8K), vop on rk3588/rk3576 need
> >> + * process multi(1/2/4/8) pixels per cycle, so the dclk feed by the
> >> + * system cru may be the 1/2 or 1/4 of mode->clock.
> >> + */
> >> + clock = vop2_set_intf_mux(vp, rkencoder->crtc_endpoint_id, polflags);
> >> }
> >>
> >> + if (!clock)
> >> + return;
> >> +
> > hmm, shouldn't the check for the validity of a mode happen before
> > atomic_enable is run? So this shouldn't error out in the middle of the
> > function?
> >
> >
> >> if (vcstate->output_mode == ROCKCHIP_OUT_MODE_AAAA &&
> >> !(vp_data->feature & VOP_FEATURE_OUTPUT_10BIT))
> >> out_mode = ROCKCHIP_OUT_MODE_P888;
> >
> > Thanks
> > Heiko
> >
> >
> >
> > _______________________________________________
> > Linux-rockchip mailing list
> > Linux-rockchip@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de>
To: Andy Yan <andyshrk@163.com>, Andy Yan <andy.yan@rock-chips.com>
Cc: hjc@rock-chips.com, dri-devel@lists.freedesktop.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
krzysztof.kozlowski+dt@linaro.org, robh+dt@kernel.org,
devicetree@vger.kernel.org, sebastian.reichel@collabora.com,
kever.yang@rock-chips.com, chris.obbard@collabora.com,
s.hauer@pengutronix.de
Subject: Re: [PATCH v2 10/12] drm/rockchip: vop2: Add support for rk3588
Date: Tue, 28 Nov 2023 10:44:33 +0100 [thread overview]
Message-ID: <4339687.HovnAMPojK@diego> (raw)
In-Reply-To: <f179e9ae-b2cd-4f6c-badc-4d76d8a3ba0d@rock-chips.com>
Hi Andy,
Am Dienstag, 28. November 2023, 10:32:55 CET schrieb Andy Yan:
> On 11/27/23 23:29, Heiko Stübner wrote:
> > Am Mittwoch, 22. November 2023, 13:55:44 CET schrieb Andy Yan:
> >> From: Andy Yan <andy.yan@rock-chips.com>
> >>
> >> VOP2 on rk3588:
> >>
> >> Four video ports:
> >> VP0 Max 4096x2160
> >> VP1 Max 4096x2160
> >> VP2 Max 4096x2160
> >> VP3 Max 2048x1080
> >>
> >> 4 4K Cluster windows with AFBC/line RGB and AFBC-only YUV support
> >> 4 4K Esmart windows with line RGB/YUV support
> >>
> >> Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
> >>
> >> ---
> >>
> >> Changes in v2:
> >> - add rk3588_ prefix for functions which are rk3588 only
> >> - make some calculation as fixed value and keep calculation formula as
> >> comment
> >> - check return value for some cru calculation functions.
> >> - check return value for syscon_regmap_lookup_by_phandle
> >> - add NV20/NV30 for esmart plane
> >>
> >> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 381 ++++++++++++++++++-
> >> drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 66 ++++
> >> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 221 +++++++++++
> >> 3 files changed, 660 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> >> index 4bcc405bcf11..9eecbe1f71f9 100644
> >> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> >> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> >> @@ -271,9 +282,12 @@ static bool vop2_cluster_window(const struct vop2_win *win)
> >> static void vop2_cfg_done(struct vop2_video_port *vp)
> >> {
> >> struct vop2 *vop2 = vp->vop2;
> >> + u32 val;
> >> +
> >> + val = BIT(vp->id) | (BIT(vp->id) << 16) |
> >> + RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN;
> >>
> >> - regmap_set_bits(vop2->map, RK3568_REG_CFG_DONE,
> >> - BIT(vp->id) | RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN);
> >> + regmap_set_bits(vop2->map, RK3568_REG_CFG_DONE, val);
> > I don't fully understand that code:
> > (1) the write mask is also present on the rk3568, so should this change
> > be a separate patch with a fixes tag?
>
> The write mask of VP config done on rk356x is missing, that means
> you can write the corresponding mask bit, but it has no effect.
>
> I once considered making it a separate patch, I can split it as a separate patch if
> you like.
I think I'd like it to be a separate patch please.
> > (2) RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN does not contain the part for
> > the write-mask
> >
> > #define RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN BIT(15)
> >
> > why is this working then?
>
>
> Actually this bit has no write-mask bit. 🙂
when doing that separate patch mentioned above, could you also add a
comment to the code stating that RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN
doesn't have a write mask bit please?
Because the TRM is not clear and ideally I'd not forget this fact for
the future :-) .
> >> }
> >>
> >> static void vop2_win_disable(struct vop2_win *win)
> > [...]
> >
> >> @@ -1298,7 +1346,11 @@ static void vop2_plane_atomic_update(struct drm_plane *plane,
> >> vop2_win_write(win, VOP2_WIN_AFBC_ENABLE, 1);
> >> vop2_win_write(win, VOP2_WIN_AFBC_FORMAT, afbc_format);
> >> vop2_win_write(win, VOP2_WIN_AFBC_UV_SWAP, uv_swap);
> >> - vop2_win_write(win, VOP2_WIN_AFBC_AUTO_GATING_EN, 0);
> >> + if (vop2->data->soc_id == 3566 || vop2->data->soc_id == 3568)
> >> + vop2_win_write(win, VOP2_WIN_AFBC_AUTO_GATING_EN, 0);
> >> + else
> >> + vop2_win_write(win, VOP2_WIN_AFBC_AUTO_GATING_EN, 1);
> >> +
> > I think this at least warrants a comment, what is happening here. Also,
> > can you already see how future vop2-users are behaving - aka are all new
> > socs in the "else" part of the conditional, or would a switch-case better
> > represent future socs?
>
>
> On rk356x, this bit is auto gating enable, but this function is not work well so
> we need to disable this function.
> On rk3588, and the following new soc(rk3528/rk3576), this bit is gating disable,
> we should write 1 to disable gating when enable a cluster window.
>
>
> Maybe i add some comments in next version ?
Yep that comment would be helpful. And with your explanation the code
itself can stay as it is :-)
Thanks
Heiko
> >> vop2_win_write(win, VOP2_WIN_AFBC_BLOCK_SPLIT_EN, 0);
> >> transform_offset = vop2_afbc_transform_offset(pstate, half_block_en);
> >> vop2_win_write(win, VOP2_WIN_AFBC_HDR_PTR, yrgb_mst);
> >
> >> @@ -1627,9 +1937,17 @@ static void vop2_crtc_atomic_enable(struct drm_crtc *crtc,
> >> drm_for_each_encoder_mask(encoder, crtc->dev, crtc_state->encoder_mask) {
> >> struct rockchip_encoder *rkencoder = to_rockchip_encoder(encoder);
> >>
> >> - rk3568_set_intf_mux(vp, rkencoder->crtc_endpoint_id, polflags);
> >> + /*
> >> + * for drive a high resolution(4KP120, 8K), vop on rk3588/rk3576 need
> >> + * process multi(1/2/4/8) pixels per cycle, so the dclk feed by the
> >> + * system cru may be the 1/2 or 1/4 of mode->clock.
> >> + */
> >> + clock = vop2_set_intf_mux(vp, rkencoder->crtc_endpoint_id, polflags);
> >> }
> >>
> >> + if (!clock)
> >> + return;
> >> +
> > hmm, shouldn't the check for the validity of a mode happen before
> > atomic_enable is run? So this shouldn't error out in the middle of the
> > function?
> >
> >
> >> if (vcstate->output_mode == ROCKCHIP_OUT_MODE_AAAA &&
> >> !(vp_data->feature & VOP_FEATURE_OUTPUT_10BIT))
> >> out_mode = ROCKCHIP_OUT_MODE_P888;
> >
> > Thanks
> > Heiko
> >
> >
> >
> > _______________________________________________
> > Linux-rockchip mailing list
> > Linux-rockchip@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de>
To: Andy Yan <andyshrk@163.com>, Andy Yan <andy.yan@rock-chips.com>
Cc: devicetree@vger.kernel.org, s.hauer@pengutronix.de,
chris.obbard@collabora.com, hjc@rock-chips.com,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
kever.yang@rock-chips.com, linux-rockchip@lists.infradead.org,
robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
sebastian.reichel@collabora.com
Subject: Re: [PATCH v2 10/12] drm/rockchip: vop2: Add support for rk3588
Date: Tue, 28 Nov 2023 10:44:33 +0100 [thread overview]
Message-ID: <4339687.HovnAMPojK@diego> (raw)
In-Reply-To: <f179e9ae-b2cd-4f6c-badc-4d76d8a3ba0d@rock-chips.com>
Hi Andy,
Am Dienstag, 28. November 2023, 10:32:55 CET schrieb Andy Yan:
> On 11/27/23 23:29, Heiko Stübner wrote:
> > Am Mittwoch, 22. November 2023, 13:55:44 CET schrieb Andy Yan:
> >> From: Andy Yan <andy.yan@rock-chips.com>
> >>
> >> VOP2 on rk3588:
> >>
> >> Four video ports:
> >> VP0 Max 4096x2160
> >> VP1 Max 4096x2160
> >> VP2 Max 4096x2160
> >> VP3 Max 2048x1080
> >>
> >> 4 4K Cluster windows with AFBC/line RGB and AFBC-only YUV support
> >> 4 4K Esmart windows with line RGB/YUV support
> >>
> >> Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
> >>
> >> ---
> >>
> >> Changes in v2:
> >> - add rk3588_ prefix for functions which are rk3588 only
> >> - make some calculation as fixed value and keep calculation formula as
> >> comment
> >> - check return value for some cru calculation functions.
> >> - check return value for syscon_regmap_lookup_by_phandle
> >> - add NV20/NV30 for esmart plane
> >>
> >> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 381 ++++++++++++++++++-
> >> drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 66 ++++
> >> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 221 +++++++++++
> >> 3 files changed, 660 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> >> index 4bcc405bcf11..9eecbe1f71f9 100644
> >> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> >> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> >> @@ -271,9 +282,12 @@ static bool vop2_cluster_window(const struct vop2_win *win)
> >> static void vop2_cfg_done(struct vop2_video_port *vp)
> >> {
> >> struct vop2 *vop2 = vp->vop2;
> >> + u32 val;
> >> +
> >> + val = BIT(vp->id) | (BIT(vp->id) << 16) |
> >> + RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN;
> >>
> >> - regmap_set_bits(vop2->map, RK3568_REG_CFG_DONE,
> >> - BIT(vp->id) | RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN);
> >> + regmap_set_bits(vop2->map, RK3568_REG_CFG_DONE, val);
> > I don't fully understand that code:
> > (1) the write mask is also present on the rk3568, so should this change
> > be a separate patch with a fixes tag?
>
> The write mask of VP config done on rk356x is missing, that means
> you can write the corresponding mask bit, but it has no effect.
>
> I once considered making it a separate patch, I can split it as a separate patch if
> you like.
I think I'd like it to be a separate patch please.
> > (2) RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN does not contain the part for
> > the write-mask
> >
> > #define RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN BIT(15)
> >
> > why is this working then?
>
>
> Actually this bit has no write-mask bit. 🙂
when doing that separate patch mentioned above, could you also add a
comment to the code stating that RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN
doesn't have a write mask bit please?
Because the TRM is not clear and ideally I'd not forget this fact for
the future :-) .
> >> }
> >>
> >> static void vop2_win_disable(struct vop2_win *win)
> > [...]
> >
> >> @@ -1298,7 +1346,11 @@ static void vop2_plane_atomic_update(struct drm_plane *plane,
> >> vop2_win_write(win, VOP2_WIN_AFBC_ENABLE, 1);
> >> vop2_win_write(win, VOP2_WIN_AFBC_FORMAT, afbc_format);
> >> vop2_win_write(win, VOP2_WIN_AFBC_UV_SWAP, uv_swap);
> >> - vop2_win_write(win, VOP2_WIN_AFBC_AUTO_GATING_EN, 0);
> >> + if (vop2->data->soc_id == 3566 || vop2->data->soc_id == 3568)
> >> + vop2_win_write(win, VOP2_WIN_AFBC_AUTO_GATING_EN, 0);
> >> + else
> >> + vop2_win_write(win, VOP2_WIN_AFBC_AUTO_GATING_EN, 1);
> >> +
> > I think this at least warrants a comment, what is happening here. Also,
> > can you already see how future vop2-users are behaving - aka are all new
> > socs in the "else" part of the conditional, or would a switch-case better
> > represent future socs?
>
>
> On rk356x, this bit is auto gating enable, but this function is not work well so
> we need to disable this function.
> On rk3588, and the following new soc(rk3528/rk3576), this bit is gating disable,
> we should write 1 to disable gating when enable a cluster window.
>
>
> Maybe i add some comments in next version ?
Yep that comment would be helpful. And with your explanation the code
itself can stay as it is :-)
Thanks
Heiko
> >> vop2_win_write(win, VOP2_WIN_AFBC_BLOCK_SPLIT_EN, 0);
> >> transform_offset = vop2_afbc_transform_offset(pstate, half_block_en);
> >> vop2_win_write(win, VOP2_WIN_AFBC_HDR_PTR, yrgb_mst);
> >
> >> @@ -1627,9 +1937,17 @@ static void vop2_crtc_atomic_enable(struct drm_crtc *crtc,
> >> drm_for_each_encoder_mask(encoder, crtc->dev, crtc_state->encoder_mask) {
> >> struct rockchip_encoder *rkencoder = to_rockchip_encoder(encoder);
> >>
> >> - rk3568_set_intf_mux(vp, rkencoder->crtc_endpoint_id, polflags);
> >> + /*
> >> + * for drive a high resolution(4KP120, 8K), vop on rk3588/rk3576 need
> >> + * process multi(1/2/4/8) pixels per cycle, so the dclk feed by the
> >> + * system cru may be the 1/2 or 1/4 of mode->clock.
> >> + */
> >> + clock = vop2_set_intf_mux(vp, rkencoder->crtc_endpoint_id, polflags);
> >> }
> >>
> >> + if (!clock)
> >> + return;
> >> +
> > hmm, shouldn't the check for the validity of a mode happen before
> > atomic_enable is run? So this shouldn't error out in the middle of the
> > function?
> >
> >
> >> if (vcstate->output_mode == ROCKCHIP_OUT_MODE_AAAA &&
> >> !(vp_data->feature & VOP_FEATURE_OUTPUT_10BIT))
> >> out_mode = ROCKCHIP_OUT_MODE_P888;
> >
> > Thanks
> > Heiko
> >
> >
> >
> > _______________________________________________
> > Linux-rockchip mailing list
> > Linux-rockchip@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
next prev parent reply other threads:[~2023-11-28 9:44 UTC|newest]
Thread overview: 118+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-22 12:53 [PATCH v2 00/12] Add VOP2 support on rk3588 Andy Yan
2023-11-22 12:53 ` Andy Yan
2023-11-22 12:53 ` Andy Yan
2023-11-22 12:53 ` [PATCH v2 01/12] drm/rockchip: move output interface related definition to rockchip_drm_drv.h Andy Yan
2023-11-22 12:53 ` Andy Yan
2023-11-22 12:53 ` Andy Yan
2023-11-27 14:03 ` Sascha Hauer
2023-11-27 14:03 ` Sascha Hauer
2023-11-27 14:03 ` Sascha Hauer
2023-11-22 12:54 ` [PATCH v2 02/12] Revert "drm/rockchip: vop2: Use regcache_sync() to fix suspend/resume" Andy Yan
2023-11-22 12:54 ` Andy Yan
2023-11-22 12:54 ` Andy Yan
2023-11-27 14:04 ` Sascha Hauer
2023-11-27 14:04 ` Sascha Hauer
2023-11-27 14:04 ` Sascha Hauer
2023-11-22 12:54 ` [PATCH v2 03/12] drm/rockchip: vop2: set half_block_en bit in all mode Andy Yan
2023-11-22 12:54 ` Andy Yan
2023-11-22 12:54 ` Andy Yan
2023-11-27 14:04 ` Sascha Hauer
2023-11-27 14:04 ` Sascha Hauer
2023-11-27 14:04 ` Sascha Hauer
2023-11-27 15:01 ` Heiko Stübner
2023-11-27 15:01 ` Heiko Stübner
2023-11-27 15:01 ` Heiko Stübner
2023-11-22 12:54 ` [PATCH v2 04/12] drm/rockchip: vop2: clear afbc en and transform bit for cluster window at linear mode Andy Yan
2023-11-22 12:54 ` Andy Yan
2023-11-22 12:54 ` Andy Yan
2023-11-27 14:04 ` Sascha Hauer
2023-11-27 14:04 ` Sascha Hauer
2023-11-27 14:04 ` Sascha Hauer
2023-11-27 15:02 ` Heiko Stübner
2023-11-27 15:02 ` Heiko Stübner
2023-11-27 15:02 ` Heiko Stübner
2023-11-28 8:03 ` Andy Yan
2023-11-28 8:03 ` Andy Yan
2023-11-28 8:03 ` Andy Yan
2023-11-28 8:30 ` Heiko Stübner
2023-11-28 8:30 ` Heiko Stübner
2023-11-28 8:30 ` Heiko Stübner
2023-11-28 9:44 ` Andy Yan
2023-11-28 9:44 ` Andy Yan
2023-11-28 9:44 ` Andy Yan
2023-11-22 12:54 ` [PATCH v2 05/12] drm/rockchip: vop2: Set YUV/RGB overlay mode Andy Yan
2023-11-22 12:54 ` Andy Yan
2023-11-22 12:54 ` Andy Yan
2023-11-27 14:16 ` Sascha Hauer
2023-11-27 14:16 ` Sascha Hauer
2023-11-27 14:16 ` Sascha Hauer
2023-11-29 6:52 ` Andy Yan
2023-11-29 6:52 ` Andy Yan
2023-11-29 6:52 ` Andy Yan
2023-11-22 12:54 ` [PATCH v2 06/12] drm/rockchip: vop2: rename grf to sys_grf Andy Yan
2023-11-22 12:54 ` Andy Yan
2023-11-22 12:54 ` Andy Yan
2023-11-27 14:17 ` Sascha Hauer
2023-11-27 14:17 ` Sascha Hauer
2023-11-27 14:17 ` Sascha Hauer
2023-11-22 12:55 ` [PATCH v2 07/12] dt-bindings: soc: rockchip: add rk3588 vop/vo syscon Andy Yan
2023-11-22 12:55 ` Andy Yan
2023-11-22 12:55 ` Andy Yan
2023-11-22 12:55 ` [PATCH v2 08/12] dt-bindings: display: vop2: Add rk3588 support Andy Yan
2023-11-22 12:55 ` Andy Yan
2023-11-22 12:55 ` Andy Yan
2023-11-22 19:07 ` Krzysztof Kozlowski
2023-11-22 19:07 ` Krzysztof Kozlowski
2023-11-22 19:07 ` Krzysztof Kozlowski
2023-11-30 12:32 ` Andy Yan
2023-11-30 12:32 ` Andy Yan
2023-11-30 12:32 ` Andy Yan
2023-11-22 12:55 ` [PATCH v2 09/12] dt-bindings: soc: vop2: Add more endpoint definition Andy Yan
2023-11-22 12:55 ` Andy Yan
2023-11-22 12:55 ` Andy Yan
2023-11-22 19:08 ` Krzysztof Kozlowski
2023-11-22 19:08 ` Krzysztof Kozlowski
2023-11-22 19:08 ` Krzysztof Kozlowski
2023-11-22 12:55 ` [PATCH v2 10/12] drm/rockchip: vop2: Add support for rk3588 Andy Yan
2023-11-22 12:55 ` Andy Yan
2023-11-22 12:55 ` Andy Yan
2023-11-27 11:19 ` Sascha Hauer
2023-11-27 11:19 ` Sascha Hauer
2023-11-27 11:19 ` Sascha Hauer
2023-11-29 8:28 ` Andy Yan
2023-11-29 8:28 ` Andy Yan
2023-11-29 8:28 ` Andy Yan
2023-11-27 15:29 ` Heiko Stübner
2023-11-27 15:29 ` Heiko Stübner
2023-11-27 15:29 ` Heiko Stübner
2023-11-28 9:32 ` Andy Yan
2023-11-28 9:32 ` Andy Yan
2023-11-28 9:32 ` Andy Yan
2023-11-28 9:44 ` Heiko Stübner [this message]
2023-11-28 9:44 ` Heiko Stübner
2023-11-28 9:44 ` Heiko Stübner
2023-11-28 10:11 ` Andy Yan
2023-11-28 10:11 ` Andy Yan
2023-11-28 10:11 ` Andy Yan
2023-11-22 12:56 ` [PATCH v2 11/12] drm/rockchip: vop2: Add debugfs support Andy Yan
2023-11-22 12:56 ` Andy Yan
2023-11-22 12:56 ` Andy Yan
2023-11-27 10:13 ` Sascha Hauer
2023-11-27 10:13 ` Sascha Hauer
2023-11-27 10:13 ` Sascha Hauer
2023-11-27 10:56 ` Andy Yan
2023-11-29 8:52 ` Sascha Hauer
2023-11-29 8:52 ` Sascha Hauer
2023-11-29 8:52 ` Sascha Hauer
2023-11-29 11:01 ` Andy Yan
2023-11-29 11:01 ` Andy Yan
2023-11-29 11:01 ` Andy Yan
2023-11-29 12:59 ` Sascha Hauer
2023-11-29 12:59 ` Sascha Hauer
2023-11-29 12:59 ` Sascha Hauer
2023-11-30 1:15 ` Andy Yan
2023-11-30 1:15 ` Andy Yan
2023-11-30 1:15 ` Andy Yan
2023-11-22 12:56 ` [PATCH v2 12/12] arm64: dts: rockchip: Add vop on rk3588 Andy Yan
2023-11-22 12:56 ` Andy Yan
2023-11-22 12:56 ` Andy Yan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4339687.HovnAMPojK@diego \
--to=heiko@sntech.de \
--cc=andy.yan@rock-chips.com \
--cc=andyshrk@163.com \
--cc=chris.obbard@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=hjc@rock-chips.com \
--cc=kever.yang@rock-chips.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=robh+dt@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=sebastian.reichel@collabora.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.