Re: [PATCH] drm/amdgpu: fix xclk freq on CHIP_STONEY
On Fri, Jun 2, 2023 at 11:50 AM Alex Deucher wrote: > > Nevermind, missing your Signed-off-by. Please add and I'll apply. Sorry that I keep forgetting... This patch is Signed-off-by: Chia-I Wu I can send v2 if necessary. > > Alex >
Re: [PATCH v6 0/3] Add sync object UAPI support to VirtIO-GPU driver
> Dmitry Osipenko (3): > drm/virtio: Refactor and optimize job submission code path > drm/virtio: Wait for each dma-fence of in-fence array individually Applied these two patches to misc-next. The syncobj patch will wait for the turnip Mesa MR. -- Best regards, Dmitry
Re: [PATCH 2/2] drm: bridge: tc358767: give VSDELAY some positive value
On 6/2/23 21:15, Lucas Stach wrote: From: David Jander The documentation is not clear about how this delay works. Empirical tests have shown that with a VSDELAY of 0, the first scanline is not properly formatted in the output stream when DSI->DP mode is used. The calculation spreadsheets from Toshiba seem to always make this value equal to the HFP + 10 for DSI->DP use-case. For DSI->DPI this value should be > 2 and for DPI->DP it seems to always be 0x64. Signed-off-by: David Jander Signed-off-by: Lucas Stach --- drivers/gpu/drm/bridge/tc358767.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index 46916ae30f8f..9f2c67b4a488 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -817,7 +817,7 @@ static int tc_set_common_video_mode(struct tc_data *tc, * sync signals */ ret = regmap_write(tc->regmap, VPCTRL0, - FIELD_PREP(VSDELAY, 0) | + FIELD_PREP(VSDELAY, right_margin + 10) | OPXLFMT_RGB888 | FRMSYNC_DISABLED | MSF_DISABLED); if (ret) return ret; Aren't you running into a problem due to VS timing misconfiguration on the scanout engine or DSI serializer side ? The VSDELAY seems to increase the length of VSYNC active . Which DSI bus mode do you use, sync events/pulses/burst ?
Re: [PATCH 1/2] drm: bridge: tc358767: increase PLL lock time delay
On 6/2/23 21:15, Lucas Stach wrote: From: David Jander The PLL often fails to lock with this delay. The new value was determined by trial and error increasing the delay bit by bit until the error did not occurr anymore even after several tries. Then double that value was taken as the minimum delay to be safe. Signed-off-by: David Jander Signed-off-by: Lucas Stach --- drivers/gpu/drm/bridge/tc358767.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index 91f7cb56a654..46916ae30f8f 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -501,7 +501,7 @@ static int tc_pllupdate(struct tc_data *tc, unsigned int pllctrl) return ret; /* Wait for PLL to lock: up to 2.09 ms, depending on refclk */ - usleep_range(3000, 6000); + usleep_range(15000, 2); The comment above does not seem to match either value, please fix. With that fixed: Reviewed-by: Marek Vasut
Re: Kernel bug related to drivers/gpu/drm/ttm/ttm_bo.c
Two further bug reports, which could be the same bug: https://bugzilla.redhat.com/show_bug.cgi?id=2012882 -> it was closed by the reporter with the assumption that the issue disappeared on 6.0.5 because he had no longer occurrences. It also relates to drivers/gpu/drm/ttm/ttm_bo.c and looks comparable to some of my earlier logs. https://bugzilla.redhat.com/show_bug.cgi?id=1985880 -> closed due to the end of the Fedora-34 release cycle. It is unknown if the reporter still experiences the problem. Also relating to drivers/gpu/drm/ttm/ttm_bo.c and looking comparable to mine.
Re: [Freedreno] [PATCH v1 2/3] drm/msm/dpu: retrieve DSI DSC struct at atomic_check()
Generic note: please use reply-to-all instead of any other options to answer the email. You have dropped all recipients (except the freedreno@) in the message (and it was left unnoticed). On Fri, 2 Jun 2023 at 20:00, Kuogee Hsieh wrote: > >> There is one option which is keep current > >> > >> 1) keep struct drm_dsc_config *msm_dsi_get_dsc_config(struct msm_dsi > >> *msm_dsi) at dsi.c > >> > >> 2) use struct msm_display_info *disp_info saved at dpu_enc to locate > >> struct msm_dsi from priv->dsi[] list (see item #3) > >> > >> 3) info.dsc = msm_dsi_get_dsc_config(priv->dsi[info.h_tile_instance[0]]); > >> > >> 4) ballistically, keep original code but move info.dsc = > >> msm_dsi_get_dsc_config(priv->dsi[i]); to other place sush as > >> atomic_check() and atomic_enable(). > >> > > 5) leave drm_dsc_config handling as is, update the dsc config from the > > DP driver as suitable. If DSC is not supported, set > > dsc->dsc_version_major = 0 and dsc->dsc_version_minor = 0 on the DP > > side. In DPU driver verify that dsc->dsc_version_major/_minor != 0. > > I am confusing with item 5) > > Currently, msm_dsi_get_dsc_config() of dsi side return dsc pointer if > dsc enabled and NULL if dsc not enabled. > > Should checking dsc == NULL is good enough to differentiate between dsc > is supported and not supported? This is called a "shared memory area". Instead of either providing a dynamic data pointer, one can provide a pointer to the static area which is filled by DP or DSI. If there is no DSC available, one flags 'data not valid' by setting major,minor to 0. > > Why need to set both dsc->dsc_version_major = 0 and > dsc->dsc_version_minor = 0 for dsc is not supported? 6) Another option (which is more in style of what is done in the vendor kernel, if I'm not mistaken): Enhance struct drm_display_mode to contain a pointer to the DSC config. Use this pointer to check whether DSC should be enabled for the particular mode or not. The panels with the static DSC configuration can use a static data pointer. -- With best wishes Dmitry
[PATCH 2/2] accel/qaic: Fix NULL pointer deref in qaic_destroy_drm_device()
If qaic_destroy_drm_device() is called before the device has fully
initialized it will cause a NULL pointer dereference as the drm device
has not yet been created. Fix this with a NULL check.
Fixes: c501ca23a6a3 ("accel/qaic: Add uapi and core driver file")
Signed-off-by: Jeffrey Hugo
Reviewed-by: Carl Vanderlip
Reviewed-by: Pranjal Ramajor Asha Kanojiya
---
drivers/accel/qaic/qaic_drv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/accel/qaic/qaic_drv.c b/drivers/accel/qaic/qaic_drv.c
index 961cd341b414..b5ba550a0c04 100644
--- a/drivers/accel/qaic/qaic_drv.c
+++ b/drivers/accel/qaic/qaic_drv.c
@@ -225,6 +225,9 @@ static void qaic_destroy_drm_device(struct qaic_device
*qdev, s32 partition_id)
struct qaic_user *usr;
qddev = qdev->qddev;
+ qdev->qddev = NULL;
+ if (!qddev)
+ return;
/*
* Existing users get unresolvable errors till they close FDs.
--
2.40.1
[PATCH 1/2] accel/qaic: Free user handle on interrupted mutex
From: Carl Vanderlip
After user handle is allocated, if mutex is interrupted, we do not free
the user handle and return an error. Kref had been initialized, but not
added to users list, so device teardown would also not call free_usr.
Fixes: c501ca23a6a3 ("accel/qaic: Add uapi and core driver file")
Signed-off-by: Carl Vanderlip
Reviewed-by: Pranjal Ramajor Asha Kanojiya
Reviewed-by: Jeffrey Hugo
Signed-off-by: Jeffrey Hugo
---
drivers/accel/qaic/qaic_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/accel/qaic/qaic_drv.c b/drivers/accel/qaic/qaic_drv.c
index 2d0828db28d8..961cd341b414 100644
--- a/drivers/accel/qaic/qaic_drv.c
+++ b/drivers/accel/qaic/qaic_drv.c
@@ -97,6 +97,7 @@ static int qaic_open(struct drm_device *dev, struct drm_file
*file)
cleanup_usr:
cleanup_srcu_struct(>qddev_lock);
+ ida_free(_usrs, usr->handle);
free_usr:
kfree(usr);
dev_unlock:
--
2.40.1
[PATCH 0/2] accel/qaic fixes for 6.4 part 2
Two additional fixes for corner cases found during development when buggy userspace or firmware ends up subjecting the KMD to error scenarios. Carl Vanderlip (1): accel/qaic: Free user handle on interrupted mutex Jeffrey Hugo (1): accel/qaic: Fix NULL pointer deref in qaic_destroy_drm_device() drivers/accel/qaic/qaic_drv.c | 4 1 file changed, 4 insertions(+) -- 2.40.1
Re: [PATCH] dim: Disallow remote branch deletions with 'dim push'
On Fri, 02 Jun 2023 03:16:20 -0700, Jani Nikula wrote: > > On Thu, 01 Jun 2023, Ashutosh Dixit wrote: > > An inadvertent 'dim push -d' can delete remote branches. Disallow such > > remote branch deletions. > > Please see > https://drm.pages.freedesktop.org/maintainer-tools/CONTRIBUTING.html > > > > > Signed-off-by: Ashutosh Dixit > > --- > > dim | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/dim b/dim > > index 126568e..e5899e6 100755 > > --- a/dim > > +++ b/dim > > @@ -1029,6 +1029,12 @@ function dim_push_branch > > fi > > fi > > > > + # Disallow remote branch deletions, say with 'dim push -d' > > + if [[ "$@" == *"-d"* ]]; then > > + echoerr "Attempt to delete remote branch, aborting." > > + return 1 > > + fi > > I'm working on adding a server side git pre-receive hook to tackle this > too, but I guess there's no harm in adding this. The choice of -d for > dry run was unfortunate, and this helps with the 'dim -d foo' vs 'dim > foo -d' mistake. Yup, understood. I thought I'd just send out the patch anyway in case it was useful. I have created a merge request for the patch here: https://gitlab.freedesktop.org/drm/maintainer-tools/-/merge_requests/21 Thanks. -- Ashutosh > > + > > git_push $remote $branch "$@" > > > > update_linux_next $branch drm-intel-next drm-intel-next-fixes > > drm-intel-fixes > > -- > Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH] MAINTAINERS: Add Carl/Pranjal as QAIC reviewers
On 5/23/2023 10:14 AM, Jeffrey Hugo wrote: Carl and Pranjal have been reviewing the QAIC patches. List them as reviewers so that they are copied on all developments which will make it easier for them to continue reviewing QAIC patches. Signed-off-by: Jeffrey Hugo Applied to drm-misc-next
RE: [PATCH v2] drm: rcar-du: Use dev_err_probe() to record cause of KMS init errors
Hi Laurent,
Thanks for the patch.
> Subject: [PATCH v2] drm: rcar-du: Use dev_err_probe() to record cause of
> KMS init errors
>
> The (large) rcar_du_modeset_init() function can fail for many reasons,
> two of two involving probe deferral. Use dev_err_probe() in those code
> paths to record the cause of the probe deferral, in order to help
> debugging probe issues.
>
> Signed-off-by: Laurent Pinchart
>
> ---
> drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 4
> drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c | 8 ++--
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
> index 12a8839fe3be..5b752adb1b02 100644
> --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
> @@ -701,6 +701,10 @@ static int rcar_du_probe(struct platform_device
> *pdev)
> /* DRM/KMS objects */
> ret = rcar_du_modeset_init(rcdu);
> if (ret < 0) {
> + /*
> + * Don't use dev_err_probe(), as it would overwrite the
> probe
> + * deferral reason recorded in rcar_du_modeset_init().
> + */
> if (ret != -EPROBE_DEFER)
> dev_err(>dev,
> "failed to initialize DRM/KMS (%d)\n", ret);
> diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> index adfb36b0e815..a9b01027bf03 100644
> --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> @@ -932,8 +932,10 @@ int rcar_du_modeset_init(struct rcar_du_device
> *rcdu)
>
> /* Initialize the Color Management Modules. */
> ret = rcar_du_cmm_init(rcdu);
> - if (ret)
> + if (ret) {
> + dev_err_probe(rcdu->dev, "failed to initialize CMM\n", ret);
dev_err_probe(rcdu->dev, ret, "failed to initialize CMM\n");
similarly for below one.
Cheers,
Biju
> return ret;
> + }
>
> /* Create the CRTCs. */
> for (swindex = 0, hwindex = 0; swindex < rcdu->num_crtcs;
> ++hwindex) { @@ -952,8 +954,10 @@ int rcar_du_modeset_init(struct
> rcar_du_device *rcdu)
>
> /* Initialize the encoders. */
> ret = rcar_du_encoders_init(rcdu);
> - if (ret < 0)
> + if (ret < 0) {
> + dev_err_probe(rcdu->dev, "failed to initialize encoders\n",
> ret);
> return ret;
> + }
>
> if (ret == 0) {
> dev_err(rcdu->dev, "error: no encoder could be
> initialized\n");
> --
> Regards,
>
> Laurent Pinchart
[PATCH 2/2] drm: bridge: tc358767: give VSDELAY some positive value
From: David Jander The documentation is not clear about how this delay works. Empirical tests have shown that with a VSDELAY of 0, the first scanline is not properly formatted in the output stream when DSI->DP mode is used. The calculation spreadsheets from Toshiba seem to always make this value equal to the HFP + 10 for DSI->DP use-case. For DSI->DPI this value should be > 2 and for DPI->DP it seems to always be 0x64. Signed-off-by: David Jander Signed-off-by: Lucas Stach --- drivers/gpu/drm/bridge/tc358767.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index 46916ae30f8f..9f2c67b4a488 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -817,7 +817,7 @@ static int tc_set_common_video_mode(struct tc_data *tc, * sync signals */ ret = regmap_write(tc->regmap, VPCTRL0, - FIELD_PREP(VSDELAY, 0) | + FIELD_PREP(VSDELAY, right_margin + 10) | OPXLFMT_RGB888 | FRMSYNC_DISABLED | MSF_DISABLED); if (ret) return ret; -- 2.39.2
[PATCH 1/2] drm: bridge: tc358767: increase PLL lock time delay
From: David Jander The PLL often fails to lock with this delay. The new value was determined by trial and error increasing the delay bit by bit until the error did not occurr anymore even after several tries. Then double that value was taken as the minimum delay to be safe. Signed-off-by: David Jander Signed-off-by: Lucas Stach --- drivers/gpu/drm/bridge/tc358767.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index 91f7cb56a654..46916ae30f8f 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -501,7 +501,7 @@ static int tc_pllupdate(struct tc_data *tc, unsigned int pllctrl) return ret; /* Wait for PLL to lock: up to 2.09 ms, depending on refclk */ - usleep_range(3000, 6000); + usleep_range(15000, 2); return 0; } -- 2.39.2
[PATCH v1] drm/xe/guc: Fix h2g_write usage of GUC_CTB_MSG_MAX_LEN
In the ABI header, GUC_CTB_MSG_MIN_LEN is '1' because
GUC_CTB_HDR_LEN is 1. This aligns with H2G/G2H CTB specification
where all command formats are defined in units of dwords so that '1'
is a dword. Accordingly, GUC_CTB_MSG_MAX_LEN is 256-1 (i.e. 255
dwords). However, h2g_write was incorrectly assuming that
GUC_CTB_MSG_MAX_LEN was in bytes. Fix this.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/xe/xe_guc_ct.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c
index 137c184df487..8e9df6052b02 100644
--- a/drivers/gpu/drm/xe/xe_guc_ct.c
+++ b/drivers/gpu/drm/xe/xe_guc_ct.c
@@ -401,7 +401,7 @@ static int h2g_write(struct xe_guc_ct *ct, const u32
*action, u32 len,
{
struct xe_device *xe = ct_to_xe(ct);
struct guc_ctb *h2g = >ctbs.h2g;
- u32 cmd[GUC_CTB_MSG_MAX_LEN / sizeof(u32)];
+ u32 cmd[GUC_CTB_MSG_MAX_LEN];
u32 cmd_len = len + GUC_CTB_HDR_LEN;
u32 cmd_idx = 0, i;
u32 tail = h2g->info.tail;
@@ -409,7 +409,7 @@ static int h2g_write(struct xe_guc_ct *ct, const u32
*action, u32 len,
tail * sizeof(u32));
lockdep_assert_held(>lock);
- XE_BUG_ON(len * sizeof(u32) > GUC_CTB_MSG_MAX_LEN);
+ XE_BUG_ON(len > GUC_CTB_MSG_MAX_LEN - 1);
XE_BUG_ON(tail > h2g->info.size);
/* Command will wrap, zero fill (NOPs), return and check credits again
*/
base-commit: 9f49c413b187c00f223eaf1e8dbe2c1a97c9954b
--
2.39.0
Re: [PATCH] drm/amdgpu: fix xclk freq on CHIP_STONEY
Nevermind, missing your Signed-off-by. Please add and I'll apply.
Alex
On Fri, Jun 2, 2023 at 2:19 PM Alex Deucher wrote:
>
> Applied. Thanks!
>
> Alex
>
> On Thu, Jun 1, 2023 at 5:48 PM Chia-I Wu wrote:
> >
> > According to Alex, most APUs from that time seem to have the same issue
> > (vbios says 48Mhz, actual is 100Mhz). I only have a CHIP_STONEY so I
> > limit the fixup to CHIP_STONEY
> > ---
> > drivers/gpu/drm/amd/amdgpu/vi.c | 11 +--
> > 1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c
> > b/drivers/gpu/drm/amd/amdgpu/vi.c
> > index 770f2d7a371fc..6a8494f98d3ef 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> > @@ -542,8 +542,15 @@ static u32 vi_get_xclk(struct amdgpu_device *adev)
> > u32 reference_clock = adev->clock.spll.reference_freq;
> > u32 tmp;
> >
> > - if (adev->flags & AMD_IS_APU)
> > - return reference_clock;
> > + if (adev->flags & AMD_IS_APU) {
> > + switch (adev->asic_type) {
> > + case CHIP_STONEY:
> > + /* vbios says 48Mhz, but the actual freq is 100Mhz
> > */
> > + return 1;
> > + default:
> > + return reference_clock;
> > + }
> > + }
> >
> > tmp = RREG32_SMC(ixCG_CLKPIN_CNTL_2);
> > if (REG_GET_FIELD(tmp, CG_CLKPIN_CNTL_2, MUX_TCLK_TO_XCLK))
> > --
> > 2.41.0.rc0.172.g3f132b7071-goog
> >
Re: [PATCH v9 2/4] lib/ref_tracker: improve printing stats
On Fri, Jun 02, 2023 at 12:21:34PM +0200, Andrzej Hajda wrote: > In case the library is tracking busy subsystem, simply > printing stack for every active reference will spam log > with long, hard to read, redundant stack traces. To improve > readabilty following changes have been made: Hi Andrzej, in case you have to respin for some other reason, you may want to consider: readabilty -> readability ...
Re: [PATCH][next] drm/amdgpu/discovery: Replace fake flex-arrays with flexible-array members
Applied. Thanks!
On Tue, May 30, 2023 at 7:08 PM Kees Cook wrote:
>
> On Sun, May 28, 2023 at 02:26:37PM -0600, Gustavo A. R. Silva wrote:
> > Zero-length and one-element arrays are deprecated, and we are moving
> > towards adopting C99 flexible-array members, instead.
> >
> > Use the DECLARE_FLEX_ARRAY() helper macro to transform zero-length
> > arrays in a union into flexible-array members. And replace a one-element
> > array with a C99 flexible-array member.
> >
> > Address the following warnings found with GCC-13 and
> > -fstrict-flex-arrays=3 enabled:
> > drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1009:89: warning: array
> > subscript kk is outside array bounds of ‘uint32_t[0]’ {aka ‘unsigned
> > int[]’} [-Warray-bounds=]
> > drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1007:94: warning: array
> > subscript kk is outside array bounds of ‘uint64_t[0]’ {aka ‘long long
> > unsigned int[]’} [-Warray-bounds=]
> > drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1310:94: warning: array
> > subscript k is outside array bounds of ‘uint64_t[0]’ {aka ‘long long
> > unsigned int[]’} [-Warray-bounds=]
> > drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1309:57: warning: array
> > subscript k is outside array bounds of ‘uint32_t[0]’ {aka ‘unsigned int[]’}
> > [-Warray-bounds=]
> >
> > This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
> > routines on memcpy() and help us make progress towards globally
> > enabling -fstrict-flex-arrays=3 [1].
> >
> > This results in no differences in binary output.
> >
> > Link: https://github.com/KSPP/linux/issues/21
> > Link: https://github.com/KSPP/linux/issues/193
> > Link: https://github.com/KSPP/linux/issues/300
> > Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1]
> > Signed-off-by: Gustavo A. R. Silva
>
> Reviewed-by: Kees Cook
>
> --
> Kees Cook
Re: [PATCH v3] amdgpu: validate offset_in_bo of drm_amdgpu_gem_va
Applied. Thanks!
Alex
On Fri, Jun 2, 2023 at 7:43 AM Christian König wrote:
>
> Am 02.06.23 um 00:44 schrieb Chia-I Wu:
> > This is motivated by OOB access in amdgpu_vm_update_range when
> > offset_in_bo+map_size overflows.
> >
> > v2: keep the validations in amdgpu_vm_bo_map
> > v3: add the validations to amdgpu_vm_bo_map/amdgpu_vm_bo_replace_map
> > rather than to amdgpu_gem_va_ioctl
> >
> > Fixes: 9f7eb5367d00 ("drm/amdgpu: actually use the VM map parameters")
> > Signed-off-by: Chia-I Wu
>
> Reviewed-by: Christian König
>
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 16
> > 1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > index 22f9a65ca0fc7..76d57bc7ac620 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > @@ -1434,14 +1434,14 @@ int amdgpu_vm_bo_map(struct amdgpu_device *adev,
> > uint64_t eaddr;
> >
> > /* validate the parameters */
> > - if (saddr & ~PAGE_MASK || offset & ~PAGE_MASK ||
> > - size == 0 || size & ~PAGE_MASK)
> > + if (saddr & ~PAGE_MASK || offset & ~PAGE_MASK || size & ~PAGE_MASK)
> > + return -EINVAL;
> > + if (saddr + size <= saddr || offset + size <= offset)
> > return -EINVAL;
> >
> > /* make sure object fit at this offset */
> > eaddr = saddr + size - 1;
> > - if (saddr >= eaddr ||
> > - (bo && offset + size > amdgpu_bo_size(bo)) ||
> > + if ((bo && offset + size > amdgpu_bo_size(bo)) ||
> > (eaddr >= adev->vm_manager.max_pfn << AMDGPU_GPU_PAGE_SHIFT))
> > return -EINVAL;
> >
> > @@ -1500,14 +1500,14 @@ int amdgpu_vm_bo_replace_map(struct amdgpu_device
> > *adev,
> > int r;
> >
> > /* validate the parameters */
> > - if (saddr & ~PAGE_MASK || offset & ~PAGE_MASK ||
> > - size == 0 || size & ~PAGE_MASK)
> > + if (saddr & ~PAGE_MASK || offset & ~PAGE_MASK || size & ~PAGE_MASK)
> > + return -EINVAL;
> > + if (saddr + size <= saddr || offset + size <= offset)
> > return -EINVAL;
> >
> > /* make sure object fit at this offset */
> > eaddr = saddr + size - 1;
> > - if (saddr >= eaddr ||
> > - (bo && offset + size > amdgpu_bo_size(bo)) ||
> > + if ((bo && offset + size > amdgpu_bo_size(bo)) ||
> > (eaddr >= adev->vm_manager.max_pfn << AMDGPU_GPU_PAGE_SHIFT))
> > return -EINVAL;
> >
>
Re: [PATCH 1/9] dt-bindings: display: Add yamls for JH7110 display subsystem
Hey Keith, On Fri, Jun 02, 2023 at 03:40:35PM +0800, Keith Zhao wrote: > Add bindings for JH7110 display subsystem which > has a display controller verisilicon dc8200 > and an HDMI interface. > > Signed-off-by: Keith Zhao > --- > .../display/verisilicon/starfive-hdmi.yaml| 93 +++ > .../display/verisilicon/verisilicon-dc.yaml | 110 ++ > .../display/verisilicon/verisilicon-drm.yaml | 42 +++ > .../devicetree/bindings/vendor-prefixes.yaml | 2 + > MAINTAINERS | 7 ++ > 5 files changed, 254 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml > create mode 100644 > Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml > create mode 100644 > Documentation/devicetree/bindings/display/verisilicon/verisilicon-drm.yaml > > diff --git > a/Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml > b/Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml > new file mode 100644 > index ..c30b7954a355 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml > @@ -0,0 +1,93 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/verisilicon/starfive-hdmi.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: StarFive HDMI transmiter > + > +description: > + The StarFive SoC uses the HDMI signal transmiter based on innosilicon IP Is innosilicon the same thing as verisilicon? Also s/transmiter/transmitter/, both here and in the title. > + to generate HDMI signal from its input and transmit the signal to the > screen. > + > +maintainers: > + - Keith Zhao > + - ShengYang Chen > + > +properties: > + compatible: > +const: starfive,hdmi Is this going to work on every SoC that StarFive has ever & will ever make? Please use soc-based compatibles ;) > + > + reg: > +minItems: 1 > + > + interrupts: > +items: > + - description: The HDMI hot plug detection interrupt. > + > + clocks: > +items: > + - description: System clock of HDMI module. > + - description: Mclk clock of HDMI audio. > + - description: Bclk clock of HDMI audio. > + - description: Pixel clock generated by HDMI module. > + > + clock-names: > +items: > + - const: sysclk > + - const: mclk > + - const: bclk > + - const: pclk > + > + resets: > +items: > + - description: Reset for HDMI module. > + > + reset-names: > +items: > + - const: hdmi_tx You only have one item here, you don't need the "items: - const:", "const:" alone will do. > diff --git > a/Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml > b/Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml > new file mode 100644 > index ..1322502c4cde > --- /dev/null > +++ > b/Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml > @@ -0,0 +1,110 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/verisilicon/verisilicon-dc.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: StarFive display controller > + > +description: > + The StarFive SoC uses the display controller based on Verisilicon IP > + to transfer the image data from a video memory > + buffer to an external LCD interface. Is it based on Verisilicon IP, or is it exactly that verisilicon IP? I ask because... > +maintainers: > + - Keith Zhao > + - ShengYang Chen > + > +properties: > + compatible: > +const: verisilicon,dc8200 ...the compatible is the verisilicon IP. I would be a lot happier if the compatibles were set yp for something like: "starfive,jh7110-foo", "verisilicon,dc8200" > diff --git > a/Documentation/devicetree/bindings/display/verisilicon/verisilicon-drm.yaml > b/Documentation/devicetree/bindings/display/verisilicon/verisilicon-drm.yaml > new file mode 100644 > index ..aed8d4af2c55 > --- /dev/null > +++ > b/Documentation/devicetree/bindings/display/verisilicon/verisilicon-drm.yaml > @@ -0,0 +1,42 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/verisilicon/verisilicon-drm.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Verisilicon DRM master device > + > +maintainers: > + - Keith Zhao > + - ShengYang Chen > + > +description: | > + The Verisilicon DRM master device is a virtual device needed to list all > + display controller or other display interface nodes that comprise the > + graphics subsystem. > + > +properties: > + compatible: > +const: verisilicon,display-subsystem Same here. > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml >
Re: [PATCH] drm/amdgpu: fix xclk freq on CHIP_STONEY
Applied. Thanks!
Alex
On Thu, Jun 1, 2023 at 5:48 PM Chia-I Wu wrote:
>
> According to Alex, most APUs from that time seem to have the same issue
> (vbios says 48Mhz, actual is 100Mhz). I only have a CHIP_STONEY so I
> limit the fixup to CHIP_STONEY
> ---
> drivers/gpu/drm/amd/amdgpu/vi.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
> index 770f2d7a371fc..6a8494f98d3ef 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -542,8 +542,15 @@ static u32 vi_get_xclk(struct amdgpu_device *adev)
> u32 reference_clock = adev->clock.spll.reference_freq;
> u32 tmp;
>
> - if (adev->flags & AMD_IS_APU)
> - return reference_clock;
> + if (adev->flags & AMD_IS_APU) {
> + switch (adev->asic_type) {
> + case CHIP_STONEY:
> + /* vbios says 48Mhz, but the actual freq is 100Mhz */
> + return 1;
> + default:
> + return reference_clock;
> + }
> + }
>
> tmp = RREG32_SMC(ixCG_CLKPIN_CNTL_2);
> if (REG_GET_FIELD(tmp, CG_CLKPIN_CNTL_2, MUX_TCLK_TO_XCLK))
> --
> 2.41.0.rc0.172.g3f132b7071-goog
>
[pull] amdgpu, amdkfd, radeon, ttm, UAPI drm-next-6.5
Hi Dave, Daniel, New stuff for 6.5. The following changes since commit e82c98f2ca439356d5595ba8c9cd782f993f6f8c: Merge tag 'amd-drm-next-6.4-2023-04-14' of https://gitlab.freedesktop.org/agd5f/linux into drm-next (2023-04-17 10:54:59 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-next-6.5-2023-06-02 for you to fetch changes up to b50a5b0ac258647bf7ae393a89a2603adfde2f1b: amd/amdkfd: drop unused KFD_IOCTL_SVM_FLAG_UNCACHED flag (2023-06-02 13:16:30 -0400) amd-drm-next-6.5-2023-06-02: amdgpu: - SR-IOV fixes - Warning fixes - Misc code cleanups and spelling fixes - DCN 3.2 updates - Improved DC FAMS support for better power management - Improved DC SubVP support for better power management - DCN 3.1.x fixes - Max IB size query - DC GPU reset fixes - RAS updates - DCN 3.0.x fixes - S/G display fixes - CP shadow buffer support - Implement connector force callback - Z8 power improvements - PSP 13.0.10 vbflash support - Mode2 reset fixes - Store MQDs in VRAM to improve queue switch latency - VCN 3.x fixes - JPEG 3.x fixes - Enable DC_FP on LoongArch - GFXOFF fixes - GC 9.4.3 partition support - SDMA 4.4.2 partition support - VCN/JPEG 4.0.3 partition support - VCN 4.0.3 updates - NBIO 7.9 updates - GC 9.4.3 updates - Take NUMA into account when allocating memory - Handle NUMA for partitions - SMU 13.0.6 updates - GC 9.4.3 RAS updates - Stop including unused swiotlb.h - SMU 13.0.7 fixes - Fix clock output ordering on some APUs - Clean up DC FPGA code - GFX9 preemption fixes - Misc irq fixes - S0ix fixes - Add new DRM_AMDGPU_WERROR config parameter to help with CI - PCIe fix for RDNA2 - kdoc fixes - Documentation updates amdkfd: - Query TTM mem limit rather than hardcoding it - GC 9.4.3 partition support - Handle NUMA for partitions radeon: - Fix possible double free - Stop including unused swiotlb.h - Fix possible division by zero ttm: - Add query for TTM mem limit - Add NUMA awareness to pools - Export ttm_pool_fini() UAPI: - Add new ctx query flag to better handle GPU resets Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22290 - Add new interface to query and set shadow buffer for RDNA3 Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21986 - Add new INFO query for max IB size Proposed userspace: https://gitlab.freedesktop.org/bnieuwenhuizen/mesa/-/commits/ib-rejection-v3 Alan Liu (4): drm/amd/display: Fix in disabling secure display drm/amdgpu: Fix desktop freezed after gpu-reset drm/amd/display: Fix in secure display context creation drm/amd/display: Fix warning in disabling vblank irq Alex Deucher (33): drm/amdgpu/gfx11: add FW version check for new CP GFX shadow feature drm/amdgpu/gfx11: check the CP FW version CP GFX shadow support drm/amdgpu/UAPI: add new CS chunk for GFX shadow buffers drm/amdgpu: don't require a job for cond_exec and shadow drm/amdgpu: add UAPI to query GFX shadow sizes drm/amdgpu: add gfx shadow callback drm/amdgpu: add get_gfx_shadow_info callback for gfx11 drm/amdgpu: add support for new GFX shadow size query drm/amdgpu: bump driver version number for CP GFX shadow drm/amdgpu: track MQD size for gfx and compute drm/amdgpu: add debugfs interface for reading MQDs drm/amdgpu/gfx11: update gpu_clock_counter logic drm/amdgpu/gfx11: drop old bring up code drm/amdgpu/gfx10: drop old bring up code drm/amdgpu: add [en/dis]able_kgq() functions drm/amdgpu/gfx10: use generic [en/dis]able_kgq() helpers drm/amdgpu/gfx11: use generic [en/dis]able_kgq() helpers drm/amdgpu/gfx10: drop unused variable drm/amdgpu/gfx11: drop unused variable drm/amdgpu/gfx8: always restore kcq MQDs drm/amdgpu/gfx9: always restore kcq MQDs drm/amdgpu/gfx10: always restore kcq/kgq MQDs drm/amdgpu/gfx11: always restore kcq/kgq MQDs drm/amdgpu: put MQDs in VRAM drm/amdgpu: drop invalid IP revision drm/amdgpu: drop unused function drm/amdgpu/gmc11: implement get_vbios_fb_size() drm/amdgpu/gmc9: fix 64 bit division in partition code drm/amdgpu/vcn4: fix endian conversion drm/amdkfd: fix stack size in svm_range_validate_and_map drm/radeon: reintroduce radeon_dp_work_func content drm/amdkfd: fix gfx_target_version for certain 11.0.3 devices amd/amdkfd: drop unused KFD_IOCTL_SVM_FLAG_UNCACHED flag Alex Hung (3): drm/amd/display: allow edp updates for virtual signal drm/amd/display: fix a divided-by-zero error drm/amd/display: implement force function in amdgpu_dm_connector_funcs Alex Sierra (3): drm/amdgpu: improve wait logic at fence polling drm/amdkfd: pass kfd_node ref to svm migration api drm/amdkfd: flag added to
[linux-next:master] BUILD REGRESSION bc708bbd8260ee4eb3428b0109f5f3be661fae46
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: bc708bbd8260ee4eb3428b0109f5f3be661fae46 Add linux-next specific
files for 20230602
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202306011435.2bxshfue-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202306021936.okttcmat-...@intel.com
Error/Warning: (recently discovered and may have been fixed)
drivers/bus/fsl-mc/fsl-mc-allocator.c:108:12: warning: variable 'mc_bus_dev' is
uninitialized when used here [-Wuninitialized]
include/drm/drm_print.h:456:39: error: format '%ld' expects argument of type
'long int', but argument 4 has type 'size_t' {aka 'unsigned int'}
[-Werror=format=]
mm/zswap.c:1210:6: warning: variable 'ret' is used uninitialized whenever 'if'
condition is true [-Wsometimes-uninitialized]
Unverified Error/Warning (likely false positive, please contact us if
interested):
fs/btrfs/volumes.c:6412 btrfs_map_block() error: we previously assumed
'mirror_num_ret' could be null (see line 6250)
fs/smb/client/cifsfs.c:982 cifs_smb3_do_mount() warn: possible memory leak of
'cifs_sb'
fs/smb/client/cifssmb.c:4089 CIFSFindFirst() warn: missing error code? 'rc'
fs/smb/client/cifssmb.c:4216 CIFSFindNext() warn: missing error code? 'rc'
fs/smb/client/connect.c:2725 cifs_match_super() error: 'tlink' dereferencing
possible ERR_PTR()
fs/smb/client/connect.c:2924 generic_ip_connect() error: we previously assumed
'socket' could be null (see line 2912)
fs/xfs/scrub/fscounters.c:459 xchk_fscounters() warn: ignoring unreachable code.
kernel/events/uprobes.c:478 uprobe_write_opcode() warn: passing zero to
'PTR_ERR'
{standard input}:1078: Error: pcrel too far
Error/Warning ids grouped by kconfigs:
gcc_recent_errors
|-- i386-allyesconfig
| `--
include-drm-drm_print.h:error:format-ld-expects-argument-of-type-long-int-but-argument-has-type-size_t-aka-unsigned-int
|-- i386-randconfig-m021-20230531
| |--
fs-smb-client-cifsfs.c-cifs_smb3_do_mount()-warn:possible-memory-leak-of-cifs_sb
| |-- fs-smb-client-cifssmb.c-CIFSFindFirst()-warn:missing-error-code-rc
| |-- fs-smb-client-cifssmb.c-CIFSFindNext()-warn:missing-error-code-rc
| |--
fs-smb-client-connect.c-cifs_match_super()-error:tlink-dereferencing-possible-ERR_PTR()
| |--
fs-smb-client-connect.c-generic_ip_connect()-error:we-previously-assumed-socket-could-be-null-(see-line-)
| |--
fs-xfs-scrub-fscounters.c-xchk_fscounters()-warn:ignoring-unreachable-code.
| `--
kernel-events-uprobes.c-uprobe_write_opcode()-warn:passing-zero-to-PTR_ERR
|-- sh-allmodconfig
| `-- standard-input:Error:pcrel-too-far
`-- x86_64-randconfig-m001-20230531
|--
fs-btrfs-volumes.c-btrfs_map_block()-error:we-previously-assumed-mirror_num_ret-could-be-null-(see-line-)
|--
fs-smb-client-cifsfs.c-cifs_smb3_do_mount()-warn:possible-memory-leak-of-cifs_sb
|-- fs-smb-client-cifssmb.c-CIFSFindFirst()-warn:missing-error-code-rc
|-- fs-smb-client-cifssmb.c-CIFSFindNext()-warn:missing-error-code-rc
|--
fs-smb-client-connect.c-cifs_match_super()-error:tlink-dereferencing-possible-ERR_PTR()
|--
fs-smb-client-connect.c-generic_ip_connect()-error:we-previously-assumed-socket-could-be-null-(see-line-)
|--
fs-xfs-scrub-fscounters.c-xchk_fscounters()-warn:ignoring-unreachable-code.
`--
kernel-events-uprobes.c-uprobe_write_opcode()-warn:passing-zero-to-PTR_ERR
clang_recent_errors
|-- arm64-randconfig-r012-20230602
| `--
drivers-bus-fsl-mc-fsl-mc-allocator.c:warning:variable-mc_bus_dev-is-uninitialized-when-used-here
|-- hexagon-allmodconfig
| `--
mm-zswap.c:warning:variable-ret-is-used-uninitialized-whenever-if-condition-is-true
|-- hexagon-randconfig-r045-20230531
| `--
mm-zswap.c:warning:variable-ret-is-used-uninitialized-whenever-if-condition-is-true
`-- s390-randconfig-r044-20230531
`--
mm-zswap.c:warning:variable-ret-is-used-uninitialized-whenever-if-condition-is-true
elapsed time: 726m
configs tested: 122
configs skipped: 5
tested configs:
alphaallyesconfig gcc
alpha defconfig gcc
alpharandconfig-r004-20230531 gcc
arc allyesconfig gcc
arc axs103_defconfig gcc
arc axs103_smp_defconfig gcc
arc buildonly-randconfig-r005-20230602 gcc
arc defconfig gcc
arc randconfig-r043-20230531 gcc
arm allmodconfig gcc
arm allyesconfig gcc
arm defconfig gcc
arm gemini_defconfig gcc
armhisi_defconfig gcc
arm mxs_defconfig clang
arm omap1_defconfig clang
arm randconfig-r046-20230531 gcc
arm s5pv210_defconfig clang
Re: [PATCH 2/2] accel/ivpu: Do not use mutex_lock_interruptible
On 5/25/2023 4:38 AM, Stanislaw Gruszka wrote:
If we get signal when waiting for the mmu->lock we do not invalidate
current MMU configuration what might result on undefined behavior.
"that might result in"
Additionally there is little or no benefit on break waiting for
ipc->lock. In current code base, we keep this lock for short periods.
What about error cases? Nothing where say the hardware can be
unresponsive and a process from userspace is blocked? Without
interruptible(), ctrl+c will have no effect.
Fixes: 263b2ba5fc93 ("accel/ivpu: Add Intel VPU MMU support")
Reviewed-by: Krystian Pradzynski
Signed-off-by: Stanislaw Gruszka
Re: [PATCH v2] drm/i915_drm.h: fix a typo
Hi, On 2023/6/3 01:24, Jani Nikula wrote: On Mon, 29 May 2023, Sui Jingfeng wrote: 'rbiter' -> 'arbiter' Signed-off-by: Sui Jingfeng Pushed to drm-intel-next, thanks for the patch. Thanks for your kindness and guidance. BR, Jani. --- include/drm/i915_drm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h index 7adce327c1c2..adff68538484 100644 --- a/include/drm/i915_drm.h +++ b/include/drm/i915_drm.h @@ -42,7 +42,7 @@ extern struct resource intel_graphics_stolen_res; * The Bridge device's PCI config space has information about the * fb aperture size and the amount of pre-reserved memory. * This is all handled in the intel-gtt.ko module. i915.ko only - * cares about the vga bit for the vga rbiter. + * cares about the vga bit for the vga arbiter. */ #define INTEL_GMCH_CTRL 0x52 #define INTEL_GMCH_VGA_DISABLE (1 << 1) -- Jingfeng
Re: [PATCH v2] drm/i915_drm.h: fix a typo
On Mon, 29 May 2023, Sui Jingfeng wrote: > 'rbiter' -> 'arbiter' > > Signed-off-by: Sui Jingfeng Pushed to drm-intel-next, thanks for the patch. BR, Jani. > --- > include/drm/i915_drm.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h > index 7adce327c1c2..adff68538484 100644 > --- a/include/drm/i915_drm.h > +++ b/include/drm/i915_drm.h > @@ -42,7 +42,7 @@ extern struct resource intel_graphics_stolen_res; > * The Bridge device's PCI config space has information about the > * fb aperture size and the amount of pre-reserved memory. > * This is all handled in the intel-gtt.ko module. i915.ko only > - * cares about the vga bit for the vga rbiter. > + * cares about the vga bit for the vga arbiter. > */ > #define INTEL_GMCH_CTRL 0x52 > #define INTEL_GMCH_VGA_DISABLE (1 << 1) -- Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH 1/2] accel/ivpu: Do not trigger extra VPU reset if the VPU is idle
On 5/25/2023 4:38 AM, Stanislaw Gruszka wrote:
From: Andrzej Kacprowski
Turning off the PLL and entering D0i3 will reset the VPU so
an explicit IP reset is redundant.
But if the VPU is active, it may interfere with PLL disabling
and to avoid that, we have to issue an additional IP reset
to silence the VPU before turning off the PLL.
Fixes: a8fed6d1e0b9 ("accel/ivpu: Fix power down sequence")
Signed-off-by: Andrzej Kacprowski
Reviewed-by: Stanislaw Gruszka
Signed-off-by: Stanislaw Gruszka
Reviewed-by: Jeffrey Hugo
Re: [PATCH] accel/ivpu: ivpu_ipc needs GENERIC_ALLOCATOR
On 5/25/2023 10:45 PM, Randy Dunlap wrote:
Drivers that use the gen_pool*() family of functions should
select GENERIC_ALLOCATOR to prevent build errors like these:
ld: drivers/accel/ivpu/ivpu_ipc.o: in function `gen_pool_free':
include/linux/genalloc.h:172: undefined reference to `gen_pool_free_owner'
ld: drivers/accel/ivpu/ivpu_ipc.o: in function `gen_pool_alloc_algo':
include/linux/genalloc.h:138: undefined reference to `gen_pool_alloc_algo_owner'
ld: drivers/accel/ivpu/ivpu_ipc.o: in function `gen_pool_free':
include/linux/genalloc.h:172: undefined reference to `gen_pool_free_owner'
ld: drivers/accel/ivpu/ivpu_ipc.o: in function `ivpu_ipc_init':
drivers/accel/ivpu/ivpu_ipc.c:441: undefined reference to `devm_gen_pool_create'
ld: drivers/accel/ivpu/ivpu_ipc.o: in function `gen_pool_add_virt':
include/linux/genalloc.h:104: undefined reference to `gen_pool_add_owner'
Fixes: 5d7422cfb498 ("accel/ivpu: Add IPC driver and JSM messages")
Signed-off-by: Randy Dunlap
Reported-by: kernel test robot
Link: https://lore.kernel.org/all/202305221206.1taugdkp-...@intel.com/
Cc: Oded Gabbay
Cc: dri-devel@lists.freedesktop.org
Cc: Jacek Lawrynowicz
Cc: Stanislaw Gruszka
Cc: Andrzej Kacprowski
Cc: Krystian Pradzynski
Cc: Jeffrey Hugo
Cc: Daniel Vetter
Reviewed-by: Jeffrey Hugo
[PATCH] drm/vkms: Add support to 1D gamma LUT
Support a 1D gamma LUT for each color channel on the VKMS driver. Add a
check for the LUT length by creating vkms_atomic_check().
Tested with:
igt@kms_color@gamma
igt@kms_color@legacy-gamma
igt@kms_color@invalid-gamma-lut-sizes
Signed-off-by: Arthur Grillo
---
drivers/gpu/drm/vkms/vkms_composer.c | 28
drivers/gpu/drm/vkms/vkms_crtc.c | 3 +++
drivers/gpu/drm/vkms/vkms_drv.c | 20 +++-
drivers/gpu/drm/vkms/vkms_drv.h | 2 ++
4 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 906d3df40cdb..7ec9ebe28d5a 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -89,6 +89,32 @@ static void fill_background(const struct pixel_argb_u16
*background_color,
output_buffer->pixels[i] = *background_color;
}
+static void apply_lut(const struct vkms_crtc_state *crtc_state, struct
line_buffer *output_buffer)
+{
+ struct drm_color_lut *lut;
+ size_t lut_length;
+
+ if (!crtc_state->base.gamma_lut)
+ return;
+
+ lut = (struct drm_color_lut *)crtc_state->base.gamma_lut->data;
+
+ lut_length = crtc_state->base.gamma_lut->length / sizeof(*lut);
+
+ if (!lut_length)
+ return;
+
+ for (size_t x = 0; x < output_buffer->n_pixels; x++) {
+ size_t lut_r_index = output_buffer->pixels[x].r * (lut_length -
1) / 0x;
+ size_t lut_g_index = output_buffer->pixels[x].g * (lut_length -
1) / 0x;
+ size_t lut_b_index = output_buffer->pixels[x].b * (lut_length -
1) / 0x;
+
+ output_buffer->pixels[x].r = lut[lut_r_index].red;
+ output_buffer->pixels[x].g = lut[lut_g_index].green;
+ output_buffer->pixels[x].b = lut[lut_b_index].blue;
+ }
+}
+
/**
* @wb_frame_info: The writeback frame buffer metadata
* @crtc_state: The crtc state
@@ -128,6 +154,8 @@ static void blend(struct vkms_writeback_job *wb,
output_buffer);
}
+ apply_lut(crtc_state, output_buffer);
+
*crc32 = crc32_le(*crc32, (void *)output_buffer->pixels,
row_size);
if (wb)
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index 515f6772b866..61e500b8c9da 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -290,6 +290,9 @@ int vkms_crtc_init(struct drm_device *dev, struct drm_crtc
*crtc,
drm_crtc_helper_add(crtc, _crtc_helper_funcs);
+ drm_mode_crtc_set_gamma_size(crtc, VKMS_LUT_SIZE);
+ drm_crtc_enable_color_mgmt(crtc, 0, false, VKMS_LUT_SIZE);
+
spin_lock_init(_out->lock);
spin_lock_init(_out->composer_lock);
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index e3c9c9571c8d..dd0af086e7fa 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -120,9 +120,27 @@ static const struct drm_driver vkms_driver = {
.minor = DRIVER_MINOR,
};
+static int vkms_atomic_check(struct drm_device *dev, struct drm_atomic_state
*state)
+{
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *new_crtc_state;
+ int i;
+
+ for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
+ if (!new_crtc_state->gamma_lut ||
!new_crtc_state->color_mgmt_changed)
+ continue;
+
+ if (new_crtc_state->gamma_lut->length / sizeof(struct
drm_color_lut *)
+ > VKMS_LUT_SIZE)
+ return -EINVAL;
+ }
+
+ return drm_atomic_helper_check(dev, state);
+}
+
static const struct drm_mode_config_funcs vkms_mode_funcs = {
.fb_create = drm_gem_fb_create,
- .atomic_check = drm_atomic_helper_check,
+ .atomic_check = vkms_atomic_check,
.atomic_commit = drm_atomic_helper_commit,
};
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 5f1a0a44a78c..a3b7025c1b9a 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -23,6 +23,8 @@
#define NUM_OVERLAY_PLANES 8
+#define VKMS_LUT_SIZE 256
+
struct vkms_frame_info {
struct drm_framebuffer *fb;
struct drm_rect src, dst;
--
2.40.1
RE: [PATCH v9 RESEND 4/5] drm: Add RZ/G2L DU Support
Hi Laurent,
Thanks for the feedback.
> Subject: Re: [PATCH v9 RESEND 4/5] drm: Add RZ/G2L DU Support
>
> Hi Biju,
>
> On Thu, Jun 01, 2023 at 12:08:44PM +, Biju Das wrote:
> > > Subject: Re: [PATCH v9 RESEND 4/5] drm: Add RZ/G2L DU Support
> > >
> > > Hi Biju,
> > >
> > > Thank you for the patch.
> > >
> > > This is a partial review, because the driver is big, and because
> > > some changes in v10 will (hopefully) simplify the code and make
> > > review easier.
> >
> > I agree v10 will simplify the code as I have do clean-ups based on
> > your review commnet.
> >
> > > On Tue, May 02, 2023 at 11:09:11AM +0100, Biju Das wrote:
> > > > The LCD controller is composed of Frame Compression Processor
> > > > (FCPVD), Video Signal Processor (VSPD), and Display Unit (DU).
> > > >
> > > > It has DPI/DSI interfaces and supports a maximum resolution of
> > > > 1080p along with 2 RPFs to support the blending of two picture
> > > > layers and raster operations (ROPs).
> > > >
> > > > The DU module is connected to VSPD. Add RZ/G2L DU support for
> > > > RZ/G2L alike SoCs.
> > > >
> > > > Signed-off-by: Biju Das
> > > > ---
> > > > Ref:
> > > >
> > > > v8->v9:
> > > > * Dropped reset_control_assert() from error patch for
> rzg2l_du_crtc_get() as
> > > >suggested by Philipp Zabel.
> > > > v7->v8:
> > > > * Dropped RCar du lib and created RZ/G2L DU DRM driver by
> creating rz_du folder.
> > > > * Updated KConfig and Makefile.
> > > > v6->v7:
> > > > * Split DU lib and RZ/G2L du driver as separate patch series as
> > > >DU support added to more platforms based on RZ/G2L alike SoCs.
> > > > * Rebased to latest drm-tip.
> > > > * Added patch #2 for binding support for RZ/V2L DU
> > > > * Added patch #4 for driver support for RZ/V2L DU
> > > > * Added patch #5 for SoC DTSI support for RZ/G2L DU
> > > > * Added patch #6 for SoC DTSI support for RZ/V2L DU
> > > > * Added patch #7 for Enabling DU on SMARC EVK based on
> RZ/{G2L,V2L} SoCs.
> > > > * Added patch #8 for Enabling DU on SMARC EVK based on RZ/G2LC
> SoC.
> > > > ---
> > > > drivers/gpu/drm/renesas/Kconfig | 1 +
> > > > drivers/gpu/drm/renesas/Makefile | 1 +
> > > > drivers/gpu/drm/renesas/rz-du/Kconfig | 20 +
> > > > drivers/gpu/drm/renesas/rz-du/Makefile| 8 +
> > > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 714
> > > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.h |
> > > > 99 +++ drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 188 +
> > > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h | 89 ++
> > > > .../gpu/drm/renesas/rz-du/rzg2l_du_encoder.c | 112 +++
> > > > .../gpu/drm/renesas/rz-du/rzg2l_du_encoder.h | 28 +
> > > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c | 770
> > > > ++ drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.h
> > > > | 43 + drivers/gpu/drm/renesas/rz-du/rzg2l_du_regs.h | 67 ++
> > > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c | 430 ++
> > > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.h | 94 +++
> > > > 15 files changed, 2664 insertions(+) create mode 100644
> > > > drivers/gpu/drm/renesas/rz-du/Kconfig
> > > > create mode 100644 drivers/gpu/drm/renesas/rz-du/Makefile
> > > > create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> > > > create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.h
> > > > create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
> > > > create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
> > > > create mode 100644
> > > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.c
> > > > create mode 100644
> > > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.h
> > > > create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
> > > > create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.h
> > > > create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_regs.h
> > > > create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c
> > > > create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.h
>
> [snip]
>
> > > > diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> > > > b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> > > > new file mode 100644
> > > > index ..d61d433d72e6
> > > > --- /dev/null
> > > > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> > > > @@ -0,0 +1,714 @@
>
> [snip]
>
> > > > +/*
> > > > +-
> > > > +
> > > > + * CRTC Functions
> > > > + */
> > > > +
> > > > +int __rzg2l_du_crtc_plane_atomic_check(struct drm_plane *plane,
> > > > + struct drm_plane_state *state,
> > > > + const struct rzg2l_du_format_info
> **format)
> > >
> > > This function is only called from rzg2l_du_vsp_plane_atomic_check(),
> > > I would inline it there.
> >
> > Agreed.
> >
> > > > +{
> > > > + struct drm_device *dev = plane->dev;
>
Re: Kernel bug related to drivers/gpu/drm/ttm/ttm_bo.c
See also (maybe this user experiences the same bug?): https://bugzilla.redhat.com/show_bug.cgi?id=2193325 To provide direct links: My original post in "Kernel bug related to drivers/gpu/drm/ttm/ttm_bo.c" relates to: https://gitlab.com/py0xc31/public-tmp-storage/-/blob/main/retry6.3.4/firefoxCrash-noPidof-kernelerror-6.3.4.pstate-passive.CUT.log https://gitlab.com/py0xc31/public-tmp-storage/-/blob/main/retry6.3.4/firefoxCrash-noPidof-kernelerror-6.3.4.pstate-passive.preHALT.log Some logs contain issues involving BOTH "amdgpu" and (one or more) CPU(s), but a few refer to only one of the two, and some others none of the two but only a reference to a kernel BUG. But sometimes logs are frozen before any log can be written. Currently, most logs do no longer contain much about amdgpu; but an earlier log with more amdgpu-related entries was https://gitlab.com/py0xc31/public-tmp-storage/-/blob/main/2nd/root-journalctl.-r.-b.-1.FirstFirefoxInsideTabFreeze_thenRemainingFirefoxFreeze_thenSystemFreeze.16-31-55screenClockFrozen.kernel6.2.15.amd_pstate-passive.log (which is also contained/elaborated in my bug report I referred to in my original post). The latter (older) log is widely comparable to the other user's bug report and it is also from roughly the same time (beginning-mid May). Maybe some Fedora updates in between trigger the bug differently, causing different logs. Another user with potentially the same issue can be found with an extract from their logs here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-26325e5399 (the post of the user "benthaase")
[PATCH v2] drm/i915/pxp: Optimize GET_PARAM:PXP_STATUS
After recent discussions with Mesa folks, it was requested
that we optimize i915's GET_PARAM for the PXP_STATUS without
changing the UAPI spec.
Add these additional optimizations:
- If any PXP initializatoin flow failed, then ensure that
we catch it so that we can change the returned PXP_STATUS
from "2" (i.e. 'PXP is supported but not yet ready')
to "-ENODEV". This typically should not happen and if it
does, we have a platform configuration issue.
- If a PXP arbitration session creation event failed
due to incorrect firmware version or blocking SOC fusing
or blocking BIOS configuration (platform reasons that won't
change if we retry), then reflect that blockage by also
returning -ENODEV in the GET_PARAM:PXP_STATUS.
- GET_PARAM:PXP_STATUS should not wait at all if PXP is
supported but non-i915 dependencies (component-driver /
firmware) we are still pending to complete the init flows.
In this case, just return "2" immediately (i.e. 'PXP is
supported but not yet ready').
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 11 +-
drivers/gpu/drm/i915/i915_getparam.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp.c | 25 ++
drivers/gpu/drm/i915/pxp/intel_pxp.h | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 7 +++---
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 7 +++---
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 9
7 files changed, 50 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
index fb0984f875f9..4dd744c96a37 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -42,8 +42,17 @@ static void gsc_work(struct work_struct *work)
}
ret = intel_gsc_proxy_request_handler(gsc);
- if (ret)
+ if (ret) {
+ if (actions & GSC_ACTION_FW_LOAD) {
+ /*
+* a proxy request failure that came together
with the
+* firmware load action means the last part of
init has
+* failed so GSC fw won't be usable after this
+*/
+ intel_uc_fw_change_status(>fw,
INTEL_UC_FIRMWARE_LOAD_FAIL);
+ }
goto out_put;
+ }
/* mark the GSC FW init as done the first time we run this */
if (actions & GSC_ACTION_FW_LOAD) {
diff --git a/drivers/gpu/drm/i915/i915_getparam.c
b/drivers/gpu/drm/i915/i915_getparam.c
index 6f11d7eaa91a..1b2ee98a158a 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -105,7 +105,7 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
return value;
break;
case I915_PARAM_PXP_STATUS:
- value = intel_pxp_get_readiness_status(i915->pxp);
+ value = intel_pxp_get_readiness_status(i915->pxp, 1);
if (value < 0)
return value;
break;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index bb2e15329f34..5677377f3bb2 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -359,21 +359,38 @@ void intel_pxp_end(struct intel_pxp *pxp)
intel_runtime_pm_put(>runtime_pm, wakeref);
}
+static bool pxp_required_fw_failed(struct intel_pxp *pxp)
+{
+ if (__intel_uc_fw_status(>ctrl_gt->uc.huc.fw) ==
INTEL_UC_FIRMWARE_LOAD_FAIL)
+ return true;
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0) &&
+ __intel_uc_fw_status(>ctrl_gt->uc.gsc.fw) ==
INTEL_UC_FIRMWARE_LOAD_FAIL)
+ return true;
+
+ return false;
+}
+
/*
* this helper is used by both intel_pxp_start and by
* the GET_PARAM IOCTL that user space calls. Thus, the
* return values here should match the UAPI spec.
*/
-int intel_pxp_get_readiness_status(struct intel_pxp *pxp)
+int intel_pxp_get_readiness_status(struct intel_pxp *pxp, int timeout_ms)
{
if (!intel_pxp_is_enabled(pxp))
return -ENODEV;
+ if (pxp_required_fw_failed(pxp))
+ return -ENODEV;
+
+ if (pxp->platform_cfg_is_bad)
+ return -ENODEV;
+
if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
- if (wait_for(intel_pxp_gsccs_is_ready_for_sessions(pxp), 250))
+ if (wait_for(intel_pxp_gsccs_is_ready_for_sessions(pxp),
timeout_ms))
return 2;
} else {
- if (wait_for(pxp_component_bound(pxp), 250))
+ if (wait_for(pxp_component_bound(pxp), timeout_ms))
return 2;
}
return 1;
@@ -387,7
Re: (subset) [PATCH] mailmap: Add missing email address
On Wed, 31 May 2023 15:37:24 +0200, Maxime Ripard wrote: > I've been using that email address for contributions for a while but it > seems I never added it to mailmap. > > Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime
Re: [PATCH v2 3/3] drm/panel-simple: allow LVDS format override
Hi Johannes,
Thank you for the patch.
On Tue, May 23, 2023 at 10:19:43AM +0200, Johannes Zink wrote:
> Some panels support multiple LVDS data mapping formats, which can be
> used e.g. run displays on jeida-18 format when only 3 LVDS lanes are
> available.
>
> Add parsing of an optional data-mapping devicetree property, which also
> touches up the bits per color to match the bus format.
Of course one could argue that the innolux,g101ice-l01 panel should have
used the panel-lvds bindings... :-)
> Signed-off-by: Johannes Zink
>
> ---
>
> Changes:
>
> v1 -> v2: - fix missing unwind goto found by test robot
> Reported-by: kernel test robot
> Reported-by: Dan Carpenter
> Link:
> https://lore.kernel.org/r/202304160359.4lhmfolu-...@intel.com/
> ---
> drivers/gpu/drm/panel/panel-simple.c | 39
> +++-
> 1 file changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 2a9c1a785a5c..0a35fdb49ccb 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -40,6 +40,7 @@
> #include
> #include
> #include
> +#include
>
> /**
> * struct panel_desc - Describes a simple panel.
> @@ -559,7 +560,7 @@ static int panel_simple_probe(struct device *dev, const
> struct panel_desc *desc)
> struct device_node *ddc;
> int connector_type;
> u32 bus_flags;
> - int err;
> + int err, ret;
>
> panel = devm_kzalloc(dev, sizeof(*panel), GFP_KERNEL);
> if (!panel)
> @@ -605,6 +606,42 @@ static int panel_simple_probe(struct device *dev, const
> struct panel_desc *desc)
> panel_simple_parse_panel_timing_node(dev, panel, );
> }
>
> +
Double blank line.
> + /* optional data-mapping property for overriding bus format */
s/optional/Optional/
> + ret = drm_of_lvds_get_data_mapping(dev->of_node);
> + if (ret == -EINVAL) {
> + dev_warn(dev, "Ignore invalid data-mapping property");
> + } else if (ret != -ENODEV) {
If someone incorrectly sets the property in DT for a non-LVDS panel,
the result won't be nice. That's of course a DT issue, but I wonder if
we could/should protect against it. You could move this code to a
separate function (which would have the added benefit of lowering the
indentation level as you can return early in error cases), and call it
from panel_simple_probe() only if the panel is an LVDS panel (as
reported by its desc->bus_format value).
> + int bpc;
> +
> + switch (ret) {
> + default:
> + WARN_ON(1);
> + fallthrough;
> + case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG:
> + fallthrough;
> + case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA:
> + bpc = 8;
> + break;
> + case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
> + bpc = 6;
> + }
> +
> + if (desc->bpc != bpc || desc->bus_format != ret) {
> + struct panel_desc *override_desc;
> +
> + override_desc = devm_kmemdup(dev, desc, sizeof(*desc),
> GFP_KERNEL);
> + if (!override_desc) {
> + err = -ENOMEM;
> + goto free_ddc;
> + }
> +
> + override_desc->bus_format = ret;
> + override_desc->bpc = bpc;
> + panel->desc = override_desc;
> + }
> + }
> +
> connector_type = desc->connector_type;
> /* Catch common mistakes for panels. */
> switch (connector_type) {
--
Regards,
Laurent Pinchart
Re: [PATCH v2 2/3] dt-bindings: display: simple: support non-default data-mapping
Hi Johannes,
Thank you for the patch.
On Tue, May 23, 2023 at 10:19:42AM +0200, Johannes Zink wrote:
> Some Displays support more than just a single default lvds data mapping,
s/lvds/LVDS/
> which can be used to run displays on only 3 LVDS lanes in the jeida-18
> data-mapping mode.
>
> Add an optional data-mapping property to allow overriding the default
> data mapping. As it does not generally apply to any display and bus: use
s/bus:/bus,/
> it selectively on the innolux,g101ice-l01, which supports changing the
> data mapping via a strapping pin.
>
> Signed-off-by: Johannes Zink
> ---
>
> Changes:
>
> v1 -> v2: - worked in Rob's review findings (thanks for reviewing my
> work): use extracted common property instead of duplicating
> the property
> - refined commit message
> - add an example dts for automated checking
> ---
> .../bindings/display/panel/panel-simple.yaml | 26
> +-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> index ec50dd268314..698301c8c920 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> @@ -21,9 +21,9 @@ description: |
>
> allOf:
>- $ref: panel-common.yaml#
> + - $ref: ../lvds-data-mapping.yaml#
>
> properties:
> -
>compatible:
> enum:
> # compatible must be listed in alphabetical order, ordered by compatible.
> @@ -353,6 +353,17 @@ properties:
>power-supply: true
>no-hpd: true
>hpd-gpios: true
> + data-mapping: true
As the property is optional, don't you need a default value ?
> +
> +if:
> + not:
> +properties:
> + compatible:
> +contains:
> + const: innolux,g101ice-l01
> +then:
> + properties:
> +data-mapping: false
>
> additionalProperties: false
>
> @@ -372,3 +383,16 @@ examples:
> };
>};
> };
> + - |
> +panel_lvds: panel-lvds {
> + compatible = "innolux,g101ice-l01";
> + power-supply = <_lcd_reg>;
> +
> + data-mapping = "jeida-24";
> +
> + port {
> +panel_in_lvds: endpoint {
> + remote-endpoint = <_out_lvds>;
> +};
> + };
> +};
>
--
Regards,
Laurent Pinchart
Re: [Intel-gfx] [PATCH] drm/i915/pxp: Optimize GET_PARAM:PXP_STATUS
Thanks Jani - will rev this up and fix these. On Fri, 2023-06-02 at 16:03 +0300, Jani Nikula wrote: > On Thu, 01 Jun 2023, Alan Previn wrote: > > After recent discussions with Mesa folks, it was requested > > that we optimize i915's GET_PARAM for the PXP_STATUS without > > changing the UAPI spec. > > > > This patch adds this additional optimizations: > > Nitpick, please avoid "This patch". It's redundant, and after the patch > gets applied it becomes a commit, not a patch. > > Instead, use the imperative mood, e.g. "Add these additional > optimizations". > > See > https://docs.kernel.org/process/submitting-patches.html#describe-your-changes alan:snip > > > -int intel_pxp_get_readiness_status(struct intel_pxp *pxp) > > +int intel_pxp_get_readiness_status(struct intel_pxp *pxp, int timeout) > > It would help the reader if you named the parameter timeout_ms. Assuming > the unit is ms. alan:snip > > -is_fw_err_platform_config(u32 type) > > +is_fw_err_platform_config(u32 type, struct intel_pxp *pxp) > > It's customary to have the parameters ordered from higher context to > lower. > alan:snip
Re: [PATCH v2 1/3] dt-bindings: display: move LVDS data-mapping definition to separate file
Hello Johannes, Thank you for the patch. On Tue, May 23, 2023 at 10:19:41AM +0200, Johannes Zink wrote: > As the LVDS data-mapping property is required in multiple bindings: move > it to separate file and include instead of duplicating it. > > Signed-off-by: Johannes Zink > > --- > > Changes: > > v1 -> v2: worked in Rob's review findings (thank you for reviewing my > work): extract common properties to > file and include it instead of duplicating it > --- > .../bindings/display/lvds-data-mapping.yaml| 84 > ++ > .../devicetree/bindings/display/lvds.yaml | 75 +++ > 2 files changed, 92 insertions(+), 67 deletions(-) > > diff --git a/Documentation/devicetree/bindings/display/lvds-data-mapping.yaml > b/Documentation/devicetree/bindings/display/lvds-data-mapping.yaml > new file mode 100644 > index ..17ef5c9a5a90 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/lvds-data-mapping.yaml > @@ -0,0 +1,84 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/lvds-data-mapping.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: LVDS Data Mapping > + > +maintainers: > + - Laurent Pinchart > + - Thierry Reding > + > +description: |+ > + LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. > Multiple > + incompatible data link layers have been used over time to transmit image > data > + to LVDS devices. This bindings supports devices compatible with the > following > + specifications. > + > + [JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February > + 1999 (Version 1.0), Japan Electronic Industry Development Association > (JEIDA) > + [LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National > + Semiconductor > + [VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video > + Electronics Standards Association (VESA) > + > + Device compatible with those specifications have been marketed under the > + FPD-Link and FlatLink brands. > + > +properties: > + data-mapping: > +enum: > + - jeida-18 > + - jeida-24 > + - vesa-24 > +description: | > + The color signals mapping order. > + > + LVDS data mappings are defined as follows. > + > + - "jeida-18" - 18-bit data mapping compatible with the [JEIDA], [LDI] > and > +[VESA] specifications. Data are transferred as follows on 3 LVDS > lanes. > + > + Slot 0 1 2 3 4 5 6 > + _ > + Clock \___/ > + __ __ __ __ __ __ __ > + DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__>< > + DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__>< > + DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__>< > + > + - "jeida-24" - 24-bit data mapping compatible with the [DSIM] and [LDI] > +specifications. Data are transferred as follows on 4 LVDS lanes. > + > + Slot 0 1 2 3 4 5 6 > + _ > + Clock \___/ > + __ __ __ __ __ __ __ > + DATA0 ><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__>< > + DATA1 ><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__>< > + DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__>< > + DATA3 ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__>< > + > + - "vesa-24" - 24-bit data mapping compatible with the [VESA] > specification. > +Data are transferred as follows on 4 LVDS lanes. > + > + Slot 0 1 2 3 4 5 6 > + _ > + Clock \___/ > + __ __ __ __ __ __ __ > + DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__>< > + DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__>< > + DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__>< > + DATA3 ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__>< > + > + Control signals are mapped as follows. > + > + CTL0: HSync > + CTL1: VSync > + CTL2: Data Enable > + CTL3: 0 > + > +additionalProperties: true > + > +... > diff --git a/Documentation/devicetree/bindings/display/lvds.yaml > b/Documentation/devicetree/bindings/display/lvds.yaml > index 7cd2ce7e9c33..2200f986c3cf 100644 > ---
Re: [PATCH 00/36] drm/amd/display: add AMD driver-specific properties for color mgmt
On 5/23/23 18:14, Melissa Wen wrote: > This series is a refined version of our RFC [1] for AMD driver-specific > color management properties. It is a collection of contributions from > Joshua, Harry and I to enhance AMD KMS color pipeline for Steam > Deck/SteamOS by exposing the large set of color caps available in AMD > display HW. > > Considering RFC feedback, this patchset differs from the previous one by > removing the KConfig option and just guarding driver-specific properties > with `AMD_PRIVATE_COLOR` - but we also removed the guards from internal > elements and operations. We stopped to advertise CRTC shaper and 3D LUTs > properties since they aren't in use in the Steam Deck color pipeline[2]. > On the other hand, we keep mapping CRTC shaper and 3D LUTs (DM) to DC > MPC setup. We also improved curve calculations to take into account HW > color caps. > > In short, for pre-blending, we added the following properties: > - plane degamma LUT and predefined transfer function; > - plane HDR multiplier > - plane shaper LUT/transfer function; > - plane 3D LUT; and finally, > - plane blend LUT/transfer function, just before blending. > > After blending, we already have DRM CRTC degamma/gamma LUTs and CTM, > therefore, we extend post-blending color pipeline with CRTC gamma > transfer function. > > The first three patches are on DRM KMS side. We expose DRM property > helper for blob lookup and replacement so that we can use it for > managing driver-specific properties. We add a tracked for plane color > mgmt changes and increase the maximum number of properties to > accommodate this expansion. > > The userspace case here is Gamescope which is the compositor for > SteamOS. It's already using all of this functionality to implement its > color management pipeline right now [3]. > > Current IGT tests kms_color and amdgpu/amd_color on DCN301 and DCN21 HW > preserve the same results with and without the guard. > > Finally, I may have missed something, please let me know if that's the > case. > Looks like we're on the right track with this. Patches 1-3, 15, 17, 24-31, 33-35 are Reviewed-by: Harry Wentland I left comments on a bunch of the other patches. Let's replace drm_ prefices with amdgpu_ or amdgpu_dm and move the property registration/ definition from amdgpu_display.c to amdgpu_dm_color.c. I'll chase internal feedback for some of the DC patches. They look fine to me but I don't want them to cause problems on other OSes. I might pull them through our internal repo. Will update you on that. Patches 16-22 will be untested without properties to actually set them. That makes me a bit uncomfortable but on the other hand they provide functionality that we'll want eventually. Let me think about them a bit more and also make sure the DC portions won't cause issues. Harry > Best Regards, > > Melissa Wen > > [1] https://lore.kernel.org/dri-devel/20230423141051.702990-1-m...@igalia.com > [2] > https://github.com/ValveSoftware/gamescope/blob/master/src/docs/Steam%20Deck%20Display%20Pipeline.png > [3] https://github.com/ValveSoftware/gamescope > > > Harry Wentland (2): > drm/amd/display: fix segment distribution for linear LUTs > drm/amd/display: fix the delta clamping for shaper LUT > > Joshua Ashton (13): > drm/amd/display: add plane degamma TF driver-specific property > drm/amd/display: add plane HDR multiplier driver-specific property > drm/amd/display: add plane blend LUT and TF driver-specific properties > drm/amd/display: copy 3D LUT settings from crtc state to stream_update > drm/amd/display: dynamically acquire 3DLUT resources for color changes > drm/amd/display: add CRTC regamma TF support > drm/amd/display: set sdr_ref_white_level to 80 for out_transfer_func > drm/amd/display: add support for plane degamma TF and LUT properties > drm/amd/display: add dc_fixpt_from_s3132 helper > drm/adm/display: add HDR multiplier support > drm/amd/display: handle empty LUTs in __set_input_tf > drm/amd/display: add DRM plane blend LUT and TF support > drm/amd/display: allow newer DC hardware to use degamma ROM for PQ/HLG > > Melissa Wen (21): > drm/drm_mode_object: increase max objects to accommodate new color > props > drm/drm_property: make replace_property_blob_from_id a DRM helper > drm/drm_plane: track color mgmt changes per plane > drm/amd/display: add CRTC driver-specific property for gamma TF > drm/amd/display: add plane driver-specific properties for degamma LUT > drm/amd/display: add plane 3D LUT driver-specific properties > drm/amd/display: add plane shaper LUT driver-specific properties > drm/amd/display: add plane shaper TF driver-private property > drm/amd/display: add comments to describe DM crtc color mgmt behavior > drm/amd/display: encapsulate atomic regamma operation > drm/amd/display: update lut3d and shaper lut to stream > drm/amd/display: allow BYPASS 3D LUT but keep shaper LUT settings > drm/amd/display: handle MPC 3D LUT
Re: [Intel-gfx] [PATCH] drm/i915/pxp: Fix size_t format specifier in gsccs_send_message()
On Tue, 30 May 2023, Andi Shyti wrote:
> Hi Nathan,
>
> On Tue, May 30, 2023 at 11:37:56AM -0700, Nathan Chancellor wrote:
>> When building ARCH=i386 allmodconfig, the following warning occurs:
>>
>> In file included from include/linux/device.h:15,
>>from include/linux/node.h:18,
>>from include/linux/cpu.h:17,
>>from include/linux/static_call.h:135,
>>from arch/x86/include/asm/perf_event.h:5,
>>from include/linux/perf_event.h:25,
>>from drivers/gpu/drm/i915/i915_pmu.h:11,
>>from drivers/gpu/drm/i915/gt/intel_engine_types.h:21,
>>from drivers/gpu/drm/i915/gt/intel_context_types.h:18,
>>from drivers/gpu/drm/i915/gem/i915_gem_context_types.h:20,
>>from drivers/gpu/drm/i915/i915_request.h:34,
>>from drivers/gpu/drm/i915/i915_active.h:13,
>>from drivers/gpu/drm/i915/gt/intel_context.h:13,
>>from drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c:8:
>> drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c: In function
>> 'gsccs_send_message':
>> include/drm/drm_print.h:456:39: error: format '%ld' expects argument of
>> type 'long int', but argument 4 has type 'size_t' {aka 'unsigned int'}
>> [-Werror=format=]
>> 456 | dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
>> | ^~~~
>> include/linux/dev_printk.h:110:30: note: in definition of macro
>> 'dev_printk_index_wrap'
>> 110 | _p_func(dev, fmt, ##__VA_ARGS__);
>> \
>> | ^~~
>> include/linux/dev_printk.h:146:61: note: in expansion of macro 'dev_fmt'
>> 146 | dev_printk_index_wrap(_dev_warn, KERN_WARNING, dev,
>> dev_fmt(fmt), ##__VA_ARGS__)
>> | ^~~
>> include/drm/drm_print.h:456:9: note: in expansion of macro 'dev_warn'
>> 456 | dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
>> | ^~~~
>> include/drm/drm_print.h:466:9: note: in expansion of macro '__drm_printk'
>> 466 | __drm_printk((drm), warn,, fmt, ##__VA_ARGS__)
>> | ^~~~
>> drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c:146:17: note: in expansion of
>> macro 'drm_warn'
>> 146 | drm_warn(>drm, "caller with insufficient PXP
>> reply size %u (%ld)\n",
>> | ^~~~
>> cc1: all warnings being treated as errors
>>
>> Use the '%zu' format specifier, as the variable is a 'size_t'.
>>
>> Fixes: dc9ac125d81f ("drm/i915/pxp: Add GSC-CS backend to send GSC fw
>> messages")
>> Signed-off-by: Nathan Chancellor
>
> yes, as specified in Documentation/core-api/printk-formats.rst.
>
> Reviewed-by: Andi Shyti
Thanks for the patch and review, pushed to drm-intel-gt-next. The CI
failure was about hdac, hardly anything to do with this one.
BR,
Jani.
>
> Thanks,
> Andi
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH 36/36] drm/amd/display: allow newer DC hardware to use degamma ROM for PQ/HLG
On 5/23/23 18:15, Melissa Wen wrote:
> From: Joshua Ashton
>
> Need to funnel the color caps through to these functions so it can check
> that the hardware is capable.
>
> Signed-off-by: Joshua Ashton
> Signed-off-by: Melissa Wen
> ---
> .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 35 ---
> 1 file changed, 23 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> index 4a2b66568451..714f07bb9c9c 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> @@ -338,6 +338,7 @@ static int amdgpu_dm_set_atomic_regamma(struct
> dc_stream_state *stream,
> /**
> * __set_input_tf - calculates the input transfer function based on expected
> * input space.
> + * @caps: dc color capabilities
> * @func: transfer function
> * @lut: lookup table that defines the color space
> * @lut_size: size of respective lut.
> @@ -345,7 +346,7 @@ static int amdgpu_dm_set_atomic_regamma(struct
> dc_stream_state *stream,
> * Returns:
> * 0 in case of success. -ENOMEM if fails.
> */
> -static int __set_input_tf(struct dc_transfer_func *func,
> +static int __set_input_tf(struct dc_color_caps *caps, struct
> dc_transfer_func *func,
> const struct drm_color_lut *lut, uint32_t lut_size)
> {
> struct dc_gamma *gamma = NULL;
> @@ -362,7 +363,7 @@ static int __set_input_tf(struct dc_transfer_func *func,
> __drm_lut_to_dc_gamma(lut, gamma, false);
> }
>
> - res = mod_color_calculate_degamma_params(NULL, func, gamma, gamma !=
> NULL);
> + res = mod_color_calculate_degamma_params(caps, func, gamma, gamma !=
> NULL);
>
> if (gamma)
> dc_gamma_release();
> @@ -511,7 +512,7 @@ static int amdgpu_dm_atomic_blend_lut(const struct
> drm_color_lut *blend_lut,
> func_blend->tf = tf;
> func_blend->sdr_ref_white_level = SDR_WHITE_LEVEL_INIT_VALUE;
>
> - ret = __set_input_tf(func_blend, blend_lut, blend_size);
> + ret = __set_input_tf(NULL, func_blend, blend_lut, blend_size);
> } else {
> func_blend->type = TF_TYPE_BYPASS;
> func_blend->tf = TRANSFER_FUNCTION_LINEAR;
> @@ -818,7 +819,8 @@ int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state
> *crtc,
>
> static int
> map_crtc_degamma_to_dc_plane(struct dm_crtc_state *crtc,
> - struct dc_plane_state *dc_plane_state)
> + struct dc_plane_state *dc_plane_state,
> + struct dc_color_caps *caps)
> {
> const struct drm_color_lut *degamma_lut;
> enum dc_transfer_func_predefined tf = TRANSFER_FUNCTION_SRGB;
> @@ -873,7 +875,7 @@ map_crtc_degamma_to_dc_plane(struct dm_crtc_state *crtc,
> dc_plane_state->in_transfer_func->tf =
> TRANSFER_FUNCTION_LINEAR;
>
> - r = __set_input_tf(dc_plane_state->in_transfer_func,
> + r = __set_input_tf(caps, dc_plane_state->in_transfer_func,
> degamma_lut, degamma_size);
> if (r)
> return r;
> @@ -886,7 +888,7 @@ map_crtc_degamma_to_dc_plane(struct dm_crtc_state *crtc,
> dc_plane_state->in_transfer_func->tf = tf;
>
> if (tf != TRANSFER_FUNCTION_SRGB &&
> - !mod_color_calculate_degamma_params(NULL,
> + !mod_color_calculate_degamma_params(caps,
>
> dc_plane_state->in_transfer_func,
> NULL, false))
> return -ENOMEM;
> @@ -897,7 +899,8 @@ map_crtc_degamma_to_dc_plane(struct dm_crtc_state *crtc,
>
> static int
> __set_dm_plane_degamma(struct drm_plane_state *plane_state,
> -struct dc_plane_state *dc_plane_state)
> +struct dc_plane_state *dc_plane_state,
> +struct dc_color_caps *color_caps)
> {
> struct dm_plane_state *dm_plane_state = to_dm_plane_state(plane_state);
> const struct drm_color_lut *degamma_lut;
> @@ -906,6 +909,9 @@ __set_dm_plane_degamma(struct drm_plane_state
> *plane_state,
> bool has_degamma_lut;
> int ret;
>
> + if (dc_plane_state->ctx && dc_plane_state->ctx->dc)
> + color_caps = _plane_state->ctx->dc->caps.color;
> +
We already do this in amdgpu_dm_update_plane_color_mgmt and pass color_caps
into this function. We shouldn't need to do this here again.
Harry
> degamma_lut = __extract_blob_lut(dm_plane_state->degamma_lut,
>_size);
>
> @@ -928,7 +934,7 @@ __set_dm_plane_degamma(struct drm_plane_state
> *plane_state,
> dc_plane_state->in_transfer_func->type =
>
Re: [RESUBMIT][PATCH] x86/mm: Fix PAT bit missing from page protection modify mask
On 02.06.23 16:48, Juergen Gross wrote: On 02.06.23 16:43, Borislav Petkov wrote: On Thu, Jun 01, 2023 at 10:47:39AM +0200, Juergen Gross wrote: As described in the commit message, this only works on bare metal due to the PAT bit not being needed for WC mappings. Making this patch Xen specific would try to cure the symptoms without fixing the underlying problem: _PAGE_PAT should be regarded the same way as the bits for caching mode (_PAGE_CHG_MASK). So why isn't _PAGE_PAT part of _PAGE_CHG_MASK? This would result in problems for large pages: _PAGE_PSE is at the same position as _PAGE_PAT (large pages are using _PAGE_PAT_LARGE instead). Yes, x86 ABI is a mess. Oh, wait: I originally thought _PAGE_CHG_MASK would be used for large pages, too. There is _HPAGE_CHG_MASK for that purpose. So adding _PAGE_PAT to _PAGE_CHG_MASK and _PAGE_PAT_LARGE to _HPAGE_CHG_MASK should do the job. At least I hope so. Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [RESUBMIT][PATCH] x86/mm: Fix PAT bit missing from page protection modify mask
On 02.06.23 16:43, Borislav Petkov wrote: On Thu, Jun 01, 2023 at 10:47:39AM +0200, Juergen Gross wrote: As described in the commit message, this only works on bare metal due to the PAT bit not being needed for WC mappings. Making this patch Xen specific would try to cure the symptoms without fixing the underlying problem: _PAGE_PAT should be regarded the same way as the bits for caching mode (_PAGE_CHG_MASK). So why isn't _PAGE_PAT part of _PAGE_CHG_MASK? This would result in problems for large pages: _PAGE_PSE is at the same position as _PAGE_PAT (large pages are using _PAGE_PAT_LARGE instead). Yes, x86 ABI is a mess. Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [RESUBMIT][PATCH] x86/mm: Fix PAT bit missing from page protection modify mask
On Thu, Jun 01, 2023 at 10:47:39AM +0200, Juergen Gross wrote: > As described in the commit message, this only works on bare metal due to the > PAT bit not being needed for WC mappings. > > Making this patch Xen specific would try to cure the symptoms without fixing > the underlying problem: _PAGE_PAT should be regarded the same way as the bits > for caching mode (_PAGE_CHG_MASK). So why isn't _PAGE_PAT part of _PAGE_CHG_MASK? It says above it "Set of bits not changed in pte_modify." And I don't see pte_modify() changing that bit either. Right now this "fix" looks like, "let's OR these two masks so that we can take care of _PAGE_PAT too". But it doesn't make a whole lotta sense to me... -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH v2 3/3] drm/panel-simple: allow LVDS format override
Hi,
gentle ping here - Do you have any feedback for me on this patch?
Thanks and best regards
Johannes
On 5/23/23 10:19, Johannes Zink wrote:
Some panels support multiple LVDS data mapping formats, which can be
used e.g. run displays on jeida-18 format when only 3 LVDS lanes are
available.
Add parsing of an optional data-mapping devicetree property, which also
touches up the bits per color to match the bus format.
Signed-off-by: Johannes Zink
---
Changes:
v1 -> v2: - fix missing unwind goto found by test robot
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Link:
https://lore.kernel.org/r/202304160359.4lhmfolu-...@intel.com/
---
drivers/gpu/drm/panel/panel-simple.c | 39 +++-
1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 2a9c1a785a5c..0a35fdb49ccb 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
/**
* struct panel_desc - Describes a simple panel.
@@ -559,7 +560,7 @@ static int panel_simple_probe(struct device *dev, const
struct panel_desc *desc)
struct device_node *ddc;
int connector_type;
u32 bus_flags;
- int err;
+ int err, ret;
panel = devm_kzalloc(dev, sizeof(*panel), GFP_KERNEL);
if (!panel)
@@ -605,6 +606,42 @@ static int panel_simple_probe(struct device *dev, const
struct panel_desc *desc)
panel_simple_parse_panel_timing_node(dev, panel, );
}
+
+ /* optional data-mapping property for overriding bus format */
+ ret = drm_of_lvds_get_data_mapping(dev->of_node);
+ if (ret == -EINVAL) {
+ dev_warn(dev, "Ignore invalid data-mapping property");
+ } else if (ret != -ENODEV) {
+ int bpc;
+
+ switch (ret) {
+ default:
+ WARN_ON(1);
+ fallthrough;
+ case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG:
+ fallthrough;
+ case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA:
+ bpc = 8;
+ break;
+ case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
+ bpc = 6;
+ }
+
+ if (desc->bpc != bpc || desc->bus_format != ret) {
+ struct panel_desc *override_desc;
+
+ override_desc = devm_kmemdup(dev, desc, sizeof(*desc),
GFP_KERNEL);
+ if (!override_desc) {
+ err = -ENOMEM;
+ goto free_ddc;
+ }
+
+ override_desc->bus_format = ret;
+ override_desc->bpc = bpc;
+ panel->desc = override_desc;
+ }
+ }
+
connector_type = desc->connector_type;
/* Catch common mistakes for panels. */
switch (connector_type) {
--
Pengutronix e.K.| Johannes Zink |
Steuerwalder Str. 21| https://www.pengutronix.de/|
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686| Fax: +49-5121-206917-|
Re: [PATCH] drm/amd/display: fix compilation error due to shifting negative value
On 6/2/23 06:12, GONG, Ruiqi wrote: Currently compiling linux-next with allmodconfig triggers the following error: ./drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h: In function ‘dc_fixpt_truncate’: ./drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:528:22: error: left shift of negative value [-Werror=shift-negative-value] 528 | arg.value &= (~0LL) << (FIXED31_32_BITS_PER_FRACTIONAL_PART - frac_bits); | ^~ Use `unsigned long long` instead. Signed-off-by: GONG, Ruiqi Applied, thanks! --- drivers/gpu/drm/amd/display/include/fixed31_32.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/include/fixed31_32.h b/drivers/gpu/drm/amd/display/include/fixed31_32.h index ece97ae0e826..d4cf7ead1d87 100644 --- a/drivers/gpu/drm/amd/display/include/fixed31_32.h +++ b/drivers/gpu/drm/amd/display/include/fixed31_32.h @@ -525,7 +525,7 @@ static inline struct fixed31_32 dc_fixpt_truncate(struct fixed31_32 arg, unsigne if (negative) arg.value = -arg.value; - arg.value &= (~0LL) << (FIXED31_32_BITS_PER_FRACTIONAL_PART - frac_bits); + arg.value &= (~0ULL) << (FIXED31_32_BITS_PER_FRACTIONAL_PART - frac_bits); if (negative) arg.value = -arg.value; return arg; -- Hamza
Re: [PATCH] drm/amd/display: clean up some inconsistent indenting
On 6/2/23 02:17, Jiapeng Chong wrote: No functional modification involved. drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dpms.c:2377 link_set_dpms_on() warn: inconsistent indenting. Reported-by: Abaci Robot Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5376 Signed-off-by: Jiapeng Chong Applied, thanks! --- drivers/gpu/drm/amd/display/dc/link/link_dpms.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/link/link_dpms.c b/drivers/gpu/drm/amd/display/dc/link/link_dpms.c index 2963267fe74a..f7f1a1586f3b 100644 --- a/drivers/gpu/drm/amd/display/dc/link/link_dpms.c +++ b/drivers/gpu/drm/amd/display/dc/link/link_dpms.c @@ -2374,8 +2374,8 @@ void link_set_dpms_on( } } - if (dc_is_virtual_signal(pipe_ctx->stream->signal)) - return; + if (dc_is_virtual_signal(pipe_ctx->stream->signal)) + return; link_enc = link_enc_cfg_get_link_enc(link); ASSERT(link_enc); -- Hamza
[PATCH v6 01/11] i2c: Enhance i2c_new_ancillary_device API
Renesas PMIC RAA215300 exposes two separate i2c devices, one for the main
device and another for rtc device.
Enhance i2c_new_ancillary_device() to instantiate an I2C client device
apart from the already supported I2C dummy client device.
Added helper function __i2c_new_dummy_device to share the code
between i2c_new_dummy_device and i2c_new_ancillary_device().
Also added helper function __i2c_new_client_device() to pass parent dev
parameter, so that the ancillary device can assign its parent during
creation.
Suggested-by: Geert Uytterhoeven
Signed-off-by: Biju Das
Reviewed-by: Hans Verkuil
Reviewed-by: Geert Uytterhoeven
---
v5->v6:
* Added Rb tag from Hans Verkuil and Geert.
* Updated commit description and comment related to i2c_new_ancillary_device()
* Fixed the issue related to assigning wrong parent device by adding check
for aux_device_name.
* Retained Rb tags as changes are trivial.
v4->v5:
* Replaced parameter dev->parent in __i2c_new_client_device() and
__i2c_new_dummy_device().
* Improved error message in __i2c_new_dummy_device() by printing device name.
* Updated comment for ancillary's device parent
* Dropped aux_device_name check in i2c_new_ancillary_device().
v3->v4:
* Dropped Rb tag from Geert as there are new changes.
* Introduced __i2c_new_dummy_device() to share the code between
i2c_new_dummy_device and i2c_new_ancillary_device().
* Introduced __i2c_new_client_device() to pass parent dev
parameter, so that the ancillary device can assign its parent during
creation.
v3:
* New patch
Ref:
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20230505172530.357455-5-biju.das...@bp.renesas.com/
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 6 +-
drivers/i2c/i2c-core-base.c | 91 +---
drivers/media/i2c/adv748x/adv748x-core.c | 2 +-
drivers/media/i2c/adv7604.c | 3 +-
include/linux/i2c.h | 3 +-
5 files changed, 68 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 2254457ab5d0..3f9164afb31f 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -1072,7 +1072,7 @@ static int adv7511_init_cec_regmap(struct adv7511 *adv)
int ret;
adv->i2c_cec = i2c_new_ancillary_device(adv->i2c_main, "cec",
- ADV7511_CEC_I2C_ADDR_DEFAULT);
+ ADV7511_CEC_I2C_ADDR_DEFAULT, NULL);
if (IS_ERR(adv->i2c_cec))
return PTR_ERR(adv->i2c_cec);
@@ -1261,7 +1261,7 @@ static int adv7511_probe(struct i2c_client *i2c)
adv7511_packet_disable(adv7511, 0x);
adv7511->i2c_edid = i2c_new_ancillary_device(i2c, "edid",
- ADV7511_EDID_I2C_ADDR_DEFAULT);
+ ADV7511_EDID_I2C_ADDR_DEFAULT, NULL);
if (IS_ERR(adv7511->i2c_edid)) {
ret = PTR_ERR(adv7511->i2c_edid);
goto uninit_regulators;
@@ -1271,7 +1271,7 @@ static int adv7511_probe(struct i2c_client *i2c)
adv7511->i2c_edid->addr << 1);
adv7511->i2c_packet = i2c_new_ancillary_device(i2c, "packet",
- ADV7511_PACKET_I2C_ADDR_DEFAULT);
+ ADV7511_PACKET_I2C_ADDR_DEFAULT, NULL);
if (IS_ERR(adv7511->i2c_packet)) {
ret = PTR_ERR(adv7511->i2c_packet);
goto err_i2c_unregister_edid;
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index ae3af738b03f..5d55e5f93275 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -893,24 +893,10 @@ int i2c_dev_irq_from_resources(const struct resource
*resources,
return 0;
}
-/**
- * i2c_new_client_device - instantiate an i2c device
- * @adap: the adapter managing the device
- * @info: describes one I2C device; bus_num is ignored
- * Context: can sleep
- *
- * Create an i2c device. Binding is handled through driver model
- * probe()/remove() methods. A driver may be bound to this device when we
- * return from this function, or any later moment (e.g. maybe hotplugging will
- * load the driver module). This call is not appropriate for use by mainboard
- * initialization logic, which usually runs during an arch_initcall() long
- * before any i2c_adapter could exist.
- *
- * This returns the new i2c client, which may be saved for later use with
- * i2c_unregister_device(); or an ERR_PTR to describe the error.
- */
-struct i2c_client *
-i2c_new_client_device(struct i2c_adapter *adap, struct i2c_board_info const
*info)
+static struct i2c_client *
+__i2c_new_client_device(struct i2c_adapter *adap,
+ struct i2c_board_info const *info,
+ struct device *parent)
{
struct i2c_client
RE: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L Display Unit support
Hi Laurent,
> -Original Message-
> From: Laurent Pinchart
> Sent: Friday, June 2, 2023 12:15 PM
> To: Biju Das
> Cc: David Airlie ; Daniel Vetter ;
> Philipp Zabel ; Geert Uytterhoeven
> ; Kieran Bingham
> ; dri-
> de...@lists.freedesktop.org; linux-renesas-...@vger.kernel.org; Fabrizio
> Castro ; Prabhakar Mahadev Lad
> ; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L Display
> Unit support
>
> Hi Biju,
>
> On Thu, Jun 01, 2023 at 12:12:59PM +, Biju Das wrote:
> > > Subject: Re: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L
> > > Display Unit support
> > >
> > > On Mon, May 29, 2023 at 02:22:06PM +, Biju Das wrote:
> > > > > Subject: Re: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L
> > > > > Display Unit support On Thu, May 25, 2023 at 02:30:10PM +,
> > > > > Biju Das wrote:
> > > > > > Hi DRM maintainers,
> > > > > >
> > > > > > Gentle ping.
> > > > >
> > > > > Sorry, I was on holidays the last two weeks.
> > > > >
> > > > > > Are we happy with moving all Renesas drm drivers to Renesas
> > > > > > specific directory or preference is for separate one??
> > > > >
> > > > > This works for me.
> > > > >
> > > > > > If it is later, I can send RZ/G2L drm driver separate.
> > > > > >
> > > > > > Otherwise, I need to rebase and resend.
> > > > >
> > > > > Your series applies cleanly on top of the latest drm-next
> > > > > branch. Is there a specific need to rebase and resend ?
> > > >
> > > > Nope. After my patch series there were some patches from Geert for
> > > > drm/shmobile merged to drm-misc-next by Thomas.
> > > >
> > > > Maybe git managed this automatically??
> > >
> > > Probably, git is nice :-)
> > >
> > > > > I haven't had time to review patch 4/5 (the driver) yet. All the
> > > > > rest looks good to me. Should I already include 1/5 in my next
> > > > > pull
> > > request ?
> > > >
> > > > Yes, please.
> > >
> > > OK, I will do so. I've reviewed 4/5 in the meantime, but changes are
> > > needed, so I won't wait for v10 before applying 1/5.
> >
> > I have incorporated review comments for v9. I need to rebase my
> changes.
> >
> > Is the pull request being done to drm-misc-next?
>
> I've just sent the pull request for drm-next, and have CC'ed you.
Thank you.
Cheers,
Biju
Re: mailmap: Add missing email address
Hi, On 2023/6/2 19:54, Maxime Ripard wrote: Hi, On Thu, Jun 01, 2023 at 12:11:59AM +0800, Sui Jingfeng wrote: Okey, that sound fine. Is it a Reviewed-by? Yes, I can't see problems from this. Reviewed-by: Sui Jingfeng Maxime -- Jingfeng
Re: [PATCH] drm/meson: venc: include linux/bitfield.h
Hi, On Fri, 02 Jun 2023 14:45:24 +0200, Arnd Bergmann wrote: > Without this header, the use of FIELD_PREP() can cause a build failure: > > drivers/gpu/drm/meson/meson_venc.c: In function 'meson_encl_set_gamma_table': > drivers/gpu/drm/meson/meson_venc.c:1595:24: error: implicit declaration of > function 'FIELD_PREP' [-Werror=implicit-function-declaration] > > Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next) [1/1] drm/meson: venc: include linux/bitfield.h https://cgit.freedesktop.org/drm/drm-misc/commit/?id=664dba662cb313da9cbb1c944c472638a65c552e -- Neil
Re: [PATCH -next] drm/meson: Remove unneeded semicolon
Hi, On Fri, 02 Jun 2023 17:14:16 +0800, Yang Li wrote: > ./drivers/gpu/drm/meson/meson_dw_mipi_dsi.c:117:2-3: Unneeded semicolon > ./drivers/gpu/drm/meson/meson_dw_mipi_dsi.c:231:2-3: Unneeded semicolon > > Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next) [1/1] drm/meson: Remove unneeded semicolon https://cgit.freedesktop.org/drm/drm-misc/commit/?id=e96f099c8544a542f7cd37d2e51ba52786adbbc7 -- Neil
Re: [PATCH] drm/meson: venc: include linux/bitfield.h
On 02/06/2023 14:45, Arnd Bergmann wrote:
From: Arnd Bergmann
Without this header, the use of FIELD_PREP() can cause a build failure:
drivers/gpu/drm/meson/meson_venc.c: In function 'meson_encl_set_gamma_table':
drivers/gpu/drm/meson/meson_venc.c:1595:24: error: implicit declaration of
function 'FIELD_PREP' [-Werror=implicit-function-declaration]
Fixes: 51fc01a03442c ("drm/meson: venc: add ENCL encoder setup for MIPI-DSI
output")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/meson/meson_venc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/meson/meson_venc.c
b/drivers/gpu/drm/meson/meson_venc.c
index 2bdc2855e249b..3bf0d6e4fc30a 100644
--- a/drivers/gpu/drm/meson/meson_venc.c
+++ b/drivers/gpu/drm/meson/meson_venc.c
@@ -5,6 +5,7 @@
* Copyright (C) 2015 Amlogic, Inc. All rights reserved.
*/
+#include
#include
#include
Acked-by: Neil Armstrong
Re: [PATCH] drm/amdgpu: clean up some inconsistent indenting
Reviewed-by: Alex Deucher
On Fri, Jun 2, 2023 at 2:17 AM Jiapeng Chong
wrote:
>
> No functional modification involved.
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:614 amdgpu_gfx_enable_kcq() warn:
> inconsistent indenting.
>
> Reported-by: Abaci Robot
> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5377
> Signed-off-by: Jiapeng Chong
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> index a33d4bc34cee..37a8f43cf281 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> @@ -611,8 +611,7 @@ int amdgpu_gfx_enable_kcq(struct amdgpu_device *adev, int
> xcc_id)
> kiq->pmf->kiq_set_resources(kiq_ring, queue_mask);
> for (i = 0; i < adev->gfx.num_compute_rings; i++) {
> j = i + xcc_id * adev->gfx.num_compute_rings;
> - kiq->pmf->kiq_map_queues(kiq_ring,
> ->gfx.compute_ring[j]);
> + kiq->pmf->kiq_map_queues(kiq_ring,
> >gfx.compute_ring[j]);
> }
>
> r = amdgpu_ring_test_helper(kiq_ring);
> --
> 2.20.1.7.g153144c
>
Re: [PATCH 1/3] drm/todo: Add atomic modesetting references
On Fri, Jun 02, 2023 at 11:11:34AM +0200, Geert Uytterhoeven wrote: > -There is a conversion guide for atomic and all you need is a GPU for a > +There is a conversion guide for atomic[1] and all you need is a GPU for a > non-converted driver (again virtual HW drivers for KVM are still all > -suitable). > +suitable). The "Atomic mode setting design overview" series [2][3] at > +LWN.net can also be helpful. > > As part of this drivers also need to convert to universal plane (which means > exposing primary & cursor as proper plane objects). But that's much easier to > do by directly using the new atomic helper driver callbacks. > > + - [1] > https://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html > + - [2] https://lwn.net/Articles/653071/ > + - [3] https://lwn.net/Articles/653466/ > + Looks like footnotes better serve these links above: >8 diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 51eb67f5268c5e..6ea92f48a2e21c 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -49,18 +49,18 @@ converted over. Modern compositors like Wayland or Surfaceflinger on Android really want an atomic modeset interface, so this is all about the bright future. -There is a conversion guide for atomic[1] and all you need is a GPU for a +There is a conversion guide for atomic [1]_ and all you need is a GPU for a non-converted driver (again virtual HW drivers for KVM are still all -suitable). The "Atomic mode setting design overview" series [2][3] at +suitable). The "Atomic mode setting design overview" series [2]_ [3]_ at LWN.net can also be helpful. As part of this drivers also need to convert to universal plane (which means exposing primary & cursor as proper plane objects). But that's much easier to do by directly using the new atomic helper driver callbacks. - - [1] https://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html - - [2] https://lwn.net/Articles/653071/ - - [3] https://lwn.net/Articles/653466/ + .. [1] https://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html + .. [2] https://lwn.net/Articles/653071/ + .. [3] https://lwn.net/Articles/653466/ Contact: Daniel Vetter, respective driver maintainers Thanks. -- An old man doll... just what I always wanted! - Clara signature.asc Description: PGP signature
Re: [PATCH] drm/amd/display: clean up some inconsistent indenting
Acked-by: Alex Deucher On Fri, Jun 2, 2023 at 2:18 AM Jiapeng Chong wrote: > > No functional modification involved. > > drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dpms.c:2377 > link_set_dpms_on() warn: inconsistent indenting. > > Reported-by: Abaci Robot > Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5376 > Signed-off-by: Jiapeng Chong > --- > drivers/gpu/drm/amd/display/dc/link/link_dpms.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/link/link_dpms.c > b/drivers/gpu/drm/amd/display/dc/link/link_dpms.c > index 2963267fe74a..f7f1a1586f3b 100644 > --- a/drivers/gpu/drm/amd/display/dc/link/link_dpms.c > +++ b/drivers/gpu/drm/amd/display/dc/link/link_dpms.c > @@ -2374,8 +2374,8 @@ void link_set_dpms_on( > } > } > > - if (dc_is_virtual_signal(pipe_ctx->stream->signal)) > - return; > + if (dc_is_virtual_signal(pipe_ctx->stream->signal)) > + return; > > link_enc = link_enc_cfg_get_link_enc(link); > ASSERT(link_enc); > -- > 2.20.1.7.g153144c >
Re: [Intel-gfx] [PATCH] drm/i915/pxp: Optimize GET_PARAM:PXP_STATUS
On Thu, 01 Jun 2023, Alan Previn wrote:
> After recent discussions with Mesa folks, it was requested
> that we optimize i915's GET_PARAM for the PXP_STATUS without
> changing the UAPI spec.
>
> This patch adds this additional optimizations:
Nitpick, please avoid "This patch". It's redundant, and after the patch
gets applied it becomes a commit, not a patch.
Instead, use the imperative mood, e.g. "Add these additional
optimizations".
See
https://docs.kernel.org/process/submitting-patches.html#describe-your-changes
>- If any PXP initializatoin flow failed, then ensure that
> we catch it so that we can change the returned PXP_STATUS
> from "2" (i.e. 'PXP is supported but not yet ready')
> to "-ENODEV". This typically should not happen and if it
> does, we have a platform configuration.
>- If a PXP arbitration session creation event failed
> due to incorrect firmware version or blocking SOC fusing
> or blocking BIOS configuration (platform reasons that won't
> change if we retry), then reflect that blockage by also
> returning -ENODEV in the GET_PARAM-PXP_STATUS.
>- GET_PARAM:PXP_STATUS should not wait at all if PXP is
> supported but non-i915 dependencies (component-driver /
> firmware) we are still pending to complete the init flows.
> In this case, just return "2" immediately (i.e. 'PXP is
> supported but not yet ready').
>
> Signed-off-by: Alan Previn
> ---
> drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 11 +-
> drivers/gpu/drm/i915/i915_getparam.c | 2 +-
> drivers/gpu/drm/i915/pxp/intel_pxp.c | 25 ++
> drivers/gpu/drm/i915/pxp/intel_pxp.h | 2 +-
> drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 7 +++---
> drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 7 +++---
> drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 9
> 7 files changed, 50 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
> index fb0984f875f9..4dd744c96a37 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
> @@ -42,8 +42,17 @@ static void gsc_work(struct work_struct *work)
> }
>
> ret = intel_gsc_proxy_request_handler(gsc);
> - if (ret)
> + if (ret) {
> + if (actions & GSC_ACTION_FW_LOAD) {
> + /*
> + * a proxy request failure that came together
> with the
> + * firmware load action means the last part of
> init has
> + * failed so GSC fw won't be usable after this
> + */
> + intel_uc_fw_change_status(>fw,
> INTEL_UC_FIRMWARE_LOAD_FAIL);
> + }
> goto out_put;
> + }
>
> /* mark the GSC FW init as done the first time we run this */
> if (actions & GSC_ACTION_FW_LOAD) {
> diff --git a/drivers/gpu/drm/i915/i915_getparam.c
> b/drivers/gpu/drm/i915/i915_getparam.c
> index 6f11d7eaa91a..1b2ee98a158a 100644
> --- a/drivers/gpu/drm/i915/i915_getparam.c
> +++ b/drivers/gpu/drm/i915/i915_getparam.c
> @@ -105,7 +105,7 @@ int i915_getparam_ioctl(struct drm_device *dev, void
> *data,
> return value;
> break;
> case I915_PARAM_PXP_STATUS:
> - value = intel_pxp_get_readiness_status(i915->pxp);
> + value = intel_pxp_get_readiness_status(i915->pxp, 1);
> if (value < 0)
> return value;
> break;
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index bb2e15329f34..1478bb9b4e26 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -359,21 +359,38 @@ void intel_pxp_end(struct intel_pxp *pxp)
> intel_runtime_pm_put(>runtime_pm, wakeref);
> }
>
> +static bool pxp_required_fw_failed(struct intel_pxp *pxp)
> +{
> + if (__intel_uc_fw_status(>ctrl_gt->uc.huc.fw) ==
> INTEL_UC_FIRMWARE_LOAD_FAIL)
> + return true;
> + if (HAS_ENGINE(pxp->ctrl_gt, GSC0) &&
> + __intel_uc_fw_status(>ctrl_gt->uc.gsc.fw) ==
> INTEL_UC_FIRMWARE_LOAD_FAIL)
> + return true;
> +
> + return false;
> +}
> +
> /*
> * this helper is used by both intel_pxp_start and by
> * the GET_PARAM IOCTL that user space calls. Thus, the
> * return values here should match the UAPI spec.
> */
> -int intel_pxp_get_readiness_status(struct intel_pxp *pxp)
> +int intel_pxp_get_readiness_status(struct intel_pxp *pxp, int timeout)
It would help the reader if you named the parameter timeout_ms. Assuming
the unit is ms.
> {
> if (!intel_pxp_is_enabled(pxp))
> return -ENODEV;
>
> + if (pxp_required_fw_failed(pxp))
> +
[PATCH] drm/meson: venc: include linux/bitfield.h
From: Arnd Bergmann
Without this header, the use of FIELD_PREP() can cause a build failure:
drivers/gpu/drm/meson/meson_venc.c: In function 'meson_encl_set_gamma_table':
drivers/gpu/drm/meson/meson_venc.c:1595:24: error: implicit declaration of
function 'FIELD_PREP' [-Werror=implicit-function-declaration]
Fixes: 51fc01a03442c ("drm/meson: venc: add ENCL encoder setup for MIPI-DSI
output")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/meson/meson_venc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/meson/meson_venc.c
b/drivers/gpu/drm/meson/meson_venc.c
index 2bdc2855e249b..3bf0d6e4fc30a 100644
--- a/drivers/gpu/drm/meson/meson_venc.c
+++ b/drivers/gpu/drm/meson/meson_venc.c
@@ -5,6 +5,7 @@
* Copyright (C) 2015 Amlogic, Inc. All rights reserved.
*/
+#include
#include
#include
--
2.39.2
Re: [git pull] drm fixes for 6.4-rc5
The pull request you sent on Fri, 2 Jun 2023 14:12:59 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-06-02 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e99a74673a19631d4a23c7e1fe2f21c55471a5d1 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH] mailmap: Add missing email address
Am 31.05.23 um 15:37 schrieb Maxime Ripard: I've been using that email address for contributions for a while but it seems I never added it to mailmap. Signed-off-by: Maxime Ripard Acked-by: Thomas Zimmermann --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index a289b25ea2c7..c14eefed259c 100644 --- a/.mailmap +++ b/.mailmap @@ -331,6 +331,7 @@ Mauro Carvalho Chehab Mauro Carvalho Chehab Maxim Mikityanskiy Maxim Mikityanskiy +Maxime Ripard Maxime Ripard Maxime Ripard Mayuresh Janorkar -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg) OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH] drm/todo: Fix corrupted duplicate in defio section
Hi
Am 02.06.23 um 13:30 schrieb Geert Uytterhoeven:
Part of the paragraph was accidentally duplicated.
This TODO item is mostly obsolete. It should be removed.
Best regards
Thomas
Fixes: be5cadc7e7b4cee8 ("drm/todo: Better defio support in the generic fbdev
emulation")
Signed-off-by: Geert Uytterhoeven
---
Documentation/gpu/todo.rst | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 66736db00e6d182d..c25e3cdbe964967a 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -312,8 +312,7 @@ everything after it has done the write-protect/mkwrite
trickery:
- Set the mkwrite and fsync callbacks with similar implementions to the core
fbdev defio stuff. These should all work on plain ptes, they don't actually
- require a struct page. uff. These should all work on plain ptes, they don't
- actually require a struct page.
+ require a struct page.
- Track the dirty pages in a separate structure (bitfield with one bit per page
should work) to avoid clobbering struct page.
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
OpenPGP_signature
Description: OpenPGP digital signature
Re: mailmap: Add missing email address
Hi, On Thu, Jun 01, 2023 at 12:11:59AM +0800, Sui Jingfeng wrote: > Okey, that sound fine. Is it a Reviewed-by? Maxime signature.asc Description: PGP signature
Re: [Intel-gfx] [PATCH v2 00/13] drm/display & drm/i915: more struct drm_edid conversions
On Wed, 31 May 2023, Jani Nikula wrote: > On Tue, 30 May 2023, Jani Nikula wrote: >> Rebase of https://patchwork.freedesktop.org/series/116813/ >> >> Move struct drm_edid conversions forward. >> >> There are still some drm_edid_raw() stragglers, but this nudges things >> forward nicely. >> >> Jani Nikula (13): >> drm/edid: parse display info has_audio similar to is_hdmi >> drm/display/dp_mst: drop has_audio from struct drm_dp_mst_port >> drm/edid: add drm_edid_read_switcheroo() >> drm/edid: make drm_edid_duplicate() safe to call with NULL parameter >> drm/display/dp_mst: convert to struct drm_edid > > Maarten, Maxime, Thomas, can I get an ack for merging the above commits > via drm-intel, please? Pushed all to drm-intel-next with Thomas' IRC ack. Thanks, Jani. > > BR, > Jani. -- Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH 2/3] drm: Remove references to removed transitional helpers
Hi Laurent,
On Fri, Jun 2, 2023 at 1:36 PM Laurent Pinchart
wrote:
> On Fri, Jun 02, 2023 at 01:17:58PM +0200, Geert Uytterhoeven wrote:
> > On Fri, Jun 2, 2023 at 1:05 PM Laurent Pinchart wrote:
> > > On Fri, Jun 02, 2023 at 11:11:35AM +0200, Geert Uytterhoeven wrote:
> > > > The transitional helpers were removed a long time ago, but some
> > > > references stuck. Remove them.
> > > >
> > > > Fixes: 21ebe615c16994f3 ("drm: Remove transitional helpers")
> > > > Signed-off-by: Geert Uytterhoeven
> >
> > > > --- a/drivers/gpu/drm/drm_plane_helper.c
> > > > +++ b/drivers/gpu/drm/drm_plane_helper.c
> > > > @@ -51,14 +51,6 @@
> > > > * planes, and newly merged drivers must not rely upon these
> > > > transitional
> > > > * helpers.
> > > > *
> > >
> > > The first paragraph starts with "This helper library has two parts.". As
> > > you're dropping the mention of the second part, I think you should
> > > rework the first paragraph too.
> >
> > That was my initial thought, too.
> > However, the code still has a second part, not related to the topic of
> > the first part (primary plane support).
>
> How about mentioning that in the comment then ?
Any suggestion about the wording?
The drm novice in me would write "The second part is not about
primary plane support" ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3] amdgpu: validate offset_in_bo of drm_amdgpu_gem_va
Am 02.06.23 um 00:44 schrieb Chia-I Wu:
This is motivated by OOB access in amdgpu_vm_update_range when
offset_in_bo+map_size overflows.
v2: keep the validations in amdgpu_vm_bo_map
v3: add the validations to amdgpu_vm_bo_map/amdgpu_vm_bo_replace_map
rather than to amdgpu_gem_va_ioctl
Fixes: 9f7eb5367d00 ("drm/amdgpu: actually use the VM map parameters")
Signed-off-by: Chia-I Wu
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 22f9a65ca0fc7..76d57bc7ac620 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1434,14 +1434,14 @@ int amdgpu_vm_bo_map(struct amdgpu_device *adev,
uint64_t eaddr;
/* validate the parameters */
- if (saddr & ~PAGE_MASK || offset & ~PAGE_MASK ||
- size == 0 || size & ~PAGE_MASK)
+ if (saddr & ~PAGE_MASK || offset & ~PAGE_MASK || size & ~PAGE_MASK)
+ return -EINVAL;
+ if (saddr + size <= saddr || offset + size <= offset)
return -EINVAL;
/* make sure object fit at this offset */
eaddr = saddr + size - 1;
- if (saddr >= eaddr ||
- (bo && offset + size > amdgpu_bo_size(bo)) ||
+ if ((bo && offset + size > amdgpu_bo_size(bo)) ||
(eaddr >= adev->vm_manager.max_pfn << AMDGPU_GPU_PAGE_SHIFT))
return -EINVAL;
@@ -1500,14 +1500,14 @@ int amdgpu_vm_bo_replace_map(struct amdgpu_device *adev,
int r;
/* validate the parameters */
- if (saddr & ~PAGE_MASK || offset & ~PAGE_MASK ||
- size == 0 || size & ~PAGE_MASK)
+ if (saddr & ~PAGE_MASK || offset & ~PAGE_MASK || size & ~PAGE_MASK)
+ return -EINVAL;
+ if (saddr + size <= saddr || offset + size <= offset)
return -EINVAL;
/* make sure object fit at this offset */
eaddr = saddr + size - 1;
- if (saddr >= eaddr ||
- (bo && offset + size > amdgpu_bo_size(bo)) ||
+ if ((bo && offset + size > amdgpu_bo_size(bo)) ||
(eaddr >= adev->vm_manager.max_pfn << AMDGPU_GPU_PAGE_SHIFT))
return -EINVAL;
Re: [PATCH 2/3] drm: Remove references to removed transitional helpers
Hi Geert,
On Fri, Jun 02, 2023 at 01:17:58PM +0200, Geert Uytterhoeven wrote:
> On Fri, Jun 2, 2023 at 1:05 PM Laurent Pinchart wrote:
> > On Fri, Jun 02, 2023 at 11:11:35AM +0200, Geert Uytterhoeven wrote:
> > > The transitional helpers were removed a long time ago, but some
> > > references stuck. Remove them.
> > >
> > > Fixes: 21ebe615c16994f3 ("drm: Remove transitional helpers")
> > > Signed-off-by: Geert Uytterhoeven
>
> > > --- a/drivers/gpu/drm/drm_plane_helper.c
> > > +++ b/drivers/gpu/drm/drm_plane_helper.c
> > > @@ -51,14 +51,6 @@
> > > * planes, and newly merged drivers must not rely upon these transitional
> > > * helpers.
> > > *
> >
> > The first paragraph starts with "This helper library has two parts.". As
> > you're dropping the mention of the second part, I think you should
> > rework the first paragraph too.
>
> That was my initial thought, too.
> However, the code still has a second part, not related to the topic of
> the first part (primary plane support).
How about mentioning that in the comment then ?
> > > - * The second part also implements transitional helpers which allow
> > > drivers to
> > > - * gradually switch to the atomic helper infrastructure for plane
> > > updates. Once
> > > - * that switch is complete drivers shouldn't use these any longer,
> > > instead using
> > > - * the proper legacy implementations for update and disable plane hooks
> > > provided
> > > - * by the atomic helpers.
> > > - *
> > > - * Again drivers are strongly urged to switch to the new interfaces.
> > > - *
> > > * The plane helpers share the function table structures with other
> > > helpers,
> > > * specifically also the atomic helpers. See
> > > drm_plane_helper_funcs for
> > > * the details.
--
Regards,
Laurent Pinchart
Re: [PATCH v9 RESEND 4/5] drm: Add RZ/G2L DU Support
Hi Biju,
On Thu, Jun 01, 2023 at 12:08:44PM +, Biju Das wrote:
> > Subject: Re: [PATCH v9 RESEND 4/5] drm: Add RZ/G2L DU Support
> >
> > Hi Biju,
> >
> > Thank you for the patch.
> >
> > This is a partial review, because the driver is big, and because some
> > changes in v10 will (hopefully) simplify the code and make review
> > easier.
>
> I agree v10 will simplify the code as I have do clean-ups based on your
> review commnet.
>
> > On Tue, May 02, 2023 at 11:09:11AM +0100, Biju Das wrote:
> > > The LCD controller is composed of Frame Compression Processor (FCPVD),
> > > Video Signal Processor (VSPD), and Display Unit (DU).
> > >
> > > It has DPI/DSI interfaces and supports a maximum resolution of 1080p
> > > along with 2 RPFs to support the blending of two picture layers and
> > > raster operations (ROPs).
> > >
> > > The DU module is connected to VSPD. Add RZ/G2L DU support for RZ/G2L
> > > alike SoCs.
> > >
> > > Signed-off-by: Biju Das
> > > ---
> > > Ref:
> > >
> > > v8->v9:
> > > * Dropped reset_control_assert() from error patch for
> > > rzg2l_du_crtc_get() as
> > >suggested by Philipp Zabel.
> > > v7->v8:
> > > * Dropped RCar du lib and created RZ/G2L DU DRM driver by creating rz_du
> > > folder.
> > > * Updated KConfig and Makefile.
> > > v6->v7:
> > > * Split DU lib and RZ/G2L du driver as separate patch series as
> > >DU support added to more platforms based on RZ/G2L alike SoCs.
> > > * Rebased to latest drm-tip.
> > > * Added patch #2 for binding support for RZ/V2L DU
> > > * Added patch #4 for driver support for RZ/V2L DU
> > > * Added patch #5 for SoC DTSI support for RZ/G2L DU
> > > * Added patch #6 for SoC DTSI support for RZ/V2L DU
> > > * Added patch #7 for Enabling DU on SMARC EVK based on RZ/{G2L,V2L} SoCs.
> > > * Added patch #8 for Enabling DU on SMARC EVK based on RZ/G2LC SoC.
> > > ---
> > > drivers/gpu/drm/renesas/Kconfig | 1 +
> > > drivers/gpu/drm/renesas/Makefile | 1 +
> > > drivers/gpu/drm/renesas/rz-du/Kconfig | 20 +
> > > drivers/gpu/drm/renesas/rz-du/Makefile| 8 +
> > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 714
> > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.h | 99 +++
> > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 188 +
> > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h | 89 ++
> > > .../gpu/drm/renesas/rz-du/rzg2l_du_encoder.c | 112 +++
> > > .../gpu/drm/renesas/rz-du/rzg2l_du_encoder.h | 28 +
> > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c | 770 ++
> > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.h | 43 +
> > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_regs.h | 67 ++
> > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c | 430 ++
> > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.h | 94 +++
> > > 15 files changed, 2664 insertions(+)
> > > create mode 100644 drivers/gpu/drm/renesas/rz-du/Kconfig
> > > create mode 100644 drivers/gpu/drm/renesas/rz-du/Makefile
> > > create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> > > create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.h
> > > create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
> > > create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
> > > create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.c
> > > create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.h
> > > create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
> > > create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.h
> > > create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_regs.h
> > > create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c
> > > create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.h
[snip]
> > > diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> > > b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> > > new file mode 100644
> > > index ..d61d433d72e6
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> > > @@ -0,0 +1,714 @@
[snip]
> > > +/*
> > > -
> > > + * CRTC Functions
> > > + */
> > > +
> > > +int __rzg2l_du_crtc_plane_atomic_check(struct drm_plane *plane,
> > > +struct drm_plane_state *state,
> > > +const struct rzg2l_du_format_info
> > > **format)
> >
> > This function is only called from rzg2l_du_vsp_plane_atomic_check(), I
> > would inline it there.
>
> Agreed.
>
> > > +{
> > > + struct drm_device *dev = plane->dev;
> > > + struct drm_crtc_state *crtc_state;
> > > + int ret;
> > > +
> > > + if (!state->crtc) {
> > > + /*
> > > + * The visible field is not reset by the DRM core but only
> > > + * updated by drm_plane_helper_check_state(), set it manually.
> > > + */
> > > + state->visible = false;
> > >
[PATCH] drm/todo: Fix corrupted duplicate in defio section
Part of the paragraph was accidentally duplicated.
Fixes: be5cadc7e7b4cee8 ("drm/todo: Better defio support in the generic fbdev
emulation")
Signed-off-by: Geert Uytterhoeven
---
Documentation/gpu/todo.rst | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 66736db00e6d182d..c25e3cdbe964967a 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -312,8 +312,7 @@ everything after it has done the write-protect/mkwrite
trickery:
- Set the mkwrite and fsync callbacks with similar implementions to the core
fbdev defio stuff. These should all work on plain ptes, they don't actually
- require a struct page. uff. These should all work on plain ptes, they don't
- actually require a struct page.
+ require a struct page.
- Track the dirty pages in a separate structure (bitfield with one bit per page
should work) to avoid clobbering struct page.
--
2.34.1
Re: [PATCH 1/3] drm/todo: Add atomic modesetting references
Hi Javier,
On Fri, Jun 2, 2023 at 12:39 PM Javier Martinez Canillas
wrote:
> Geert Uytterhoeven writes:
> > The section about converting existing KMS drivers to atomic modesetting
> > mentions the existence of a conversion guide, but does not reference it.
> > While the guide is old and rusty, it still contains useful information,
> > so add a link to it. Also link to the LWN.net articles that give an
> > overview about the atomic mode setting design.
> > --- a/Documentation/gpu/todo.rst
> > +++ b/Documentation/gpu/todo.rst
> > @@ -49,14 +49,19 @@ converted over. Modern compositors like Wayland or
> > Surfaceflinger on Android
> > really want an atomic modeset interface, so this is all about the bright
> > future.
> >
> > -There is a conversion guide for atomic and all you need is a GPU for a
> > +There is a conversion guide for atomic[1] and all you need is a GPU for a
> > non-converted driver (again virtual HW drivers for KVM are still all
> > -suitable).
>
> Are any of the virtual drivers not yet ported to atomic? This sentence
> seems to be outdated and maybe you could remove it on a following patch?
Good question. I'm not sure which driver(s) this refers to.
drivers/gpu/drm/vkms/ was introduced much later, and always had
DRIVER_ATOMIC. Perhaps just the boochs driver, which was converted?
> Reviewed-by: Javier Martinez Canillas
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 2/3] drm: Remove references to removed transitional helpers
Hi Laurent,
On Fri, Jun 2, 2023 at 1:05 PM Laurent Pinchart
wrote:
> On Fri, Jun 02, 2023 at 11:11:35AM +0200, Geert Uytterhoeven wrote:
> > The transitional helpers were removed a long time ago, but some
> > references stuck. Remove them.
> >
> > Fixes: 21ebe615c16994f3 ("drm: Remove transitional helpers")
> > Signed-off-by: Geert Uytterhoeven
> > --- a/drivers/gpu/drm/drm_plane_helper.c
> > +++ b/drivers/gpu/drm/drm_plane_helper.c
> > @@ -51,14 +51,6 @@
> > * planes, and newly merged drivers must not rely upon these transitional
> > * helpers.
> > *
>
> The first paragraph starts with "This helper library has two parts.". As
> you're dropping the mention of the second part, I think you should
> rework the first paragraph too.
That was my initial thought, too.
However, the code still has a second part, not related to the topic of
the first part (primary plane support).
>
> > - * The second part also implements transitional helpers which allow
> > drivers to
> > - * gradually switch to the atomic helper infrastructure for plane updates.
> > Once
> > - * that switch is complete drivers shouldn't use these any longer, instead
> > using
> > - * the proper legacy implementations for update and disable plane hooks
> > provided
> > - * by the atomic helpers.
> > - *
> > - * Again drivers are strongly urged to switch to the new interfaces.
> > - *
> > * The plane helpers share the function table structures with other
> > helpers,
> > * specifically also the atomic helpers. See
> > drm_plane_helper_funcs for
> > * the details.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[GIT PULL FOR v6.5] drm: rcar-du: Miscellaneous changes
Hello,
The following changes since commit 85d712f033d23bb56a373e29465470c036532d46:
Merge tag 'drm-intel-gt-next-2023-05-24' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2023-05-29 06:21:51
+1000)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pinchartl/linux.git
tags/drm-next-20230529
for you to fetch changes up to 11696c5e89245a1d360f75be3dfc4960b25a265a:
drm: Place Renesas drivers in a separate dir (2023-05-29 16:41:03 +0300)
Renesas DRM/KMS drivers:
- Group drivers in renesas subdirectory to prepare for new platform
- Drop deprecated R-Car H3 ES1.x support
Biju Das (1):
drm: Place Renesas drivers in a separate dir
Wolfram Sang (1):
drm: rcar-du: remove R-Car H3 ES1.* workarounds
MAINTAINERS| 3 +-
drivers/gpu/drm/Kconfig| 4 +-
drivers/gpu/drm/Makefile | 3 +-
drivers/gpu/drm/renesas/Kconfig| 4 ++
drivers/gpu/drm/renesas/Makefile | 4 ++
drivers/gpu/drm/{ => renesas}/rcar-du/Kconfig | 0
drivers/gpu/drm/{ => renesas}/rcar-du/Makefile | 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_cmm.c | 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_cmm.h | 0
.../gpu/drm/{ => renesas}/rcar-du/rcar_du_crtc.c | 37 ++---
.../gpu/drm/{ => renesas}/rcar-du/rcar_du_crtc.h | 0
.../gpu/drm/{ => renesas}/rcar-du/rcar_du_drv.c| 48 --
.../gpu/drm/{ => renesas}/rcar-du/rcar_du_drv.h| 2 -
.../drm/{ => renesas}/rcar-du/rcar_du_encoder.c| 0
.../drm/{ => renesas}/rcar-du/rcar_du_encoder.h| 0
.../gpu/drm/{ => renesas}/rcar-du/rcar_du_group.c | 0
.../gpu/drm/{ => renesas}/rcar-du/rcar_du_group.h | 0
.../gpu/drm/{ => renesas}/rcar-du/rcar_du_kms.c| 0
.../gpu/drm/{ => renesas}/rcar-du/rcar_du_kms.h| 0
.../gpu/drm/{ => renesas}/rcar-du/rcar_du_plane.c | 0
.../gpu/drm/{ => renesas}/rcar-du/rcar_du_plane.h | 0
.../gpu/drm/{ => renesas}/rcar-du/rcar_du_regs.h | 3 +-
.../gpu/drm/{ => renesas}/rcar-du/rcar_du_vsp.c| 0
.../gpu/drm/{ => renesas}/rcar-du/rcar_du_vsp.h| 0
.../drm/{ => renesas}/rcar-du/rcar_du_writeback.c | 0
.../drm/{ => renesas}/rcar-du/rcar_du_writeback.h | 0
.../gpu/drm/{ => renesas}/rcar-du/rcar_dw_hdmi.c | 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_lvds.c | 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_lvds.h | 0
.../gpu/drm/{ => renesas}/rcar-du/rcar_lvds_regs.h | 0
.../gpu/drm/{ => renesas}/rcar-du/rcar_mipi_dsi.c | 0
.../gpu/drm/{ => renesas}/rcar-du/rcar_mipi_dsi.h | 0
.../drm/{ => renesas}/rcar-du/rcar_mipi_dsi_regs.h | 0
.../gpu/drm/{ => renesas}/rcar-du/rzg2l_mipi_dsi.c | 0
.../{ => renesas}/rcar-du/rzg2l_mipi_dsi_regs.h| 0
drivers/gpu/drm/{ => renesas}/shmobile/Kconfig | 0
drivers/gpu/drm/{ => renesas}/shmobile/Makefile| 0
.../{ => renesas}/shmobile/shmob_drm_backlight.c | 0
.../{ => renesas}/shmobile/shmob_drm_backlight.h | 0
.../drm/{ => renesas}/shmobile/shmob_drm_crtc.c| 0
.../drm/{ => renesas}/shmobile/shmob_drm_crtc.h| 0
.../gpu/drm/{ => renesas}/shmobile/shmob_drm_drv.c | 0
.../gpu/drm/{ => renesas}/shmobile/shmob_drm_drv.h | 0
.../gpu/drm/{ => renesas}/shmobile/shmob_drm_kms.c | 0
.../gpu/drm/{ => renesas}/shmobile/shmob_drm_kms.h | 0
.../drm/{ => renesas}/shmobile/shmob_drm_plane.c | 0
.../drm/{ => renesas}/shmobile/shmob_drm_plane.h | 0
.../drm/{ => renesas}/shmobile/shmob_drm_regs.h| 0
48 files changed, 15 insertions(+), 93 deletions(-)
create mode 100644 drivers/gpu/drm/renesas/Kconfig
create mode 100644 drivers/gpu/drm/renesas/Makefile
rename drivers/gpu/drm/{ => renesas}/rcar-du/Kconfig (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/Makefile (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_cmm.c (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_cmm.h (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_crtc.c (96%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_crtc.h (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_drv.c (93%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_drv.h (96%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_encoder.c (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_encoder.h (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_group.c (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_group.h (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_kms.c (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_kms.h (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_plane.c (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_plane.h (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_regs.h
Re: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L Display Unit support
Hi Biju,
On Thu, Jun 01, 2023 at 12:12:59PM +, Biju Das wrote:
> > Subject: Re: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L Display
> > Unit support
> >
> > On Mon, May 29, 2023 at 02:22:06PM +, Biju Das wrote:
> > > > Subject: Re: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L
> > > > Display Unit support
> > > > On Thu, May 25, 2023 at 02:30:10PM +, Biju Das wrote:
> > > > > Hi DRM maintainers,
> > > > >
> > > > > Gentle ping.
> > > >
> > > > Sorry, I was on holidays the last two weeks.
> > > >
> > > > > Are we happy with moving all Renesas drm drivers to Renesas
> > > > > specific directory or preference is for separate one??
> > > >
> > > > This works for me.
> > > >
> > > > > If it is later, I can send RZ/G2L drm driver separate.
> > > > >
> > > > > Otherwise, I need to rebase and resend.
> > > >
> > > > Your series applies cleanly on top of the latest drm-next branch. Is
> > > > there a specific need to rebase and resend ?
> > >
> > > Nope. After my patch series there were some patches from Geert for
> > > drm/shmobile merged to drm-misc-next by Thomas.
> > >
> > > Maybe git managed this automatically??
> >
> > Probably, git is nice :-)
> >
> > > > I haven't had time to review patch 4/5 (the driver) yet. All the
> > > > rest looks good to me. Should I already include 1/5 in my next pull
> > request ?
> > >
> > > Yes, please.
> >
> > OK, I will do so. I've reviewed 4/5 in the meantime, but changes are
> > needed, so I won't wait for v10 before applying 1/5.
>
> I have incorporated review comments for v9. I need to rebase my changes.
>
> Is the pull request being done to drm-misc-next?
I've just sent the pull request for drm-next, and have CC'ed you.
> > > > > Please let me know your preference.
> > > > >
> > > > > Cheers,
> > > > > Biju
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Biju Das
> > > > > > Sent: Monday, May 15, 2023 8:58 AM
> > > > > > To: David Airlie ; Daniel Vetter
> > > > > > ; Philipp Zabel ; Geert
> > > > > > Uytterhoeven ; Laurent Pinchart
> > > > > > ; Kieran Bingham
> > > > > >
> > > > > > Cc: dri-devel@lists.freedesktop.org;
> > > > > > linux-renesas-...@vger.kernel.org;
> > > > > > Fabrizio Castro ; Prabhakar
> > > > > > Mahadev Lad
> > > > > > Subject: RE: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L
> > > > > > Display Unit support
> > > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > Gentle ping. Are we happy with this patch series?
> > > > > >
> > > > > > Cheers,
> > > > > > Biju
> > > > > >
> > > > > > > Subject: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L
> > > > > > > Display Unit support
> > > > > > >
> > > > > > > RZ/G2L LCD controller composed of Frame compression
> > > > > > > Processor(FCPVD), Video signal processor (VSPD) and Display
> > > > > > > unit(DU). The output of LCDC is connected to Display parallel
> > > > > > > interface and MIPI link video interface.
> > > > > > >
> > > > > > > The output from DSI is connected to ADV7535.
> > > > > > >
> > > > > > > Created a vendor specific directory renesas and moved all
> > > > > > > renesas drm drivers to it (rcar-du and shmobile). Then added
> > > > > > > support for RZ/G2L DU DRM driver by creating rz_du directory.
> > > > > > >
> > > > > > > Ref:
> > > > > > >
> > > > > > >
> > > > > > > v8->v9:
> > > > > > > * Added Rb tag from Laurent and Acked-by tag from Kieran for
> > > > patch#1.
> > > > > > > * Added Rb tag from Laurent and Geert for patch#3.
> > > > > > > * Dropped reset_control_assert() from error patch for
> > > > > > > rzg2l_du_crtc_get() as
> > > > > > >suggested by Philipp Zabel.
> > > > > > > * Added Rb tag from Laurent oatch#5.
> > > > > > > * Updated MAINTAINERS entries for common parts(Makefile and
> > > > Kconfig).
> > > > > > > v7->v8:
> > > > > > > * Moved rcar-du and shmobile DRM drivers to renesas specific
> > > > > > > vendor directory.
> > > > > > > * Fixed the typo vsp2->du in RZ/V2L DU bindings patch.
> > > > > > > * Added Rb tag from Rob for RZ/V2L DU bindings patch.
> > > > > > > * Dropped RCar du lib and created RZ/G2L DU DRM driver by
> > > > > > > creating rz_du folder.
> > > > > > > * Updated MAINTAINERS entries.
> > > > > > > v6->v7:
> > > > > > > * Split DU lib and RZ/G2L du driver as separate patch series
> > as
> > > > > > >DU support added to more platforms based on RZ/G2L alike
> > SoCs.
> > > > > > > * Rebased to latest drm-tip.
> > > > > > > * Added patch #2 for binding support for RZ/V2L DU
> > > > > > > * Added patch #4 for driver support for RZ/V2L DU
> > > > > > > * Added patch #5 for SoC DTSI support for RZ/G2L DU
> > > > > > > * Added patch #6 for SoC DTSI support for RZ/V2L DU
> > > > > > > * Added patch #7 for Enabling DU on SMARC EVK based on
> > > > > > > RZ/{G2L,V2L} SoCs.
> > > > > > > * Added patch #8 for Enabling DU on SMARC EVK based on
> > > > > > > RZ/G2LC
> > > > SoC.
> > > > > > > v5->v6:
> > > > > > > * Merged DU lib and RZ/G2L du driver in same
Re: [PATCH 3/3] drm: Fix references to drm_plane_helper_check_state()
Hi Geert,
Thank you for the patch.
On Fri, Jun 02, 2023 at 11:11:36AM +0200, Geert Uytterhoeven wrote:
> As of commit a01cb8ba3f628293 ("drm: Move drm_plane_helper_check_state()
> into drm_atomic_helper.c"), drm_plane_helper_check_state() no longer
> exists, but is part of drm_atomic_helper_check_plane_state().
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
> ---
> Interestingly, all these comments appeared only after the commit that
> removed the function...
>
> This is against next-20230602, which does not have the
> drivers/gpu/drm/{ => renesas}/rcar-du move yet.
>
> Biju: you're adding a new copy in
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> ---
> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 3 ++-
> drivers/gpu/drm/tidss/tidss_plane.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> index d759e019218181ce..e445fac8e0b46c21 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> @@ -600,7 +600,8 @@ int __rcar_du_plane_atomic_check(struct drm_plane *plane,
> if (!state->crtc) {
> /*
>* The visible field is not reset by the DRM core but only
> - * updated by drm_plane_helper_check_state(), set it manually.
> + * updated by drm_atomic_helper_check_plane_state(), set it
> + * manually.
>*/
> state->visible = false;
> *format = NULL;
> diff --git a/drivers/gpu/drm/tidss/tidss_plane.c
> b/drivers/gpu/drm/tidss/tidss_plane.c
> index 6bdd6e4a955ab3cc..e1c0ef0c3894c855 100644
> --- a/drivers/gpu/drm/tidss/tidss_plane.c
> +++ b/drivers/gpu/drm/tidss/tidss_plane.c
> @@ -38,7 +38,8 @@ static int tidss_plane_atomic_check(struct drm_plane *plane,
> if (!new_plane_state->crtc) {
> /*
>* The visible field is not reset by the DRM core but only
> - * updated by drm_plane_helper_check_state(), set it manually.
> + * updated by drm_atomic_helper_check_plane_state(), set it
> + * manually.
>*/
> new_plane_state->visible = false;
> return 0;
--
Regards,
Laurent Pinchart
Re: [PATCH 2/3] drm: Remove references to removed transitional helpers
Hi Geert,
Thank you for the patch.
On Fri, Jun 02, 2023 at 11:11:35AM +0200, Geert Uytterhoeven wrote:
> The transitional helpers were removed a long time ago, but some
> references stuck. Remove them.
>
> Fixes: 21ebe615c16994f3 ("drm: Remove transitional helpers")
> Signed-off-by: Geert Uytterhoeven
> ---
> It doesn't look like the drm_encoder_helper_funcs were ever used by the
> transitional plane helpers?
> ---
> drivers/gpu/drm/drm_plane_helper.c | 8
> include/drm/drm_crtc.h | 5 ---
> include/drm/drm_modeset_helper_vtables.h | 48 +++-
> 3 files changed, 21 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_plane_helper.c
> b/drivers/gpu/drm/drm_plane_helper.c
> index c91e454eba097942..be45bdb58d849653 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -51,14 +51,6 @@
> * planes, and newly merged drivers must not rely upon these transitional
> * helpers.
> *
The first paragraph starts with "This helper library has two parts.". As
you're dropping the mention of the second part, I think you should
rework the first paragraph too.
> - * The second part also implements transitional helpers which allow drivers
> to
> - * gradually switch to the atomic helper infrastructure for plane updates.
> Once
> - * that switch is complete drivers shouldn't use these any longer, instead
> using
> - * the proper legacy implementations for update and disable plane hooks
> provided
> - * by the atomic helpers.
> - *
> - * Again drivers are strongly urged to switch to the new interfaces.
> - *
> * The plane helpers share the function table structures with other helpers,
> * specifically also the atomic helpers. See drm_plane_helper_funcs
> for
> * the details.
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 8e1cbc75143ef216..8b48a1974da3143c 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -77,11 +77,6 @@ struct drm_plane_helper_funcs;
> * intended to indicate whether a full modeset is needed, rather than
> strictly
> * describing what has changed in a commit. See also:
> * drm_atomic_crtc_needs_modeset()
> - *
> - * WARNING: Transitional helpers (like drm_helper_crtc_mode_set() or
> - * drm_helper_crtc_mode_set_base()) do not maintain many of the derived
> control
> - * state like @plane_mask so drivers not converted over to atomic helpers
> should
> - * not rely on these being accurate!
> */
> struct drm_crtc_state {
> /** @crtc: backpointer to the CRTC */
> diff --git a/include/drm/drm_modeset_helper_vtables.h
> b/include/drm/drm_modeset_helper_vtables.h
> index 965faf082a6d1acb..e3c3ac615909474b 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -59,8 +59,8 @@ enum mode_set_atomic {
> /**
> * struct drm_crtc_helper_funcs - helper operations for CRTCs
> *
> - * These hooks are used by the legacy CRTC helpers, the transitional plane
> - * helpers and the new atomic modesetting helpers.
> + * These hooks are used by the legacy CRTC helpers and the new atomic
> + * modesetting helpers.
> */
> struct drm_crtc_helper_funcs {
> /**
> @@ -216,9 +216,7 @@ struct drm_crtc_helper_funcs {
>*
>* This callback is used to update the display mode of a CRTC without
>* changing anything of the primary plane configuration. This fits the
> - * requirement of atomic and hence is used by the atomic helpers. It is
> - * also used by the transitional plane helpers to implement a
> - * @mode_set hook in drm_helper_crtc_mode_set().
> + * requirement of atomic and hence is used by the atomic helpers.
>*
>* Note that the display pipe is completely off when this function is
>* called. Atomic drivers which need hardware to be running before they
> @@ -333,8 +331,8 @@ struct drm_crtc_helper_funcs {
>* all updated. Again the recommendation is to just call check helpers
>* until a maximal configuration is reached.
>*
> - * This callback is used by the atomic modeset helpers and by the
> - * transitional plane helpers, but it is optional.
> + * This callback is used by the atomic modeset helpers, but it is
> + * optional.
>*
>* NOTE:
>*
> @@ -373,8 +371,8 @@ struct drm_crtc_helper_funcs {
>* has picked. See drm_atomic_helper_commit_planes() for a discussion of
>* the tradeoffs and variants of plane commit helpers.
>*
> - * This callback is used by the atomic modeset helpers and by the
> - * transitional plane helpers, but it is optional.
> + * This callback is used by the atomic modeset helpers, but it is
> + * optional.
>*/
> void (*atomic_begin)(struct drm_crtc *crtc,
>struct drm_atomic_state *state);
> @@ -397,8 +395,8 @@ struct drm_crtc_helper_funcs
Re: [PATCH 1/3] drm/todo: Add atomic modesetting references
Hi Geert, Thank you for the patch. On Fri, Jun 02, 2023 at 11:11:34AM +0200, Geert Uytterhoeven wrote: > The section about converting existing KMS drivers to atomic modesetting > mentions the existence of a conversion guide, but does not reference it. > While the guide is old and rusty, it still contains useful information, > so add a link to it. Also link to the LWN.net articles that give an > overview about the atomic mode setting design. > > Signed-off-by: Geert Uytterhoeven > --- > Documentation/gpu/todo.rst | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index 68bdafa0284f55f6..51eb67f5268c5ec1 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -49,14 +49,19 @@ converted over. Modern compositors like Wayland or > Surfaceflinger on Android > really want an atomic modeset interface, so this is all about the bright > future. > > -There is a conversion guide for atomic and all you need is a GPU for a > +There is a conversion guide for atomic[1] and all you need is a GPU for a > non-converted driver (again virtual HW drivers for KVM are still all > -suitable). > +suitable). The "Atomic mode setting design overview" series [2][3] at s/ / / Reviewed-by: Laurent Pinchart > +LWN.net can also be helpful. > > As part of this drivers also need to convert to universal plane (which means > exposing primary & cursor as proper plane objects). But that's much easier to > do by directly using the new atomic helper driver callbacks. > > + - [1] > https://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html > + - [2] https://lwn.net/Articles/653071/ > + - [3] https://lwn.net/Articles/653466/ > + > Contact: Daniel Vetter, respective driver maintainers > > Level: Advanced -- Regards, Laurent Pinchart
Re: How to fetch the implicit sync fence for a GPU buffer?
On Friday, June 2nd, 2023 at 12:29, Michel Dänzer wrote: > > I’m wondering whether there’s an API -- maybe something analogous to > > drmPrimeHandleToFD() – that allows userspace to fetch a waitable fence fd > > for a dmabuf? > > A dma-buf fd itself can serve this purpose; it polls as readable when the GPU > has finished drawing to the buffer. If you _really_ need a sync_file FD, you can extract it via DMA_BUF_IOCTL_EXPORT_SYNC_FILE. This is a somewhat recent kernel uAPI.
Re: [PATCH 1/3] drm/todo: Add atomic modesetting references
Geert Uytterhoeven writes: Hello Geert, Thanks for your patch. > The section about converting existing KMS drivers to atomic modesetting > mentions the existence of a conversion guide, but does not reference it. > While the guide is old and rusty, it still contains useful information, > so add a link to it. Also link to the LWN.net articles that give an > overview about the atomic mode setting design. > This is a great idea and agree that would be very useful to have these. > Signed-off-by: Geert Uytterhoeven > --- > Documentation/gpu/todo.rst | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index 68bdafa0284f55f6..51eb67f5268c5ec1 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -49,14 +49,19 @@ converted over. Modern compositors like Wayland or > Surfaceflinger on Android > really want an atomic modeset interface, so this is all about the bright > future. > > -There is a conversion guide for atomic and all you need is a GPU for a > +There is a conversion guide for atomic[1] and all you need is a GPU for a > non-converted driver (again virtual HW drivers for KVM are still all > -suitable). Are any of the virtual drivers not yet ported to atomic? This sentence seems to be outdated and maybe you could remove it on a following patch? Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: How to fetch the implicit sync fence for a GPU buffer?
On 6/1/23 23:15, Hoosier, Matt wrote: > Hi, > > > > In the past there has been writing about Wayland’s model using implicit > synchronization of GPU renderbuffers and KMS commits [1] [2]. > > > > It would sometimes be nice to do that waiting explicitly in a compositor > before enqueueing a KMS pageflip that references a buffer who may go on > rendering for some time still. This stalls the pipeline. > > > > I’m wondering whether there’s an API -- maybe something analogous to > drmPrimeHandleToFD() – that allows userspace to fetch a waitable fence fd for > a dmabuf? A dma-buf fd itself can serve this purpose; it polls as readable when the GPU has finished drawing to the buffer. See https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880 for how I used this to implement what you describe above in mutter. Note that this involves some Wayland state management challenges for correct operation in all cases though. -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
[PATCH v9 4/4] lib/ref_tracker: remove warnings in case of allocation failure
Library can handle allocation failures. To avoid allocation warnings
__GFP_NOWARN has been added everywhere. Moreover GFP_ATOMIC has been
replaced with GFP_NOWAIT in case of stack allocation on tracker free
call.
Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
Reviewed-by: Eric Dumazet
---
lib/ref_tracker.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/ref_tracker.c b/lib/ref_tracker.c
index cce4614b07940f..cf5609b1ca7936 100644
--- a/lib/ref_tracker.c
+++ b/lib/ref_tracker.c
@@ -189,7 +189,7 @@ int ref_tracker_alloc(struct ref_tracker_dir *dir,
unsigned long entries[REF_TRACKER_STACK_ENTRIES];
struct ref_tracker *tracker;
unsigned int nr_entries;
- gfp_t gfp_mask = gfp;
+ gfp_t gfp_mask = gfp | __GFP_NOWARN;
unsigned long flags;
WARN_ON_ONCE(dir->dead);
@@ -237,7 +237,8 @@ int ref_tracker_free(struct ref_tracker_dir *dir,
return -EEXIST;
}
nr_entries = stack_trace_save(entries, ARRAY_SIZE(entries), 1);
- stack_handle = stack_depot_save(entries, nr_entries, GFP_ATOMIC);
+ stack_handle = stack_depot_save(entries, nr_entries,
+ GFP_NOWAIT | __GFP_NOWARN);
spin_lock_irqsave(>lock, flags);
if (tracker->dead) {
--
2.34.1
[PATCH v9 3/4] lib/ref_tracker: add printing to memory buffer
Similar to stack_(depot|trace)_snprint the patch
adds helper to printing stats to memory buffer.
It will be helpful in case of debugfs.
Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
Reviewed-by: Eric Dumazet
---
include/linux/ref_tracker.h | 8 +++
lib/ref_tracker.c | 56 ++---
2 files changed, 56 insertions(+), 8 deletions(-)
diff --git a/include/linux/ref_tracker.h b/include/linux/ref_tracker.h
index 19a69e7809d6c1..8eac4f3d52547c 100644
--- a/include/linux/ref_tracker.h
+++ b/include/linux/ref_tracker.h
@@ -46,6 +46,8 @@ void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
void ref_tracker_dir_print(struct ref_tracker_dir *dir,
unsigned int display_limit);
+int ref_tracker_dir_snprint(struct ref_tracker_dir *dir, char *buf, size_t
size);
+
int ref_tracker_alloc(struct ref_tracker_dir *dir,
struct ref_tracker **trackerp, gfp_t gfp);
@@ -74,6 +76,12 @@ static inline void ref_tracker_dir_print(struct
ref_tracker_dir *dir,
{
}
+static inline int ref_tracker_dir_snprint(struct ref_tracker_dir *dir,
+ char *buf, size_t size)
+{
+ return 0;
+}
+
static inline int ref_tracker_alloc(struct ref_tracker_dir *dir,
struct ref_tracker **trackerp,
gfp_t gfp)
diff --git a/lib/ref_tracker.c b/lib/ref_tracker.c
index 2ffe79c90c1771..cce4614b07940f 100644
--- a/lib/ref_tracker.c
+++ b/lib/ref_tracker.c
@@ -62,8 +62,27 @@ ref_tracker_get_stats(struct ref_tracker_dir *dir, unsigned
int limit)
return stats;
}
-void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
- unsigned int display_limit)
+struct ostream {
+ char *buf;
+ int size, used;
+};
+
+#define pr_ostream(stream, fmt, args...) \
+({ \
+ struct ostream *_s = (stream); \
+\
+ if (!_s->buf) { \
+ pr_err(fmt, ##args); \
+ } else { \
+ int ret, len = _s->size - _s->used; \
+ ret = snprintf(_s->buf + _s->used, len, pr_fmt(fmt), ##args); \
+ _s->used += min(ret, len); \
+ } \
+})
+
+static void
+__ref_tracker_dir_pr_ostream(struct ref_tracker_dir *dir,
+unsigned int display_limit, struct ostream *s)
{
struct ref_tracker_dir_stats *stats;
unsigned int i = 0, skipped;
@@ -77,8 +96,8 @@ void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
stats = ref_tracker_get_stats(dir, display_limit);
if (IS_ERR(stats)) {
- pr_err("%s@%pK: couldn't get stats, error %pe\n",
- dir->name, dir, stats);
+ pr_ostream(s, "%s@%pK: couldn't get stats, error %pe\n",
+ dir->name, dir, stats);
return;
}
@@ -88,19 +107,27 @@ void ref_tracker_dir_print_locked(struct ref_tracker_dir
*dir,
stack = stats->stacks[i].stack_handle;
if (sbuf && !stack_depot_snprint(stack, sbuf, STACK_BUF_SIZE,
4))
sbuf[0] = 0;
- pr_err("%s@%pK has %d/%d users at\n%s\n", dir->name, dir,
- stats->stacks[i].count, stats->total, sbuf);
+ pr_ostream(s, "%s@%pK has %d/%d users at\n%s\n", dir->name, dir,
+ stats->stacks[i].count, stats->total, sbuf);
skipped -= stats->stacks[i].count;
}
if (skipped)
- pr_err("%s@%pK skipped reports about %d/%d users.\n",
- dir->name, dir, skipped, stats->total);
+ pr_ostream(s, "%s@%pK skipped reports about %d/%d users.\n",
+ dir->name, dir, skipped, stats->total);
kfree(sbuf);
kfree(stats);
}
+
+void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
+ unsigned int display_limit)
+{
+ struct ostream os = {};
+
+ __ref_tracker_dir_pr_ostream(dir, display_limit, );
+}
EXPORT_SYMBOL(ref_tracker_dir_print_locked);
void ref_tracker_dir_print(struct ref_tracker_dir *dir,
@@ -114,6 +141,19 @@ void ref_tracker_dir_print(struct ref_tracker_dir *dir,
}
EXPORT_SYMBOL(ref_tracker_dir_print);
+int ref_tracker_dir_snprint(struct ref_tracker_dir *dir, char *buf, size_t
size)
+{
+ struct ostream os = { .buf = buf, .size = size };
+ unsigned long flags;
+
+ spin_lock_irqsave(>lock, flags);
+ __ref_tracker_dir_pr_ostream(dir, 16, );
+ spin_unlock_irqrestore(>lock, flags);
+
+ return os.used;
+}
+EXPORT_SYMBOL(ref_tracker_dir_snprint);
+
void ref_tracker_dir_exit(struct ref_tracker_dir *dir)
{
struct ref_tracker *tracker, *n;
--
2.34.1
[PATCH v9 2/4] lib/ref_tracker: improve printing stats
In case the library is tracking busy subsystem, simply
printing stack for every active reference will spam log
with long, hard to read, redundant stack traces. To improve
readabilty following changes have been made:
- reports are printed per stack_handle - log is more compact,
- added display name for ref_tracker_dir - it will differentiate
multiple subsystems,
- stack trace is printed indented, in the same printk call,
- info about dropped references is printed as well.
Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
Reviewed-by: Eric Dumazet
---
include/linux/ref_tracker.h | 9 -
lib/ref_tracker.c | 90 +++--
lib/test_ref_tracker.c | 2 +-
net/core/dev.c | 2 +-
net/core/net_namespace.c| 4 +-
5 files changed, 90 insertions(+), 17 deletions(-)
diff --git a/include/linux/ref_tracker.h b/include/linux/ref_tracker.h
index 87a92f2bec1b88..19a69e7809d6c1 100644
--- a/include/linux/ref_tracker.h
+++ b/include/linux/ref_tracker.h
@@ -17,12 +17,15 @@ struct ref_tracker_dir {
booldead;
struct list_headlist; /* List of active trackers */
struct list_headquarantine; /* List of dead trackers */
+ charname[32];
#endif
};
#ifdef CONFIG_REF_TRACKER
+
static inline void ref_tracker_dir_init(struct ref_tracker_dir *dir,
- unsigned int quarantine_count)
+ unsigned int quarantine_count,
+ const char *name)
{
INIT_LIST_HEAD(>list);
INIT_LIST_HEAD(>quarantine);
@@ -31,6 +34,7 @@ static inline void ref_tracker_dir_init(struct
ref_tracker_dir *dir,
dir->dead = false;
refcount_set(>untracked, 1);
refcount_set(>no_tracker, 1);
+ strscpy(dir->name, name, sizeof(dir->name));
stack_depot_init();
}
@@ -51,7 +55,8 @@ int ref_tracker_free(struct ref_tracker_dir *dir,
#else /* CONFIG_REF_TRACKER */
static inline void ref_tracker_dir_init(struct ref_tracker_dir *dir,
- unsigned int quarantine_count)
+ unsigned int quarantine_count,
+ const char *name)
{
}
diff --git a/lib/ref_tracker.c b/lib/ref_tracker.c
index d4eb0929af8f96..2ffe79c90c1771 100644
--- a/lib/ref_tracker.c
+++ b/lib/ref_tracker.c
@@ -1,11 +1,16 @@
// SPDX-License-Identifier: GPL-2.0-or-later
+
+#define pr_fmt(fmt) "ref_tracker: " fmt
+
#include
+#include
#include
#include
#include
#include
#define REF_TRACKER_STACK_ENTRIES 16
+#define STACK_BUF_SIZE 1024
struct ref_tracker {
struct list_headhead; /* anchor into dir->list or
dir->quarantine */
@@ -14,24 +19,87 @@ struct ref_tracker {
depot_stack_handle_tfree_stack_handle;
};
-void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
- unsigned int display_limit)
+struct ref_tracker_dir_stats {
+ int total;
+ int count;
+ struct {
+ depot_stack_handle_t stack_handle;
+ unsigned int count;
+ } stacks[];
+};
+
+static struct ref_tracker_dir_stats *
+ref_tracker_get_stats(struct ref_tracker_dir *dir, unsigned int limit)
{
+ struct ref_tracker_dir_stats *stats;
struct ref_tracker *tracker;
- unsigned int i = 0;
- lockdep_assert_held(>lock);
+ stats = kmalloc(struct_size(stats, stacks, limit),
+ GFP_NOWAIT | __GFP_NOWARN);
+ if (!stats)
+ return ERR_PTR(-ENOMEM);
+ stats->total = 0;
+ stats->count = 0;
list_for_each_entry(tracker, >list, head) {
- if (i < display_limit) {
- pr_err("leaked reference.\n");
- if (tracker->alloc_stack_handle)
- stack_depot_print(tracker->alloc_stack_handle);
- i++;
- } else {
- break;
+ depot_stack_handle_t stack = tracker->alloc_stack_handle;
+ int i;
+
+ ++stats->total;
+ for (i = 0; i < stats->count; ++i)
+ if (stats->stacks[i].stack_handle == stack)
+ break;
+ if (i >= limit)
+ continue;
+ if (i >= stats->count) {
+ stats->stacks[i].stack_handle = stack;
+ stats->stacks[i].count = 0;
+ ++stats->count;
}
+ ++stats->stacks[i].count;
+ }
+
+ return stats;
+}
+
+void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
+ unsigned int display_limit)
+{
+ struct ref_tracker_dir_stats *stats;
+ unsigned int i = 0, skipped;
+
[PATCH v9 1/4] lib/ref_tracker: add unlocked leak print helper
To have reliable detection of leaks, caller must be able to check under
the same lock both: tracked counter and the leaks. dir.lock is natural
candidate for such lock and unlocked print helper can be called with this
lock taken.
As a bonus we can reuse this helper in ref_tracker_dir_exit.
Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
Reviewed-by: Eric Dumazet
---
include/linux/ref_tracker.h | 8 ++
lib/ref_tracker.c | 66 ++---
2 files changed, 46 insertions(+), 28 deletions(-)
diff --git a/include/linux/ref_tracker.h b/include/linux/ref_tracker.h
index 9ca353ab712b5e..87a92f2bec1b88 100644
--- a/include/linux/ref_tracker.h
+++ b/include/linux/ref_tracker.h
@@ -36,6 +36,9 @@ static inline void ref_tracker_dir_init(struct
ref_tracker_dir *dir,
void ref_tracker_dir_exit(struct ref_tracker_dir *dir);
+void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
+ unsigned int display_limit);
+
void ref_tracker_dir_print(struct ref_tracker_dir *dir,
unsigned int display_limit);
@@ -56,6 +59,11 @@ static inline void ref_tracker_dir_exit(struct
ref_tracker_dir *dir)
{
}
+static inline void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
+ unsigned int display_limit)
+{
+}
+
static inline void ref_tracker_dir_print(struct ref_tracker_dir *dir,
unsigned int display_limit)
{
diff --git a/lib/ref_tracker.c b/lib/ref_tracker.c
index dc7b14aa3431e2..d4eb0929af8f96 100644
--- a/lib/ref_tracker.c
+++ b/lib/ref_tracker.c
@@ -14,6 +14,38 @@ struct ref_tracker {
depot_stack_handle_tfree_stack_handle;
};
+void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
+ unsigned int display_limit)
+{
+ struct ref_tracker *tracker;
+ unsigned int i = 0;
+
+ lockdep_assert_held(>lock);
+
+ list_for_each_entry(tracker, >list, head) {
+ if (i < display_limit) {
+ pr_err("leaked reference.\n");
+ if (tracker->alloc_stack_handle)
+ stack_depot_print(tracker->alloc_stack_handle);
+ i++;
+ } else {
+ break;
+ }
+ }
+}
+EXPORT_SYMBOL(ref_tracker_dir_print_locked);
+
+void ref_tracker_dir_print(struct ref_tracker_dir *dir,
+ unsigned int display_limit)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(>lock, flags);
+ ref_tracker_dir_print_locked(dir, display_limit);
+ spin_unlock_irqrestore(>lock, flags);
+}
+EXPORT_SYMBOL(ref_tracker_dir_print);
+
void ref_tracker_dir_exit(struct ref_tracker_dir *dir)
{
struct ref_tracker *tracker, *n;
@@ -27,13 +59,13 @@ void ref_tracker_dir_exit(struct ref_tracker_dir *dir)
kfree(tracker);
dir->quarantine_avail++;
}
- list_for_each_entry_safe(tracker, n, >list, head) {
- pr_err("leaked reference.\n");
- if (tracker->alloc_stack_handle)
- stack_depot_print(tracker->alloc_stack_handle);
+ if (!list_empty(>list)) {
+ ref_tracker_dir_print_locked(dir, 16);
leak = true;
- list_del(>head);
- kfree(tracker);
+ list_for_each_entry_safe(tracker, n, >list, head) {
+ list_del(>head);
+ kfree(tracker);
+ }
}
spin_unlock_irqrestore(>lock, flags);
WARN_ON_ONCE(leak);
@@ -42,28 +74,6 @@ void ref_tracker_dir_exit(struct ref_tracker_dir *dir)
}
EXPORT_SYMBOL(ref_tracker_dir_exit);
-void ref_tracker_dir_print(struct ref_tracker_dir *dir,
- unsigned int display_limit)
-{
- struct ref_tracker *tracker;
- unsigned long flags;
- unsigned int i = 0;
-
- spin_lock_irqsave(>lock, flags);
- list_for_each_entry(tracker, >list, head) {
- if (i < display_limit) {
- pr_err("leaked reference.\n");
- if (tracker->alloc_stack_handle)
- stack_depot_print(tracker->alloc_stack_handle);
- i++;
- } else {
- break;
- }
- }
- spin_unlock_irqrestore(>lock, flags);
-}
-EXPORT_SYMBOL(ref_tracker_dir_print);
-
int ref_tracker_alloc(struct ref_tracker_dir *dir,
struct ref_tracker **trackerp,
gfp_t gfp)
--
2.34.1
[PATCH v9 0/4] drm/i915: use ref_tracker library for tracking wakerefs
Hi Jakub, This is reviewed series of ref_tracker patches, ready to merge via network tree, rebased on net-next/main. i915 patches will be merged later via intel-gfx tree. Signed-off-by: Andrzej Hajda --- Changes in v9: - removed i915 patches, just to merge network part - added r-b-s - Link to v8: https://lore.kernel.org/r/20230224-track_gt-v8-0-4b6517e61...@intel.com Changes in v8: - addressed comments from Eric, Zhou and CI, thanks, - added ref_tracker_dir_init name argument to all callers in one patch - moved intel_wakeref_tracker_show to *.c - s/intel_wakeref_tracker_show/intel_ref_tracker_show/ - removed 'default n' from Kconfig - changed strlcpy to strscpy, - removed assignement from if condition, - removed long lines from patch description - added tags - Link to v7: https://lore.kernel.org/r/20230224-track_gt-v7-0-11f08358c...@intel.com Changes in v7: - removed 8th patch (hold wakeref), as it was already merged - added tags (thx Andi) - Link to v6: https://lore.kernel.org/r/20230224-track_gt-v6-0-0dc8601fd...@intel.com Changes in v6: - rebased to solve minor conflict and allow CI testing - Link to v5: https://lore.kernel.org/r/20230224-track_gt-v5-0-77be86f2c...@intel.com Changes in v5 (thx Andi for review): - use *_locked convention instead of __*, - improved commit messages, - re-worked i915 patches, squashed separation and conversion patches, - added tags, - Link to v4: https://lore.kernel.org/r/20230224-track_gt-v4-0-464e8ab4c...@intel.com Changes in v4: - split "Separate wakeref tracking" to smaller parts - fixed typos, - Link to v1-v3: https://patchwork.freedesktop.org/series/100327/ --- Andrzej Hajda (4): lib/ref_tracker: add unlocked leak print helper lib/ref_tracker: improve printing stats lib/ref_tracker: add printing to memory buffer lib/ref_tracker: remove warnings in case of allocation failure include/linux/ref_tracker.h | 25 ++- lib/ref_tracker.c | 179 lib/test_ref_tracker.c | 2 +- net/core/dev.c | 2 +- net/core/net_namespace.c| 4 +- 5 files changed, 176 insertions(+), 36 deletions(-) --- base-commit: 23fcb62bc19c37adb72a585d5dc702ac55b74fb1 change-id: 20230224-track_gt-1b3da8bdacd7 Best regards, -- Andrzej Hajda
RE: [PATCH 3/3] drm: Fix references to drm_plane_helper_check_state()
Hi Geert,
Thanks for the feedback.
> Subject: [PATCH 3/3] drm: Fix references to
> drm_plane_helper_check_state()
>
> As of commit a01cb8ba3f628293 ("drm: Move drm_plane_helper_check_state()
> into drm_atomic_helper.c"), drm_plane_helper_check_state() no longer
> exists, but is part of drm_atomic_helper_check_plane_state().
>
> Signed-off-by: Geert Uytterhoeven
> ---
> Interestingly, all these comments appeared only after the commit that
> removed the function...
>
> This is against next-20230602, which does not have the drivers/gpu/drm/{
> => renesas}/rcar-du move yet.
>
> Biju: you're adding a new copy in
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
OK, will update the comment in __rzg2l_du_vsp_plane_atomic_check()
as it is moved to drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c
based on Laurent's review comment.
Cheers,
Biju
> ---
> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 3 ++-
> drivers/gpu/drm/tidss/tidss_plane.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> index d759e019218181ce..e445fac8e0b46c21 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> @@ -600,7 +600,8 @@ int __rcar_du_plane_atomic_check(struct drm_plane
> *plane,
> if (!state->crtc) {
> /*
>* The visible field is not reset by the DRM core but only
> - * updated by drm_plane_helper_check_state(), set it
> manually.
> + * updated by drm_atomic_helper_check_plane_state(), set it
> + * manually.
>*/
> state->visible = false;
> *format = NULL;
> diff --git a/drivers/gpu/drm/tidss/tidss_plane.c
> b/drivers/gpu/drm/tidss/tidss_plane.c
> index 6bdd6e4a955ab3cc..e1c0ef0c3894c855 100644
> --- a/drivers/gpu/drm/tidss/tidss_plane.c
> +++ b/drivers/gpu/drm/tidss/tidss_plane.c
> @@ -38,7 +38,8 @@ static int tidss_plane_atomic_check(struct drm_plane
> *plane,
> if (!new_plane_state->crtc) {
> /*
>* The visible field is not reset by the DRM core but only
> - * updated by drm_plane_helper_check_state(), set it
> manually.
> + * updated by drm_atomic_helper_check_plane_state(), set it
> + * manually.
>*/
> new_plane_state->visible = false;
> return 0;
> --
> 2.34.1
Re: [PATCH] dim: Disallow remote branch deletions with 'dim push'
On Thu, 01 Jun 2023, Ashutosh Dixit wrote: > An inadvertent 'dim push -d' can delete remote branches. Disallow such > remote branch deletions. Please see https://drm.pages.freedesktop.org/maintainer-tools/CONTRIBUTING.html > > Signed-off-by: Ashutosh Dixit > --- > dim | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/dim b/dim > index 126568e..e5899e6 100755 > --- a/dim > +++ b/dim > @@ -1029,6 +1029,12 @@ function dim_push_branch > fi > fi > > + # Disallow remote branch deletions, say with 'dim push -d' > + if [[ "$@" == *"-d"* ]]; then > + echoerr "Attempt to delete remote branch, aborting." > + return 1 > + fi I'm working on adding a server side git pre-receive hook to tackle this too, but I guess there's no harm in adding this. The choice of -d for dry run was unfortunate, and this helps with the 'dim -d foo' vs 'dim foo -d' mistake. BR, Jani. > + > git_push $remote $branch "$@" > > update_linux_next $branch drm-intel-next drm-intel-next-fixes > drm-intel-fixes -- Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH -next] drm/meson: Remove unneeded semicolon
On 02/06/2023 11:14, Yang Li wrote: ./drivers/gpu/drm/meson/meson_dw_mipi_dsi.c:117:2-3: Unneeded semicolon ./drivers/gpu/drm/meson/meson_dw_mipi_dsi.c:231:2-3: Unneeded semicolon Reported-by: Abaci Robot Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5392 Signed-off-by: Yang Li --- drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c index dd505ac37976..57447abf1a29 100644 --- a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c +++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c @@ -114,7 +114,7 @@ static int dw_mipi_dsi_phy_init(void *priv_data) case MIPI_DSI_FMT_RGB666_PACKED: case MIPI_DSI_FMT_RGB565: return -EINVAL; - }; + } /* Configure color format for DPI register */ writel_relaxed(FIELD_PREP(MIPI_DSI_TOP_DPI_COLOR_MODE, dpi_data_format) | @@ -228,7 +228,7 @@ static int meson_dw_mipi_dsi_host_attach(void *priv_data, case MIPI_DSI_FMT_RGB565: dev_err(mipi_dsi->dev, "invalid pixel format %d\n", device->format); return -EINVAL; - }; + } ret = phy_init(mipi_dsi->phy); if (ret) Acked-by: Neil Armstrong
[PATCH -next] drm/meson: Remove unneeded semicolon
./drivers/gpu/drm/meson/meson_dw_mipi_dsi.c:117:2-3: Unneeded semicolon ./drivers/gpu/drm/meson/meson_dw_mipi_dsi.c:231:2-3: Unneeded semicolon Reported-by: Abaci Robot Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5392 Signed-off-by: Yang Li --- drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c index dd505ac37976..57447abf1a29 100644 --- a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c +++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c @@ -114,7 +114,7 @@ static int dw_mipi_dsi_phy_init(void *priv_data) case MIPI_DSI_FMT_RGB666_PACKED: case MIPI_DSI_FMT_RGB565: return -EINVAL; - }; + } /* Configure color format for DPI register */ writel_relaxed(FIELD_PREP(MIPI_DSI_TOP_DPI_COLOR_MODE, dpi_data_format) | @@ -228,7 +228,7 @@ static int meson_dw_mipi_dsi_host_attach(void *priv_data, case MIPI_DSI_FMT_RGB565: dev_err(mipi_dsi->dev, "invalid pixel format %d\n", device->format); return -EINVAL; - }; + } ret = phy_init(mipi_dsi->phy); if (ret) -- 2.20.1.7.g153144c
[PATCH 1/3] drm/todo: Add atomic modesetting references
The section about converting existing KMS drivers to atomic modesetting mentions the existence of a conversion guide, but does not reference it. While the guide is old and rusty, it still contains useful information, so add a link to it. Also link to the LWN.net articles that give an overview about the atomic mode setting design. Signed-off-by: Geert Uytterhoeven --- Documentation/gpu/todo.rst | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 68bdafa0284f55f6..51eb67f5268c5ec1 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -49,14 +49,19 @@ converted over. Modern compositors like Wayland or Surfaceflinger on Android really want an atomic modeset interface, so this is all about the bright future. -There is a conversion guide for atomic and all you need is a GPU for a +There is a conversion guide for atomic[1] and all you need is a GPU for a non-converted driver (again virtual HW drivers for KVM are still all -suitable). +suitable). The "Atomic mode setting design overview" series [2][3] at +LWN.net can also be helpful. As part of this drivers also need to convert to universal plane (which means exposing primary & cursor as proper plane objects). But that's much easier to do by directly using the new atomic helper driver callbacks. + - [1] https://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html + - [2] https://lwn.net/Articles/653071/ + - [3] https://lwn.net/Articles/653466/ + Contact: Daniel Vetter, respective driver maintainers Level: Advanced -- 2.34.1
[PATCH 2/3] drm: Remove references to removed transitional helpers
The transitional helpers were removed a long time ago, but some
references stuck. Remove them.
Fixes: 21ebe615c16994f3 ("drm: Remove transitional helpers")
Signed-off-by: Geert Uytterhoeven
---
It doesn't look like the drm_encoder_helper_funcs were ever used by the
transitional plane helpers?
---
drivers/gpu/drm/drm_plane_helper.c | 8
include/drm/drm_crtc.h | 5 ---
include/drm/drm_modeset_helper_vtables.h | 48 +++-
3 files changed, 21 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane_helper.c
b/drivers/gpu/drm/drm_plane_helper.c
index c91e454eba097942..be45bdb58d849653 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -51,14 +51,6 @@
* planes, and newly merged drivers must not rely upon these transitional
* helpers.
*
- * The second part also implements transitional helpers which allow drivers to
- * gradually switch to the atomic helper infrastructure for plane updates. Once
- * that switch is complete drivers shouldn't use these any longer, instead
using
- * the proper legacy implementations for update and disable plane hooks
provided
- * by the atomic helpers.
- *
- * Again drivers are strongly urged to switch to the new interfaces.
- *
* The plane helpers share the function table structures with other helpers,
* specifically also the atomic helpers. See drm_plane_helper_funcs for
* the details.
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 8e1cbc75143ef216..8b48a1974da3143c 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -77,11 +77,6 @@ struct drm_plane_helper_funcs;
* intended to indicate whether a full modeset is needed, rather than strictly
* describing what has changed in a commit. See also:
* drm_atomic_crtc_needs_modeset()
- *
- * WARNING: Transitional helpers (like drm_helper_crtc_mode_set() or
- * drm_helper_crtc_mode_set_base()) do not maintain many of the derived control
- * state like @plane_mask so drivers not converted over to atomic helpers
should
- * not rely on these being accurate!
*/
struct drm_crtc_state {
/** @crtc: backpointer to the CRTC */
diff --git a/include/drm/drm_modeset_helper_vtables.h
b/include/drm/drm_modeset_helper_vtables.h
index 965faf082a6d1acb..e3c3ac615909474b 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -59,8 +59,8 @@ enum mode_set_atomic {
/**
* struct drm_crtc_helper_funcs - helper operations for CRTCs
*
- * These hooks are used by the legacy CRTC helpers, the transitional plane
- * helpers and the new atomic modesetting helpers.
+ * These hooks are used by the legacy CRTC helpers and the new atomic
+ * modesetting helpers.
*/
struct drm_crtc_helper_funcs {
/**
@@ -216,9 +216,7 @@ struct drm_crtc_helper_funcs {
*
* This callback is used to update the display mode of a CRTC without
* changing anything of the primary plane configuration. This fits the
-* requirement of atomic and hence is used by the atomic helpers. It is
-* also used by the transitional plane helpers to implement a
-* @mode_set hook in drm_helper_crtc_mode_set().
+* requirement of atomic and hence is used by the atomic helpers.
*
* Note that the display pipe is completely off when this function is
* called. Atomic drivers which need hardware to be running before they
@@ -333,8 +331,8 @@ struct drm_crtc_helper_funcs {
* all updated. Again the recommendation is to just call check helpers
* until a maximal configuration is reached.
*
-* This callback is used by the atomic modeset helpers and by the
-* transitional plane helpers, but it is optional.
+* This callback is used by the atomic modeset helpers, but it is
+* optional.
*
* NOTE:
*
@@ -373,8 +371,8 @@ struct drm_crtc_helper_funcs {
* has picked. See drm_atomic_helper_commit_planes() for a discussion of
* the tradeoffs and variants of plane commit helpers.
*
-* This callback is used by the atomic modeset helpers and by the
-* transitional plane helpers, but it is optional.
+* This callback is used by the atomic modeset helpers, but it is
+* optional.
*/
void (*atomic_begin)(struct drm_crtc *crtc,
struct drm_atomic_state *state);
@@ -397,8 +395,8 @@ struct drm_crtc_helper_funcs {
* has picked. See drm_atomic_helper_commit_planes() for a discussion of
* the tradeoffs and variants of plane commit helpers.
*
-* This callback is used by the atomic modeset helpers and by the
-* transitional plane helpers, but it is optional.
+* This callback is used by the atomic modeset helpers, but it is
+* optional.
*/
void (*atomic_flush)(struct
[PATCH 3/3] drm: Fix references to drm_plane_helper_check_state()
As of commit a01cb8ba3f628293 ("drm: Move drm_plane_helper_check_state()
into drm_atomic_helper.c"), drm_plane_helper_check_state() no longer
exists, but is part of drm_atomic_helper_check_plane_state().
Signed-off-by: Geert Uytterhoeven
---
Interestingly, all these comments appeared only after the commit that
removed the function...
This is against next-20230602, which does not have the
drivers/gpu/drm/{ => renesas}/rcar-du move yet.
Biju: you're adding a new copy in
drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
---
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 3 ++-
drivers/gpu/drm/tidss/tidss_plane.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index d759e019218181ce..e445fac8e0b46c21 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -600,7 +600,8 @@ int __rcar_du_plane_atomic_check(struct drm_plane *plane,
if (!state->crtc) {
/*
* The visible field is not reset by the DRM core but only
-* updated by drm_plane_helper_check_state(), set it manually.
+* updated by drm_atomic_helper_check_plane_state(), set it
+* manually.
*/
state->visible = false;
*format = NULL;
diff --git a/drivers/gpu/drm/tidss/tidss_plane.c
b/drivers/gpu/drm/tidss/tidss_plane.c
index 6bdd6e4a955ab3cc..e1c0ef0c3894c855 100644
--- a/drivers/gpu/drm/tidss/tidss_plane.c
+++ b/drivers/gpu/drm/tidss/tidss_plane.c
@@ -38,7 +38,8 @@ static int tidss_plane_atomic_check(struct drm_plane *plane,
if (!new_plane_state->crtc) {
/*
* The visible field is not reset by the DRM core but only
-* updated by drm_plane_helper_check_state(), set it manually.
+* updated by drm_atomic_helper_check_plane_state(), set it
+* manually.
*/
new_plane_state->visible = false;
return 0;
--
2.34.1
[PATCH 0/3] drm: Atomic modesetting doc and comment improvements
Hi all,
This patch series contains various improvements to the documentation and
comments related to atomic modesetting. Hopefully, it will ease the job
of DRM novice who want to tackle the daunting task of converting a
legacy DRM driver to atomic modesetting.
Thanks for your comments!
Geert Uytterhoeven (3):
drm/todo: Add atomic modesetting references
drm: Remove references to removed transitional helpers
drm: Fix references to drm_plane_helper_check_state()
Documentation/gpu/todo.rst | 9 -
drivers/gpu/drm/drm_plane_helper.c | 8
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 3 +-
drivers/gpu/drm/tidss/tidss_plane.c | 3 +-
include/drm/drm_crtc.h | 5 ---
include/drm/drm_modeset_helper_vtables.h | 48 +++-
6 files changed, 32 insertions(+), 44 deletions(-)
--
2.34.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3 1/3] drm/msm/adreno: Add Adreno A690 support
On 1.06.2023 20:30, Akhil P Oommen wrote:
> On Wed, May 31, 2023 at 10:30:09PM +0200, Konrad Dybcio wrote:
>>
>>
>>
>> On 31.05.2023 05:09, Bjorn Andersson wrote:
>>> From: Bjorn Andersson
>>>
>>> Introduce support for the Adreno A690, found in Qualcomm SC8280XP.
>>>
>>> Tested-by: Steev Klimaszewski
>>> Reviewed-by: Konrad Dybcio
>>> Signed-off-by: Bjorn Andersson
>>> Signed-off-by: Bjorn Andersson
>>> ---
>> Couple of additional nits that you may or may not incorporate:
>>
>> [...]
>>
>>> + {REG_A6XX_RBBM_CLOCK_HYST_SP0, 0xF3CF},
>> It would be cool if we could stop adding uppercase hex outside preprocessor
>> defines..
>>
>>
>> [...]
>>> + A6XX_PROTECT_RDONLY(0x0fc00, 0x01fff),
>>> + A6XX_PROTECT_NORDWR(0x11c00, 0x0), /*note: infiite range */
>> typo
>>
>>
>>
>> -- Questions to Rob that don't really concern this patch --
>>
>>> +static void a690_build_bw_table(struct a6xx_hfi_msg_bw_table *msg)
>> Rob, I'll be looking into reworking these into dynamic tables.. would you
>> be okay with two more additions (A730, A740) on top of this before I do that?
>> The number of these funcs has risen quite a bit and we're abusing the fact
>> that so far there's a 1-1 mapping of SoC-Adreno (at the current state of
>> mainline, not in general)..
>
> +1. But please leave a618 and 7c3 as it is.
OK I'll note that
Konrad
>
> -Akhil
>
>>
>>> +{
>>> + /*
>>> +* Send a single "off" entry just to get things running
>>> +* TODO: bus scaling
>>> +*/
>> Also something I'll be looking into in the near future..
>>
>>> @@ -531,6 +562,8 @@ static int a6xx_hfi_send_bw_table(struct a6xx_gmu *gmu)
>>> adreno_7c3_build_bw_table();
>>> else if (adreno_is_a660(adreno_gpu))
>>> a660_build_bw_table();
>>> + else if (adreno_is_a690(adreno_gpu))
>>> + a690_build_bw_table();
>>> else
>>> a6xx_build_bw_table();
>> I think changing the is_adreno_... to switch statements with a gpu_model
>> var would make it easier to read.. Should I also rework that?
>>
>> Konrad
>>
>>>
>>> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
>>> b/drivers/gpu/drm/msm/adreno/adreno_device.c
>>> index 8cff86e9d35c..e5a865024e94 100644
>>> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
>>> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
>>> @@ -355,6 +355,20 @@ static const struct adreno_info gpulist[] = {
>>> .init = a6xx_gpu_init,
>>> .zapfw = "a640_zap.mdt",
>>> .hwcg = a640_hwcg,
>>> + }, {
>>> + .rev = ADRENO_REV(6, 9, 0, ANY_ID),
>>> + .revn = 690,
>>> + .name = "A690",
>>> + .fw = {
>>> + [ADRENO_FW_SQE] = "a660_sqe.fw",
>>> + [ADRENO_FW_GMU] = "a690_gmu.bin",
>>> + },
>>> + .gmem = SZ_4M,
>>> + .inactive_period = DRM_MSM_INACTIVE_PERIOD,
>>> + .init = a6xx_gpu_init,
>>> + .zapfw = "a690_zap.mdt",
>>> + .hwcg = a690_hwcg,
>>> + .address_space_size = SZ_16G,
>>> },
>>> };
>>>
>>> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
>>> b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
>>> index f62612a5c70f..ac9c429ca07b 100644
>>> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
>>> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
>>> @@ -55,7 +55,7 @@ struct adreno_reglist {
>>> u32 value;
>>> };
>>>
>>> -extern const struct adreno_reglist a615_hwcg[], a630_hwcg[], a640_hwcg[],
>>> a650_hwcg[], a660_hwcg[];
>>> +extern const struct adreno_reglist a615_hwcg[], a630_hwcg[], a640_hwcg[],
>>> a650_hwcg[], a660_hwcg[], a690_hwcg[];
>>>
>>> struct adreno_info {
>>> struct adreno_rev rev;
>>> @@ -272,6 +272,11 @@ static inline int adreno_is_a660(struct adreno_gpu
>>> *gpu)
>>> return gpu->revn == 660;
>>> }
>>>
>>> +static inline int adreno_is_a690(struct adreno_gpu *gpu)
>>> +{
>>> + return gpu->revn == 690;
>>> +};
>>> +
>>> /* check for a615, a616, a618, a619 or any derivatives */
>>> static inline int adreno_is_a615_family(struct adreno_gpu *gpu)
>>> {
>>> @@ -280,13 +285,13 @@ static inline int adreno_is_a615_family(struct
>>> adreno_gpu *gpu)
>>>
>>> static inline int adreno_is_a660_family(struct adreno_gpu *gpu)
>>> {
>>> - return adreno_is_a660(gpu) || adreno_is_7c3(gpu);
>>> + return adreno_is_a660(gpu) || adreno_is_a690(gpu) || adreno_is_7c3(gpu);
>>> }
>>>
>>> /* check for a650, a660, or any derivatives */
>>> static inline int adreno_is_a650_family(struct adreno_gpu *gpu)
>>> {
>>> - return gpu->revn == 650 || gpu->revn == 620 ||
>>> adreno_is_a660_family(gpu);
>>> + return gpu->revn == 650 || gpu->revn == 620 ||
>>> adreno_is_a660_family(gpu);
>>> }
>>>
>>> u64 adreno_private_address_space_size(struct msm_gpu *gpu);
Re: [PATCH v5 08/12] drm/msm/dpu: Add SM6375 support
On 1.06.2023 16:56, Marijn Suijten wrote:
> On 2023-05-23 09:46:19, Konrad Dybcio wrote:
>> Add basic SM6375 support to the DPU1 driver to enable display output.
>
> Nit: The SM6350 commit doesn't use the word "basic" here: what does it
> mean? Is this addition not complete (because it seems so)?
Well the 6350 commit dates back to 2021 and we didn't have INTF_TE or
DSC back then, so it's possible I had that in mind..
Konrad
>
>> Reviewed-by: Dmitry Baryshkov
>> Signed-off-by: Konrad Dybcio
>> ---
>> .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h | 139
>> +
>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 1 +
>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 +
>> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 1 +
>> 4 files changed, 142 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h
>> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h
>> new file mode 100644
>> index ..924f2526c06a
>> --- /dev/null
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h
>> @@ -0,0 +1,139 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * Copyright (c) 2022. Qualcomm Innovation Center, Inc. All rights reserved.
>> + * Copyright (c) 2015-2018, 2020 The Linux Foundation. All rights reserved.
>> + * Copyright (c) 2023, Linaro Limited
>> + */
>> +
>> +#ifndef _DPU_6_9_SM6375_H
>> +#define _DPU_6_9_SM6375_H
>> +
>> +static const struct dpu_caps sm6375_dpu_caps = {
>> +.max_mixer_width = DEFAULT_DPU_LINE_WIDTH,
>> +.max_mixer_blendstages = 0x4,
>> +.qseed_type = DPU_SSPP_SCALER_QSEED4,
>> +.has_dim_layer = true,
>> +.has_idle_pc = true,
>> +.max_linewidth = 2160,
>> +.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
>> +};
>> +
>> +static const struct dpu_ubwc_cfg sm6375_ubwc_cfg = {
>> +.ubwc_version = DPU_HW_UBWC_VER_20,
>> +.ubwc_swizzle = 6,
>> +.highest_bank_bit = 1,
>> +};
>> +
>> +static const struct dpu_mdp_cfg sm6375_mdp[] = {
>> +{
>> +.name = "top_0", .id = MDP_TOP,
>> +.base = 0x0, .len = 0x494,
>> +.features = 0,
>> +.clk_ctrls[DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
>> +.clk_ctrls[DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8 },
>> +},
>> +};
>> +
>> +static const struct dpu_ctl_cfg sm6375_ctl[] = {
>> +{
>> +.name = "ctl_0", .id = CTL_0,
>> +.base = 0x1000, .len = 0x1dc,
>> +.features = BIT(DPU_CTL_ACTIVE_CFG),
>> +.intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
>> +},
>> +};
>> +
>> +static const struct dpu_sspp_cfg sm6375_sspp[] = {
>> +SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, 0x1f8, VIG_SC7180_MASK,
>> +sm6115_vig_sblk_0, 0, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0),
>> +SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, 0x1f8, DMA_SDM845_MASK,
>> +sdm845_dma_sblk_0, 1, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA0),
>> +};
>> +
>> +static const struct dpu_lm_cfg sm6375_lm[] = {
>> +LM_BLK("lm_0", LM_0, 0x44000, MIXER_QCM2290_MASK,
>> +_lm_sblk, PINGPONG_0, 0, DSPP_0),
>> +};
>> +
>> +static const struct dpu_dspp_cfg sm6375_dspp[] = {
>> +DSPP_BLK("dspp_0", DSPP_0, 0x54000, DSPP_SC7180_MASK,
>> +_dspp_sblk),
>> +};
>> +
>> +static const struct dpu_pingpong_cfg sm6375_pp[] = {
>> +PP_BLK("pingpong_0", PINGPONG_0, 0x7, PINGPONG_SM8150_MASK, 0,
>> sdm845_pp_sblk,
>> +DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
>> +-1),
>> +};
>> +
>> +static const struct dpu_dsc_cfg sm6375_dsc[] = {
>> +DSC_BLK("dsc_0", DSC_0, 0x8, BIT(DPU_DSC_OUTPUT_CTRL)),
>> +};
>> +
>> +static const struct dpu_intf_cfg sm6375_intf[] = {
>> +INTF_BLK("intf_0", INTF_0, 0x0, 0x280, INTF_NONE, 0, 0, 0, 0, 0),
>> +INTF_BLK_DSI_TE("intf_1", INTF_1, 0x6a800, 0x2c0, INTF_DSI, 0, 24,
>> INTF_SC7280_MASK,
>
> Did you forget to set this back to SC7180? This will be enabling
> DPU_INTF_DATA_COMPRESS otherwise, which is a DPU 7.x feature.
>
> - Marijn
>
>> +DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 26),
>> +DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 27),
>> +DPU_IRQ_IDX(MDP_INTF1_TEAR_INTR, 2)),
>> +};
>> +
>> +static const struct dpu_perf_cfg sm6375_perf_data = {
>> +.max_bw_low = 520,
>> +.max_bw_high = 620,
>> +.min_core_ib = 250,
>> +.min_llcc_ib = 0, /* No LLCC on this SoC */
>> +.min_dram_ib = 160,
>> +.min_prefill_lines = 24,
>> +/* TODO: confirm danger_lut_tbl */
>> +.danger_lut_tbl = {0x, 0x, 0x0},
>> +.safe_lut_tbl = {0xfe00, 0xfe00, 0x},
>> +.qos_lut_tbl = {
>> +{.nentry = ARRAY_SIZE(sm6350_qos_linear_macrotile),
>> +.entries = sm6350_qos_linear_macrotile
>> +},
>> +{.nentry = ARRAY_SIZE(sm6350_qos_linear_macrotile),
>> +.entries = sm6350_qos_linear_macrotile
>> +},
>> +{.nentry = ARRAY_SIZE(sc7180_qos_nrt),
>> +.entries = sc7180_qos_nrt
Re: [PATCH 2/2] drm: lcdif: force modeset when FB format changes
On Thu, Jun 1, 2023 at 2:45 AM Lucas Stach wrote: > > Force a modeset if the new FB has a different format than the > currently active one. While it might be possible to change between > compatible formats without a full modeset as the format control is > also supposed to be double buffered, the colorspace conversion is > not, so when the CSC changes we need a modeset. > > For now just always force a modeset when the FB format changes to > properly reconfigure all parts of the device for the new format. > > Signed-off-by: Lucas Stach > --- > drivers/gpu/drm/mxsfb/lcdif_kms.c | 26 -- > 1 file changed, 20 insertions(+), 6 deletions(-) Reviewed-by: Liu Ying
[PATCH 2/9] riscv: dts: starfive: jh7110: add dc controller node
Add the dc controller and hdmi node for the Starfive JH7110 SoC.
Signed-off-by: Keith Zhao
---
.../jh7110-starfive-visionfive-2.dtsi | 87 +++
arch/riscv/boot/dts/starfive/jh7110.dtsi | 46 ++
2 files changed, 133 insertions(+)
diff --git a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
index 1155b97b593d..8dc6c8a15c59 100644
--- a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
@@ -31,6 +31,21 @@ memory@4000 {
reg = <0x0 0x4000 0x1 0x0>;
};
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ linux,cma {
+ compatible = "shared-dma-pool";
+ reusable;
+ size = <0x0 0x2000>;
+ alignment = <0x0 0x1000>;
+ alloc-ranges = <0x0 0x8000 0x0 0x2000>;
+ linux,cma-default;
+ };
+ };
+
gpio-restart {
compatible = "gpio-restart";
gpios = < 35 GPIO_ACTIVE_HIGH>;
@@ -214,6 +229,41 @@ GPOEN_DISABLE,
slew-rate = <0>;
};
};
+
+ hdmi_pins: hdmi-0 {
+ hdmi-scl-pins {
+ pinmux = ;
+ input-enable;
+ bias-pull-up;
+ };
+
+ hdmi-sda-pins {
+ pinmux = ;
+ input-enable;
+ bias-pull-up;
+ };
+
+ hdmi-cec-pins {
+ pinmux = ;
+ input-enable;
+ bias-pull-up;
+ };
+
+ hdmi-hpd-pins {
+ pinmux = ;
+ input-enable;
+ bias-disable; /* external pull-up */
+ };
+ };
+
};
{
@@ -221,3 +271,40 @@ {
pinctrl-0 = <_pins>;
status = "okay";
};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ hdmi_in: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hdmi_input: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <_out_dpi0>;
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ dc_out: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ dc_out_dpi0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <_input>;
+ };
+
+ };
+};
diff --git a/arch/riscv/boot/dts/starfive/jh7110.dtsi
b/arch/riscv/boot/dts/starfive/jh7110.dtsi
index 9acb5fb1716d..66be6e65a066 100644
--- a/arch/riscv/boot/dts/starfive/jh7110.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7110.dtsi
@@ -249,6 +249,11 @@ tdm_ext: tdm-ext-clock {
#clock-cells = <0>;
};
+ display: display-subsystem {
+ compatible = "verisilicon,display-subsystem";
+ ports = <_out>;
+ };
+
soc {
compatible = "simple-bus";
interrupt-parent = <>;
@@ -570,5 +575,46 @@ voutcrg: clock-controller@295c {
#reset-cells = <1>;
power-domains = < JH7110_PD_VOUT>;
};
+
+ dc8200: dc8200@2940 {
+ compatible = "verisilicon,dc8200";
+ reg = <0x0 0x2940 0x0 0x100>,
+ <0x0 0x29400800 0x0 0x2000>,
+ <0x0 0x295B 0x0 0x90>;
+ interrupts = <95>;
+ clocks = < JH7110_SYSCLK_NOC_BUS_DISP_AXI>,
+ < JH7110_VOUTCLK_DC8200_PIX0>,
+ < JH7110_VOUTCLK_DC8200_PIX1>,
+ < JH7110_VOUTCLK_DC8200_AXI>,
+ < JH7110_VOUTCLK_DC8200_CORE>,
+ < JH7110_VOUTCLK_DC8200_AHB>,
+ <_pixelclk>,
+ < JH7110_VOUTCLK_DC8200_PIX>;
+ clock-names = "clk_vout_noc_disp",
+ "clk_vout_pix0","clk_vout_pix1",
+ "clk_vout_axi","clk_vout_core",
+ "clk_vout_vout_ahb","hdmitx0_pixel",
+ "clk_vout_dc8200";
+ resets = < JH7110_VOUTRST_DC8200_AXI>,
+< JH7110_VOUTRST_DC8200_AHB>,
+< JH7110_VOUTRST_DC8200_CORE>;
+
[PATCH 8/9] drm/verisilicon: Add verisilicon dc controller driver
Add DC8200 display controller driver for StarFive JH7110 SoC.
Signed-off-by: Keith Zhao
---
drivers/gpu/drm/verisilicon/Makefile |4 +-
drivers/gpu/drm/verisilicon/vs_dc.c| 1040
drivers/gpu/drm/verisilicon/vs_dc.h| 62 +
drivers/gpu/drm/verisilicon/vs_dc_hw.c | 2008
drivers/gpu/drm/verisilicon/vs_dc_hw.h | 496 ++
drivers/gpu/drm/verisilicon/vs_drv.c |2 +
6 files changed, 3611 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.c
create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.h
create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.c
create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.h
diff --git a/drivers/gpu/drm/verisilicon/Makefile
b/drivers/gpu/drm/verisilicon/Makefile
index d96ad9399fc7..0ed25b5e3062 100644
--- a/drivers/gpu/drm/verisilicon/Makefile
+++ b/drivers/gpu/drm/verisilicon/Makefile
@@ -1,7 +1,9 @@
# SPDX-License-Identifier: GPL-2.0
-vs_drm-objs := vs_drv.o \
+vs_drm-objs := vs_dc_hw.o \
+ vs_dc.o \
vs_crtc.o \
+ vs_drv.o \
vs_fb.o \
vs_gem.o \
vs_plane.o
diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c
b/drivers/gpu/drm/verisilicon/vs_dc.c
new file mode 100644
index ..a512aaa57f2f
--- /dev/null
+++ b/drivers/gpu/drm/verisilicon/vs_dc.c
@@ -0,0 +1,1040 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2023 VeriSilicon Holdings Co., Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "vs_crtc.h"
+#include "vs_dc_hw.h"
+#include "vs_dc.h"
+#include "vs_drv.h"
+#include "vs_type.h"
+
+static const char * const vout_clocks[] = {
+ "clk_vout_noc_disp",
+ "clk_vout_pix0",
+ "clk_vout_pix1",
+ "clk_vout_axi",
+ "clk_vout_core",
+ "clk_vout_vout_ahb",
+ "hdmitx0_pixel",
+ "clk_vout_dc8200",
+
+};
+
+static const char * const vout_resets[] = {
+ "rst_vout_axi",
+ "rst_vout_ahb",
+ "rst_vout_core",
+};
+
+static inline void update_format(u32 format, u64 mod, struct dc_hw_fb *fb)
+{
+ u8 f = FORMAT_A8R8G8B8;
+
+ switch (format) {
+ case DRM_FORMAT_XRGB:
+ case DRM_FORMAT_RGBX:
+ case DRM_FORMAT_XBGR:
+ case DRM_FORMAT_BGRX:
+ f = FORMAT_X4R4G4B4;
+ break;
+ case DRM_FORMAT_ARGB:
+ case DRM_FORMAT_RGBA:
+ case DRM_FORMAT_ABGR:
+ case DRM_FORMAT_BGRA:
+ f = FORMAT_A4R4G4B4;
+ break;
+ case DRM_FORMAT_XRGB1555:
+ case DRM_FORMAT_RGBX5551:
+ case DRM_FORMAT_XBGR1555:
+ case DRM_FORMAT_BGRX5551:
+ f = FORMAT_X1R5G5B5;
+ break;
+ case DRM_FORMAT_ARGB1555:
+ case DRM_FORMAT_RGBA5551:
+ case DRM_FORMAT_ABGR1555:
+ case DRM_FORMAT_BGRA5551:
+ f = FORMAT_A1R5G5B5;
+ break;
+ case DRM_FORMAT_RGB565:
+ case DRM_FORMAT_BGR565:
+ f = FORMAT_R5G6B5;
+ break;
+ case DRM_FORMAT_XRGB:
+ case DRM_FORMAT_RGBX:
+ case DRM_FORMAT_XBGR:
+ case DRM_FORMAT_BGRX:
+ f = FORMAT_X8R8G8B8;
+ break;
+ case DRM_FORMAT_ARGB:
+ case DRM_FORMAT_RGBA:
+ case DRM_FORMAT_ABGR:
+ case DRM_FORMAT_BGRA:
+ f = FORMAT_A8R8G8B8;
+ break;
+ case DRM_FORMAT_YUYV:
+ case DRM_FORMAT_YVYU:
+ f = FORMAT_YUY2;
+ break;
+ case DRM_FORMAT_UYVY:
+ case DRM_FORMAT_VYUY:
+ f = FORMAT_UYVY;
+ break;
+ case DRM_FORMAT_YUV420:
+ case DRM_FORMAT_YVU420:
+ f = FORMAT_YV12;
+ break;
+ case DRM_FORMAT_NV21:
+ f = FORMAT_NV12;
+ break;
+ case DRM_FORMAT_NV16:
+ case DRM_FORMAT_NV61:
+ f = FORMAT_NV16;
+ break;
+ case DRM_FORMAT_P010:
+ f = FORMAT_P010;
+ break;
+ case DRM_FORMAT_ARGB2101010:
+ case DRM_FORMAT_RGBA1010102:
+ case DRM_FORMAT_ABGR2101010:
+ case DRM_FORMAT_BGRA1010102:
+ f = FORMAT_A2R10G10B10;
+ break;
+ case DRM_FORMAT_NV12:
+ if (fourcc_mod_vs_get_type(mod) ==
+ DRM_FORMAT_MOD_VS_TYPE_CUSTOM_10BIT)
+ f = FORMAT_NV12_10BIT;
+ else
+ f = FORMAT_NV12;
+ break;
+ case DRM_FORMAT_YUV444:
+ if (fourcc_mod_vs_get_type(mod) ==
+ DRM_FORMAT_MOD_VS_TYPE_CUSTOM_10BIT)
+ f = FORMAT_YUV444_10BIT;
+ else
+
[PATCH 9/9] drm/verisilicon: Add starfive hdmi driver
Add HDMI dirver for StarFive SoC JH7110.
Signed-off-by: Keith Zhao
---
drivers/gpu/drm/verisilicon/Kconfig | 11 +
drivers/gpu/drm/verisilicon/Makefile| 1 +
drivers/gpu/drm/verisilicon/starfive_hdmi.c | 928
drivers/gpu/drm/verisilicon/starfive_hdmi.h | 296 +++
drivers/gpu/drm/verisilicon/vs_drv.c| 6 +
drivers/gpu/drm/verisilicon/vs_drv.h| 4 +
6 files changed, 1246 insertions(+)
create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.c
create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.h
diff --git a/drivers/gpu/drm/verisilicon/Kconfig
b/drivers/gpu/drm/verisilicon/Kconfig
index 89d12185f73b..35e85ac41b10 100644
--- a/drivers/gpu/drm/verisilicon/Kconfig
+++ b/drivers/gpu/drm/verisilicon/Kconfig
@@ -11,3 +11,14 @@ config DRM_VERISILICON
This driver provides VeriSilicon kernel mode
setting and buffer management. It does not
provide 2D or 3D acceleration.
+
+config STARFIVE_HDMI
+ bool "Starfive specific extensions HDMI"
+ help
+ This selects support for StarFive SoC specific extensions
+ for the Innosilicon HDMI driver. If you want to enable
+ HDMI on JH7110 based SoC, you should select this option.
+
+ To compile this driver as a module, choose M here.
+
+
diff --git a/drivers/gpu/drm/verisilicon/Makefile
b/drivers/gpu/drm/verisilicon/Makefile
index 0ed25b5e3062..ebe2c94f529a 100644
--- a/drivers/gpu/drm/verisilicon/Makefile
+++ b/drivers/gpu/drm/verisilicon/Makefile
@@ -8,5 +8,6 @@ vs_drm-objs := vs_dc_hw.o \
vs_gem.o \
vs_plane.o
+vs_drm-$(CONFIG_STARFIVE_HDMI) += starfive_hdmi.o
obj-$(CONFIG_DRM_VERISILICON) += vs_drm.o
diff --git a/drivers/gpu/drm/verisilicon/starfive_hdmi.c
b/drivers/gpu/drm/verisilicon/starfive_hdmi.c
new file mode 100644
index ..128ecca03309
--- /dev/null
+++ b/drivers/gpu/drm/verisilicon/starfive_hdmi.c
@@ -0,0 +1,928 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023 StarFive Technology Co., Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "starfive_hdmi.h"
+#include "vs_drv.h"
+
+static struct starfive_hdmi *encoder_to_hdmi(struct drm_encoder *encoder)
+{
+ return container_of(encoder, struct starfive_hdmi, encoder);
+}
+
+static struct starfive_hdmi *connector_to_hdmi(struct drm_connector *connector)
+{
+ return container_of(connector, struct starfive_hdmi, connector);
+}
+
+struct starfive_hdmi_i2c {
+ struct i2c_adapter adap;
+
+ u8 ddc_addr;
+ u8 segment_addr;
+ /* protects the edid data when use i2c cmd to read edid */
+ struct mutex lock;
+ struct completion cmp;
+};
+
+static const struct pre_pll_config pre_pll_cfg_table[] = {
+ { 25175000, 25175000, 1, 100, 2, 3, 3, 12, 3, 3, 4, 0, 0xf5},
+ { 2520, 2520, 1, 100, 2, 3, 3, 12, 3, 3, 4, 0, 0},
+ { 2700, 2700, 1, 90, 3, 2, 2, 10, 3, 3, 4, 0, 0},
+ { 27027000, 27027000, 1, 90, 3, 2, 2, 10, 3, 3, 4, 0, 0x170a3d},
+ { 2832, 2832, 1, 28, 2, 1, 1, 3, 0, 3, 4, 0, 0x51eb85},
+ { 3024, 3024, 1, 30, 2, 1, 1, 3, 0, 3, 4, 0, 0x3d70a3},
+ { 3150, 3150, 1, 31, 2, 1, 1, 3, 0, 3, 4, 0, 0x7f},
+ { 3375, 3375, 1, 33, 2, 1, 1, 3, 0, 3, 4, 0, 0xcf},
+ { 3600, 3600, 1, 36, 2, 1, 1, 3, 0, 3, 4, 0, 0},
+ { 4000, 4000, 1, 80, 2, 2, 2, 12, 2, 2, 2, 0, 0},
+ { 4697, 4697, 1, 46, 2, 1, 1, 3, 0, 3, 4, 0, 0xf851eb},
+ { 4950, 4950, 1, 49, 2, 1, 1, 3, 0, 3, 4, 0, 0x7f},
+ { 4900, 4900, 1, 49, 2, 1, 1, 3, 0, 3, 4, 0, 0},
+ { 5000, 5000, 1, 50, 2, 1, 1, 3, 0, 3, 4, 0, 0},
+ { 5400, 5400, 1, 54, 2, 1, 1, 3, 0, 3, 4, 0, 0},
+ { 54054000, 54054000, 1, 54, 2, 1, 1, 3, 0, 3, 4, 0, 0x0dd2f1},
+ { 57284000, 57284000, 1, 57, 2, 1, 1, 3, 0, 3, 4, 0, 0x48b439},
+ { 5823, 5823, 1, 58, 2, 1, 1, 3, 0, 3, 4, 0, 0x3ae147},
+ { 59341000, 59341000, 1, 59, 2, 1, 1, 3, 0, 3, 4, 0, 0x574bc6},
+ { 5940, 5940, 1, 99, 3, 1, 1, 1, 3, 3, 4, 0, 0},
+ { 6500, 6500, 1, 130, 2, 2, 2, 12, 0, 2, 2, 0, 0},
+ { 6825, 6825, 1, 68, 2, 1, 1, 3, 0, 3, 4, 0, 0x3f},
+ { 7100, 7100, 1, 71, 2, 1, 1, 3, 0, 3, 4, 0, 0},
+ { 74176000, 74176000, 1, 98, 1, 2, 2, 1, 2, 3, 4, 0, 0xe6ae6b},
+ { 7425, 7425, 1, 99, 1, 2, 2, 1, 2, 3, 4, 0, 0},
+ { 7500, 7500, 1, 75, 2, 1, 1, 3, 0, 3, 4, 0, 0},
+ { 7875, 7875, 1, 78, 2, 1, 1, 3, 0, 3, 4, 0, 0xcf},
+ { 7950, 7950, 1, 79, 2, 1, 1, 3, 0, 3, 4, 0, 0x7f},
[PATCH 5/9] drm/verisilicon: Add mode config funcs
Add mode setting functions for JH7110 SoC.
Signed-off-by: Keith Zhao
---
drivers/gpu/drm/verisilicon/Makefile | 1 +
drivers/gpu/drm/verisilicon/vs_drv.c | 3 +
drivers/gpu/drm/verisilicon/vs_fb.c | 181 +++
drivers/gpu/drm/verisilicon/vs_fb.h | 15 +++
4 files changed, 200 insertions(+)
create mode 100644 drivers/gpu/drm/verisilicon/vs_fb.c
create mode 100644 drivers/gpu/drm/verisilicon/vs_fb.h
diff --git a/drivers/gpu/drm/verisilicon/Makefile
b/drivers/gpu/drm/verisilicon/Makefile
index 30360e370e47..38254dc5d98d 100644
--- a/drivers/gpu/drm/verisilicon/Makefile
+++ b/drivers/gpu/drm/verisilicon/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
vs_drm-objs := vs_drv.o \
+ vs_fb.o \
vs_gem.o
obj-$(CONFIG_DRM_VERISILICON) += vs_drm.o
diff --git a/drivers/gpu/drm/verisilicon/vs_drv.c
b/drivers/gpu/drm/verisilicon/vs_drv.c
index e0a2fc43b55f..d84aacd751bc 100644
--- a/drivers/gpu/drm/verisilicon/vs_drv.c
+++ b/drivers/gpu/drm/verisilicon/vs_drv.c
@@ -30,6 +30,7 @@
#include
#include "vs_drv.h"
+#include "vs_fb.h"
#include "vs_gem.h"
#define DRV_NAME "starfive"
@@ -118,6 +119,8 @@ static int vs_drm_bind(struct device *dev)
if (ret)
goto err_mode;
+ vs_mode_config_init(drm_dev);
+
ret = drm_vblank_init(drm_dev, drm_dev->mode_config.num_crtc);
if (ret)
goto err_bind;
diff --git a/drivers/gpu/drm/verisilicon/vs_fb.c
b/drivers/gpu/drm/verisilicon/vs_fb.c
new file mode 100644
index ..3e85f7365084
--- /dev/null
+++ b/drivers/gpu/drm/verisilicon/vs_fb.c
@@ -0,0 +1,181 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2023 VeriSilicon Holdings Co., Ltd.
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "vs_fb.h"
+#include "vs_gem.h"
+
+#define fourcc_mod_vs_get_type(val) \
+ (((val) & DRM_FORMAT_MOD_VS_TYPE_MASK) >> 54)
+
+static struct drm_framebuffer_funcs vs_fb_funcs = {
+ .create_handle = drm_gem_fb_create_handle,
+ .destroy= drm_gem_fb_destroy,
+ .dirty = drm_atomic_helper_dirtyfb,
+};
+
+static struct drm_framebuffer *
+vs_fb_alloc(struct drm_device *dev, const struct drm_mode_fb_cmd2 *mode_cmd,
+ struct vs_gem_object **obj, unsigned int num_planes)
+{
+ struct drm_framebuffer *fb;
+ int ret, i;
+
+ fb = kzalloc(sizeof(*fb), GFP_KERNEL);
+ if (!fb)
+ return ERR_PTR(-ENOMEM);
+
+ drm_helper_mode_fill_fb_struct(dev, fb, mode_cmd);
+
+ for (i = 0; i < num_planes; i++)
+ fb->obj[i] = [i]->base;
+
+ ret = drm_framebuffer_init(dev, fb, _fb_funcs);
+ if (ret) {
+ dev_err(dev->dev, "Failed to initialize framebuffer: %d\n",
+ ret);
+ kfree(fb);
+ return ERR_PTR(ret);
+ }
+
+ return fb;
+}
+
+static struct drm_framebuffer *vs_fb_create(struct drm_device *dev,
+ struct drm_file *file_priv,
+ const struct drm_mode_fb_cmd2
*mode_cmd)
+{
+ struct drm_framebuffer *fb;
+ const struct drm_format_info *info;
+ struct vs_gem_object *objs[MAX_NUM_PLANES];
+ struct drm_gem_object *obj;
+ unsigned int height, size;
+ unsigned char i, num_planes;
+ int ret = 0;
+
+ info = drm_get_format_info(dev, mode_cmd);
+ if (!info)
+ return ERR_PTR(-EINVAL);
+
+ num_planes = info->num_planes;
+ if (num_planes > MAX_NUM_PLANES)
+ return ERR_PTR(-EINVAL);
+
+ for (i = 0; i < num_planes; i++) {
+ obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[i]);
+ if (!obj) {
+ dev_err(dev->dev, "Failed to lookup GEM object.\n");
+ ret = -ENXIO;
+ goto err;
+ }
+
+ height = drm_format_info_plane_height(info,
+ mode_cmd->height, i);
+
+ size = height * mode_cmd->pitches[i] + mode_cmd->offsets[i];
+
+ if (obj->size < size) {
+ drm_gem_object_put(obj);
+
+ ret = -EINVAL;
+ goto err;
+ }
+
+ objs[i] = to_vs_gem_object(obj);
+ }
+
+ fb = vs_fb_alloc(dev, mode_cmd, objs, i);
+ if (IS_ERR(fb)) {
+ ret = PTR_ERR(fb);
+ goto err;
+ }
+
+ return fb;
+
+err:
+ for (; i > 0; i--)
+ drm_gem_object_put([i - 1]->base);
+
+ return ERR_PTR(ret);
+}
+
+struct vs_gem_object *vs_fb_get_gem_obj(struct drm_framebuffer *fb,
+ unsigned char plane)
+{
+ if (plane > MAX_NUM_PLANES)
+ return NULL;
+
+
[PATCH 1/9] dt-bindings: display: Add yamls for JH7110 display subsystem
Add bindings for JH7110 display subsystem which
has a display controller verisilicon dc8200
and an HDMI interface.
Signed-off-by: Keith Zhao
---
.../display/verisilicon/starfive-hdmi.yaml| 93 +++
.../display/verisilicon/verisilicon-dc.yaml | 110 ++
.../display/verisilicon/verisilicon-drm.yaml | 42 +++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
MAINTAINERS | 7 ++
5 files changed, 254 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml
create mode 100644
Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml
create mode 100644
Documentation/devicetree/bindings/display/verisilicon/verisilicon-drm.yaml
diff --git
a/Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml
b/Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml
new file mode 100644
index ..c30b7954a355
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/verisilicon/starfive-hdmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive HDMI transmiter
+
+description:
+ The StarFive SoC uses the HDMI signal transmiter based on innosilicon IP
+ to generate HDMI signal from its input and transmit the signal to the screen.
+
+maintainers:
+ - Keith Zhao
+ - ShengYang Chen
+
+properties:
+ compatible:
+const: starfive,hdmi
+
+ reg:
+minItems: 1
+
+ interrupts:
+items:
+ - description: The HDMI hot plug detection interrupt.
+
+ clocks:
+items:
+ - description: System clock of HDMI module.
+ - description: Mclk clock of HDMI audio.
+ - description: Bclk clock of HDMI audio.
+ - description: Pixel clock generated by HDMI module.
+
+ clock-names:
+items:
+ - const: sysclk
+ - const: mclk
+ - const: bclk
+ - const: pclk
+
+ resets:
+items:
+ - description: Reset for HDMI module.
+
+ reset-names:
+items:
+ - const: hdmi_tx
+
+ '#sound-dai-cells':
+const: 0
+
+ port:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ Port node with one endpoint connected to a display connector node.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - '#sound-dai-cells'
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+hdmi: hdmi@2959 {
+ compatible = "starfive,hdmi";
+ reg = <0x2959 0x4000>;
+ interrupts = <99>;
+ clocks = < 17>,
+ < 15>,
+ < 16>,
+ <_pixelclk>;
+ clock-names = "sysclk", "mclk","bclk","pclk";
+ resets = < 9>;
+ reset-names = "hdmi_tx";
+ #sound-dai-cells = <0>;
+ hdmi_in: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hdmi_input: endpoint@0 {
+reg = <0>;
+remote-endpoint = <_out_dpi0>;
+ };
+ };
+};
diff --git
a/Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml
b/Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml
new file mode 100644
index ..1322502c4cde
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml
@@ -0,0 +1,110 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/verisilicon/verisilicon-dc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive display controller
+
+description:
+ The StarFive SoC uses the display controller based on Verisilicon IP
+ to transfer the image data from a video memory
+ buffer to an external LCD interface.
+
+maintainers:
+ - Keith Zhao
+ - ShengYang Chen
+
+properties:
+ compatible:
+const: verisilicon,dc8200
+
+ reg:
+maxItems: 3
+
+ interrupts:
+items:
+ - description: The interrupt will be generated when DC finish one frame
+
+ clocks:
+items:
+ - description: Clock for display system noc bus.
+ - description: Pixel clock for display channel 0.
+ - description: Pixel clock for display channel 1.
+ - description: Clock for axi interface of display controller.
+ - description: Core clock for display controller.
+ - description: Clock for ahb interface of display controller.
+ - description: External HDMI pixel clock.
+ - description: Parent clock for pixel clock
+
+ clock-names:
+items:
+ - const: clk_vout_noc_disp
+ - const: clk_vout_pix0
+ - const: clk_vout_pix1
+ - const: clk_vout_axi
+ - const: clk_vout_core
+ - const: clk_vout_vout_ahb
+ - const: hdmitx0_pixel
+ - const: clk_vout_dc8200
+
+ resets:
+items:
+
[PATCH 3/9] drm/verisilicon: Add basic drm driver
Add a basic platform driver of the DRM driver for JH7110 SoC.
Signed-off-by: Keith Zhao
---
MAINTAINERS | 2 +
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/verisilicon/Kconfig | 13 ++
drivers/gpu/drm/verisilicon/Makefile | 6 +
drivers/gpu/drm/verisilicon/vs_drv.c | 284 +++
drivers/gpu/drm/verisilicon/vs_drv.h | 48 +
include/uapi/drm/drm_fourcc.h| 83
include/uapi/drm/vs_drm.h| 50 +
9 files changed, 489 insertions(+)
create mode 100644 drivers/gpu/drm/verisilicon/Kconfig
create mode 100644 drivers/gpu/drm/verisilicon/Makefile
create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.c
create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.h
create mode 100644 include/uapi/drm/vs_drm.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 293aa13d484c..da5b6766a7bb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7055,6 +7055,8 @@ L:dri-devel@lists.freedesktop.org
S: Maintained
T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/verisilicon/
+F: drivers/gpu/drm/verisilicon/
+F: include/uapi/drm/vs_drm.h
DRM DRIVERS FOR VIVANTE GPU IP
M: Lucas Stach
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index ba3fb04bb691..f7e461fa4656 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -371,6 +371,8 @@ source "drivers/gpu/drm/solomon/Kconfig"
source "drivers/gpu/drm/sprd/Kconfig"
+source "drivers/gpu/drm/verisilicon/Kconfig"
+
config DRM_HYPERV
tristate "DRM Support for Hyper-V synthetic video device"
depends on DRM && PCI && MMU && HYPERV
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index a33257d2bc7f..e50622ee4e46 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -194,3 +194,4 @@ obj-y += gud/
obj-$(CONFIG_DRM_HYPERV) += hyperv/
obj-y += solomon/
obj-$(CONFIG_DRM_SPRD) += sprd/
+obj-$(CONFIG_DRM_VERISILICON) += verisilicon/
diff --git a/drivers/gpu/drm/verisilicon/Kconfig
b/drivers/gpu/drm/verisilicon/Kconfig
new file mode 100644
index ..89d12185f73b
--- /dev/null
+++ b/drivers/gpu/drm/verisilicon/Kconfig
@@ -0,0 +1,13 @@
+# SPDX-License-Identifier: GPL-2.0
+
+config DRM_VERISILICON
+ tristate "DRM Support for VeriSilicon"
+ depends on DRM
+ select DRM_KMS_HELPER
+ select CMA
+ select DMA_CMA
+ help
+ Choose this option if you have a VeriSilicon soc chipset.
+ This driver provides VeriSilicon kernel mode
+ setting and buffer management. It does not
+ provide 2D or 3D acceleration.
diff --git a/drivers/gpu/drm/verisilicon/Makefile
b/drivers/gpu/drm/verisilicon/Makefile
new file mode 100644
index ..64ce1b26546c
--- /dev/null
+++ b/drivers/gpu/drm/verisilicon/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0
+
+vs_drm-objs := vs_drv.o
+
+obj-$(CONFIG_DRM_VERISILICON) += vs_drm.o
+
diff --git a/drivers/gpu/drm/verisilicon/vs_drv.c
b/drivers/gpu/drm/verisilicon/vs_drv.c
new file mode 100644
index ..24d333598477
--- /dev/null
+++ b/drivers/gpu/drm/verisilicon/vs_drv.c
@@ -0,0 +1,284 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2023 VeriSilicon Holdings Co., Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "vs_drv.h"
+
+#define DRV_NAME "starfive"
+#define DRV_DESC "Starfive DRM driver"
+#define DRV_DATE "202305161"
+#define DRV_MAJOR 1
+#define DRV_MINOR 0
+
+static struct platform_driver vs_drm_platform_driver;
+
+static const struct file_operations fops = {
+ .owner = THIS_MODULE,
+ .open = drm_open,
+ .release= drm_release,
+ .unlocked_ioctl = drm_ioctl,
+ .compat_ioctl = drm_compat_ioctl,
+ .poll = drm_poll,
+ .read = drm_read,
+};
+
+static struct drm_driver vs_drm_driver = {
+ .driver_features= DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_GEM,
+ .lastclose = drm_fb_helper_lastclose,
+ .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+ .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+ .fops = ,
+ .name = DRV_NAME,
+ .desc = DRV_DESC,
+ .date = DRV_DATE,
+ .major = DRV_MAJOR,
+ .minor = DRV_MINOR,
+};
+
+void vs_drm_update_pitch_alignment(struct drm_device *drm_dev,
+ unsigned int alignment)
+{
+
[PATCH 0/9] Add DRM driver for StarFive SoC JH7110
Hi, This series is a DRM driver for StarFive SoC JH7110, which includes a display controller driver for Verisilicon DC8200 and an HMDI driver. We use GEM framework for buffer management and allocate memory by using DMA APIs. The JH7110 display subsystem includes a display controller Verisilicon DC8200 and an HDMI transmitter. The HDMI TX IP is designed for transmitting video and audio data from DC8200 to a display device. The HDMI TX IP consists of the digital controller and the physical layer. This series does not support HDMI audio driver. Keith Zhao (9): dt-bindings: display: Add yamls for JH7110 display subsystem riscv: dts: starfive: jh7110: add dc controller node drm/verisilicon: Add basic drm driver drm/verisilicon: Add gem driver for JH7110 SoC drm/verisilicon: Add mode config funcs drm/verisilicon: Add drm crtc funcs drm/verisilicon: Add drm plane funcs drm/verisilicon: Add verisilicon dc controller driver drm/verisilicon: Add starfive hdmi driver .../display/verisilicon/starfive-hdmi.yaml| 93 + .../display/verisilicon/verisilicon-dc.yaml | 110 + .../display/verisilicon/verisilicon-drm.yaml | 42 + .../devicetree/bindings/vendor-prefixes.yaml |2 + MAINTAINERS |9 + .../jh7110-starfive-visionfive-2.dtsi | 87 + arch/riscv/boot/dts/starfive/jh7110.dtsi | 46 + drivers/gpu/drm/Kconfig |2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/verisilicon/Kconfig | 24 + drivers/gpu/drm/verisilicon/Makefile | 13 + drivers/gpu/drm/verisilicon/starfive_hdmi.c | 928 drivers/gpu/drm/verisilicon/starfive_hdmi.h | 296 +++ drivers/gpu/drm/verisilicon/vs_crtc.c | 388 drivers/gpu/drm/verisilicon/vs_crtc.h | 74 + drivers/gpu/drm/verisilicon/vs_dc.c | 1040 + drivers/gpu/drm/verisilicon/vs_dc.h | 62 + drivers/gpu/drm/verisilicon/vs_dc_hw.c| 2008 + drivers/gpu/drm/verisilicon/vs_dc_hw.h| 496 drivers/gpu/drm/verisilicon/vs_drv.c | 301 +++ drivers/gpu/drm/verisilicon/vs_drv.h | 52 + drivers/gpu/drm/verisilicon/vs_fb.c | 181 ++ drivers/gpu/drm/verisilicon/vs_fb.h | 15 + drivers/gpu/drm/verisilicon/vs_gem.c | 372 +++ drivers/gpu/drm/verisilicon/vs_gem.h | 72 + drivers/gpu/drm/verisilicon/vs_plane.c| 440 drivers/gpu/drm/verisilicon/vs_plane.h| 74 + drivers/gpu/drm/verisilicon/vs_type.h | 72 + include/uapi/drm/drm_fourcc.h | 83 + include/uapi/drm/vs_drm.h | 50 + 30 files changed, 7433 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml create mode 100644 Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml create mode 100644 Documentation/devicetree/bindings/display/verisilicon/verisilicon-drm.yaml create mode 100644 drivers/gpu/drm/verisilicon/Kconfig create mode 100644 drivers/gpu/drm/verisilicon/Makefile create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.c create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.h create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.c create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.h create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.c create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.h create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.c create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.h create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.c create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.h create mode 100644 drivers/gpu/drm/verisilicon/vs_fb.c create mode 100644 drivers/gpu/drm/verisilicon/vs_fb.h create mode 100644 drivers/gpu/drm/verisilicon/vs_gem.c create mode 100644 drivers/gpu/drm/verisilicon/vs_gem.h create mode 100644 drivers/gpu/drm/verisilicon/vs_plane.c create mode 100644 drivers/gpu/drm/verisilicon/vs_plane.h create mode 100644 drivers/gpu/drm/verisilicon/vs_type.h create mode 100644 include/uapi/drm/vs_drm.h -- 2.34.1
