Re: [PATCH v9 3/8] x86/vmware: Introduce VMware hypercall API
Hi Alexey, kernel test robot noticed the following build errors: [auto build test ERROR on drm-misc/drm-misc-next] [also build test ERROR on dtor-input/next dtor-input/for-linus linus/master v6.9-rc7 next-20240509] [cannot apply to tip/x86/vmware] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Alexey-Makhalov/x86-vmware-Move-common-macros-to-vmware-h/20240507-055606 base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next patch link: https://lore.kernel.org/r/20240506215305.30756-4-alexey.makhalov%40broadcom.com patch subject: [PATCH v9 3/8] x86/vmware: Introduce VMware hypercall API config: x86_64-buildonly-randconfig-003-20240510 (https://download.01.org/0day-ci/archive/20240510/202405101333.vdlwwpgr-...@intel.com/config) compiler: gcc-11 (Ubuntu 11.4.0-4ubuntu1) 11.4.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240510/202405101333.vdlwwpgr-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202405101333.vdlwwpgr-...@intel.com/ All errors (new ones prefixed by >>): ld: drivers/gpu/drm/vmwgfx/vmwgfx_msg.o: in function `vmw_close_channel': >> vmwgfx_msg.c:(.text+0xaf): undefined reference to `vmware_hypercall_mode' ld: drivers/gpu/drm/vmwgfx/vmwgfx_msg.o: in function `vmw_port_hb_in': vmwgfx_msg.c:(.text+0x2c4): undefined reference to `vmware_hypercall_mode' ld: drivers/gpu/drm/vmwgfx/vmwgfx_msg.o: in function `vmw_port_hb_out': vmwgfx_msg.c:(.text+0x604): undefined reference to `vmware_hypercall_mode' ld: drivers/gpu/drm/vmwgfx/vmwgfx_msg.o: in function `vmw_send_msg': vmwgfx_msg.c:(.text+0x8b0): undefined reference to `vmware_hypercall_mode' ld: drivers/gpu/drm/vmwgfx/vmwgfx_msg.o: in function `vmw_open_channel.constprop.0': vmwgfx_msg.c:(.text+0x9e8): undefined reference to `vmware_hypercall_mode' ld: drivers/gpu/drm/vmwgfx/vmwgfx_msg.o:vmwgfx_msg.c:(.text+0xc3c): more undefined references to `vmware_hypercall_mode' follow -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
[PATCH v7 7/8] media: imagination: Round to closest multiple for cropping region
If neither of the flags to round down (V4L2_SEL_FLAG_LE) or round up
(V4L2_SEL_FLAG_GE) are specified by the user, then round to nearest
multiple of requested value while updating the crop rectangle coordinates.
Use the rounding macro which gives preference to rounding down in case two
nearest values (high and low) are possible to raise the probability of
cropping rectangle falling inside the bound region.
Signed-off-by: Devarsh Thakkar
---
V1->V6 (No change, patch introduced in V7)
---
drivers/media/platform/imagination/e5010-jpeg-enc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/imagination/e5010-jpeg-enc.c
b/drivers/media/platform/imagination/e5010-jpeg-enc.c
index 189e2a99c43d..abd66bc9b96c 100644
--- a/drivers/media/platform/imagination/e5010-jpeg-enc.c
+++ b/drivers/media/platform/imagination/e5010-jpeg-enc.c
@@ -517,10 +517,10 @@ static int e5010_s_selection(struct file *file, void *fh,
struct v4l2_selection
switch (s->flags) {
case 0:
- s->r.width = round_down(s->r.width,
queue->fmt->frmsize.step_width);
- s->r.height = round_down(s->r.height,
queue->fmt->frmsize.step_height);
- s->r.left = round_down(s->r.left,
queue->fmt->frmsize.step_width);
- s->r.top = round_down(s->r.top, 2);
+ s->r.width = round_closest_down(s->r.width,
queue->fmt->frmsize.step_width);
+ s->r.height = round_closest_down(s->r.height,
queue->fmt->frmsize.step_height);
+ s->r.left = round_closest_down(s->r.left,
queue->fmt->frmsize.step_width);
+ s->r.top = round_closest_down(s->r.top, 2);
if (s->r.left + s->r.width > queue->width)
s->r.width = round_down(s->r.width + s->r.left -
queue->width,
--
2.39.1
Re: [PATCH v2] mailbox: mtk-cmdq: Fix sleeping function called from invalid context
RE: [PATCH] drm/mst: Fix NULL pointer dereference at drm_dp_add_payload_part2
[Public]
> -Original Message-
> From: Limonciello, Mario
> Sent: Friday, May 10, 2024 3:18 AM
> To: Linux regressions mailing list ; Wentland,
> Harry
> ; Lin, Wayne
> Cc: ly...@redhat.com; imre.d...@intel.com; Leon Weiß bochum.de>; sta...@vger.kernel.org; dri-devel@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Subject: Re: [PATCH] drm/mst: Fix NULL pointer dereference at
> drm_dp_add_payload_part2
>
> On 5/9/2024 07:43, Linux regression tracking (Thorsten Leemhuis) wrote:
> > On 18.04.24 21:43, Harry Wentland wrote:
> >> On 2024-03-07 01:29, Wayne Lin wrote:
> >>> [Why]
> >>> Commit:
> >>> - commit 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
> >>> allocation/removement") accidently overwrite the commit
> >>> - commit 54d217406afe ("drm: use mgr->dev in drm_dbg_kms in
> >>> drm_dp_add_payload_part2") which cause regression.
> >>>
> >>> [How]
> >>> Recover the original NULL fix and remove the unnecessary input
> >>> parameter 'state' for drm_dp_add_payload_part2().
> >>>
> >>> Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
> >>> allocation/removement")
> >>> Reported-by: Leon Weiß
> >>> Link:
> >>> https://lore.kernel.org/r/38c253ea42072cc825dc969ac4e6b9b600371cc8.c
> >>> a...@ruhr-uni-bochum.de/
> >>> Cc: ly...@redhat.com
> >>> Cc: imre.d...@intel.com
> >>> Cc: sta...@vger.kernel.org
> >>> Cc: regressi...@lists.linux.dev
> >>> Signed-off-by: Wayne Lin
> >>
> >> I haven't been deep in MST code in a while but this all looks pretty
> >> straightforward and good.
> >>
> >> Reviewed-by: Harry Wentland
> >
> > Hmmm, that was three weeks ago, but it seems since then nothing
> > happened to fix the linked regression through this or some other
> > patch. Is there a reason? The build failure report from the CI maybe?
>
> It touches files outside of amd but only has an ack from AMD. I think we
> /probably/ want an ack from i915 and nouveau to take it through.
Thanks, Mario!
Hi Thorsten,
Yeah, like what Mario said. Would also like to have ack from i915 and nouveau.
>
> >
> > Wayne Lin, do you know what's up?
> >
> > Ciao, Thorsten
> >
> >>> ---
> >>> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
> >>> drivers/gpu/drm/display/drm_dp_mst_topology.c | 4 +---
> >>> drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
> >>> drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
> >>> include/drm/display/drm_dp_mst_helper.h | 1 -
> >>> 5 files changed, 4 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git
> >>> a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> >>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> >>> index c27063305a13..2c36f3d00ca2 100644
> >>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> >>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> >>> @@ -363,7 +363,7 @@ void dm_helpers_dp_mst_send_payload_allocation(
> >>> mst_state = to_drm_dp_mst_topology_state(mst_mgr->base.state);
> >>> new_payload = drm_atomic_get_mst_payload_state(mst_state,
> >>> aconnector->mst_output_port);
> >>>
> >>> - ret = drm_dp_add_payload_part2(mst_mgr, mst_state->base.state,
> new_payload);
> >>> + ret = drm_dp_add_payload_part2(mst_mgr, new_payload);
> >>>
> >>> if (ret) {
> >>> amdgpu_dm_set_mst_status(>mst_status,
> >>> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> >>> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> >>> index 03d528209426..95fd18f24e94 100644
> >>> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> >>> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> >>> @@ -3421,7 +3421,6 @@
> EXPORT_SYMBOL(drm_dp_remove_payload_part2);
> >>> /**
> >>>* drm_dp_add_payload_part2() - Execute payload update part 2
> >>>* @mgr: Manager to use.
> >>> - * @state: The global atomic state
> >>>* @payload: The payload to update
> >>>*
> >>>* If @payload was successfully assigned a starting time slot by
> >>> drm_dp_add_payload_part1(), this @@ -3430,14 +3429,13 @@
> EXPORT_SYMBOL(drm_dp_remove_payload_part2);
> >>>* Returns: 0 on success, negative error code on failure.
> >>>*/
> >>> int drm_dp_add_payload_part2(struct drm_dp_mst_topology_mgr *mgr,
> >>> - struct drm_atomic_state *state,
> >>>struct drm_dp_mst_atomic_payload *payload)
> >>> {
> >>> int ret = 0;
> >>>
> >>> /* Skip failed payloads */
> >>> if (payload->payload_allocation_status !=
> DRM_DP_MST_PAYLOAD_ALLOCATION_DFP) {
> >>> - drm_dbg_kms(state->dev, "Part 1 of payload creation for %s
> failed, skipping part 2\n",
> >>> + drm_dbg_kms(mgr->dev, "Part 1 of payload creation for %s
> failed,
> >>> +skipping part 2\n",
> >>> payload->port->connector->name);
> >>> return -EIO;
> >>>
Re: [pull] amdgpu, amdkfd drm-fixes-6.9
On Thu, 9 May 2024 at 09:00, Alex Deucher wrote: > > Hi Dave, Sima, > > Fixes for 6.9. > > The following changes since commit dd5a440a31fae6e459c0d627162825505361: > > Linux 6.9-rc7 (2024-05-05 14:06:01 -0700) > > are available in the Git repository at: > > https://gitlab.freedesktop.org/agd5f/linux.git > tags/amd-drm-fixes-6.9-2024-05-08 > > for you to fetch changes up to 3d09248a06d285397e7b873415505d299202e1c6: > > drm/amdgpu: Fix comparison in amdgpu_res_cpu_visible (2024-05-08 18:47:52 > -0400) > > > amd-drm-fixes-6.9-2024-05-08: > > amdgpu: > - DCN 3.5 fix > - MST DSC fixes > - S0i3 fix > - S4 fix > - Warning fix > - HDP MMIO mapping fix > - Fix a regression in visible vram handling > > amdkfd: > - Spatial partition fix > > > Agustin Gutierrez (2): > drm/amd/display: Fix DSC-re-computing > drm/amd/display: MST DSC check for older devices > > Alex Deucher (1): > drm/amdkfd: don't allow mapping the MMIO HDP page with large pages > > Lijo Lazar (2): > Revert "drm/amdkfd: Add partition id field to location_id" > drm/amd/amdxcp: Fix warnings Hey, this has a "fixes:" for a patch that doesn't exist. Can we fix that up? I can pull this but I'd prefer it to get fixed if you have a chance. Dave.
Re: [PATCH v5 2/7] drm/panel: himax-hx83102: Break out as separate driver
Hi,
Doug Anderson 于2024年5月10日周五 00:42写道：
>
> Hi,
>
> On Wed, May 8, 2024 at 6:53 PM Cong Yang
> wrote:
> >
> > +static int hx83102_enable(struct drm_panel *panel)
> > +{
> > + struct hx83102 *ctx = panel_to_hx83102(panel);
> > + struct mipi_dsi_device *dsi = ctx->dsi;
> > + struct device *dev = >dev;
> > + int ret;
> > +
> > + ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
> > + if (ret) {
> > + dev_err(dev, "Failed to exit sleep mode: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + msleep(120);
> > +
> > + ret = mipi_dsi_dcs_set_display_on(dsi);
> > + if (ret) {
> > + dev_err(dev, "Failed to turn on the display: %d\n", ret);
> > + return ret;
> > + }
>
> FWIW, I think that the mipi_dsi_dcs_exit_sleep_mode(), msleep(120),
> and mipi_dsi_dcs_set_display_on() should also be in the prepare() to
> match how they were in the boe-tv101wum-nl6.c driver, right? Then the
> enable() would be left with just the simple "msleep(130)".
>
> I know it doesn't make much difference and it probably doesn't matter
> and maybe I'm just being a little nitpicky, but given that the
> prepare() and enable() functions are unique phases I'd rather be
> explicit if we've moving something from one phase to the other.
Yes, if it is consistent with the boe-tv101wum-nl6.c driver, then it
should be moved to prepare().
However, I was working from the driver readability,
enable() corresponds to 0x11 & 0x29.
disable() corresponds to 0x28 & 0x10.
..
Ok, I'll be happy to send V6 version to fix that, thanks!
>
>
> -Doug
Re: [PATCH] drm/panel: jdi-fhd-r63452: move DCS off commands to disable
On Thu, May 09, 2024 at 08:14:07PM +0200, Barnabás Czémán wrote:
> Move DCS off commands from .unprepare to .disable so that they
> actually reach the DSI host.
>
> Signed-off-by: Barnabás Czémán
> ---
> drivers/gpu/drm/panel/panel-jdi-fhd-r63452.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
I don't think this is correct. If the driver sends enable commands in
prepare, it should be able to send commands during unprepare too.
>
> diff --git a/drivers/gpu/drm/panel/panel-jdi-fhd-r63452.c
> b/drivers/gpu/drm/panel/panel-jdi-fhd-r63452.c
> index 483dc88d16d8..f7222974d6ed 100644
> --- a/drivers/gpu/drm/panel/panel-jdi-fhd-r63452.c
> +++ b/drivers/gpu/drm/panel/panel-jdi-fhd-r63452.c
> @@ -169,6 +169,15 @@ static int jdi_fhd_r63452_prepare(struct drm_panel
> *panel)
> }
>
> static int jdi_fhd_r63452_unprepare(struct drm_panel *panel)
> +{
> + struct jdi_fhd_r63452 *ctx = to_jdi_fhd_r63452(panel);
> +
> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> +
> + return 0;
> +}
> +
> +static int jdi_fhd_r63452_disable(struct drm_panel *panel)
> {
> struct jdi_fhd_r63452 *ctx = to_jdi_fhd_r63452(panel);
> struct device *dev = >dsi->dev;
> @@ -178,8 +187,6 @@ static int jdi_fhd_r63452_unprepare(struct drm_panel
> *panel)
> if (ret < 0)
> dev_err(dev, "Failed to un-initialize panel: %d\n", ret);
>
> - gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> -
> return 0;
> }
>
> @@ -219,6 +226,7 @@ static int jdi_fhd_r63452_get_modes(struct drm_panel
> *panel,
> static const struct drm_panel_funcs jdi_fhd_r63452_panel_funcs = {
> .prepare = jdi_fhd_r63452_prepare,
> .unprepare = jdi_fhd_r63452_unprepare,
> + .disable = jdi_fhd_r63452_disable,
> .get_modes = jdi_fhd_r63452_get_modes,
> };
>
>
> ---
> base-commit: 704ba27ac55579704ba1289392448b0c66b56258
> change-id: 20240509-jdi-use-disable-ee29098d9c81
>
> Best regards,
> --
> Barnabás Czémán
>
--
With best wishes
Dmitry
Re: [PATCH v9 3/8] x86/vmware: Introduce VMware hypercall API
On 5/7/24 2:58 AM, Borislav Petkov wrote:
On Mon, May 06, 2024 at 02:53:00PM -0700, Alexey Makhalov wrote:
+#define VMWARE_HYPERCALL \
+ ALTERNATIVE_3("cmpb $"\
+ __stringify(CPUID_VMWARE_FEATURES_ECX_VMMCALL) \
+ ", %[mode]\n\t" \
+ "jg 2f\n\t" \
+ "je 1f\n\t" \
+ "movw %[port], %%dx\n\t"\
+ "inl (%%dx), %%eax\n\t" \
+ "jmp 3f\n\t"\
+ "1: vmmcall\n\t"\
+ "jmp 3f\n\t"\
+ "2: vmcall\n\t" \
+ "3:\n\t", \
+ "movw %[port], %%dx\n\t"\
+ "inl (%%dx), %%eax", X86_FEATURE_HYPERVISOR,\
That's a bunch of insns and their size would inadvertently go into the final
image.
What you should try to do is something like this:
ALTERNATIVE_3("jmp .Lend_legacy_call", "", X86_FEATURE_HYPERVISOR,
"vmcall; jmp .Lend_legacy_call", X86_FEATURE_VMCALL,
"vmmcall; jmp .Lend_legacy_call", X86_FEATURE_VMW_VMMCALL)
/* bunch of conditional branches and INs and V*MCALLs, etc go
here */
.Lend_legacy_call:
so that you don't have these 26 bytes, as you say, of alternatives to patch but
only the JMPs and the VM*CALLs.
See for an example the macros in arch/x86/entry/calling.h which simply jump
over the code when not needed.
Good idea!
Also, you could restructure the alternative differently so that that bunch of
insns call is completely out-of-line because all current machines support
VM*CALL so you won't even need to patch. You only get to patch when running on
some old rust and there you can just as well go completely out-of-line.
Alternatives patching has not been performed at platform detection time.
And platform detection hypercalls should work on all machines.
That is the reason we have IN as a default hypercall behavior.
Something along those lines, anyway.
- * The high bandwidth in call. The low word of edx is presumed to have the
- * HB bit set.
+ * High bandwidth calls are not supported on encrypted memory guests.
+ * The caller should check cc_platform_has(CC_ATTR_MEM_ENCRYPT) and use
+ * low bandwidth hypercall it memory encryption is set.
s/it/if/
Acked.
-#define VMWARE_PORT(cmd, eax, ebx, ecx, edx) \
- __asm__("inl (%%dx), %%eax" : \
- "=a"(eax), "=c"(ecx), "=d"(edx), "=b"(ebx) :\
- "a"(VMWARE_HYPERVISOR_MAGIC), \
- "c"(VMWARE_CMD_##cmd),\
- "d"(VMWARE_HYPERVISOR_PORT), "b"(UINT_MAX) :\
- "memory")
-
-#define VMWARE_VMCALL(cmd, eax, ebx, ecx, edx) \
- __asm__("vmcall" :\
- "=a"(eax), "=c"(ecx), "=d"(edx), "=b"(ebx) :\
- "a"(VMWARE_HYPERVISOR_MAGIC), \
- "c"(VMWARE_CMD_##cmd),\
- "d"(0), "b"(UINT_MAX) : \
- "memory")
-
-#define VMWARE_VMMCALL(cmd, eax, ebx, ecx, edx)
\
- __asm__("vmmcall" : \
- "=a"(eax), "=c"(ecx), "=d"(edx), "=b"(ebx) :\
- "a"(VMWARE_HYPERVISOR_MAGIC), \
- "c"(VMWARE_CMD_##cmd),\
- "d"(0), "b"(UINT_MAX) : \
- "memory")
-
-#define VMWARE_CMD(cmd, eax, ebx, ecx, edx) do { \
- switch (vmware_hypercall_mode) {\
- case CPUID_VMWARE_FEATURES_ECX_VMCALL: \
- VMWARE_VMCALL(cmd, eax, ebx, ecx, edx); \
- break; \
- case CPUID_VMWARE_FEATURES_ECX_VMMCALL: \
- VMWARE_VMMCALL(cmd, eax, ebx, ecx, edx);\
- break; \
- default:\
- VMWARE_PORT(cmd, eax, ebx, ecx, edx); \
- break; \
- }
Re: [PATCH v9 1/8] x86/vmware: Move common macros to vmware.h
On 5/7/24 2:14 AM, Borislav Petkov wrote: On Mon, May 06, 2024 at 02:52:58PM -0700, Alexey Makhalov wrote: +#define VMWARE_HYPERVISOR_PORT 0x5658 +#define VMWARE_HYPERVISOR_PORT_HB (VMWARE_HYPERVISOR_PORT | \ +VMWARE_HYPERVISOR_HB) You can't help yourself not sneaking in any changes which are not code movement, can ya? Indeed! My fault. The purpose of a sole code movement patch is to ease the review. Not to have to look at the code movement *and* some *additional* changes which you've done in-flight. Just because you felt like it. But which is nasty to review. Agree. I should not claim it as sole code movement then. At least moving macros from .c to .h file requires changing vmware_hypercall_mode variable visibility from static to global. If you think this type of changes is Ok for sole code movement patch, then I'll continue following this path. Otherwise, will change patch description. Thanks for the patience. --Alexey
[PATCH RFC 4/7] drm/panel: innolux-p079zca: use mipi_dsi_dcs_nop_multi()
Remove conditional code and use mipi_dsi_dcs_nop_multi() wrapper to
simplify driver code.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index ade8bf7491ee..0691a27a0daa 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -224,21 +224,14 @@ static const struct drm_display_mode innolux_p097pfg_mode
= {
static void innolux_panel_write_multi(struct mipi_dsi_multi_context *ctx,
const void *payload, size_t size)
{
- struct mipi_dsi_device *dsi = ctx->dsi;
- struct device *dev = >dev;
-
mipi_dsi_generic_write_multi(ctx, payload, size);
- if (ctx->accum_err)
- return;
/*
* Included by random guessing, because without this
* (or at least, some delay), the panel sometimes
* didn't appear to pick up the command sequence.
*/
- ctx->accum_err = mipi_dsi_dcs_nop(ctx->dsi);
- if (ctx->accum_err)
- dev_err(dev, "failed to send DCS nop: %d\n", ctx->accum_err);
+ mipi_dsi_dcs_nop_multi(ctx);
}
#define innolux_panel_init_cmd_multi(ctx, seq...) \
--
2.39.2
[PATCH RFC 6/7] drm/panel: lg-sw43408: add missing error handling
Add missing error handling for the mipi_dsi_ functions that actually
return error code instead of silently ignoring it.
Fixes: 069a6c0e94f9 ("drm: panel: Add LG sw43408 panel driver")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-lg-sw43408.c | 33 ++--
1 file changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-lg-sw43408.c
b/drivers/gpu/drm/panel/panel-lg-sw43408.c
index 2b3a73696dce..67a98ac508f8 100644
--- a/drivers/gpu/drm/panel/panel-lg-sw43408.c
+++ b/drivers/gpu/drm/panel/panel-lg-sw43408.c
@@ -62,16 +62,25 @@ static int sw43408_program(struct drm_panel *panel)
{
struct sw43408_panel *ctx = to_panel_info(panel);
struct drm_dsc_picture_parameter_set pps;
+ int ret;
mipi_dsi_dcs_write_seq(ctx->link, MIPI_DCS_SET_GAMMA_CURVE, 0x02);
- mipi_dsi_dcs_set_tear_on(ctx->link, MIPI_DSI_DCS_TEAR_MODE_VBLANK);
+ ret = mipi_dsi_dcs_set_tear_on(ctx->link,
MIPI_DSI_DCS_TEAR_MODE_VBLANK);
+ if (ret < 0) {
+ dev_err(panel->dev, "Failed to set tearing: %d\n", ret);
+ return ret;
+ }
mipi_dsi_dcs_write_seq(ctx->link, 0x53, 0x0c, 0x30);
mipi_dsi_dcs_write_seq(ctx->link, 0x55, 0x00, 0x70, 0xdf, 0x00, 0x70,
0xdf);
mipi_dsi_dcs_write_seq(ctx->link, 0xf7, 0x01, 0x49, 0x0c);
- mipi_dsi_dcs_exit_sleep_mode(ctx->link);
+ ret = mipi_dsi_dcs_exit_sleep_mode(ctx->link);
+ if (ret < 0) {
+ dev_err(panel->dev, "Failed to exit sleep mode: %d\n", ret);
+ return ret;
+ }
msleep(135);
@@ -97,14 +106,22 @@ static int sw43408_program(struct drm_panel *panel)
mipi_dsi_dcs_write_seq(ctx->link, 0x55, 0x04, 0x61, 0xdb, 0x04, 0x70,
0xdb);
mipi_dsi_dcs_write_seq(ctx->link, 0xb0, 0xca);
- mipi_dsi_dcs_set_display_on(ctx->link);
+ ret = mipi_dsi_dcs_set_display_on(ctx->link);
+ if (ret < 0) {
+ dev_err(panel->dev, "Failed to set display on: %d\n", ret);
+ return ret;
+ }
msleep(50);
ctx->link->mode_flags &= ~MIPI_DSI_MODE_LPM;
drm_dsc_pps_payload_pack(, ctx->link->dsc);
- mipi_dsi_picture_parameter_set(ctx->link, );
+ ret = mipi_dsi_picture_parameter_set(ctx->link, );
+ if (ret < 0) {
+ dev_err(panel->dev, "Failed to set PPS: %d\n", ret);
+ return ret;
+ }
ctx->link->mode_flags |= MIPI_DSI_MODE_LPM;
@@ -113,8 +130,12 @@ static int sw43408_program(struct drm_panel *panel)
* PPS 1 if pps_identifier is 0
* PPS 2 if pps_identifier is 1
*/
- mipi_dsi_compression_mode_ext(ctx->link, true,
- MIPI_DSI_COMPRESSION_DSC, 1);
+ ret = mipi_dsi_compression_mode_ext(ctx->link, true,
+ MIPI_DSI_COMPRESSION_DSC, 1);
+ if (ret < 0) {
+ dev_err(panel->dev, "Failed to set compression mode: %d\n",
ret);
+ return ret;
+ }
return 0;
}
--
2.39.2
[PATCH RFC 7/7] drm/panel: lg-sw43408: use new streamlined MIPI DSI API
Use newer mipi_dsi_*_multi() functions in order to simplify and cleanup
panel's prepare() and unprepare() functions.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-lg-sw43408.c | 95 +---
1 file changed, 37 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-lg-sw43408.c
b/drivers/gpu/drm/panel/panel-lg-sw43408.c
index 67a98ac508f8..f3dcc39670ea 100644
--- a/drivers/gpu/drm/panel/panel-lg-sw43408.c
+++ b/drivers/gpu/drm/panel/panel-lg-sw43408.c
@@ -40,104 +40,83 @@ static inline struct sw43408_panel *to_panel_info(struct
drm_panel *panel)
static int sw43408_unprepare(struct drm_panel *panel)
{
- struct sw43408_panel *ctx = to_panel_info(panel);
+ struct sw43408_panel *sw43408 = to_panel_info(panel);
+ struct mipi_dsi_multi_context ctx = { .dsi = sw43408->link };
int ret;
- ret = mipi_dsi_dcs_set_display_off(ctx->link);
- if (ret < 0)
- dev_err(panel->dev, "set_display_off cmd failed ret = %d\n",
ret);
+ mipi_dsi_dcs_set_display_off_multi();
- ret = mipi_dsi_dcs_enter_sleep_mode(ctx->link);
- if (ret < 0)
- dev_err(panel->dev, "enter_sleep cmd failed ret = %d\n", ret);
+ mipi_dsi_dcs_enter_sleep_mode_multi();
- msleep(100);
+ mipi_dsi_msleep(, 100);
- gpiod_set_value(ctx->reset_gpio, 1);
+ gpiod_set_value(sw43408->reset_gpio, 1);
+
+ ret = regulator_bulk_disable(ARRAY_SIZE(sw43408->supplies),
sw43408->supplies);
- return regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
+ return ret ? : ctx.accum_err;
}
static int sw43408_program(struct drm_panel *panel)
{
- struct sw43408_panel *ctx = to_panel_info(panel);
+ struct sw43408_panel *sw43408 = to_panel_info(panel);
+ struct mipi_dsi_multi_context ctx = { .dsi = sw43408->link };
struct drm_dsc_picture_parameter_set pps;
- int ret;
- mipi_dsi_dcs_write_seq(ctx->link, MIPI_DCS_SET_GAMMA_CURVE, 0x02);
+ mipi_dsi_dcs_write_seq_multi(, MIPI_DCS_SET_GAMMA_CURVE, 0x02);
- ret = mipi_dsi_dcs_set_tear_on(ctx->link,
MIPI_DSI_DCS_TEAR_MODE_VBLANK);
- if (ret < 0) {
- dev_err(panel->dev, "Failed to set tearing: %d\n", ret);
- return ret;
- }
+ mipi_dsi_dcs_set_tear_on_multi(, MIPI_DSI_DCS_TEAR_MODE_VBLANK);
- mipi_dsi_dcs_write_seq(ctx->link, 0x53, 0x0c, 0x30);
- mipi_dsi_dcs_write_seq(ctx->link, 0x55, 0x00, 0x70, 0xdf, 0x00, 0x70,
0xdf);
- mipi_dsi_dcs_write_seq(ctx->link, 0xf7, 0x01, 0x49, 0x0c);
+ mipi_dsi_dcs_write_seq_multi(, 0x53, 0x0c, 0x30);
+ mipi_dsi_dcs_write_seq_multi(, 0x55, 0x00, 0x70, 0xdf, 0x00, 0x70,
0xdf);
+ mipi_dsi_dcs_write_seq_multi(, 0xf7, 0x01, 0x49, 0x0c);
- ret = mipi_dsi_dcs_exit_sleep_mode(ctx->link);
- if (ret < 0) {
- dev_err(panel->dev, "Failed to exit sleep mode: %d\n", ret);
- return ret;
- }
+ mipi_dsi_dcs_exit_sleep_mode_multi();
- msleep(135);
+ mipi_dsi_msleep(, 135);
/* COMPRESSION_MODE moved after setting the PPS */
- mipi_dsi_dcs_write_seq(ctx->link, 0xb0, 0xac);
- mipi_dsi_dcs_write_seq(ctx->link, 0xe5,
+ mipi_dsi_dcs_write_seq_multi(, 0xb0, 0xac);
+ mipi_dsi_dcs_write_seq_multi(, 0xe5,
0x00, 0x3a, 0x00, 0x3a, 0x00, 0x0e, 0x10);
- mipi_dsi_dcs_write_seq(ctx->link, 0xb5,
+ mipi_dsi_dcs_write_seq_multi(, 0xb5,
0x75, 0x60, 0x2d, 0x5d, 0x80, 0x00, 0x0a, 0x0b,
0x00, 0x05, 0x0b, 0x00, 0x80, 0x0d, 0x0e, 0x40,
0x00, 0x0c, 0x00, 0x16, 0x00, 0xb8, 0x00, 0x80,
0x0d, 0x0e, 0x40, 0x00, 0x0c, 0x00, 0x16, 0x00,
0xb8, 0x00, 0x81, 0x00, 0x03, 0x03, 0x03, 0x01,
0x01);
- msleep(85);
- mipi_dsi_dcs_write_seq(ctx->link, 0xcd,
+ mipi_dsi_msleep(, 85);
+ mipi_dsi_dcs_write_seq_multi(, 0xcd,
0x00, 0x00, 0x00, 0x19, 0x19, 0x19, 0x19, 0x19,
0x19, 0x19, 0x19, 0x19, 0x19, 0x19, 0x19, 0x19,
0x16, 0x16);
- mipi_dsi_dcs_write_seq(ctx->link, 0xcb, 0x80, 0x5c, 0x07, 0x03, 0x28);
- mipi_dsi_dcs_write_seq(ctx->link, 0xc0, 0x02, 0x02, 0x0f);
- mipi_dsi_dcs_write_seq(ctx->link, 0x55, 0x04, 0x61, 0xdb, 0x04, 0x70,
0xdb);
- mipi_dsi_dcs_write_seq(ctx->link, 0xb0, 0xca);
-
- ret = mipi_dsi_dcs_set_display_on(ctx->link);
- if (ret < 0) {
- dev_err(panel->dev, "Failed to set display on: %d\n", ret);
- return ret;
- }
+ mipi_dsi_dcs_write_seq_multi(, 0xcb, 0x80, 0x5c, 0x07, 0x03, 0x28);
+ mipi_dsi_dcs_write_seq_multi(, 0xc0, 0x02, 0x02, 0x0f);
+
[PATCH RFC 3/7] drm/panel: ilitek-ili9882t: use wrapped MIPI DCS functions
Remove conditional code and always use mipi_dsi_dcs_*multi() wrappers to
simplify driver's init/exit code.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-ilitek-ili9882t.c | 30 +--
1 file changed, 10 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
index 58fc1d799371..e7a74d5443b0 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
@@ -402,19 +402,15 @@ static int starry_ili9882t_init(struct ili9882t *ili)
mipi_dsi_dcs_write_seq_multi(, 0x92, 0x22);
ili9882t_switch_page(, 0x00);
- mipi_dsi_dcs_write_seq_multi(, MIPI_DCS_EXIT_SLEEP_MODE);
- if (ctx.accum_err)
- return ctx.accum_err;
+ mipi_dsi_dcs_exit_sleep_mode_multi();
- msleep(120);
+ mipi_dsi_msleep(, 120);
- mipi_dsi_dcs_write_seq_multi(, MIPI_DCS_SET_DISPLAY_ON);
- if (ctx.accum_err)
- return ctx.accum_err;
+ mipi_dsi_dcs_set_display_on_multi();
- msleep(20);
+ mipi_dsi_msleep(, 20);
- return 0;
+ return ctx.accum_err;
};
static inline struct ili9882t *to_ili9882t(struct drm_panel *panel)
@@ -424,20 +420,14 @@ static inline struct ili9882t *to_ili9882t(struct
drm_panel *panel)
static int ili9882t_enter_sleep_mode(struct ili9882t *ili)
{
- struct mipi_dsi_device *dsi = ili->dsi;
- int ret;
-
- dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
+ struct mipi_dsi_multi_context ctx = { .dsi = ili->dsi };
- ret = mipi_dsi_dcs_set_display_off(dsi);
- if (ret < 0)
- return ret;
+ ili->dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
- ret = mipi_dsi_dcs_enter_sleep_mode(dsi);
- if (ret < 0)
- return ret;
+ mipi_dsi_dcs_set_display_off_multi();
+ mipi_dsi_dcs_enter_sleep_mode_multi();
- return 0;
+ return ctx.accum_err;
}
static int ili9882t_disable(struct drm_panel *panel)
--
2.39.2
[PATCH RFC 2/7] drm/panel: boe-tv101wum-nl6: use wrapped MIPI DCS functions
Remove conditional code and always use mipi_dsi_dcs_*multi() wrappers to
simplify driver's init/exit code.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 73 --
1 file changed, 21 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index aab60cec0603..456c1a5a2110 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -448,22 +448,16 @@ static int boe_tv110c9m_init(struct boe_panel *boe)
mipi_dsi_dcs_write_seq_multi(, 0x55, 0x00);
mipi_dsi_dcs_write_seq_multi(, 0xbb, 0x13);
mipi_dsi_dcs_write_seq_multi(, 0x3b, 0x03, 0x96, 0x1a, 0x04, 0x04);
- if (ctx.accum_err)
- return ctx.accum_err;
- msleep(100);
+ mipi_dsi_msleep(, 100);
mipi_dsi_dcs_write_seq_multi(, 0x11);
- if (ctx.accum_err)
- return ctx.accum_err;
- msleep(200);
+ mipi_dsi_msleep(, 200);
mipi_dsi_dcs_write_seq_multi(, 0x29);
- if (ctx.accum_err)
- return ctx.accum_err;
- msleep(100);
+ mipi_dsi_msleep(, 100);
return 0;
};
@@ -893,22 +887,16 @@ static int inx_hj110iz_init(struct boe_panel *boe)
mipi_dsi_dcs_write_seq_multi(, 0xb0, 0x01);
mipi_dsi_dcs_write_seq_multi(, 0x35, 0x00);
mipi_dsi_dcs_write_seq_multi(, 0x3b, 0x03, 0xae, 0x1a, 0x04, 0x04);
- if (ctx.accum_err)
- return ctx.accum_err;
- msleep(100);
+ mipi_dsi_msleep(, 100);
mipi_dsi_dcs_write_seq_multi(, 0x11);
- if (ctx.accum_err)
- return ctx.accum_err;
- msleep(200);
+ mipi_dsi_msleep(, 200);
mipi_dsi_dcs_write_seq_multi(, 0x29);
- if (ctx.accum_err)
- return ctx.accum_err;
- msleep(100);
+ mipi_dsi_msleep(, 100);
return 0;
};
@@ -1207,10 +1195,8 @@ static int boe_init(struct boe_panel *boe)
mipi_dsi_dcs_write_seq_multi(, 0xb3, 0x08);
mipi_dsi_dcs_write_seq_multi(, 0xb0, 0x04);
mipi_dsi_dcs_write_seq_multi(, 0xb8, 0x68);
- if (ctx.accum_err)
- return ctx.accum_err;
- msleep(150);
+ mipi_dsi_msleep(, 150);
return 0;
};
@@ -1222,16 +1208,12 @@ static int auo_kd101n80_45na_init(struct boe_panel *boe)
msleep(24);
mipi_dsi_dcs_write_seq_multi(, 0x11);
- if (ctx.accum_err)
- return ctx.accum_err;
- msleep(120);
+ mipi_dsi_msleep(, 120);
mipi_dsi_dcs_write_seq_multi(, 0x29);
- if (ctx.accum_err)
- return ctx.accum_err;
- msleep(120);
+ mipi_dsi_msleep(, 120);
return 0;
};
@@ -1283,10 +1265,8 @@ static int auo_b101uan08_3_init(struct boe_panel *boe)
mipi_dsi_dcs_write_seq_multi(, 0xe5, 0x4f);
mipi_dsi_dcs_write_seq_multi(, 0xe6, 0x41);
mipi_dsi_dcs_write_seq_multi(, 0xe7, 0x41);
- if (ctx.accum_err)
- return ctx.accum_err;
- msleep(150);
+ mipi_dsi_msleep(, 150);
return 0;
};
@@ -1385,16 +1365,12 @@ static int starry_qfh032011_53g_init(struct boe_panel
*boe)
mipi_dsi_dcs_write_seq_multi(, 0xe1, 0x23);
mipi_dsi_dcs_write_seq_multi(, 0xe2, 0x07);
mipi_dsi_dcs_write_seq_multi(, 0X11);
- if (ctx.accum_err)
- return ctx.accum_err;
- msleep(120);
+ mipi_dsi_msleep(, 120);
mipi_dsi_dcs_write_seq_multi(, 0X29);
- if (ctx.accum_err)
- return ctx.accum_err;
- msleep(80);
+ mipi_dsi_msleep(, 80);
return 0;
};
@@ -1490,13 +1466,12 @@ static int starry_himax83102_j02_init(struct boe_panel
*boe)
mipi_dsi_dcs_write_seq_multi(, 0xba, 0x4f);
mipi_dsi_dcs_write_seq_multi(, 0xe9, 0x3f);
mipi_dsi_dcs_write_seq_multi(, 0xbd, 0x00);
- mipi_dsi_dcs_write_seq_multi(, 0x11);
- if (ctx.accum_err)
- return ctx.accum_err;
- msleep(120);
+ mipi_dsi_dcs_exit_sleep_mode_multi();
- mipi_dsi_dcs_write_seq_multi(, 0x29);
+ mipi_dsi_msleep(, 120);
+
+ mipi_dsi_dcs_set_display_on_multi();
return ctx.accum_err;
};
@@ -1508,20 +1483,14 @@ static inline struct boe_panel *to_boe_panel(struct
drm_panel *panel)
static int boe_panel_enter_sleep_mode(struct boe_panel *boe)
{
- struct mipi_dsi_device *dsi = boe->dsi;
- int ret;
-
- dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
+ struct mipi_dsi_multi_context ctx = { .dsi = boe->dsi };
- ret = mipi_dsi_dcs_set_display_off(dsi);
- if (ret < 0)
- return ret;
+ boe->dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
- ret = mipi_dsi_dcs_enter_sleep_mode(dsi);
- if (ret < 0)
- return ret;
+ mipi_dsi_dcs_set_display_off_multi();
+
[PATCH RFC 1/7] drm/mipi-dsi: wrap more functions for streamline handling
Follow the pattern of mipi_dsi_dcs_*_multi() and wrap several existing
MIPI DSI functions to use the context for processing. This simplifies
and streamlines driver code to use simpler code pattern.
Note, msleep function is also wrapped in this way as it is frequently
called inbetween other mipi_dsi_dcs_*() functions.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_mipi_dsi.c | 209 +
include/drm/drm_mipi_dsi.h | 19
2 files changed, 228 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index d2957cb692d3..4e5e7ad10b7e 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -1429,6 +1429,215 @@ int mipi_dsi_dcs_get_display_brightness_large(struct
mipi_dsi_device *dsi,
}
EXPORT_SYMBOL(mipi_dsi_dcs_get_display_brightness_large);
+/**
+ * mipi_dsi_picture_parameter_set_multi() - transmit the DSC PPS to the
peripheral
+ * @ctx: Context for multiple DSI transactions
+ * @pps: VESA DSC 1.1 Picture Parameter Set
+ *
+ * Like mipi_dsi_picture_parameter_set() but deals with errors in a way that
+ * makes it convenient to make several calls in a row.
+ */
+void mipi_dsi_picture_parameter_set_multi(struct mipi_dsi_multi_context *ctx,
+ const struct drm_dsc_picture_parameter_set
*pps)
+{
+ struct mipi_dsi_device *dsi = ctx->dsi;
+ struct device *dev = >dev;
+ ssize_t ret;
+
+ if (ctx->accum_err)
+ return;
+
+ ret = mipi_dsi_picture_parameter_set(dsi, pps);
+ if (ret < 0) {
+ ctx->accum_err = ret;
+ dev_err(dev, "sending PPS failed: %d\n",
+ ctx->accum_err);
+ }
+}
+EXPORT_SYMBOL(mipi_dsi_picture_parameter_set_multi);
+
+/**
+ * mipi_dsi_compression_mode_ext() - enable/disable DSC on the peripheral
+ * @ctx: Context for multiple DSI transactions
+ * @enable: Whether to enable or disable the DSC
+ * @algo: Selected compression algorithm
+ * @pps_selector: Select PPS from the table of pre-stored or uploaded PPS
entries
+ *
+ * Like mipi_dsi_compression_mode_ext_multi() but deals with errors in a way
that
+ * makes it convenient to make several calls in a row.
+ */
+void mipi_dsi_compression_mode_ext_multi(struct mipi_dsi_multi_context *ctx,
+bool enable,
+enum mipi_dsi_compression_algo algo,
+unsigned int pps_selector)
+{
+ struct mipi_dsi_device *dsi = ctx->dsi;
+ struct device *dev = >dev;
+ ssize_t ret;
+
+ if (ctx->accum_err)
+ return;
+
+ ret = mipi_dsi_compression_mode_ext(dsi, enable, algo, pps_selector);
+ if (ret < 0) {
+ ctx->accum_err = ret;
+ dev_err(dev, "sending COMPRESSION_MODE failed: %d\n",
+ ctx->accum_err);
+ }
+}
+EXPORT_SYMBOL(mipi_dsi_compression_mode_ext_multi);
+
+/**
+ * mipi_dsi_dcs_nop_multi() - send DCS NOP packet
+ * @ctx: Context for multiple DSI transactions
+ *
+ * Like mipi_dsi_dcs_nop() but deals with errors in a way that
+ * makes it convenient to make several calls in a row.
+ */
+void mipi_dsi_dcs_nop_multi(struct mipi_dsi_multi_context *ctx)
+{
+ struct mipi_dsi_device *dsi = ctx->dsi;
+ struct device *dev = >dev;
+ ssize_t ret;
+
+ if (ctx->accum_err)
+ return;
+
+ ret = mipi_dsi_dcs_nop(dsi);
+ if (ret < 0) {
+ ctx->accum_err = ret;
+ dev_err(dev, "sending DCS NOP failed: %d\n",
+ ctx->accum_err);
+ }
+}
+EXPORT_SYMBOL(mipi_dsi_dcs_nop_multi);
+
+/**
+ * mipi_dsi_dcs_enter_sleep_mode_multi() - send DCS ENTER_SLEEP_MODE packet
+ * @ctx: Context for multiple DSI transactions
+ *
+ * Like mipi_dsi_dcs_enter_sleep_mode() but deals with errors in a way that
+ * makes it convenient to make several calls in a row.
+ */
+void mipi_dsi_dcs_enter_sleep_mode_multi(struct mipi_dsi_multi_context *ctx)
+{
+ struct mipi_dsi_device *dsi = ctx->dsi;
+ struct device *dev = >dev;
+ ssize_t ret;
+
+ if (ctx->accum_err)
+ return;
+
+ ret = mipi_dsi_dcs_enter_sleep_mode(dsi);
+ if (ret < 0) {
+ ctx->accum_err = ret;
+ dev_err(dev, "sending DCS ENTER_SLEEP_MODE failed: %d\n",
+ ctx->accum_err);
+ }
+}
+EXPORT_SYMBOL(mipi_dsi_dcs_enter_sleep_mode_multi);
+
+/**
+ * mipi_dsi_dcs_exit_sleep_mode_multi() - send DCS EXIT_SLEEP_MODE packet
+ * @ctx: Context for multiple DSI transactions
+ *
+ * Like mipi_dsi_dcs_exit_sleep_mode() but deals with errors in a way that
+ * makes it convenient to make several calls in a row.
+ */
+void mipi_dsi_dcs_exit_sleep_mode_multi(struct mipi_dsi_multi_context *ctx)
+{
+ struct mipi_dsi_device *dsi = ctx->dsi;
+ struct device *dev = >dev;
+ ssize_t ret;
[PATCH RFC 5/7] drm/panel: novatek-nt36672e: use wrapped MIPI DCS functions
Remove conditional code and always use mipi_dsi_dcs_*multi() wrappers to
simplify driver's init/exit code. This also includes passing context to
the init_sequence() function instead of passing the DSI device.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-novatek-nt36672e.c | 587 -
1 file changed, 281 insertions(+), 306 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
b/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
index 9ce8df455232..f190285d75a1 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
@@ -33,7 +33,7 @@ struct panel_desc {
enum mipi_dsi_pixel_format format;
unsigned int lanes;
const char *panel_name;
- int (*init_sequence)(struct mipi_dsi_device *dsi);
+ void (*init_sequence)(struct mipi_dsi_multi_context *ctx);
};
struct nt36672e_panel {
@@ -49,297 +49,293 @@ static inline struct nt36672e_panel
*to_nt36672e_panel(struct drm_panel *panel)
return container_of(panel, struct nt36672e_panel, panel);
}
-static int nt36672e_1080x2408_60hz_init(struct mipi_dsi_device *dsi)
+static void nt36672e_1080x2408_60hz_init(struct mipi_dsi_multi_context *ctx)
{
- struct mipi_dsi_multi_context ctx = { .dsi = dsi };
-
- mipi_dsi_dcs_write_seq_multi(, 0xff, 0x10);
- mipi_dsi_dcs_write_seq_multi(, 0xfb, 0x01);
- mipi_dsi_dcs_write_seq_multi(, 0xb0, 0x00);
- mipi_dsi_dcs_write_seq_multi(, 0xc0, 0x00);
- mipi_dsi_dcs_write_seq_multi(, 0xc1, 0x89, 0x28, 0x00, 0x08, 0x00,
0xaa, 0x02,
+ mipi_dsi_dcs_write_seq_multi(ctx, 0xff, 0x10);
+ mipi_dsi_dcs_write_seq_multi(ctx, 0xfb, 0x01);
+ mipi_dsi_dcs_write_seq_multi(ctx, 0xb0, 0x00);
+ mipi_dsi_dcs_write_seq_multi(ctx, 0xc0, 0x00);
+ mipi_dsi_dcs_write_seq_multi(ctx, 0xc1, 0x89, 0x28, 0x00, 0x08, 0x00,
0xaa, 0x02,
0x0e, 0x00, 0x2b, 0x00, 0x07, 0x0d, 0xb7,
0x0c, 0xb7);
- mipi_dsi_dcs_write_seq_multi(, 0xc2, 0x1b, 0xa0);
- mipi_dsi_dcs_write_seq_multi(, 0xff, 0x20);
- mipi_dsi_dcs_write_seq_multi(, 0xfb, 0x01);
- mipi_dsi_dcs_write_seq_multi(, 0x01, 0x66);
- mipi_dsi_dcs_write_seq_multi(, 0x06, 0x40);
- mipi_dsi_dcs_write_seq_multi(, 0x07, 0x38);
- mipi_dsi_dcs_write_seq_multi(, 0x2f, 0x83);
- mipi_dsi_dcs_write_seq_multi(, 0x69, 0x91);
- mipi_dsi_dcs_write_seq_multi(, 0x95, 0xd1);
- mipi_dsi_dcs_write_seq_multi(, 0x96, 0xd1);
- mipi_dsi_dcs_write_seq_multi(, 0xf2, 0x64);
- mipi_dsi_dcs_write_seq_multi(, 0xf3, 0x54);
- mipi_dsi_dcs_write_seq_multi(, 0xf4, 0x64);
- mipi_dsi_dcs_write_seq_multi(, 0xf5, 0x54);
- mipi_dsi_dcs_write_seq_multi(, 0xf6, 0x64);
- mipi_dsi_dcs_write_seq_multi(, 0xf7, 0x54);
- mipi_dsi_dcs_write_seq_multi(, 0xf8, 0x64);
- mipi_dsi_dcs_write_seq_multi(, 0xf9, 0x54);
- mipi_dsi_dcs_write_seq_multi(, 0xff, 0x24);
- mipi_dsi_dcs_write_seq_multi(, 0xfb, 0x01);
- mipi_dsi_dcs_write_seq_multi(, 0x01, 0x0f);
- mipi_dsi_dcs_write_seq_multi(, 0x03, 0x0c);
- mipi_dsi_dcs_write_seq_multi(, 0x05, 0x1d);
- mipi_dsi_dcs_write_seq_multi(, 0x08, 0x2f);
- mipi_dsi_dcs_write_seq_multi(, 0x09, 0x2e);
- mipi_dsi_dcs_write_seq_multi(, 0x0a, 0x2d);
- mipi_dsi_dcs_write_seq_multi(, 0x0b, 0x2c);
- mipi_dsi_dcs_write_seq_multi(, 0x11, 0x17);
- mipi_dsi_dcs_write_seq_multi(, 0x12, 0x13);
- mipi_dsi_dcs_write_seq_multi(, 0x13, 0x15);
- mipi_dsi_dcs_write_seq_multi(, 0x15, 0x14);
- mipi_dsi_dcs_write_seq_multi(, 0x16, 0x16);
- mipi_dsi_dcs_write_seq_multi(, 0x17, 0x18);
- mipi_dsi_dcs_write_seq_multi(, 0x1b, 0x01);
- mipi_dsi_dcs_write_seq_multi(, 0x1d, 0x1d);
- mipi_dsi_dcs_write_seq_multi(, 0x20, 0x2f);
- mipi_dsi_dcs_write_seq_multi(, 0x21, 0x2e);
- mipi_dsi_dcs_write_seq_multi(, 0x22, 0x2d);
- mipi_dsi_dcs_write_seq_multi(, 0x23, 0x2c);
- mipi_dsi_dcs_write_seq_multi(, 0x29, 0x17);
- mipi_dsi_dcs_write_seq_multi(, 0x2a, 0x13);
- mipi_dsi_dcs_write_seq_multi(, 0x2b, 0x15);
- mipi_dsi_dcs_write_seq_multi(, 0x2f, 0x14);
- mipi_dsi_dcs_write_seq_multi(, 0x30, 0x16);
- mipi_dsi_dcs_write_seq_multi(, 0x31, 0x18);
- mipi_dsi_dcs_write_seq_multi(, 0x32, 0x04);
- mipi_dsi_dcs_write_seq_multi(, 0x34, 0x10);
- mipi_dsi_dcs_write_seq_multi(, 0x35, 0x1f);
- mipi_dsi_dcs_write_seq_multi(, 0x36, 0x1f);
- mipi_dsi_dcs_write_seq_multi(, 0x4d, 0x14);
- mipi_dsi_dcs_write_seq_multi(, 0x4e, 0x36);
- mipi_dsi_dcs_write_seq_multi(, 0x4f, 0x36);
- mipi_dsi_dcs_write_seq_multi(, 0x53, 0x36);
- mipi_dsi_dcs_write_seq_multi(, 0x71, 0x30);
- mipi_dsi_dcs_write_seq_multi(, 0x79, 0x11);
- mipi_dsi_dcs_write_seq_multi(, 0x7a, 0x82);
- mipi_dsi_dcs_write_seq_multi(, 0x7b, 0x8f);
-
[PATCH RFC 0/7] drm/mipi-dsi: simplify MIPI DSI init/cleanup even more
Follow the example of mipi_dsi_generic_write_multi(), mipi_dsi_dcs_write_buffer_multi(), mipi_dsi_generic_write_seq_multi() and mipi_dsi_dcs_write_seq_multi(). Define _multi variants for several other common MIPI DSI functions and use these functions in the panel code. This series also includes a fix for the LG SW43408. If the proposed approach is declined, the fix will be submitted separately. Depends: https://lore.kernel.org/dri-devel/20240508205222.2251854-1-diand...@chromium.org/ Signed-off-by: Dmitry Baryshkov --- Dmitry Baryshkov (7): drm/mipi-dsi: wrap more functions for streamline handling drm/panel: boe-tv101wum-nl6: use wrapped MIPI DCS functions drm/panel: ilitek-ili9882t: use wrapped MIPI DCS functions drm/panel: innolux-p079zca: use mipi_dsi_dcs_nop_multi() drm/panel: novatek-nt36672e: use wrapped MIPI DCS functions drm/panel: lg-sw43408: add missing error handling drm/panel: lg-sw43408: use new streamlined MIPI DSI API drivers/gpu/drm/drm_mipi_dsi.c | 209 + drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 73 +-- drivers/gpu/drm/panel/panel-ilitek-ili9882t.c | 30 +- drivers/gpu/drm/panel/panel-innolux-p079zca.c | 9 +- drivers/gpu/drm/panel/panel-lg-sw43408.c | 74 ++-- drivers/gpu/drm/panel/panel-novatek-nt36672e.c | 587 - include/drm/drm_mipi_dsi.h | 19 + 7 files changed, 578 insertions(+), 423 deletions(-) --- base-commit: c09cb909a4fba9c42baa343bb9a84986c15d5f01 change-id: 20240510-dsi-panels-upd-api-479adb2b0e01 Best regards, -- Dmitry Baryshkov
Re: [PATCH v6 0/7] Adds support for ConfigFS to VKMS!
Sima--thanks SO MUCH for going through with everything leaving a detailed review. I am excited to go through your feedback. It makes me extremely happy to see these patches get people excited. They've bounced between a few people, and I recently asked to take them over again from the folks who were most recently looking at them but haven't since had capacity to revisit them. I'd love to contribute more but I am currently pretty swamped and I probably couldn't realistically make too much headway before the middle of June. José--if you've got capacity and interest, I'd love to see this work get in! Thanks!! Please let me know your timeline and if you want to split anything up or have any questions, I'd love to help if possible. But most important to me is seeing the community benefit from the feature. And (in case it got lost in the shuffle of all these patches) the IGT tests really make it much easier to develop this thing. Marius has posted the most recent patches: https://lore.kernel.org/igt-dev/?q=configfs Thanks! -- Jim On Wed, May 8, 2024 at 2:17 PM José Expósito wrote: > > Hi everyone, > > I wasn't aware of these patches, but I'm really glad they are getting > some attention, thanks a lot for your review Sima. > > Given that it's been a while since the patches were emailed, I'm not > sure if the original authors of the patches could implement your > comments. If not, I can work on it. Please let me know. > > I'm working on a Mutter feature that'd greatly benefit from this uapi > and I'm sure other compositors would find it useful. > > I'll start working on a new version in a few days if nobody else is > already working on it. > > Best wishes, > José Expósito
[PATCH v2 2/2] drm/panel/lg-sw43408: mark sw43408_backlight_ops as static
Fix sparse warning regarding symbol 'sw43408_backlight_ops' not being
declared.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202404200739.hbwzvohr-...@intel.com/
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-lg-sw43408.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-lg-sw43408.c
b/drivers/gpu/drm/panel/panel-lg-sw43408.c
index 115f4702d59f..2b3a73696dce 100644
--- a/drivers/gpu/drm/panel/panel-lg-sw43408.c
+++ b/drivers/gpu/drm/panel/panel-lg-sw43408.c
@@ -182,7 +182,7 @@ static int sw43408_backlight_update_status(struct
backlight_device *bl)
return mipi_dsi_dcs_set_display_brightness_large(dsi, brightness);
}
-const struct backlight_ops sw43408_backlight_ops = {
+static const struct backlight_ops sw43408_backlight_ops = {
.update_status = sw43408_backlight_update_status,
};
--
2.39.2
[PATCH v2 1/2] drm/panel/lg-sw43408: select CONFIG_DRM_DISPLAY_DP_HELPER
This panel driver uses DSC PPS functions and as such depends on the DRM_DISPLAY_DP_HELPER. Select this symbol to make required functions available to the driver. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202404200800.kysryyli-...@intel.com/ Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/panel/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index 982324ef5a41..2ae0eb0638f3 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -340,6 +340,8 @@ config DRM_PANEL_LG_SW43408 depends on OF depends on DRM_MIPI_DSI depends on BACKLIGHT_CLASS_DEVICE + select DRM_DISPLAY_DP_HELPER + select DRM_DISPLAY_HELPER help Say Y here if you want to enable support for LG sw43408 panel. The panel has a 1080x2160@60Hz resolution and uses 24 bit RGB per -- 2.39.2
[PATCH v2 0/2] drm/panel: two fixes for lg-sw43408
Fix two issues with the panel-lg-sw43408 driver reported by the kernel test robot. Signed-off-by: Dmitry Baryshkov --- Changes in v2: - use SELECT instead of DEPEND to follow the reverted Kconfig changes - Link to v1: https://lore.kernel.org/r/20240420-panel-sw43408-fix-v1-0-b282ff725...@linaro.org --- Dmitry Baryshkov (2): drm/panel/lg-sw43408: select CONFIG_DRM_DISPLAY_DP_HELPER drm/panel/lg-sw43408: mark sw43408_backlight_ops as static drivers/gpu/drm/panel/Kconfig| 2 ++ drivers/gpu/drm/panel/panel-lg-sw43408.c | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) --- base-commit: 704ba27ac55579704ba1289392448b0c66b56258 change-id: 20240420-panel-sw43408-fix-ff6549c121be Best regards, -- Dmitry Baryshkov
[PATCH v7 6/8] math.h Add macros to round to closest specified power of 2
Add macros to round to nearest specified power of 2. Two macros are added : round_closest_up and round_closest_down which round up to nearest multiple of 2 with a preference to round up or round down respectively if there are two possible nearest values to the given number. This patch is inspired from the Mentor Graphics IPU driver [1] which uses similar macro locally and which can be updated to use this generic macro instead along with other drivers having similar requirements. [1]: https://elixir.bootlin.com/linux/v6.8.9/source/drivers/gpu/ipu-v3/ipu-image-convert.c#L480 Signed-off-by: Devarsh Thakkar --- V1->V6 (No change, patch introduced in V7) --- include/linux/math.h | 36 1 file changed, 36 insertions(+) diff --git a/include/linux/math.h b/include/linux/math.h index dd4152711de7..82ee3265c910 100644 --- a/include/linux/math.h +++ b/include/linux/math.h @@ -34,6 +34,42 @@ */ #define round_down(x, y) ((x) & ~__round_mask(x, y)) +/** + * round_closest_up - round to nearest specified power of 2 with preference + * to rounding up + * @x: the value to round + * @y: multiple to round to (must be a power of 2) + * + * Rounds @x to nearest multiple of @y (which must be a power of 2). + * The rounded value can be greater than or less than @x depending + * upon it's nearness to @x. If there are two nearest possible values, + * then preference will be given to the greater value. + * + * Examples : + * round_closest_up(17, 4) = 16 + * round_closest_up(15, 4) = 16 + * round_closest_up(14, 4) = 16 + */ +#define round_closest_up(x, y) round_down((x) + (y) / 2, (y)) + +/** + * round_closest_down - round to nearest specified power of 2 with preference + * to rounding down + * @x: the value to round + * @y: multiple to round down to (must be a power of 2) + * + * Rounds @x to nearest multiple of @y (which must be a power of 2). + * The rounded value can be greater than or less than @x depending + * upon it's nearness to @x. If there are two nearest possible values, + * then preference will be given to the lesser value. + * + * Examples : + * round_closest_down(17, 4) = 16 + * round_closest_down(15, 4) = 16 + * round_closest_down(14, 4) = 12 + */ +#define round_closest_down(x, y) round_up((x) - (y) / 2, (y)) + #define DIV_ROUND_UP __KERNEL_DIV_ROUND_UP #define DIV_ROUND_DOWN_ULL(ll, d) \ -- 2.39.1
Re: [PATCH v4] drm/nouveau: use tile_mode and pte_kind for VM_BIND bo allocations
On Thu, May 9, 2024 at 3:44 PM Mohamed Ahmed <
mohamedahmedegypt2...@gmail.com> wrote:
> Allows PTE kind and tile mode on BO create with VM_BIND,
> and adds a GETPARAM to indicate this change. This is needed to support
> modifiers in NVK and ensure correctness when dealing with the nouveau
> GL driver.
>
> The userspace modifiers implementation this is for can be found here:
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24795
>
> Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI")
> Signed-off-by: Mohamed Ahmed
>
Reviewed-by: Faith Ekstrand
> ---
> drivers/gpu/drm/nouveau/nouveau_abi16.c | 3 ++
> drivers/gpu/drm/nouveau/nouveau_bo.c| 44 +++--
> include/uapi/drm/nouveau_drm.h | 7
> 3 files changed, 29 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
> b/drivers/gpu/drm/nouveau/nouveau_abi16.c
> index 80f74ee0f..47e53e17b 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
> @@ -272,6 +272,9 @@ nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS)
> getparam->value =
> (u64)ttm_resource_manager_usage(vram_mgr);
> break;
> }
> + case NOUVEAU_GETPARAM_HAS_VMA_TILEMODE:
> + getparam->value = 1;
> + break;
> default:
> NV_PRINTK(dbg, cli, "unknown parameter %lld\n",
> getparam->param);
> return -EINVAL;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index db8cbf615..186add400 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -241,28 +241,28 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size,
> int *align, u32 domain,
> }
>
> nvbo->contig = !(tile_flags & NOUVEAU_GEM_TILE_NONCONTIG);
> - if (!nouveau_cli_uvmm(cli) || internal) {
> - /* for BO noVM allocs, don't assign kinds */
> - if (cli->device.info.family >= NV_DEVICE_INFO_V0_FERMI) {
> - nvbo->kind = (tile_flags & 0xff00) >> 8;
> - if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
> - kfree(nvbo);
> - return ERR_PTR(-EINVAL);
> - }
>
> - nvbo->comp = mmu->kind[nvbo->kind] != nvbo->kind;
> - } else if (cli->device.info.family >=
> NV_DEVICE_INFO_V0_TESLA) {
> - nvbo->kind = (tile_flags & 0x7f00) >> 8;
> - nvbo->comp = (tile_flags & 0x0003) >> 16;
> - if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
> - kfree(nvbo);
> - return ERR_PTR(-EINVAL);
> - }
> - } else {
> - nvbo->zeta = (tile_flags & 0x0007);
> + if (cli->device.info.family >= NV_DEVICE_INFO_V0_FERMI) {
> + nvbo->kind = (tile_flags & 0xff00) >> 8;
> + if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
> + kfree(nvbo);
> + return ERR_PTR(-EINVAL);
> + }
> +
> + nvbo->comp = mmu->kind[nvbo->kind] != nvbo->kind;
> + } else if (cli->device.info.family >= NV_DEVICE_INFO_V0_TESLA) {
> + nvbo->kind = (tile_flags & 0x7f00) >> 8;
> + nvbo->comp = (tile_flags & 0x0003) >> 16;
> + if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
> + kfree(nvbo);
> + return ERR_PTR(-EINVAL);
> }
> - nvbo->mode = tile_mode;
> + } else {
> + nvbo->zeta = (tile_flags & 0x0007);
> + }
> + nvbo->mode = tile_mode;
>
> + if (!nouveau_cli_uvmm(cli) || internal) {
> /* Determine the desirable target GPU page size for the
> buffer. */
> for (i = 0; i < vmm->page_nr; i++) {
> /* Because we cannot currently allow VMM maps to
> fail
> @@ -304,12 +304,6 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size,
> int *align, u32 domain,
> }
> nvbo->page = vmm->page[pi].shift;
> } else {
> - /* reject other tile flags when in VM mode. */
> - if (tile_mode)
> - return ERR_PTR(-EINVAL);
> - if (tile_flags & ~NOUVEAU_GEM_TILE_NONCONTIG)
> - return ERR_PTR(-EINVAL);
> -
> /* Determine the desirable target GPU page size for the
> buffer. */
> for (i = 0; i < vmm->page_nr; i++) {
> /* Because we cannot currently allow VMM maps to
> fail
> diff --git a/include/uapi/drm/nouveau_drm.h
> b/include/uapi/drm/nouveau_drm.h
> index cd84227f1..5402f77ee 100644
> ---
[PATCH v4] drm/nouveau: use tile_mode and pte_kind for VM_BIND bo allocations
Allows PTE kind and tile mode on BO create with VM_BIND,
and adds a GETPARAM to indicate this change. This is needed to support
modifiers in NVK and ensure correctness when dealing with the nouveau
GL driver.
The userspace modifiers implementation this is for can be found here:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24795
Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI")
Signed-off-by: Mohamed Ahmed
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 3 ++
drivers/gpu/drm/nouveau/nouveau_bo.c| 44 +++--
include/uapi/drm/nouveau_drm.h | 7
3 files changed, 29 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index 80f74ee0f..47e53e17b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -272,6 +272,9 @@ nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS)
getparam->value = (u64)ttm_resource_manager_usage(vram_mgr);
break;
}
+ case NOUVEAU_GETPARAM_HAS_VMA_TILEMODE:
+ getparam->value = 1;
+ break;
default:
NV_PRINTK(dbg, cli, "unknown parameter %lld\n",
getparam->param);
return -EINVAL;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index db8cbf615..186add400 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -241,28 +241,28 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int
*align, u32 domain,
}
nvbo->contig = !(tile_flags & NOUVEAU_GEM_TILE_NONCONTIG);
- if (!nouveau_cli_uvmm(cli) || internal) {
- /* for BO noVM allocs, don't assign kinds */
- if (cli->device.info.family >= NV_DEVICE_INFO_V0_FERMI) {
- nvbo->kind = (tile_flags & 0xff00) >> 8;
- if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
- kfree(nvbo);
- return ERR_PTR(-EINVAL);
- }
- nvbo->comp = mmu->kind[nvbo->kind] != nvbo->kind;
- } else if (cli->device.info.family >= NV_DEVICE_INFO_V0_TESLA) {
- nvbo->kind = (tile_flags & 0x7f00) >> 8;
- nvbo->comp = (tile_flags & 0x0003) >> 16;
- if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
- kfree(nvbo);
- return ERR_PTR(-EINVAL);
- }
- } else {
- nvbo->zeta = (tile_flags & 0x0007);
+ if (cli->device.info.family >= NV_DEVICE_INFO_V0_FERMI) {
+ nvbo->kind = (tile_flags & 0xff00) >> 8;
+ if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
+ kfree(nvbo);
+ return ERR_PTR(-EINVAL);
+ }
+
+ nvbo->comp = mmu->kind[nvbo->kind] != nvbo->kind;
+ } else if (cli->device.info.family >= NV_DEVICE_INFO_V0_TESLA) {
+ nvbo->kind = (tile_flags & 0x7f00) >> 8;
+ nvbo->comp = (tile_flags & 0x0003) >> 16;
+ if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
+ kfree(nvbo);
+ return ERR_PTR(-EINVAL);
}
- nvbo->mode = tile_mode;
+ } else {
+ nvbo->zeta = (tile_flags & 0x0007);
+ }
+ nvbo->mode = tile_mode;
+ if (!nouveau_cli_uvmm(cli) || internal) {
/* Determine the desirable target GPU page size for the buffer.
*/
for (i = 0; i < vmm->page_nr; i++) {
/* Because we cannot currently allow VMM maps to fail
@@ -304,12 +304,6 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int
*align, u32 domain,
}
nvbo->page = vmm->page[pi].shift;
} else {
- /* reject other tile flags when in VM mode. */
- if (tile_mode)
- return ERR_PTR(-EINVAL);
- if (tile_flags & ~NOUVEAU_GEM_TILE_NONCONTIG)
- return ERR_PTR(-EINVAL);
-
/* Determine the desirable target GPU page size for the buffer.
*/
for (i = 0; i < vmm->page_nr; i++) {
/* Because we cannot currently allow VMM maps to fail
diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
index cd84227f1..5402f77ee 100644
--- a/include/uapi/drm/nouveau_drm.h
+++ b/include/uapi/drm/nouveau_drm.h
@@ -68,6 +68,13 @@ extern "C" {
*/
#define NOUVEAU_GETPARAM_VRAM_USED 19
+/*
+ * NOUVEAU_GETPARAM_HAS_VMA_TILEMODE
+ *
+ * Query whether tile mode and PTE kind are accepted with VM allocs or not.
+ */
+#define NOUVEAU_GETPARAM_HAS_VMA_TILEMODE 20
+
struct drm_nouveau_getparam {
Re: [PATCH v2] drm/msm/dpu: fix encoder irq wait skip
On Thu, 9 May 2024 at 22:40, Barnabás Czémán wrote:
>
> The irq_idx is unsigned so it cannot be lower than zero, better
> to change the condition to check if it is equal with zero.
> It could not cause any issue because a valid irq index starts from one.
>
> Fixes: 5a9d50150c2c ("drm/msm/dpu: shift IRQ indices by 1")
> Signed-off-by: Barnabás Czémán
In the previous revision you have got the Reviewed-by tag, which you
didn't include here for some reason.
This revision is:
Reviewed-by: Dmitry Baryshkov
Note, there is no need to send a next iteration just for these tags.
They usually get picked up by the patch management software (including
the Fixes tag).
> ---
> Changes in v2:
> - Add Fixes in commit message.
> - Link to v1:
> https://lore.kernel.org/r/20240509-irq_wait-v1-1-41d653e37...@gmail.com
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 119f3ea50a7c..cf7d769ab3b9 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -428,7 +428,7 @@ int dpu_encoder_helper_wait_for_irq(struct
> dpu_encoder_phys *phys_enc,
> return -EWOULDBLOCK;
> }
>
> - if (irq_idx < 0) {
> + if (irq_idx == 0) {
> DRM_DEBUG_KMS("skip irq wait id=%u, callback=%ps\n",
> DRMID(phys_enc->parent), func);
> return 0;
>
> ---
> base-commit: 704ba27ac55579704ba1289392448b0c66b56258
> change-id: 20240509-irq_wait-49444cea77e2
>
> Best regards,
> --
> Barnabás Czémán
>
--
With best wishes
Dmitry
Re: [PATCH v2] drm/msm/dpu: fix encoder irq wait skip
On 5/9/2024 12:40 PM, Barnabás Czémán wrote:
The irq_idx is unsigned so it cannot be lower than zero, better
to change the condition to check if it is equal with zero.
It could not cause any issue because a valid irq index starts from one.
Fixes: 5a9d50150c2c ("drm/msm/dpu: shift IRQ indices by 1")
Signed-off-by: Barnabás Czémán
---
Changes in v2:
- Add Fixes in commit message.
- Link to v1:
https://lore.kernel.org/r/20240509-irq_wait-v1-1-41d653e37...@gmail.com
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
no functional change, so you could have retained by R-b, but here it is
again,
Reviewed-by: Abhinav Kumar
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 119f3ea50a7c..cf7d769ab3b9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -428,7 +428,7 @@ int dpu_encoder_helper_wait_for_irq(struct dpu_encoder_phys
*phys_enc,
return -EWOULDBLOCK;
}
- if (irq_idx < 0) {
+ if (irq_idx == 0) {
DRM_DEBUG_KMS("skip irq wait id=%u, callback=%ps\n",
DRMID(phys_enc->parent), func);
return 0;
---
base-commit: 704ba27ac55579704ba1289392448b0c66b56258
change-id: 20240509-irq_wait-49444cea77e2
Best regards,
[PATCH v7 8/8] gpu: ipu-v3: Use generic macro for rounding to nearest multiple
Use generic macro round_closest_up for rounding to nearest multiple instead of using local function. Signed-off-by: Devarsh Thakkar --- V1->V6 (No change, patch introduced in V7) --- drivers/gpu/ipu-v3/ipu-image-convert.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/ipu-v3/ipu-image-convert.c b/drivers/gpu/ipu-v3/ipu-image-convert.c index 841316582ea9..5192a8b5c02c 100644 --- a/drivers/gpu/ipu-v3/ipu-image-convert.c +++ b/drivers/gpu/ipu-v3/ipu-image-convert.c @@ -477,8 +477,6 @@ static int calc_image_resize_coefficients(struct ipu_image_convert_ctx *ctx, return 0; } -#define round_closest(x, y) round_down((x) + (y)/2, (y)) - /* * Find the best aligned seam position for the given column / row index. * Rotation and image offsets are out of scope. @@ -565,7 +563,7 @@ static void find_best_seam(struct ipu_image_convert_ctx *ctx, * The closest input sample position that we could actually * start the input tile at, 19.13 fixed point. */ - in_pos_aligned = round_closest(in_pos, 8192U * in_align); + in_pos_aligned = round_closest_up(in_pos, 8192U * in_align); /* Convert 19.13 fixed point to integer */ in_pos_rounded = in_pos_aligned / 8192U; -- 2.39.1
[PATCH v2] drm/msm/dpu: fix encoder irq wait skip
The irq_idx is unsigned so it cannot be lower than zero, better
to change the condition to check if it is equal with zero.
It could not cause any issue because a valid irq index starts from one.
Fixes: 5a9d50150c2c ("drm/msm/dpu: shift IRQ indices by 1")
Signed-off-by: Barnabás Czémán
---
Changes in v2:
- Add Fixes in commit message.
- Link to v1:
https://lore.kernel.org/r/20240509-irq_wait-v1-1-41d653e37...@gmail.com
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 119f3ea50a7c..cf7d769ab3b9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -428,7 +428,7 @@ int dpu_encoder_helper_wait_for_irq(struct dpu_encoder_phys
*phys_enc,
return -EWOULDBLOCK;
}
- if (irq_idx < 0) {
+ if (irq_idx == 0) {
DRM_DEBUG_KMS("skip irq wait id=%u, callback=%ps\n",
DRMID(phys_enc->parent), func);
return 0;
---
base-commit: 704ba27ac55579704ba1289392448b0c66b56258
change-id: 20240509-irq_wait-49444cea77e2
Best regards,
--
Barnabás Czémán
Re: [PATCH] drm/msm/dpu: guard ctl irq callback register/unregister
There was some previously sent patch series made by Dmitry for these soc, msm8996 was sent together by sdm660 but in the last version it was dropped. I have recreated msm8996 DPU support from that series but it will need some more test. I am testing msm8953 series but it is depend on msm8996.
Re: [PATCH] drm/msm/dpu: fix encoder irq wait skip
On 5/9/2024 10:39 AM, Barnabás Czémán wrote:
The irq_idx is unsigned so it cannot be lower than zero, better
to change the condition to check if it is equal with zero.
It could not cause any issue because a valid irq index starts from one.
Signed-off-by: Barnabás Czémán
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
I think we also need
Fixes: 5a9d50150c2c ("drm/msm/dpu: shift IRQ indices by 1")
With that,
Reviewed-by: Abhinav Kumar
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 119f3ea50a7c..cf7d769ab3b9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -428,7 +428,7 @@ int dpu_encoder_helper_wait_for_irq(struct dpu_encoder_phys
*phys_enc,
return -EWOULDBLOCK;
}
- if (irq_idx < 0) {
+ if (irq_idx == 0) {
DRM_DEBUG_KMS("skip irq wait id=%u, callback=%ps\n",
DRMID(phys_enc->parent), func);
return 0;
---
base-commit: 704ba27ac55579704ba1289392448b0c66b56258
change-id: 20240509-irq_wait-49444cea77e2
Best regards,
[PULL] drm-xe-fixes
Hi Dave and Sima, Please pull the drm-xe-fixes for this week targeting v6.9. thanks Lucas De Marchi drm-xe-fixes-2024-05-09: - Fix use zero-length element array - Move more from system wq to ordered private wq - Do not ignore return for drmm_mutex_init The following changes since commit dd5a440a31fae6e459c0d627162825505361: Linux 6.9-rc7 (2024-05-05 14:06:01 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/drm/xe/kernel.git tags/drm-xe-fixes-2024-05-09 for you to fetch changes up to c002bfe644a29ba600c571f2abba13a155a12dcd: drm/xe: Use ordered WQ for G2H handler (2024-05-09 09:41:27 -0500) - Fix use zero-length element array - Move more from system wq to ordered private wq - Do not ignore return for drmm_mutex_init Daniele Ceraolo Spurio (1): drm/xe/guc: Check error code when initializing the CT mutex Lucas De Marchi (1): drm/xe/ads: Use flexible-array Matthew Brost (1): drm/xe: Use ordered WQ for G2H handler drivers/gpu/drm/xe/xe_guc_ads.c | 2 +- drivers/gpu/drm/xe/xe_guc_ct.c | 10 +- drivers/gpu/drm/xe/xe_guc_ct.h | 2 +- drivers/gpu/drm/xe/xe_guc_ct_types.h | 2 ++ 4 files changed, 13 insertions(+), 3 deletions(-)
Re: [PATCH] drm/mst: Fix NULL pointer dereference at drm_dp_add_payload_part2
On 5/9/2024 07:43, Linux regression tracking (Thorsten Leemhuis) wrote:
On 18.04.24 21:43, Harry Wentland wrote:
On 2024-03-07 01:29, Wayne Lin wrote:
[Why]
Commit:
- commit 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
allocation/removement")
accidently overwrite the commit
- commit 54d217406afe ("drm: use mgr->dev in drm_dbg_kms in
drm_dp_add_payload_part2")
which cause regression.
[How]
Recover the original NULL fix and remove the unnecessary input parameter
'state' for
drm_dp_add_payload_part2().
Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
allocation/removement")
Reported-by: Leon Weiß
Link:
https://lore.kernel.org/r/38c253ea42072cc825dc969ac4e6b9b600371cc8.ca...@ruhr-uni-bochum.de/
Cc: ly...@redhat.com
Cc: imre.d...@intel.com
Cc: sta...@vger.kernel.org
Cc: regressi...@lists.linux.dev
Signed-off-by: Wayne Lin
I haven't been deep in MST code in a while but this all looks
pretty straightforward and good.
Reviewed-by: Harry Wentland
Hmmm, that was three weeks ago, but it seems since then nothing happened
to fix the linked regression through this or some other patch. Is there
a reason? The build failure report from the CI maybe?
It touches files outside of amd but only has an ack from AMD. I think
we /probably/ want an ack from i915 and nouveau to take it through.
Wayne Lin, do you know what's up?
Ciao, Thorsten
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
drivers/gpu/drm/display/drm_dp_mst_topology.c | 4 +---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
include/drm/display/drm_dp_mst_helper.h | 1 -
5 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index c27063305a13..2c36f3d00ca2 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -363,7 +363,7 @@ void dm_helpers_dp_mst_send_payload_allocation(
mst_state = to_drm_dp_mst_topology_state(mst_mgr->base.state);
new_payload = drm_atomic_get_mst_payload_state(mst_state,
aconnector->mst_output_port);
- ret = drm_dp_add_payload_part2(mst_mgr, mst_state->base.state, new_payload);
+ ret = drm_dp_add_payload_part2(mst_mgr, new_payload);
if (ret) {
amdgpu_dm_set_mst_status(>mst_status,
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 03d528209426..95fd18f24e94 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3421,7 +3421,6 @@ EXPORT_SYMBOL(drm_dp_remove_payload_part2);
/**
* drm_dp_add_payload_part2() - Execute payload update part 2
* @mgr: Manager to use.
- * @state: The global atomic state
* @payload: The payload to update
*
* If @payload was successfully assigned a starting time slot by
drm_dp_add_payload_part1(), this
@@ -3430,14 +3429,13 @@ EXPORT_SYMBOL(drm_dp_remove_payload_part2);
* Returns: 0 on success, negative error code on failure.
*/
int drm_dp_add_payload_part2(struct drm_dp_mst_topology_mgr *mgr,
-struct drm_atomic_state *state,
struct drm_dp_mst_atomic_payload *payload)
{
int ret = 0;
/* Skip failed payloads */
if (payload->payload_allocation_status !=
DRM_DP_MST_PAYLOAD_ALLOCATION_DFP) {
- drm_dbg_kms(state->dev, "Part 1 of payload creation for %s failed,
skipping part 2\n",
+ drm_dbg_kms(mgr->dev, "Part 1 of payload creation for %s failed,
skipping part 2\n",
payload->port->connector->name);
return -EIO;
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 53aec023ce92..2fba66aec038 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -1160,7 +1160,7 @@ static void intel_mst_enable_dp(struct intel_atomic_state
*state,
if (first_mst_stream)
intel_ddi_wait_for_fec_status(encoder, pipe_config, true);
- drm_dp_add_payload_part2(_dp->mst_mgr, >base,
+ drm_dp_add_payload_part2(_dp->mst_mgr,
drm_atomic_get_mst_payload_state(mst_state,
connector->port));
if (DISPLAY_VER(dev_priv) >= 12)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 0c3d88ad0b0e..88728a0b2c25 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -915,7 +915,7 @@ nv50_msto_cleanup(struct drm_atomic_state *state,
msto->disabled = false;
drm_dp_remove_payload_part2(mgr, new_mst_state,
Re: [PATCH] drm/msm/dpu: guard ctl irq callback register/unregister
On 5/9/2024 10:52 AM, Barnabás Czémán wrote: CTLs on older qualcomm SOCs like msm8953 and msm8996 has not got interrupts, so better to skip CTL irq callback register/unregister make dpu_ctl_cfg be able to define without intr_start. Thanks for the patch. Have msm8953 and msm8996 migrated to DPU or is there a series planned to migrate them? The change itself is correct but without the catalogs for those chipsets merged, we will never hit this path. Signed-off-by: Barnabás Czémán --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c index 489be1c0c704..250d83af53a4 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c @@ -298,7 +298,7 @@ static void dpu_encoder_phys_cmd_irq_enable(struct dpu_encoder_phys *phys_enc) phys_enc); dpu_encoder_phys_cmd_control_vblank_irq(phys_enc, true); - if (dpu_encoder_phys_cmd_is_master(phys_enc)) + if (dpu_encoder_phys_cmd_is_master(phys_enc) && phys_enc->irq[INTR_IDX_CTL_START]) dpu_core_irq_register_callback(phys_enc->dpu_kms, phys_enc->irq[INTR_IDX_CTL_START], dpu_encoder_phys_cmd_ctl_start_irq, @@ -311,7 +311,7 @@ static void dpu_encoder_phys_cmd_irq_disable(struct dpu_encoder_phys *phys_enc) phys_enc->hw_pp->idx - PINGPONG_0, phys_enc->vblank_refcount); - if (dpu_encoder_phys_cmd_is_master(phys_enc)) + if (dpu_encoder_phys_cmd_is_master(phys_enc) && phys_enc->irq[INTR_IDX_CTL_START]) dpu_core_irq_unregister_callback(phys_enc->dpu_kms, phys_enc->irq[INTR_IDX_CTL_START]); --- base-commit: 704ba27ac55579704ba1289392448b0c66b56258 change-id: 20240509-ctl_irq-a90b2d7a0bf5 Best regards,
Re: [PATCH] docs: document python version used for compilation
On 5/9/2024 9:48 AM, Jonathan Corbet wrote: Dmitry Baryshkov writes: The drm/msm driver had adopted using Python3 script to generate register header files instead of shipping pre-generated header files. Document the minimal Python version supported by the script. Signed-off-by: Dmitry Baryshkov --- Documentation/process/changes.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst index 5685d7bfe4d0..8d225a9f65a2 100644 --- a/Documentation/process/changes.rst +++ b/Documentation/process/changes.rst @@ -63,6 +63,7 @@ cpio any cpio --version GNU tar1.28 tar --version gtags (optional) 6.6.5gtags --version mkimage (optional) 2017.01 mkimage --version +Python (optional) 3.5.xpython3 --version == === Is it really optional - can you build the driver without it? True, we cannot build the driver now without it. So we should be dropping the optional tag. With that addressed, Reviewed-by: Abhinav Kumar This document needs some help... I'm missing a number of things that are *not* marked as "optional" (jfsutils, reiserfsprogs, pcmciautils, ppp, ...) and somehow my system works fine :) It would be nice to document *why* users might need a specific tool. But I guess we aren't going to do that now. I can apply this, but I do wonder about the "optional" marking. Thanks, jon
[PATCH v2] drm/msm/adreno: De-spaghettify the use of memory barriers
return readl(gpu->mmio + (reg << 2)); + gpu_write(gpu, reg, data); + gpu_read(gpu, reg); } static inline void gpu_rmw(struct msm_gpu *gpu, u32 reg, u32 mask, u32 or) --- base-commit: ec2d9beb604a623a9f5308f7abcff3561e08c155 change-id: 20240509-topic-adreno-a8939b92f625 Best regards, -- Konrad Dybcio
[PATCH] drm/panel: jdi-fhd-r63452: move DCS off commands to disable
Move DCS off commands from .unprepare to .disable so that they
actually reach the DSI host.
Signed-off-by: Barnabás Czémán
---
drivers/gpu/drm/panel/panel-jdi-fhd-r63452.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-jdi-fhd-r63452.c
b/drivers/gpu/drm/panel/panel-jdi-fhd-r63452.c
index 483dc88d16d8..f7222974d6ed 100644
--- a/drivers/gpu/drm/panel/panel-jdi-fhd-r63452.c
+++ b/drivers/gpu/drm/panel/panel-jdi-fhd-r63452.c
@@ -169,6 +169,15 @@ static int jdi_fhd_r63452_prepare(struct drm_panel *panel)
}
static int jdi_fhd_r63452_unprepare(struct drm_panel *panel)
+{
+ struct jdi_fhd_r63452 *ctx = to_jdi_fhd_r63452(panel);
+
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+
+ return 0;
+}
+
+static int jdi_fhd_r63452_disable(struct drm_panel *panel)
{
struct jdi_fhd_r63452 *ctx = to_jdi_fhd_r63452(panel);
struct device *dev = >dsi->dev;
@@ -178,8 +187,6 @@ static int jdi_fhd_r63452_unprepare(struct drm_panel *panel)
if (ret < 0)
dev_err(dev, "Failed to un-initialize panel: %d\n", ret);
- gpiod_set_value_cansleep(ctx->reset_gpio, 1);
-
return 0;
}
@@ -219,6 +226,7 @@ static int jdi_fhd_r63452_get_modes(struct drm_panel *panel,
static const struct drm_panel_funcs jdi_fhd_r63452_panel_funcs = {
.prepare = jdi_fhd_r63452_prepare,
.unprepare = jdi_fhd_r63452_unprepare,
+ .disable = jdi_fhd_r63452_disable,
.get_modes = jdi_fhd_r63452_get_modes,
};
---
base-commit: 704ba27ac55579704ba1289392448b0c66b56258
change-id: 20240509-jdi-use-disable-ee29098d9c81
Best regards,
--
Barnabás Czémán
[PATCH] drm/msm/dpu: guard ctl irq callback register/unregister
CTLs on older qualcomm SOCs like msm8953 and msm8996 has not got interrupts, so better to skip CTL irq callback register/unregister make dpu_ctl_cfg be able to define without intr_start. Signed-off-by: Barnabás Czémán --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c index 489be1c0c704..250d83af53a4 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c @@ -298,7 +298,7 @@ static void dpu_encoder_phys_cmd_irq_enable(struct dpu_encoder_phys *phys_enc) phys_enc); dpu_encoder_phys_cmd_control_vblank_irq(phys_enc, true); - if (dpu_encoder_phys_cmd_is_master(phys_enc)) + if (dpu_encoder_phys_cmd_is_master(phys_enc) && phys_enc->irq[INTR_IDX_CTL_START]) dpu_core_irq_register_callback(phys_enc->dpu_kms, phys_enc->irq[INTR_IDX_CTL_START], dpu_encoder_phys_cmd_ctl_start_irq, @@ -311,7 +311,7 @@ static void dpu_encoder_phys_cmd_irq_disable(struct dpu_encoder_phys *phys_enc) phys_enc->hw_pp->idx - PINGPONG_0, phys_enc->vblank_refcount); - if (dpu_encoder_phys_cmd_is_master(phys_enc)) + if (dpu_encoder_phys_cmd_is_master(phys_enc) && phys_enc->irq[INTR_IDX_CTL_START]) dpu_core_irq_unregister_callback(phys_enc->dpu_kms, phys_enc->irq[INTR_IDX_CTL_START]); --- base-commit: 704ba27ac55579704ba1289392448b0c66b56258 change-id: 20240509-ctl_irq-a90b2d7a0bf5 Best regards, -- Barnabás Czémán
[PATCH] drm/msm/dpu: fix encoder irq wait skip
The irq_idx is unsigned so it cannot be lower than zero, better
to change the condition to check if it is equal with zero.
It could not cause any issue because a valid irq index starts from one.
Signed-off-by: Barnabás Czémán
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 119f3ea50a7c..cf7d769ab3b9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -428,7 +428,7 @@ int dpu_encoder_helper_wait_for_irq(struct dpu_encoder_phys
*phys_enc,
return -EWOULDBLOCK;
}
- if (irq_idx < 0) {
+ if (irq_idx == 0) {
DRM_DEBUG_KMS("skip irq wait id=%u, callback=%ps\n",
DRMID(phys_enc->parent), func);
return 0;
---
base-commit: 704ba27ac55579704ba1289392448b0c66b56258
change-id: 20240509-irq_wait-49444cea77e2
Best regards,
--
Barnabás Czémán
Re: [PATCH] drm/radeon: Delay Connector detecting when HPD singals is unstable
On Thu, May 9, 2024 at 4:58 AM oushixiong wrote:
>
> From: Shixiong Ou
>
> In some causes, HPD signals will jitter when plugging in
> or unplugging HDMI.
>
> Rescheduling the hotplug work for a second when EDID may still be
> readable but HDP is disconnected, and fixes this issue.
>
> Signed-off-by: Shixiong Ou
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/radeon/radeon_connectors.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
> b/drivers/gpu/drm/radeon/radeon_connectors.c
> index b84b58926106..cf0114ca59a4 100644
> --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> @@ -1267,6 +1267,16 @@ radeon_dvi_detect(struct drm_connector *connector,
> bool force)
> goto exit;
> }
> }
> +
> + if (dret && radeon_connector->hpd.hpd != RADEON_HPD_NONE &&
> + !radeon_hpd_sense(rdev, radeon_connector->hpd.hpd) &&
> + connector->connector_type == DRM_MODE_CONNECTOR_HDMIA) {
> + DRM_DEBUG_KMS("EDID is readable when HPD disconnected\n");
> + schedule_delayed_work(>hotplug_work,
> msecs_to_jiffies(1000));
> + ret = connector_status_disconnected;
> + goto exit;
> + }
> +
> if (dret) {
> radeon_connector->detected_by_load = false;
> radeon_connector_free_edid(connector);
> --
> 2.17.1
>
[PATCH] staging:vme_user: Add blank line after struct decl
Added blank line after struct declarions for improving readability indicated by
checkpatch.pl
Signed-off-by: Ashok Kumar
---
drivers/staging/vme_user/vme_user.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/vme_user/vme_user.c
b/drivers/staging/vme_user/vme_user.c
index 36183f923768..5829a4141561 100644
--- a/drivers/staging/vme_user/vme_user.c
+++ b/drivers/staging/vme_user/vme_user.c
@@ -106,6 +106,7 @@ static struct vme_dev *vme_user_bridge; /*
Pointer to user device */
static const struct class vme_user_sysfs_class = {
.name = DRIVER_NAME,
};
+
static const int type[VME_DEVS] = {MASTER_MINOR, MASTER_MINOR,
MASTER_MINOR, MASTER_MINOR,
SLAVE_MINOR,SLAVE_MINOR,
--
2.34.1
Re: [PATCH v5 1/7] dt-bindings: display: panel: Add himax hx83102 panel bindings
On Thu, May 09, 2024 at 09:52:01AM +0800, Cong Yang wrote: > In V1, discussed with Doug and Linus [1], we need break out as separate > driver for the himax83102-j02 controller. Beacuse "starry,himax83102-j02" > and in this series "BOE nv110wum-l60" "IVO t109nw41" panels use same > controller, they have some common CMDS. So add new documentation for > this panels. > > For himax83102-j02 controller, no need 3v3 supply, so remove it. > > [1]: > https://lore.kernel.org/all/CACRpkdbzYZAS0=zbqjuc4cb2wj4s1h6n6asazqvdmv95r3z...@mail.gmail.com > > Signed-off-by: Cong Yang Reviewed-by: Conor Dooley Cheers, Conor. signature.asc Description: PGP signature
Re: [PATCH] drm/amd/pm: remove deprecated I2C_CLASS_SPD support from newly added SMU_14_0_2
On Thu, May 9, 2024 at 8:02 AM Heiner Kallweit wrote: > > Support for I2C_CLASS_SPD is currently being removed from the kernel. > Only remaining step is to remove the definition of I2C_CLASS_SPD. > Setting I2C_CLASS_SPD in a driver is a no-op meanwhile, so remove it > here. > > Signed-off-by: Heiner Kallweit Reviewed-by: Alex Deucher and applied. Thanks! > --- > drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_2_ppt.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_2_ppt.c > b/drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_2_ppt.c > index 0d5ad531c..fb6f3bbe2 100644 > --- a/drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_2_ppt.c > +++ b/drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_2_ppt.c > @@ -1616,7 +1616,6 @@ static int smu_v14_0_2_i2c_control_init(struct > smu_context *smu) > smu_i2c->port = i; > mutex_init(_i2c->mutex); > control->owner = THIS_MODULE; > - control->class = I2C_CLASS_SPD; > control->dev.parent = >pdev->dev; > control->algo = _v14_0_2_i2c_algo; > snprintf(control->name, sizeof(control->name), "AMDGPU SMU > %d", i); > -- > 2.45.0 >
Re: [PATCH] docs: document python version used for compilation
Dmitry Baryshkov writes: > The drm/msm driver had adopted using Python3 script to generate register > header files instead of shipping pre-generated header files. Document > the minimal Python version supported by the script. > > Signed-off-by: Dmitry Baryshkov > --- > Documentation/process/changes.rst | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/process/changes.rst > b/Documentation/process/changes.rst > index 5685d7bfe4d0..8d225a9f65a2 100644 > --- a/Documentation/process/changes.rst > +++ b/Documentation/process/changes.rst > @@ -63,6 +63,7 @@ cpio any cpio --version > GNU tar1.28 tar --version > gtags (optional) 6.6.5gtags --version > mkimage (optional) 2017.01 mkimage --version > +Python (optional) 3.5.xpython3 --version > == === > Is it really optional - can you build the driver without it? This document needs some help... I'm missing a number of things that are *not* marked as "optional" (jfsutils, reiserfsprogs, pcmciautils, ppp, ...) and somehow my system works fine :) It would be nice to document *why* users might need a specific tool. But I guess we aren't going to do that now. I can apply this, but I do wonder about the "optional" marking. Thanks, jon
Re: [PATCH v5 2/7] drm/panel: himax-hx83102: Break out as separate driver
Hi,
On Wed, May 8, 2024 at 6:53 PM Cong Yang
wrote:
>
> +static int hx83102_enable(struct drm_panel *panel)
> +{
> + struct hx83102 *ctx = panel_to_hx83102(panel);
> + struct mipi_dsi_device *dsi = ctx->dsi;
> + struct device *dev = >dev;
> + int ret;
> +
> + ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
> + if (ret) {
> + dev_err(dev, "Failed to exit sleep mode: %d\n", ret);
> + return ret;
> + }
> +
> + msleep(120);
> +
> + ret = mipi_dsi_dcs_set_display_on(dsi);
> + if (ret) {
> + dev_err(dev, "Failed to turn on the display: %d\n", ret);
> + return ret;
> + }
FWIW, I think that the mipi_dsi_dcs_exit_sleep_mode(), msleep(120),
and mipi_dsi_dcs_set_display_on() should also be in the prepare() to
match how they were in the boe-tv101wum-nl6.c driver, right? Then the
enable() would be left with just the simple "msleep(130)".
I know it doesn't make much difference and it probably doesn't matter
and maybe I'm just being a little nitpicky, but given that the
prepare() and enable() functions are unique phases I'd rather be
explicit if we've moving something from one phase to the other.
-Doug
Re: [PATCH v5 7/7] drm/panel: himax-hx83102: Support for IVO t109nw41 MIPI-DSI panel
Hi,
On Wed, May 8, 2024 at 6:53 PM Cong Yang
wrote:
>
> +static int ivo_t109nw41_init(struct hx83102 *ctx)
> +{
> + struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi };
> +
> + msleep(60);
> +
> + hx83102_enable_extended_cmds(_ctx, true);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPOWER, 0x2c, 0xed,
> 0xed, 0x0f, 0xcf, 0x42,
> +0xf5, 0x39, 0x36, 0x36, 0x36, 0x36,
> 0x32, 0x8b, 0x11, 0x65, 0x00, 0x88,
> +0xfa, 0xff, 0xff, 0x8f, 0xff, 0x08,
> 0xd6, 0x33);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETDISP, 0x00, 0x47,
> 0xb0, 0x80, 0x00, 0x12,
> +0x71, 0x3c, 0xa3, 0x22, 0x20, 0x00,
> 0x00, 0x88, 0x01);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETCYC, 0x35, 0x35,
> 0x43, 0x43, 0x35, 0x35,
> +0x30, 0x7a, 0x30, 0x7a, 0x01, 0x9d);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0xcd);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETMIPI, 0x84);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0x3f);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETVDC, 0x1b, 0x04);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_UNKNOWN_BE, 0x20);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPTBA, 0xfc, 0xc4);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSTBA, 0x34, 0x34,
> 0x22, 0x11, 0x22, 0xa0,
> +0x31, 0x08, 0xf5, 0x03);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0xcc);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETTCON, 0x80);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0x3f);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0xd3);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETTCON, 0x22);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0x3f);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0xc6);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETRAMDMY, 0x97);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0x3f);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPWM, 0x00, 0x1e,
> 0x13, 0x88, 0x01);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETCLOCK, 0x08, 0x13,
> 0x07, 0x00, 0x0f, 0x34);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPANEL, 0x02, 0x03,
> 0x44);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0xc4);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETCASCADE, 0x03);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0x3f);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPCTRL, 0x07, 0x06,
> 0x00, 0x02, 0x04, 0x2c,
> +0xff);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETGIP0, 0x06, 0x00,
> 0x00, 0x00, 0x00, 0x08,
> +0x08, 0x08, 0x08, 0x37, 0x07, 0x64,
> 0x7c, 0x11, 0x11, 0x03, 0x03, 0x32,
> +0x10, 0x0e, 0x00, 0x0e, 0x32, 0x17,
> 0x97, 0x07, 0x97, 0x32, 0x00, 0x02,
> +0x00, 0x02, 0x00, 0x00);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETGIP1, 0x25, 0x24,
> 0x25, 0x24, 0x18, 0x18,
> +0x18, 0x18, 0x07, 0x06, 0x07, 0x06,
> 0x05, 0x04, 0x05, 0x04, 0x03, 0x02,
> +0x03, 0x02, 0x01, 0x00, 0x01, 0x00,
> 0x1e, 0x1e, 0x1e, 0x1e, 0x1f, 0x1f,
> +0x1f, 0x1f, 0x21, 0x20, 0x21, 0x20,
> 0x18, 0x18, 0x18, 0x18, 0x18, 0x18,
> +0x18, 0x18);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETGIP3, 0xaa, 0xaa,
> 0xaa, 0xaa, 0xaa, 0xa0,
> +0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xa0,
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETGMA, 0x04, 0x04,
> 0x06, 0x0a, 0x0a, 0x05,
> +0x12, 0x14, 0x17, 0x13, 0x2c, 0x33,
> 0x39, 0x4b, 0x4c, 0x56, 0x61, 0x78,
> +0x7a, 0x41, 0x50, 0x68, 0x73, 0x04,
> 0x04, 0x06, 0x0a, 0x0a, 0x05, 0x12,
> +0x14, 0x17, 0x13, 0x2c, 0x33, 0x39,
> 0x4b, 0x4c, 0x56, 0x61, 0x78, 0x7a,
> +0x41, 0x50, 0x68, 0x73);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETTP1, 0x07, 0x10,
> 0x10, 0x1a, 0x26, 0x9e,
> +0x00, 0x4f, 0xa0, 0x14, 0x14, 0x00,
> 0x00, 0x00, 0x00, 0x12, 0x0a, 0x02,
> +0x02, 0x00, 0x33, 0x02, 0x04, 0x18,
> 0x01);
> + mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETBANK, 0x01);
> +
[PULL] drm-xe-next-fixes
Hi, Dave & Sima This weeks -next-fixes. Two fixes breifly described below. Driver Changes: - Use ordered WQ for G2H handler. (Matthew Brost) - Use flexible-array rather than zero-sized (Lucas De Marchi) Thanks, Thomas The following changes since commit 3bc8848bb7f7478e6806e4522b06b63f40a53e1e: drm/xe: Merge 16021540221 and 18034896535 WAs (2024-05-02 11:29:42 +0200) are available in the Git repository at: https://gitlab.freedesktop.org/drm/xe/kernel.git tags/drm-xe-next-fixes-2024-05-09-1 for you to fetch changes up to d69c3d4b53829097b8948d6791ea32c07de3faab: drm/xe/ads: Use flexible-array (2024-05-09 17:51:46 +0200) Driver Changes: - Use ordered WQ for G2H handler. (Matthew Brost) - Use flexible-array rather than zero-sized (Lucas De Marchi) Lucas De Marchi (1): drm/xe/ads: Use flexible-array Matthew Brost (1): drm/xe: Use ordered WQ for G2H handler drivers/gpu/drm/xe/xe_guc_ads.c | 2 +- drivers/gpu/drm/xe/xe_guc_ct.c | 5 + drivers/gpu/drm/xe/xe_guc_ct.h | 2 +- drivers/gpu/drm/xe/xe_guc_ct_types.h | 2 ++ 4 files changed, 9 insertions(+), 2 deletions(-)
Re: [Linaro-mm-sig] Re: [PATCH] epoll: try to be a _bit_ better about file lifetimes
On Thu, 9 May 2024 at 04:39, Christian Brauner wrote: > > Not worth it without someone explaining in detail why imho. First pass > should be to try and replace kcmp() in scenarios where it's obviously > not needed or overkill. Ack. > I've added a CLASS(fd_raw) in a preliminary patch since we'll need that > anyway which means that your comparison patch becomes even simpler imho. > I've also added a selftest patch: > > https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/log/?h=vfs.misc LGTM. Maybe worth adding an explicit test for "open same file, but two separate opens, F_DUPFD_QUERY returns 0? Just to clarify the "it's not testing the file on the filesystem for equality, but the file pointer itself". Linus
Re: [PATCH] drm/etnaviv: Create an accel device node if compute-only
On Thu, May 09, 2024 at 03:53:01PM +0200, Tomeu Vizoso wrote: > Oded, Dave, > > Do you have an opinion on this? > > Thanks, > > Tomeu Hi Tomeu, Sorry for not replying earlier, I was down with Covid (again...). To your question, I don't have an objection to what you are suggesting. My personal view of accel is that it is an integral part of DRM and therefore, if there is an *existing* drm driver that wants to create an accel node, I'm not against it. There is the question of why you want to expose an accel node, and here I would like to hear Dave's and Sima's opinion on your suggested solution as it may affect the direction of other drm drivers. Thanks, Oded. p.s. Please only use bottom-posting when replying, thanks :) > > On Fri, Apr 26, 2024 at 8:10 AM Tomeu Vizoso wrote: > > > > On Thu, Apr 25, 2024 at 8:59 PM Jeffrey Hugo wrote: > > > > > > On 4/24/2024 12:37 AM, Tomeu Vizoso wrote: > > > > If we expose a render node for NPUs without rendering capabilities, the > > > > userspace stack will offer it to compositors and applications for > > > > rendering, which of course won't work. > > > > > > > > Userspace is probably right in not questioning whether a render node > > > > might not be capable of supporting rendering, so change it in the kernel > > > > instead by exposing a /dev/accel node. > > > > > > > > Before we bring the device up we don't know whether it is capable of > > > > rendering or not (depends on the features of its blocks), so first try > > > > to probe a rendering node, and if we find out that there is no rendering > > > > hardware, abort and retry with an accel node. > > > > > > > > Signed-off-by: Tomeu Vizoso > > > > Cc: Oded Gabbay > > > > > > I hope Oded chimes in as Accel maintainer. I think Airlie/Vetter had > > > also previously mentioned they'd have opinions on what is Accel vs DRM. > > > > > > This gets a nack from me in its current state. This is not a strong > > > nack, and I don't want to discourage you. I think there is a path > > > forward. > > > > > > The Accel subsystem documentation says that accel drivers will reside in > > > drivers/accel/ but this does not. > > > > Indeed, there is that code organization aspect. > > > > > Also, the commit text for "accel: add dedicated minor for accelerator > > > devices" mentions - > > > > > > "for drivers that > > > declare they handle compute accelerator, using a new driver feature > > > flag called DRIVER_COMPUTE_ACCEL. It is important to note that this > > > driver feature is mutually exclusive with DRIVER_RENDER. Devices that > > > want to expose both graphics and compute device char files should be > > > handled by two drivers that are connected using the auxiliary bus > > > framework." > > > > > > I don't see any of that happening here (two drivers connected by aux > > > bus, one in drivers/accel). > > > > Well, the text refers to devices, not drivers. The case we are talking > > about is a driver that wants to sometimes expose an accel node, and > > sometimes a render node, depending on the hardware it is dealing with. > > So there would either be a device exposing a single render node, or a > > device exposing a single accel node. > > > > Though by using the auxiliary bus we could in theory solve the code > > organization problem mentioned above, I'm not quite seeing how to do > > this in a clean way. The driver in /drivers/gpu/drm would have to be a > > DRM driver that doesn't register a DRM device, but registers a device > > in the auxiliary bus for the driver in /drivers/accel to bind to? Or > > are you seeing some possibility that would fit better in the current > > DRM framework? > > > > > I think this is the first case we've had of a combo DRM/Accel usecase, > > > and so there isn't an existing example to refer you to on how to > > > structure things. I think you are going to be the first example where > > > we figure all of this out. > > > > Yep, I will be grateful for any ideas on how to structure this. > > > > > On a more implementation note, ioctls for Accel devices should not be > > > marked DRM_RENDER_ALLOW. Seems like your attempt to reuse as much of > > > the code as possible trips over this. > > > > Indeed, thanks. > > > > Cheers, > > > > Tomeu > > > > > -Jeff
Re: [PATCH v1 2/2] HID: i2c-hid: elan: Add ili2900 timing
Hi, On Wed, May 8, 2024 at 11:43 PM Zhaoxiong Lv wrote: > > From: lvzhaoxiong > > ILI2900 requires reset to pull down time greater than 10ms, > so the configuration post_power_delay_ms is 10, and the chipset > initial time is required to be greater than 100ms, > so the post_gpio_reset_on_delay_ms is set to 100. > > Signed-off-by: lvzhaoxiong > --- > drivers/hid/i2c-hid/i2c-hid-of-elan.c | 8 > 1 file changed, 8 insertions(+) You silently ignored pretty much all of the feedback from the previous version [1], so I'm not planning to review this version. [1] https://lore.kernel.org/r/CAD=FV=x5tk0tccda+vlnu0aoas1tdwuqvkmzm-278docx8k...@mail.gmail.com
Re: [PATCH v2 0/2] Add starry bindings and driver
Hi, On Thu, May 9, 2024 at 1:35 AM Zhaoxiong Lv wrote: > > Add bindings and driver for starry. > --- > Modifications between V1 and V2: > Kconfig and Makefile configurations added for starry driver > > --- > > Zhaoxiong Lv (2): > dt-bindings: display: panel: Add Starry-er88577 support > drm/panel: starry: add new panel driver > > .../display/panel/starry,er88577.yaml | 59 +++ > drivers/gpu/drm/panel/Kconfig | 9 + > drivers/gpu/drm/panel/Makefile| 1 + > drivers/gpu/drm/panel/panel-starry-er88577.c | 444 ++ > 4 files changed, 513 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/starry,er88577.yaml > create mode 100644 drivers/gpu/drm/panel/panel-starry-er88577.c I don't think anyone is going to look at this series since it's not taking into account previous feedback. Please talk to Cong Yang (CCed) who is also working at Huaquin and is also sending MIPI panel patches. Hopefully he should be able to pre-review your patches with you so that you can learn from what he learned. If for some reason you are unable to work with Cong Yang then let me know and we can figure out the next steps here. -Doug
[PATCH v3 6/7] ARM: dts: rockchip: Add D-PHY for RK3128
The InnoSilicon D-PHY found in RK3128 SoCs supports DSI/LVDS/TTL with a
maximum transfer rate of 1 Gbps per lane. While adding it, also add it's
clocks to RK3128_PD_VIO powerdomain as the phy is part of it.
Signed-off-by: Alex Bee
---
changes since v1:
- also added SCLK_MIPI_24M to powerdomain
- reword commit message
arch/arm/boot/dts/rockchip/rk3128.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi
b/arch/arm/boot/dts/rockchip/rk3128.dtsi
index fb98873fd94e..fbd95bb08cd3 100644
--- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
@@ -216,6 +216,8 @@ power-domain@RK3128_PD_VIO {
< ACLK_LCDC0>,
< HCLK_LCDC0>,
< PCLK_MIPI>,
+< PCLK_MIPIPHY>,
+< SCLK_MIPI_24M>,
< ACLK_RGA>,
< HCLK_RGA>,
< ACLK_VIO0>,
@@ -496,6 +498,18 @@ hdmi_out: port@1 {
};
};
+ dphy: phy@20038000 {
+ compatible = "rockchip,rk3128-dsi-dphy";
+ reg = <0x20038000 0x4000>;
+ clocks = < SCLK_MIPI_24M>, < PCLK_MIPIPHY>;
+ clock-names = "ref", "pclk";
+ resets = < SRST_MIPIPHY_P>;
+ reset-names = "apb";
+ power-domains = < RK3128_PD_VIO>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
timer0: timer@20044000 {
compatible = "rockchip,rk3128-timer", "rockchip,rk3288-timer";
reg = <0x20044000 0x20>;
--
2.43.2
[PATCH v3 3/7] clk: rockchip: rk3128: Export PCLK_MIPIPHY
Export the D-DHY's APB clock for usage in the DT. Also drop the
CLK_IGNORE_UNUSED-flag, as the clock will be enabled on demand.
Signed-off-by: Alex Bee
---
changes since v1:
- reword commit message
drivers/clk/rockchip/clk-rk3128.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3128.c
b/drivers/clk/rockchip/clk-rk3128.c
index 75071e0cd321..a20d1fd25e2a 100644
--- a/drivers/clk/rockchip/clk-rk3128.c
+++ b/drivers/clk/rockchip/clk-rk3128.c
@@ -526,7 +526,7 @@ static struct rockchip_clk_branch common_clk_branches[]
__initdata = {
GATE(PCLK_ACODEC, "pclk_acodec", "pclk_cpu", 0, RK2928_CLKGATE_CON(5),
14, GFLAGS),
GATE(0, "pclk_ddrupctl", "pclk_cpu", CLK_IGNORE_UNUSED,
RK2928_CLKGATE_CON(5), 7, GFLAGS),
GATE(0, "pclk_grf", "pclk_cpu", CLK_IGNORE_UNUSED,
RK2928_CLKGATE_CON(5), 4, GFLAGS),
- GATE(0, "pclk_mipiphy", "pclk_cpu", CLK_IGNORE_UNUSED,
RK2928_CLKGATE_CON(5), 0, GFLAGS),
+ GATE(PCLK_MIPIPHY, "pclk_mipiphy", "pclk_cpu", 0,
RK2928_CLKGATE_CON(5), 0, GFLAGS),
GATE(0, "pclk_pmu", "pclk_pmu_pre", 0, RK2928_CLKGATE_CON(9), 2,
GFLAGS),
GATE(0, "pclk_pmu_niu", "pclk_pmu_pre", CLK_IGNORE_UNUSED,
RK2928_CLKGATE_CON(9), 3, GFLAGS),
--
2.43.2
[PATCH v3 7/7] ARM: dts: rockchip: Add DSI for RK3128
Add the Designware MIPI DSI controller and it's port nodes.
Signed-off-by: Alex Bee
---
changes since v1:
- added HCLK_VIO_H2P as ahb clock
changes since v2:
- dropped ahb clock again
arch/arm/boot/dts/rockchip/rk3128.dtsi | 36 ++
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi
b/arch/arm/boot/dts/rockchip/rk3128.dtsi
index fbd95bb08cd3..7f2bf3e51082 100644
--- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
@@ -277,6 +277,42 @@ vop_out_hdmi: endpoint@0 {
reg = <0>;
remote-endpoint = <_in_vop>;
};
+
+ vop_out_dsi: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <_in_vop>;
+ };
+ };
+ };
+
+ dsi: dsi@1011 {
+ compatible = "rockchip,rk3128-mipi-dsi", "snps,dw-mipi-dsi";
+ reg = <0x1011 0x4000>;
+ interrupts = ;
+ clocks = < PCLK_MIPI>;
+ clock-names = "pclk";
+ phys = <>;
+ phy-names = "dphy";
+ resets = < SRST_VIO_MIPI_DSI>;
+ reset-names = "apb";
+ rockchip,grf = <>;
+ power-domains = < RK3128_PD_VIO>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dsi_in: port@0 {
+ reg = <0>;
+ dsi_in_vop: endpoint {
+ remote-endpoint = <_out_dsi>;
+ };
+ };
+
+ dsi_out: port@1 {
+ reg = <1>;
+ };
};
};
--
2.43.2
[PATCH v3 4/7] clk: rockchip: rk3128: Add hclk_vio_h2p to critical clocks
The DSI controller needs this clock to be enabled in order to be able to
access the registers. Make it critical for that purpose.
Signed-off-by: Alex Bee
---
changes since v1:
- dropped patch
changes since v2:
-re-added patch
drivers/clk/rockchip/clk-rk3128.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/rockchip/clk-rk3128.c
b/drivers/clk/rockchip/clk-rk3128.c
index a20d1fd25e2a..d076b7971f33 100644
--- a/drivers/clk/rockchip/clk-rk3128.c
+++ b/drivers/clk/rockchip/clk-rk3128.c
@@ -563,6 +563,7 @@ static const char *const rk3128_critical_clocks[]
__initconst = {
"pclk_cpu",
"aclk_peri",
"hclk_peri",
+ "hclk_vio_h2p",
"pclk_peri",
"pclk_pmu",
"sclk_timer5",
--
2.43.2
[PATCH v3 5/7] drm/rockchip: dsi: Add support for RK3128
The DesignWare MIPI DSI controller found RK3128 SoCs supports up to 4 DSI
data lanes. Similar to PX30/RK356x/RV1126 it uses an external D-PHY.
Signed-off-by: Alex Bee
---
changes since v1:
- none
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 20 +++
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 4cc8ed8f4fbd..58a44af0e9ad 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -153,6 +153,11 @@
#define PX30_DSI_TURNDISABLE BIT(5)
#define PX30_DSI_LCDC_SEL BIT(0)
+#define RK3128_GRF_LVDS_CON0 0x0150
+#define RK3128_DSI_FORCETXSTOPMODE GENMASK(13, 10)
+#define RK3128_DSI_FORCERXMODE BIT(9)
+#define RK3128_DSI_TURNDISABLE BIT(8)
+
#define RK3288_GRF_SOC_CON60x025c
#define RK3288_DSI0_LCDC_SEL BIT(6)
#define RK3288_DSI1_LCDC_SEL BIT(9)
@@ -1493,6 +1498,18 @@ static const struct rockchip_dw_dsi_chip_data
px30_chip_data[] = {
{ /* sentinel */ }
};
+static const struct rockchip_dw_dsi_chip_data rk3128_chip_data[] = {
+ {
+ .reg = 0x1011,
+ .lanecfg1_grf_reg = RK3128_GRF_LVDS_CON0,
+ .lanecfg1 = HIWORD_UPDATE(0, RK3128_DSI_TURNDISABLE |
+RK3128_DSI_FORCERXMODE |
+RK3128_DSI_FORCETXSTOPMODE),
+ .max_data_lanes = 4,
+ },
+ { /* sentinel */ }
+};
+
static const struct rockchip_dw_dsi_chip_data rk3288_chip_data[] = {
{
.reg = 0xff96,
@@ -1670,6 +1687,9 @@ static const struct of_device_id
dw_mipi_dsi_rockchip_dt_ids[] = {
{
.compatible = "rockchip,px30-mipi-dsi",
.data = _chip_data,
+ }, {
+.compatible = "rockchip,rk3128-mipi-dsi",
+.data = _chip_data,
}, {
.compatible = "rockchip,rk3288-mipi-dsi",
.data = _chip_data,
--
2.43.2
[PATCH v3 0/7] Add DSI support for RK3128
This series aims to add support for the DesignWare MIPI DSI controller and the Innoslicon D-PHY found in RK3128 SoCs. The code additions are rather tiny: It only need some code in the Rockchip dw-mipi-dsi glue layer for this SoC and do some changes in the SoC's clock driver. Support for the phy was already added when the Innosilicon D-PHY driver was initially submitted. I tested it with a 800x1280 DSI panel where all 4 lanes that are supported are used. changes in v2: To improve power-efficiency when the DSI controller is not in use, I dropped the patch which made hclk_vio_h2p a critical clock and instead added support for an AHB clock to the DSI controller driver and updated the bindings and the addition to the SoC DT accordingly. Link to v1: https://lore.kernel.org/linux-kernel/20240506194343.282119-1-knaerz...@gmail.com/ changes in v3: Dropped the changes for the additional AHB clock for the DSI controller, as it's not part of the IP block. (Heiko) Link to v2: https://lore.kernel.org/linux-kernel/20240509120715.86694-1-knaerz...@gmail.com/ Please see individual patches for details about the changes. Alex Bee (7): dt-bindings: display: rockchip,dw-mipi-dsi: Document RK3128 DSI dt-bindings: clock: rk3128: Add PCLK_MIPIPHY clk: rockchip: rk3128: Export PCLK_MIPIPHY clk: rockchip: rk3128: Add hclk_vio_h2p to critical clocks drm/rockchip: dsi: Add support for RK3128 ARM: dts: rockchip: Add D-PHY for RK3128 ARM: dts: rockchip: Add DSI for RK3128 .../rockchip/rockchip,dw-mipi-dsi.yaml| 2 + arch/arm/boot/dts/rockchip/rk3128.dtsi| 50 +++ drivers/clk/rockchip/clk-rk3128.c | 3 +- .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 20 include/dt-bindings/clock/rk3128-cru.h| 1 + 5 files changed, 75 insertions(+), 1 deletion(-) -- 2.43.2
[PATCH v3 2/7] dt-bindings: clock: rk3128: Add PCLK_MIPIPHY
The DPHY's APB clock is required to be exposed in order to be able to enable it and access the phy's registers. Signed-off-by: Alex Bee Acked-by: Conor Dooley --- changes since v1: - none include/dt-bindings/clock/rk3128-cru.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/clock/rk3128-cru.h b/include/dt-bindings/clock/rk3128-cru.h index 6a47825dac5d..1be455ba4985 100644 --- a/include/dt-bindings/clock/rk3128-cru.h +++ b/include/dt-bindings/clock/rk3128-cru.h @@ -116,6 +116,7 @@ #define PCLK_GMAC 367 #define PCLK_PMU_PRE 368 #define PCLK_SIM_CARD 369 +#define PCLK_MIPIPHY 370 /* hclk gates */ #define HCLK_SPDIF 440 -- 2.43.2
[PATCH v3 1/7] dt-bindings: display: rockchip, dw-mipi-dsi: Document RK3128 DSI
Document the MIPI DSI controller for Rockchip RK3128. The integration is similar to PX30 so it's bindings-constraints can be re-used. Signed-off-by: Alex Bee Acked-by: Conor Dooley --- changes since v1: - added ahb clock changes since v2: - revert added ahb clock .../rockchip/rockchip,dw-mipi-dsi.yaml| 25 ++- 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-mipi-dsi.yaml index ccf79e738fa1..ccd71c5324af 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-mipi-dsi.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-mipi-dsi.yaml @@ -15,6 +15,7 @@ properties: items: - enum: - rockchip,px30-mipi-dsi + - rockchip,rk3128-mipi-dsi - rockchip,rk3288-mipi-dsi - rockchip,rk3399-mipi-dsi - rockchip,rk3568-mipi-dsi @@ -77,6 +78,7 @@ allOf: contains: enum: - rockchip,px30-mipi-dsi + - rockchip,rk3128-mipi-dsi - rockchip,rk3568-mipi-dsi - rockchip,rv1126-mipi-dsi -- 2.43.2
[PATCH v3 0/7] Add DSI support for RK3128
This series aims to add support for the DesignWare MIPI DSI controller and the Innoslicon D-PHY found in RK3128 SoCs. The code additions are rather tiny: It only need some code in the Rockchip dw-mipi-dsi glue layer for this SoC and do some changes in the SoC's clock driver. Support for the phy was already added when the Innosilicon D-PHY driver was initially submitted. I tested it with a 800x1280 DSI panel where all 4 lanes that are supported are used. changes in v2: To improve power-efficiency when the DSI controller is not in use, I dropped the patch which made hclk_vio_h2p a critical clock and instead added support for an AHB clock to the DSI controller driver and updated the bindings and the addition to the SoC DT accordingly. Link to v1: https://lore.kernel.org/linux-kernel/20240506194343.282119-1-knaerz...@gmail.com/ changes in v3: Dropped the changes for the additional AHB clock for the DSI controller, as it's not part of the IP block. (Heiko) Link to v2: https://lore.kernel.org/linux-kernel/20240509120715.86694-1-knaerz...@gmail.com/ Please see individual patches for details about the changes. Alex Bee (7): dt-bindings: display: rockchip,dw-mipi-dsi: Document RK3128 DSI dt-bindings: clock: rk3128: Add PCLK_MIPIPHY clk: rockchip: rk3128: Export PCLK_MIPIPHY clk: rockchip: rk3128: Add hclk_vio_h2p to critical clocks drm/rockchip: dsi: Add support for RK3128 ARM: dts: rockchip: Add D-PHY for RK3128 ARM: dts: rockchip: Add DSI for RK3128 .../rockchip/rockchip,dw-mipi-dsi.yaml| 2 + arch/arm/boot/dts/rockchip/rk3128.dtsi| 50 +++ drivers/clk/rockchip/clk-rk3128.c | 3 +- .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 20 include/dt-bindings/clock/rk3128-cru.h| 1 + 5 files changed, 75 insertions(+), 1 deletion(-) -- 2.43.2
Re: [PATCH] drm/etnaviv: Create an accel device node if compute-only
Oded, Dave, Do you have an opinion on this? Thanks, Tomeu On Fri, Apr 26, 2024 at 8:10 AM Tomeu Vizoso wrote: > > On Thu, Apr 25, 2024 at 8:59 PM Jeffrey Hugo wrote: > > > > On 4/24/2024 12:37 AM, Tomeu Vizoso wrote: > > > If we expose a render node for NPUs without rendering capabilities, the > > > userspace stack will offer it to compositors and applications for > > > rendering, which of course won't work. > > > > > > Userspace is probably right in not questioning whether a render node > > > might not be capable of supporting rendering, so change it in the kernel > > > instead by exposing a /dev/accel node. > > > > > > Before we bring the device up we don't know whether it is capable of > > > rendering or not (depends on the features of its blocks), so first try > > > to probe a rendering node, and if we find out that there is no rendering > > > hardware, abort and retry with an accel node. > > > > > > Signed-off-by: Tomeu Vizoso > > > Cc: Oded Gabbay > > > > I hope Oded chimes in as Accel maintainer. I think Airlie/Vetter had > > also previously mentioned they'd have opinions on what is Accel vs DRM. > > > > This gets a nack from me in its current state. This is not a strong > > nack, and I don't want to discourage you. I think there is a path forward. > > > > The Accel subsystem documentation says that accel drivers will reside in > > drivers/accel/ but this does not. > > Indeed, there is that code organization aspect. > > > Also, the commit text for "accel: add dedicated minor for accelerator > > devices" mentions - > > > > "for drivers that > > declare they handle compute accelerator, using a new driver feature > > flag called DRIVER_COMPUTE_ACCEL. It is important to note that this > > driver feature is mutually exclusive with DRIVER_RENDER. Devices that > > want to expose both graphics and compute device char files should be > > handled by two drivers that are connected using the auxiliary bus > > framework." > > > > I don't see any of that happening here (two drivers connected by aux > > bus, one in drivers/accel). > > Well, the text refers to devices, not drivers. The case we are talking > about is a driver that wants to sometimes expose an accel node, and > sometimes a render node, depending on the hardware it is dealing with. > So there would either be a device exposing a single render node, or a > device exposing a single accel node. > > Though by using the auxiliary bus we could in theory solve the code > organization problem mentioned above, I'm not quite seeing how to do > this in a clean way. The driver in /drivers/gpu/drm would have to be a > DRM driver that doesn't register a DRM device, but registers a device > in the auxiliary bus for the driver in /drivers/accel to bind to? Or > are you seeing some possibility that would fit better in the current > DRM framework? > > > I think this is the first case we've had of a combo DRM/Accel usecase, > > and so there isn't an existing example to refer you to on how to > > structure things. I think you are going to be the first example where > > we figure all of this out. > > Yep, I will be grateful for any ideas on how to structure this. > > > On a more implementation note, ioctls for Accel devices should not be > > marked DRM_RENDER_ALLOW. Seems like your attempt to reuse as much of > > the code as possible trips over this. > > Indeed, thanks. > > Cheers, > > Tomeu > > > -Jeff
[PATCH] docs: document python version used for compilation
The drm/msm driver had adopted using Python3 script to generate register header files instead of shipping pre-generated header files. Document the minimal Python version supported by the script. Signed-off-by: Dmitry Baryshkov --- Documentation/process/changes.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst index 5685d7bfe4d0..8d225a9f65a2 100644 --- a/Documentation/process/changes.rst +++ b/Documentation/process/changes.rst @@ -63,6 +63,7 @@ cpio any cpio --version GNU tar1.28 tar --version gtags (optional) 6.6.5gtags --version mkimage (optional) 2017.01 mkimage --version +Python (optional) 3.5.xpython3 --version == === .. [#f1] Sphinx is needed only to build the Kernel documentation --- base-commit: 704ba27ac55579704ba1289392448b0c66b56258 change-id: 20240509-python-version-a8b6ca2125ff Best regards, -- Dmitry Baryshkov
Re: [PATCH v2 0/7] Add DSI support for RK3128
Am 09.05.24 um 14:43 schrieb Alex Bee: Hi Heiko Am 09.05.24 um 14:21 schrieb Heiko Stübner: Hi Alex, Am Donnerstag, 9. Mai 2024, 14:07:08 CEST schrieb Alex Bee: This series aims to add support for the DesignWare MIPI DSI controller and the Innoslicon D-PHY found in RK3128 SoCs. The code additions are rather tiny: It only need some code in the Rockchip dw-mipi-dsi glue layer for this SoC, add support for an additional clock and do some changes in the SoC's clock driver. Support for the phy was already added when the Innosilicon D-PHY driver was initially submitted. I tested it with a 800x1280 DSI panel where all 4 lanes that are supported are used. changes in v2: To improve power-efficiency when the DSI controller is not in use, I dropped the patch which made hclk_vio_h2p a critical clock and instead added support for an AHB clock to the DSI controller driver and updated the bindings and the addition to the SoC DT accordingly. The naming already suggests that hclk_vio_h2p is not a clock-part of the actual dsi controller, but more an internal thing inside the clock controller. At least naming and perceived functionality would suggest a chain of hclk_vio -> hclk_vio_h2p -> pclk_mipi I personally wouldn't give to much on naming when it comes to Rockchip CRUs. Actually looking at "Fig. 2-5 Chip Clock Architecture Diagram 4" of RK312x its: ... -> hclk_vio -> hclk_h2p (clock in question) -> pclk_mipi (DSI APB clock) -> hclk_rga -> hclk_vop Also there is no other display output path (HDMI, LVDS) which requires this clock to be enabled. They all work when it's disabled. That really makes me think it's just the AHB clock line for the DSI controller. Maybe Andy can share some details? Anyway: I just looked at the "MIPI Controller architecture" part of the TRM - there is not even AHB clock line, only APB. So I revert the change with the additional clock, make the h2p-clock critical again and resend. Alex In any case, I really don't see hclk_vio_h2p to be in the realm of the actual DSI controller, but more a part of clock-controller / interconnect. Similar to the NIU clocks for the interconnect. rk3588 actually tries to implement this already and while the gate-link clocks are described as "recent", I think this definitly the same concept used a most/all older Rockchip SoCs, just nobody cared about that till now ;-) [0] . So TL;DR I'd really prefer to not leak CRU-details into the DSI controller. Heiko [0] Which reminds me that I should look at Sebastian's make GATE-LINK actually-work-patch.
Re: [PATCH] drm/msm: remove python 3.9 dependency for compiling msm
On Wed, 8 May 2024 at 02:05, Abhinav Kumar wrote:
>
> Since commit 5acf49119630 ("drm/msm: import gen_header.py script from Mesa"),
> compilation is broken on machines having python versions older than 3.9
> due to dependency on argparse.BooleanOptionalAction.
>
> Switch to use simple bool for the validate flag to remove the dependency.
>
> Fixes: 5acf49119630 ("drm/msm: import gen_header.py script from Mesa")
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/registers/gen_header.py | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
Reviewed-by: Dmitry Baryshkov
--
With best wishes
Dmitry
simpledrm, running display servers, and drivers replacing simpledrm while the display server is running
Hi So I have been made aware of an apparent race condition of some drivers taking a bit longer to load, which could lead to a possible race condition of display servers/greeters using the simpledrm device, and then experiencing problems once the real driver loads, the simpledrm device that the display servers are using as their primary GPU goes away. For example Weston crashes, Xorg crashes, wlroots seems to stay running, but doesn't draw anything on the screen, kwin aborts, This is if you boot on a QEMU machine with the virtio card, with modprobe.blacklist=virtio_gpu, and then, when the display server is running, run sudo modprobe virtio-gpu Namely, it's been recently reported here: https://github.com/sddm/sddm/issues/1917[1] and here https://github.com/systemd/systemd/issues/32509[2] My thinking: Instead of simpledrm's /dev/dri/card0 device going away when the real driver loads, is it possible for simpledrm to instead simulate an unplug of the fake display/CRTC? That way in theory, the simpledrm device will now be useless for drawing for drawing to the screen at that point, since the real driver is now taken over, but this way here, at least the display server doesn't lose its handles to the /dev/dri/card0 device, (and then maybe only remove itself once the final handle to it closes?) Is something like this possible to do with the way simpledrm works with the low level video memory? Or is this not possible? Thanks [1] https://github.com/sddm/sddm/issues/1917 [2] https://github.com/systemd/systemd/issues/32509
Re: [PATCH v2 0/7] Add DSI support for RK3128
Hi Heiko Am 09.05.24 um 14:21 schrieb Heiko Stübner: Hi Alex, Am Donnerstag, 9. Mai 2024, 14:07:08 CEST schrieb Alex Bee: This series aims to add support for the DesignWare MIPI DSI controller and the Innoslicon D-PHY found in RK3128 SoCs. The code additions are rather tiny: It only need some code in the Rockchip dw-mipi-dsi glue layer for this SoC, add support for an additional clock and do some changes in the SoC's clock driver. Support for the phy was already added when the Innosilicon D-PHY driver was initially submitted. I tested it with a 800x1280 DSI panel where all 4 lanes that are supported are used. changes in v2: To improve power-efficiency when the DSI controller is not in use, I dropped the patch which made hclk_vio_h2p a critical clock and instead added support for an AHB clock to the DSI controller driver and updated the bindings and the addition to the SoC DT accordingly. The naming already suggests that hclk_vio_h2p is not a clock-part of the actual dsi controller, but more an internal thing inside the clock controller. At least naming and perceived functionality would suggest a chain of hclk_vio -> hclk_vio_h2p -> pclk_mipi I personally wouldn't give to much on naming when it comes to Rockchip CRUs. Actually looking at "Fig. 2-5 Chip Clock Architecture Diagram 4" of RK312x its: ... -> hclk_vio -> hclk_h2p (clock in question) -> pclk_mipi (DSI APB clock) -> hclk_rga -> hclk_vop Also there is no other display output path (HDMI, LVDS) which requires this clock to be enabled. They all work when it's disabled. That really makes me think it's just the AHB clock line for the DSI controller. Maybe Andy can share some details? Alex In any case, I really don't see hclk_vio_h2p to be in the realm of the actual DSI controller, but more a part of clock-controller / interconnect. Similar to the NIU clocks for the interconnect. rk3588 actually tries to implement this already and while the gate-link clocks are described as "recent", I think this definitly the same concept used a most/all older Rockchip SoCs, just nobody cared about that till now ;-) [0] . So TL;DR I'd really prefer to not leak CRU-details into the DSI controller. Heiko [0] Which reminds me that I should look at Sebastian's make GATE-LINK actually-work-patch.
Re: [PATCH] drm/mst: Fix NULL pointer dereference at drm_dp_add_payload_part2
On 18.04.24 21:43, Harry Wentland wrote:
> On 2024-03-07 01:29, Wayne Lin wrote:
>> [Why]
>> Commit:
>> - commit 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
>> allocation/removement")
>> accidently overwrite the commit
>> - commit 54d217406afe ("drm: use mgr->dev in drm_dbg_kms in
>> drm_dp_add_payload_part2")
>> which cause regression.
>>
>> [How]
>> Recover the original NULL fix and remove the unnecessary input parameter
>> 'state' for
>> drm_dp_add_payload_part2().
>>
>> Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
>> allocation/removement")
>> Reported-by: Leon Weiß
>> Link:
>> https://lore.kernel.org/r/38c253ea42072cc825dc969ac4e6b9b600371cc8.ca...@ruhr-uni-bochum.de/
>> Cc: ly...@redhat.com
>> Cc: imre.d...@intel.com
>> Cc: sta...@vger.kernel.org
>> Cc: regressi...@lists.linux.dev
>> Signed-off-by: Wayne Lin
>
> I haven't been deep in MST code in a while but this all looks
> pretty straightforward and good.
>
> Reviewed-by: Harry Wentland
Hmmm, that was three weeks ago, but it seems since then nothing happened
to fix the linked regression through this or some other patch. Is there
a reason? The build failure report from the CI maybe?
Wayne Lin, do you know what's up?
Ciao, Thorsten
>> ---
>> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
>> drivers/gpu/drm/display/drm_dp_mst_topology.c | 4 +---
>> drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
>> drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
>> include/drm/display/drm_dp_mst_helper.h | 1 -
>> 5 files changed, 4 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
>> index c27063305a13..2c36f3d00ca2 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
>> @@ -363,7 +363,7 @@ void dm_helpers_dp_mst_send_payload_allocation(
>> mst_state = to_drm_dp_mst_topology_state(mst_mgr->base.state);
>> new_payload = drm_atomic_get_mst_payload_state(mst_state,
>> aconnector->mst_output_port);
>>
>> -ret = drm_dp_add_payload_part2(mst_mgr, mst_state->base.state,
>> new_payload);
>> +ret = drm_dp_add_payload_part2(mst_mgr, new_payload);
>>
>> if (ret) {
>> amdgpu_dm_set_mst_status(>mst_status,
>> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> index 03d528209426..95fd18f24e94 100644
>> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> @@ -3421,7 +3421,6 @@ EXPORT_SYMBOL(drm_dp_remove_payload_part2);
>> /**
>> * drm_dp_add_payload_part2() - Execute payload update part 2
>> * @mgr: Manager to use.
>> - * @state: The global atomic state
>> * @payload: The payload to update
>> *
>> * If @payload was successfully assigned a starting time slot by
>> drm_dp_add_payload_part1(), this
>> @@ -3430,14 +3429,13 @@ EXPORT_SYMBOL(drm_dp_remove_payload_part2);
>> * Returns: 0 on success, negative error code on failure.
>> */
>> int drm_dp_add_payload_part2(struct drm_dp_mst_topology_mgr *mgr,
>> - struct drm_atomic_state *state,
>> struct drm_dp_mst_atomic_payload *payload)
>> {
>> int ret = 0;
>>
>> /* Skip failed payloads */
>> if (payload->payload_allocation_status !=
>> DRM_DP_MST_PAYLOAD_ALLOCATION_DFP) {
>> -drm_dbg_kms(state->dev, "Part 1 of payload creation for %s
>> failed, skipping part 2\n",
>> +drm_dbg_kms(mgr->dev, "Part 1 of payload creation for %s
>> failed, skipping part 2\n",
>> payload->port->connector->name);
>> return -EIO;
>> }
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
>> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
>> index 53aec023ce92..2fba66aec038 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
>> @@ -1160,7 +1160,7 @@ static void intel_mst_enable_dp(struct
>> intel_atomic_state *state,
>> if (first_mst_stream)
>> intel_ddi_wait_for_fec_status(encoder, pipe_config, true);
>>
>> -drm_dp_add_payload_part2(_dp->mst_mgr, >base,
>> +drm_dp_add_payload_part2(_dp->mst_mgr,
>> drm_atomic_get_mst_payload_state(mst_state,
>> connector->port));
>>
>> if (DISPLAY_VER(dev_priv) >= 12)
>> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
>> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
>> index 0c3d88ad0b0e..88728a0b2c25 100644
>> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
>> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
>> @@ -915,7 +915,7 @@ nv50_msto_cleanup(struct drm_atomic_state *state,
>> msto->disabled = false;
>>
Re: [PATCH] drm/i915/gt: Disarm breadcrumbs if engines are already idle
On 23.04.2024 18:23, Janusz Krzysztofik wrote:
From: Chris Wilson
The breadcrumbs use a GT wakeref for guarding the interrupt, but are
disarmed during release of the engine wakeref. This leaves a hole where
we may attach a breadcrumb just as the engine is parking (after it has
parked its breadcrumbs), execute the irq worker with some signalers still
attached, but never be woken again.
That issue manifests itself in CI with IGT runner timeouts while tests
are waiting indefinitely for release of all GT wakerefs.
<6> [209.151778] i915: Running live_engine_pm_selftests/live_engine_busy_stats
<7> [209.231628] i915 :00:02.0: [drm:intel_power_well_disable [i915]]
disabling PW_5
<7> [209.231816] i915 :00:02.0: [drm:intel_power_well_disable [i915]]
disabling PW_4
<7> [209.231944] i915 :00:02.0: [drm:intel_power_well_disable [i915]]
disabling PW_3
<7> [209.232056] i915 :00:02.0: [drm:intel_power_well_disable [i915]]
disabling PW_2
<7> [209.232166] i915 :00:02.0: [drm:intel_power_well_disable [i915]]
disabling DC_off
<7> [209.232270] i915 :00:02.0: [drm:skl_enable_dc6 [i915]] Enabling DC6
<7> [209.232368] i915 :00:02.0: [drm:gen9_set_dc_state.part.0 [i915]]
Setting DC state from 00 to 02
<4> [299.356116] [IGT] Inactivity timeout exceeded. Killing the current test
with SIGQUIT.
...
<6> [299.356526] sysrq: Show State
...
<6> [299.373964] task:i915_selftest state:D stack:11784 pid:5578 tgid:5578
ppid:873flags:0x4002
<6> [299.373967] Call Trace:
<6> [299.373968]
<6> [299.373970] __schedule+0x3bb/0xda0
<6> [299.373974] schedule+0x41/0x110
<6> [299.373976] intel_wakeref_wait_for_idle+0x82/0x100 [i915]
<6> [299.374083] ? __pfx_var_wake_function+0x10/0x10
<6> [299.374087] live_engine_busy_stats+0x9b/0x500 [i915]
<6> [299.374173] __i915_subtests+0xbe/0x240 [i915]
<6> [299.374277] ? __pfx___intel_gt_live_setup+0x10/0x10 [i915]
<6> [299.374369] ? __pfx___intel_gt_live_teardown+0x10/0x10 [i915]
<6> [299.374456] intel_engine_live_selftests+0x1c/0x30 [i915]
<6> [299.374547] __run_selftests+0xbb/0x190 [i915]
<6> [299.374635] i915_live_selftests+0x4b/0x90 [i915]
<6> [299.374717] i915_pci_probe+0x10d/0x210 [i915]
At the end of the interrupt worker, if there are no more engines awake,
disarm the breadcrumb and go to sleep.
Fixes: 9d5612ca165a ("drm/i915/gt: Defer enabling the breadcrumb interrupt to after
submission")
Closes: https://gitlab.freedesktop.org/drm/intel/issues/10026
Signed-off-by: Chris Wilson
Cc: Andrzej Hajda
Cc: # v5.12+
Signed-off-by: Janusz Krzysztofik
Completely forgot this one.
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index d650beb8ed22f..20b9b04ec1e0b 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -263,8 +263,13 @@ static void signal_irq_work(struct irq_work *work)
i915_request_put(rq);
}
+ /* Lazy irq enabling after HW submission */
if (!READ_ONCE(b->irq_armed) && !list_empty(>signalers))
intel_breadcrumbs_arm_irq(b);
+
+ /* And confirm that we still want irqs enabled before we yield */
+ if (READ_ONCE(b->irq_armed) && !atomic_read(>active))
+ intel_breadcrumbs_disarm_irq(b);
}
struct intel_breadcrumbs *
@@ -315,13 +320,7 @@ void __intel_breadcrumbs_park(struct intel_breadcrumbs *b)
return;
/* Kick the work once more to drain the signalers, and disarm the irq */
- irq_work_sync(>irq_work);
- while (READ_ONCE(b->irq_armed) && !atomic_read(>active)) {
- local_irq_disable();
- signal_irq_work(>irq_work);
- local_irq_enable();
- cond_resched();
- }
+ irq_work_queue(>irq_work);
}
void intel_breadcrumbs_free(struct kref *kref)
@@ -404,7 +403,7 @@ static void insert_breadcrumb(struct i915_request *rq)
* the request as it may have completed and raised the interrupt as
* we were attaching it into the lists.
*/
- if (!b->irq_armed || __i915_request_is_complete(rq))
+ if (!READ_ONCE(b->irq_armed) || __i915_request_is_complete(rq))
irq_work_queue(>irq_work);
}
Re: [RFC 0/5] Discussion around eviction improvements
On 08/05/2024 19:09, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Last few days I was looking at the situation with VRAM over subscription, what happens versus what perhaps should happen. Browsing through the driver and running some simple experiments. I ended up with this patch series which, as a disclaimer, may be completely wrong but as I found some suspicious things, to me at least, I thought it was a good point to stop and request some comments. To perhaps summarise what are the main issues I think I found: * Migration rate limiting does not bother knowing if actual migration happened and so can over-account and unfairly penalise. * Migration rate limiting does not even work, at least not for the common case where userspace configures VRAM+GTT. It thinks it can stop migration attempts by playing with bo->allowed_domains vs bo->preferred domains but, both from the code, and from empirical experiments, I see that not working at all. Both masks are identical so fiddling with them achieves nothing. * Idea of the fallback placement only works when VRAM has free space. As soon as it does not, ttm_resource_compatible is happy to leave the buffers in the secondary placement forever. * Driver thinks it will be re-validating evicted buffers on the next submission but it does not for the very common case of VRAM+GTT because it only checks if current placement is *none* of the preferred placements. All those problems are addressed in individual patches. End result of this series appears to be driver which will try harder to move buffers back into VRAM, but will be (more) correctly throttled in doing so by the existing rate limiting logic. I have run a quick benchmark of Cyberpunk 2077 and cannot say that I saw a change but that could be a good thing too. At least I did not break anything, perhaps.. On one occassion I did see the rate limiting logic get confused while for a period of few minutes it went to a mode where it was constantly giving a high migration budget. But that recovered itself when I switched clients and did not come back so I don't know. If there is something wrong there I don't think it would be caused by any patches in this series. Since yesterday I also briefly tested with Far Cry New Dawn. One run each so possibly doesn't mean anything apart that there isn't a regression aka migration throttling is keeping things at bay even with increased requests to migrate things back to VRAM: before after min/avg/max fps 36/44/5437/45/55 Cyberpunk 2077 from yesterday was similarly close: 26.96/29.59/30.40 29.70/30.00/30.32 I guess the real story is proper DGPU where misplaced buffers have a real cost. Regards, Tvrtko Series is probably rough but should be good enough for dicsussion. I am curious to hear if I identified at least something correctly as a real problem. It would also be good to hear what are the suggested games to check and see whether there is any improvement. Cc: Christian König Cc: Friedrich Vock Tvrtko Ursulin (5): drm/amdgpu: Fix migration rate limiting accounting drm/amdgpu: Actually respect buffer migration budget drm/ttm: Add preferred placement flag drm/amdgpu: Use preferred placement for VRAM+GTT drm/amdgpu: Re-validate evicted buffers drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 38 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 8 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 21 ++-- drivers/gpu/drm/ttm/ttm_resource.c | 13 +--- include/drm/ttm/ttm_placement.h| 3 ++ 5 files changed, 65 insertions(+), 18 deletions(-)
Re: [PATCH v2 0/7] Add DSI support for RK3128
Hi Alex, Am Donnerstag, 9. Mai 2024, 14:07:08 CEST schrieb Alex Bee: > This series aims to add support for the DesignWare MIPI DSI controller and > the Innoslicon D-PHY found in RK3128 SoCs. The code additions are rather > tiny: It only need some code in the Rockchip dw-mipi-dsi glue layer for > this SoC, add support for an additional clock and do some changes in the > SoC's clock driver. Support for the phy was already added when the > Innosilicon D-PHY driver was initially submitted. I tested it with a > 800x1280 DSI panel where all 4 lanes that are supported are used. > > changes in v2: > To improve power-efficiency when the DSI controller is not in use, I > dropped the patch which made hclk_vio_h2p a critical clock and instead > added support for an AHB clock to the DSI controller driver and updated > the bindings and the addition to the SoC DT accordingly. The naming already suggests that hclk_vio_h2p is not a clock-part of the actual dsi controller, but more an internal thing inside the clock controller. At least naming and perceived functionality would suggest a chain of hclk_vio -> hclk_vio_h2p -> pclk_mipi In any case, I really don't see hclk_vio_h2p to be in the realm of the actual DSI controller, but more a part of clock-controller / interconnect. Similar to the NIU clocks for the interconnect. rk3588 actually tries to implement this already and while the gate-link clocks are described as "recent", I think this definitly the same concept used a most/all older Rockchip SoCs, just nobody cared about that till now ;-) [0] . So TL;DR I'd really prefer to not leak CRU-details into the DSI controller. Heiko [0] Which reminds me that I should look at Sebastian's make GATE-LINK actually-work-patch.
Re: [PATCH] drm: deprecate driver date
On 29/04/2024 17:43, Jani Nikula wrote:
> The driver date serves no useful purpose, because it's hardly ever
> updated. The information is misleading at best.
>
> As described in Documentation/gpu/drm-internals.rst:
>
> The driver date, formatted as MMDD, is meant to identify the date
> of the latest modification to the driver. However, as most drivers
> fail to update it, its value is mostly useless. The DRM core prints it
> to the kernel log at initialization time and passes it to userspace
> through the DRM_IOCTL_VERSION ioctl.
>
> Stop printing the driver date at init, and start returning the empty
> string "" as driver date through the DRM_IOCTL_VERSION ioctl.
I agree with the idea of this, unfortuantly it breaks user space :(
It's a bug in libdrm, but given this breaks existing user space I think
we'll need to revert/reconsider.
The issue is in drmGetVersion() [1]:
> if (version->date_len)
>
> version->date= drmMalloc(version->date_len + 1);
>
So if date_len == 0, then version->date isn't populated (and isn't
initialized at all). But then later on in drmCopyVersion() [2] the
(unset) version->date is passed to strdup():
> static void drmCopyVersion(drmVersionPtr d, const drm_version_t *s)
>
> {
>
> d->version_major = s->version_major;
>
> d->version_minor = s->version_minor;
>
> d->version_patchlevel = s->version_patchlevel;
>
> d->name_len = s->name_len;
>
> d->name = strdup(s->name);
>
> d->date_len = s->date_len;
>
> d->date = strdup(s->date);
>
> d->desc_len = s->desc_len;
>
> d->desc = strdup(s->desc);
>
> }
>
Which then segfaults if the uninitialized value points off somewhere
bad. And this does happen (my test setup reproduced this).
A simple fix is to make sure the string isn't empty - so return
"unknown" or just a space, or even "\0".
Steve
[1]
https://gitlab.freedesktop.org/mesa/drm/-/blob/7c5c742de8a8b577654964635f05d7033c92ee53/xf86drm.c#L1393
[2]
https://gitlab.freedesktop.org/mesa/drm/-/blob/7c5c742de8a8b577654964635f05d7033c92ee53/xf86drm.c#L1352
> The driver date initialization in drivers and the struct drm_driver date
> member can be removed in follow-up.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> The below approximates when each driver's date was last updated.
>
> $ git grepblame "\(\.date = \".*\"\|#define.*DRIVER_DATE\)" -- drivers/gpu
> drivers/accel
> fe77368c0f3e0 drivers/accel/habanalabs/common/habanalabs_drv.c 94 (Tomer
> Tayar 2023-02-19 11:58:46 +0200 104) .date = "20190505",
> 35b137630f08d drivers/accel/ivpu/ivpu_drv.h 20 (Jacek Lawrynowicz 2023-01-17
> 10:27:17 +0100 24) #define DRIVER_DATE "20230117"
> d38ceaf99ed01 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.h 43 (Alex Deucher
> 2015-04-20 16:55:21 -0400 43) #define DRIVER_DATE "20150101"
> 61f1c4a8ab757 drivers/gpu/drm/arm/display/komeda/komeda_kms.c 51 (james qian
> wang (Arm Technology China) 2019-01-03 11:41:30 + 64).date =
> "20181101",
> 8e22d79240d95 drivers/gpu/drm/arm/hdlcd_drv.c 343 (Liviu Dudau 2015-04-02
> 19:48:39 +0100 234) .date = "20151021",
> ad49f8602fe88 drivers/gpu/drm/arm/malidp_drv.c 232 (Liviu Dudau 2016-03-07
> 10:00:53 + 571).date = "20160106",
> 4f2a8f5898ecd drivers/gpu/drm/aspeed/aspeed_gfx_drv.c 208 (Joel Stanley
> 2019-04-03 10:49:08 +1030 253).date = "20180319",
> 312fec1405dd5 drivers/gpu/drm/ast/ast_drv.h 46 (Dave Airlie 2012-02-29
> 13:40:04 + 46) #define DRIVER_DATE "20120228"
> 1a396789f65a2 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 504 (Boris
> Brezillon 2015-01-06 11:13:28 +0100 741).date = "20141504",
> 9913f74fe1570 drivers/gpu/drm/exynos/exynos_drm_drv.c 37 (Marek Szyprowski
> 2018-05-10 08:46:36 +0900 37) #define DRIVER_DATE "20180330"
> f90cd811ae7a3 drivers/gpu/drm/gma500/psb_drv.h 43 (Arthur Borsboom 2014-03-15
> 22:12:17 +0100 29) #define DRIVER_DATE "20140314"
> 1053d01864937 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 1070 (Xu YiPing
> 2019-08-20 23:06:19 + 930) .date = "20150718",
> 76c56a5affeba drivers/gpu/drm/hyperv/hyperv_drm_drv.c 22 (Deepak Rawat
> 2021-05-27 04:22:28 -0700 22) #define DRIVER_DATE "2020"
> 3570bd989acc6 drivers/gpu/drm/i915/i915_driver.h 18 (Jani Nikula 2023-09-29
> 12:43:23 +0300 18)
[PATCH v2 3/7] clk: rockchip: rk3128: Export PCLK_MIPIPHY
Export the D-DHY's APB clock for usage in the DT. Also drop the
CLK_IGNORE_UNUSED-flag, as the clock will be enabled on demand.
Signed-off-by: Alex Bee
---
changes since v1:
- reword commit message
drivers/clk/rockchip/clk-rk3128.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3128.c
b/drivers/clk/rockchip/clk-rk3128.c
index 75071e0cd321..a20d1fd25e2a 100644
--- a/drivers/clk/rockchip/clk-rk3128.c
+++ b/drivers/clk/rockchip/clk-rk3128.c
@@ -526,7 +526,7 @@ static struct rockchip_clk_branch common_clk_branches[]
__initdata = {
GATE(PCLK_ACODEC, "pclk_acodec", "pclk_cpu", 0, RK2928_CLKGATE_CON(5),
14, GFLAGS),
GATE(0, "pclk_ddrupctl", "pclk_cpu", CLK_IGNORE_UNUSED,
RK2928_CLKGATE_CON(5), 7, GFLAGS),
GATE(0, "pclk_grf", "pclk_cpu", CLK_IGNORE_UNUSED,
RK2928_CLKGATE_CON(5), 4, GFLAGS),
- GATE(0, "pclk_mipiphy", "pclk_cpu", CLK_IGNORE_UNUSED,
RK2928_CLKGATE_CON(5), 0, GFLAGS),
+ GATE(PCLK_MIPIPHY, "pclk_mipiphy", "pclk_cpu", 0,
RK2928_CLKGATE_CON(5), 0, GFLAGS),
GATE(0, "pclk_pmu", "pclk_pmu_pre", 0, RK2928_CLKGATE_CON(9), 2,
GFLAGS),
GATE(0, "pclk_pmu_niu", "pclk_pmu_pre", CLK_IGNORE_UNUSED,
RK2928_CLKGATE_CON(9), 3, GFLAGS),
--
2.43.2
[PATCH v2 7/7] ARM: dts: rockchip: Add DSI for RK3128
Add the Designware MIPI DSI controller and it's port nodes.
Signed-off-by: Alex Bee
---
changes since v1:
- added HCLK_VIO_H2P as ahb clock
arch/arm/boot/dts/rockchip/rk3128.dtsi | 36 ++
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi
b/arch/arm/boot/dts/rockchip/rk3128.dtsi
index fbd95bb08cd3..1ed4436549ee 100644
--- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
@@ -277,6 +277,42 @@ vop_out_hdmi: endpoint@0 {
reg = <0>;
remote-endpoint = <_in_vop>;
};
+
+ vop_out_dsi: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <_in_vop>;
+ };
+ };
+ };
+
+ dsi: dsi@1011 {
+ compatible = "rockchip,rk3128-mipi-dsi", "snps,dw-mipi-dsi";
+ reg = <0x1011 0x4000>;
+ interrupts = ;
+ clocks = < PCLK_MIPI>, < HCLK_VIO_H2P>;
+ clock-names = "pclk", "ahb";
+ phys = <>;
+ phy-names = "dphy";
+ resets = < SRST_VIO_MIPI_DSI>;
+ reset-names = "apb";
+ rockchip,grf = <>;
+ power-domains = < RK3128_PD_VIO>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dsi_in: port@0 {
+ reg = <0>;
+ dsi_in_vop: endpoint {
+ remote-endpoint = <_out_dsi>;
+ };
+ };
+
+ dsi_out: port@1 {
+ reg = <1>;
+ };
};
};
--
2.43.2
[PATCH v2 6/7] ARM: dts: rockchip: Add D-PHY for RK3128
The InnoSilicon D-PHY found in RK3128 SoCs supports DSI/LVDS/TTL with a
maximum transfer rate of 1 Gbps per lane. While adding it, also add it's
clocks to RK3128_PD_VIO powerdomain as the phy is part of it.
Signed-off-by: Alex Bee
---
changes since v1:
- also added SCLK_MIPI_24M to powerdomain
- reword commit message
arch/arm/boot/dts/rockchip/rk3128.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi
b/arch/arm/boot/dts/rockchip/rk3128.dtsi
index fb98873fd94e..fbd95bb08cd3 100644
--- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
@@ -216,6 +216,8 @@ power-domain@RK3128_PD_VIO {
< ACLK_LCDC0>,
< HCLK_LCDC0>,
< PCLK_MIPI>,
+< PCLK_MIPIPHY>,
+< SCLK_MIPI_24M>,
< ACLK_RGA>,
< HCLK_RGA>,
< ACLK_VIO0>,
@@ -496,6 +498,18 @@ hdmi_out: port@1 {
};
};
+ dphy: phy@20038000 {
+ compatible = "rockchip,rk3128-dsi-dphy";
+ reg = <0x20038000 0x4000>;
+ clocks = < SCLK_MIPI_24M>, < PCLK_MIPIPHY>;
+ clock-names = "ref", "pclk";
+ resets = < SRST_MIPIPHY_P>;
+ reset-names = "apb";
+ power-domains = < RK3128_PD_VIO>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
timer0: timer@20044000 {
compatible = "rockchip,rk3128-timer", "rockchip,rk3288-timer";
reg = <0x20044000 0x20>;
--
2.43.2
[PATCH v2 5/7] drm/rockchip: dsi: Add support for RK3128
The DesignWare MIPI DSI controller found RK3128 SoCs supports up to 4 DSI
data lanes. Similar to PX30/RK356x/RV1126 it uses an external D-PHY.
Signed-off-by: Alex Bee
---
changes since v1:
- none
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 20 +++
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 6ed64cc35275..17fd5260218a 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -153,6 +153,11 @@
#define PX30_DSI_TURNDISABLE BIT(5)
#define PX30_DSI_LCDC_SEL BIT(0)
+#define RK3128_GRF_LVDS_CON0 0x0150
+#define RK3128_DSI_FORCETXSTOPMODE GENMASK(13, 10)
+#define RK3128_DSI_FORCERXMODE BIT(9)
+#define RK3128_DSI_TURNDISABLE BIT(8)
+
#define RK3288_GRF_SOC_CON60x025c
#define RK3288_DSI0_LCDC_SEL BIT(6)
#define RK3288_DSI1_LCDC_SEL BIT(9)
@@ -1518,6 +1523,18 @@ static const struct rockchip_dw_dsi_chip_data
px30_chip_data[] = {
{ /* sentinel */ }
};
+static const struct rockchip_dw_dsi_chip_data rk3128_chip_data[] = {
+ {
+ .reg = 0x1011,
+ .lanecfg1_grf_reg = RK3128_GRF_LVDS_CON0,
+ .lanecfg1 = HIWORD_UPDATE(0, RK3128_DSI_TURNDISABLE |
+RK3128_DSI_FORCERXMODE |
+RK3128_DSI_FORCETXSTOPMODE),
+ .max_data_lanes = 4,
+ },
+ { /* sentinel */ }
+};
+
static const struct rockchip_dw_dsi_chip_data rk3288_chip_data[] = {
{
.reg = 0xff96,
@@ -1695,6 +1712,9 @@ static const struct of_device_id
dw_mipi_dsi_rockchip_dt_ids[] = {
{
.compatible = "rockchip,px30-mipi-dsi",
.data = _chip_data,
+ }, {
+.compatible = "rockchip,rk3128-mipi-dsi",
+.data = _chip_data,
}, {
.compatible = "rockchip,rk3288-mipi-dsi",
.data = _chip_data,
--
2.43.2
[PATCH v2 4/7] drm/rockchip: dsi: Support optional AHB clock
Some integrations of the IP additionally have an AHB clock which has to be
enabled before accessing the registers is possible.
Add support for it as an optional clock.
Signed-off-by: Alex Bee
---
changes since v1:
- new patch
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 25 +++
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 4cc8ed8f4fbd..6ed64cc35275 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -265,6 +265,7 @@ struct dw_mipi_dsi_rockchip {
struct clk *pllref_clk;
struct clk *grf_clk;
struct clk *phy_cfg_clk;
+ struct clk *ahb_clk;
/* dual-channel */
bool is_slave;
@@ -1153,7 +1154,15 @@ static int dw_mipi_dsi_dphy_init(struct phy *phy)
goto err_init;
}
+ ret = clk_prepare_enable(dsi->ahb_clk);
+ if (ret) {
+ clk_disable_unprepare(dsi->grf_clk);
+ clk_disable_unprepare(dsi->pclk);
+ goto err_init;
+ }
+
ret = dsi->cdata->dphy_rx_init(phy);
+ clk_disable_unprepare(dsi->ahb_clk);
clk_disable_unprepare(dsi->grf_clk);
clk_disable_unprepare(dsi->pclk);
if (ret < 0)
@@ -1240,6 +1249,12 @@ static int dw_mipi_dsi_dphy_power_on(struct phy *phy)
goto err_phy_cfg_clk;
}
+ ret = clk_prepare_enable(dsi->ahb_clk);
+ if (ret) {
+ DRM_DEV_ERROR(dsi->dev, "Failed to enable ahb_clk: %d\n", ret);
+ goto err_ahb_clk;
+ }
+
/* do soc-variant specific init */
if (dsi->cdata->dphy_rx_power_on) {
ret = dsi->cdata->dphy_rx_power_on(phy);
@@ -1269,6 +1284,8 @@ static int dw_mipi_dsi_dphy_power_on(struct phy *phy)
return ret;
err_pwr_on:
+ clk_disable_unprepare(dsi->ahb_clk);
+err_ahb_clk:
clk_disable_unprepare(dsi->phy_cfg_clk);
err_phy_cfg_clk:
clk_disable_unprepare(dsi->grf_clk);
@@ -1296,6 +1313,7 @@ static int dw_mipi_dsi_dphy_power_off(struct phy *phy)
DRM_DEV_ERROR(dsi->dev, "hardware-specific phy shutdown
failed: %d\n", ret);
}
+ clk_disable_unprepare(dsi->ahb_clk);
clk_disable_unprepare(dsi->grf_clk);
clk_disable_unprepare(dsi->pclk);
@@ -1429,6 +1447,13 @@ static int dw_mipi_dsi_rockchip_probe(struct
platform_device *pdev)
}
}
+ dsi->ahb_clk = devm_clk_get_optional(dev, "ahb");
+ if (IS_ERR(dsi->ahb_clk)) {
+ ret = PTR_ERR(dsi->ahb_clk);
+ DRM_DEV_ERROR(dev, "Unable to get ahb_clk: %d\n", ret);
+ return ret;
+ }
+
dsi->grf_regmap = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
if (IS_ERR(dsi->grf_regmap)) {
DRM_DEV_ERROR(dev, "Unable to get rockchip,grf\n");
--
2.43.2
[PATCH v2 2/7] dt-bindings: clock: rk3128: Add PCLK_MIPIPHY
The DPHY's APB clock is required to be exposed in order to be able to enable it and access the phy's registers. Signed-off-by: Alex Bee Acked-by: Conor Dooley --- changes since v1: - none include/dt-bindings/clock/rk3128-cru.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/clock/rk3128-cru.h b/include/dt-bindings/clock/rk3128-cru.h index 6a47825dac5d..1be455ba4985 100644 --- a/include/dt-bindings/clock/rk3128-cru.h +++ b/include/dt-bindings/clock/rk3128-cru.h @@ -116,6 +116,7 @@ #define PCLK_GMAC 367 #define PCLK_PMU_PRE 368 #define PCLK_SIM_CARD 369 +#define PCLK_MIPIPHY 370 /* hclk gates */ #define HCLK_SPDIF 440 -- 2.43.2
[PATCH v2 1/7] dt-bindings: display: rockchip, dw-mipi-dsi: Document RK3128 DSI
Document the MIPI DSI controller for Rockchip RK3128. The integration is very similar to PX30, but it has an additional AHB clock. Signed-off-by: Alex Bee --- changes since v1: - added ahb clock .../rockchip/rockchip,dw-mipi-dsi.yaml| 25 ++- 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-mipi-dsi.yaml index ccf79e738fa1..fdd1c8ad6045 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-mipi-dsi.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-mipi-dsi.yaml @@ -15,6 +15,7 @@ properties: items: - enum: - rockchip,px30-mipi-dsi + - rockchip,rk3128-mipi-dsi - rockchip,rk3288-mipi-dsi - rockchip,rk3399-mipi-dsi - rockchip,rk3568-mipi-dsi @@ -36,7 +37,10 @@ properties: - const: pclk - const: phy_cfg - const: grf - - const: pclk + - minItems: 1 +items: + - const: pclk + - const: ahb rockchip,grf: $ref: /schemas/types.yaml#/definitions/phandle @@ -120,6 +124,25 @@ allOf: clock-names: minItems: 4 + - if: + properties: +compatible: + contains: +enum: + - rockchip,rk3128-mipi-dsi + +then: + properties: +clocks: + minItems: 2 + +clock-names: + minItems: 2 + + required: +- phys +- phy-names + unevaluatedProperties: false examples: -- 2.43.2
[PATCH v2 0/7] Add DSI support for RK3128
This series aims to add support for the DesignWare MIPI DSI controller and the Innoslicon D-PHY found in RK3128 SoCs. The code additions are rather tiny: It only need some code in the Rockchip dw-mipi-dsi glue layer for this SoC, add support for an additional clock and do some changes in the SoC's clock driver. Support for the phy was already added when the Innosilicon D-PHY driver was initially submitted. I tested it with a 800x1280 DSI panel where all 4 lanes that are supported are used. changes in v2: To improve power-efficiency when the DSI controller is not in use, I dropped the patch which made hclk_vio_h2p a critical clock and instead added support for an AHB clock to the DSI controller driver and updated the bindings and the addition to the SoC DT accordingly. Link to v1: https://lore.kernel.org/linux-kernel/20240506194343.282119-1-knaerz...@gmail.com/ Please see individual patches for details about the changes. Alex Bee (7): dt-bindings: display: rockchip,dw-mipi-dsi: Document RK3128 DSI dt-bindings: clock: rk3128: Add PCLK_MIPIPHY clk: rockchip: rk3128: Export PCLK_MIPIPHY drm/rockchip: dsi: Support optional AHB clock drm/rockchip: dsi: Add support for RK3128 ARM: dts: rockchip: Add D-PHY for RK3128 ARM: dts: rockchip: Add DSI for RK3128 .../rockchip/rockchip,dw-mipi-dsi.yaml| 25 +- arch/arm/boot/dts/rockchip/rk3128.dtsi| 50 +++ drivers/clk/rockchip/clk-rk3128.c | 2 +- .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 45 + include/dt-bindings/clock/rk3128-cru.h| 1 + 5 files changed, 121 insertions(+), 2 deletions(-) -- 2.43.2
Re: [Linaro-mm-sig] Re: [PATCH] epoll: try to be a _bit_ better about file lifetimes
On Wed, May 08, 2024 at 10:14:44AM -0700, Linus Torvalds wrote: > On Wed, 8 May 2024 at 09:19, Linus Torvalds > wrote: > > > > So since we already have two versions of F_DUPFD (the other being > > F_DUPFD_CLOEXEC) I decided that the best thing to do is to just extend > > on that existing naming pattern, and called it F_DUPFD_QUERY instead. > > > > I'm not married to the name, so if somebody hates it, feel free to > > argue otherwise. > > Side note: with this patch, doing > >ret = fcntl(fd1, F_DUPFD_QUERY, fd2); > > will result in: > > -1 (EBADF): 'fd1' is not a valid file descriptor > -1 (EINVAL): old kernel that doesn't support F_DUPFD_QUERY > 0: fd2 does not refer to the same file as fd1 > 1: fd2 is the same 'struct file' as fd1 > > and it might be worth noting a couple of things here: > > (a) fd2 being an invalid file descriptor does not cause EBADF, it > just causes "does not match". > > (b) we *could* use more bits for more equality > > IOW, it would possibly make sense to extend the 0/1 result to be > > - bit #0: same file pointer > - bit #1: same path > - bit #2: same dentry > - bit #3: same inode > > which are all different levels of "sameness". Not worth it without someone explaining in detail why imho. First pass should be to try and replace kcmp() in scenarios where it's obviously not needed or overkill. I've added a CLASS(fd_raw) in a preliminary patch since we'll need that anyway which means that your comparison patch becomes even simpler imho. I've also added a selftest patch: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/log/?h=vfs.misc ?
[PATCH] drm/amd/pm: remove deprecated I2C_CLASS_SPD support from newly added SMU_14_0_2
Support for I2C_CLASS_SPD is currently being removed from the kernel. Only remaining step is to remove the definition of I2C_CLASS_SPD. Setting I2C_CLASS_SPD in a driver is a no-op meanwhile, so remove it here. Signed-off-by: Heiner Kallweit --- drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_2_ppt.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_2_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_2_ppt.c index 0d5ad531c..fb6f3bbe2 100644 --- a/drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_2_ppt.c +++ b/drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_2_ppt.c @@ -1616,7 +1616,6 @@ static int smu_v14_0_2_i2c_control_init(struct smu_context *smu) smu_i2c->port = i; mutex_init(_i2c->mutex); control->owner = THIS_MODULE; - control->class = I2C_CLASS_SPD; control->dev.parent = >pdev->dev; control->algo = _v14_0_2_i2c_algo; snprintf(control->name, sizeof(control->name), "AMDGPU SMU %d", i); -- 2.45.0
Re: [PATCH 0/2] drm/fourcc.h: Add libcamera to Open Source Waiver
On Thu, 14 Mar 2024 at 10:12, Jacopo Mondi wrote: > gentle nudge for > > *) libcamera: are we ok being listed here ? > *) DRM/KMS: is it ok splitting the list of projects in the way I've >done ? My bikeshed would be to change the list to 1) OpenGL / OpenGL ES / EGL and its extensions, 2) Vulkan and its extensions, 3) libcamera. But it doesn't really make much difference; people are going to get the point. With whatever reasonable wording, series is: Reviewed-by: Daniel Stone Thanks Jacopo! -d
Re: [PATCH 2/2] drm/fourcc.h: Add libcamera to Open Source Waiver
On Wed, Feb 28, 2024 at 11:22:44AM +0100, Jacopo Mondi wrote:
> The libcamera (www.libcamera.org) project uses the drm/fourcc.h header
> to define its own image formats. Albeit libcamera aims for fully open
> source driver and userspace software stacks, it is licensed with the
> 'GNU L-GPL' license which allows closed source application to link
> against the library.
>
> Add libcamera to the list projects to which the 'Open Source User
> Waiver' notice applies.
>
> Signed-off-by: Jacopo Mondi
> ---
> include/uapi/drm/drm_fourcc.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 4e6df826946a..beef743ac818 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -97,6 +97,7 @@ extern "C" {
> *
> * - GL
> * - Vulkan extensions
> + * - libcamera
I think we can bikeshed whether we want to be more specific (with like
listing the gl/vk extensions), but imo it's a good start and imo also
totally makes sense to officially list libcamera. On both patches.
Acked-by: Daniel Vetter
I think collect a handful more acks from drm and libcamera folks and then
land this.
-Sima
> *
> * and other standards, and hence used both by open source and closed source
> * driver stacks, the usual requirement for an upstream in-kernel or open
> source
> --
> 2.43.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 3/3] dt-bindings: display: panel: constrain 'reg' in DSI panels
DSI-attached devices could respond to more than one virtual channel number, thus their bindings are supposed to constrain the 'reg' property to match hardware. Add missing 'reg' constrain for DSI-attached display panels, based on DTS sources in Linux kernel (assume all devices take only one channel number). Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml | 5 - .../devicetree/bindings/display/panel/boe,bf060y8m-aj0.yaml | 4 +++- Documentation/devicetree/bindings/display/panel/boe,himax8279d.yaml | 4 +++- .../devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml | 4 +++- .../devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml | 2 +- Documentation/devicetree/bindings/display/panel/elida,kd35t133.yaml | 5 - .../devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml | 5 - Documentation/devicetree/bindings/display/panel/himax,hx83112a.yaml | 4 +++- Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml | 3 ++- Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml | 4 +++- .../devicetree/bindings/display/panel/ilitek,ili9881c.yaml | 4 +++- .../devicetree/bindings/display/panel/innolux,p097pfg.yaml | 4 +++- .../devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml | 3 ++- .../devicetree/bindings/display/panel/jdi,lpm102a188a.yaml | 4 +++- .../devicetree/bindings/display/panel/jdi,lt070me05000.yaml | 4 +++- .../devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml | 5 - .../devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml | 5 - Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml | 4 +++- .../devicetree/bindings/display/panel/newvision,nv3051d.yaml| 4 +++- .../devicetree/bindings/display/panel/novatek,nt35510.yaml | 5 - .../devicetree/bindings/display/panel/novatek,nt35950.yaml | 4 +++- .../devicetree/bindings/display/panel/novatek,nt36523.yaml | 4 +++- .../devicetree/bindings/display/panel/novatek,nt36672a.yaml | 4 +++- .../devicetree/bindings/display/panel/olimex,lcd-olinuxino.yaml | 4 +++- .../devicetree/bindings/display/panel/raydium,rm67191.yaml | 4 +++- .../devicetree/bindings/display/panel/raydium,rm692e5.yaml | 4 +++- .../devicetree/bindings/display/panel/raydium,rm69380.yaml | 5 +++-- Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml | 2 +- .../devicetree/bindings/display/panel/samsung,amoled-mipi-dsi.yaml | 4 +++- .../devicetree/bindings/display/panel/samsung,s6d16d0.yaml | 4 +++- .../devicetree/bindings/display/panel/samsung,s6d7aa0.yaml | 3 ++- .../bindings/display/panel/samsung,s6e88a0-ams452ef01.yaml | 5 - .../devicetree/bindings/display/panel/samsung,s6e8aa0.yaml | 4 +++- .../devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml| 4 +++- .../devicetree/bindings/display/panel/sharp,ls043t1le01.yaml| 4 +++- .../devicetree/bindings/display/panel/sharp,ls060t1sx01.yaml| 4 +++- Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml | 5 - .../devicetree/bindings/display/panel/sony,td4353-jdi.yaml | 3 ++- .../devicetree/bindings/display/panel/sony,tulip-truly-nt35521.yaml | 3 ++- .../devicetree/bindings/display/panel/synaptics,r63353.yaml | 6 -- .../devicetree/bindings/display/panel/visionox,rm69299.yaml | 3 ++- .../devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml | 5 - 42 files changed, 126 insertions(+), 44 deletions(-) diff --git a/Documentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml b/Documentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml index 75a09df68ba0..2399cabf044c 100644 --- a/Documentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml +++ b/Documentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml @@ -21,7 +21,10 @@ allOf: properties: compatible: const: asus,z00t-tm5p5-n35596 - reg: true + + reg: +maxItems: 1 + reset-gpios: true vdd-supply: description: core voltage supply diff --git a/Documentation/devicetree/bindings/display/panel/boe,bf060y8m-aj0.yaml b/Documentation/devicetree/bindings/display/panel/boe,bf060y8m-aj0.yaml index a8f3afa922c8..8b7448ad9138 100644 --- a/Documentation/devicetree/bindings/display/panel/boe,bf060y8m-aj0.yaml +++ b/Documentation/devicetree/bindings/display/panel/boe,bf060y8m-aj0.yaml @@ -26,6 +26,9 @@ properties: compatible: const: boe,bf060y8m-aj0 + reg: +maxItems: 1 + elvdd-supply: description: EL Driving positive (VDD) supply (4.40-4.80V) elvss-supply: @@ -38,7 +41,6 @@ properties: description: I/O voltage supply (1.62-1.98V) port: true - reg: true reset-gpios: true required: diff --git
[PATCH 2/3] dt-bindings: display: panel: constrain 'reg' in SPI panels
SPI-attached devices could have more than one chip-select, thus their bindings are supposed to constrain the 'reg' property to match hardware. Add missing 'reg' constrain for SPI-attached display panels. Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml | 4 +++- .../devicetree/bindings/display/panel/fascontek,fs035vg158.yaml | 3 +++ Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml | 4 +++- Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml | 3 +++ Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml | 3 ++- Documentation/devicetree/bindings/display/panel/innolux,ej030na.yaml | 4 +++- .../devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml | 4 +++- .../devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml | 3 +++ Documentation/devicetree/bindings/display/panel/lg,lg4573.yaml| 3 ++- .../devicetree/bindings/display/panel/lgphilips,lb035q02.yaml | 3 +++ Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml | 4 +++- .../devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml | 3 +++ .../devicetree/bindings/display/panel/samsung,ams495qa01.yaml | 4 +++- Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml | 4 +++- .../devicetree/bindings/display/panel/samsung,lms380kf01.yaml | 3 ++- .../devicetree/bindings/display/panel/samsung,lms397kf04.yaml | 3 ++- Documentation/devicetree/bindings/display/panel/samsung,s6d27a1.yaml | 3 ++- Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.yaml | 4 +++- Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml | 4 +++- Documentation/devicetree/bindings/display/panel/sony,acx565akm.yaml | 3 +++ Documentation/devicetree/bindings/display/panel/tpo,td.yaml | 4 +++- Documentation/devicetree/bindings/display/panel/tpo,tpg110.yaml | 3 ++- 22 files changed, 60 insertions(+), 16 deletions(-) diff --git a/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml b/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml index acd2f3faa6b9..0aa2d3fbadaa 100644 --- a/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml +++ b/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml @@ -17,10 +17,12 @@ properties: compatible: const: abt,y030xx067a + reg: +maxItems: 1 + backlight: true port: true power-supply: true - reg: true reset-gpios: true required: diff --git a/Documentation/devicetree/bindings/display/panel/fascontek,fs035vg158.yaml b/Documentation/devicetree/bindings/display/panel/fascontek,fs035vg158.yaml index d13c4bd26de4..9847da784cc8 100644 --- a/Documentation/devicetree/bindings/display/panel/fascontek,fs035vg158.yaml +++ b/Documentation/devicetree/bindings/display/panel/fascontek,fs035vg158.yaml @@ -17,6 +17,9 @@ properties: compatible: const: fascontek,fs035vg158 + reg: +maxItems: 1 + spi-3wire: true required: diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml index 3cabbba86581..ef5a2240b684 100644 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml @@ -24,6 +24,9 @@ properties: - newhaven,1.8-128160EF - const: ilitek,ili9163 + reg: +maxItems: 1 + spi-max-frequency: maximum: 3200 @@ -32,7 +35,6 @@ properties: description: Display data/command selection (D/CX) backlight: true - reg: true reset-gpios: true rotation: true diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml index 7d221ef35443..44423465f6e3 100644 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml @@ -26,6 +26,9 @@ properties: - dlink,dir-685-panel - const: ilitek,ili9322 + reg: +maxItems: 1 + reset-gpios: true port: true diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml index 94f169ea065a..5f41758c96d5 100644 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml @@ -28,7 +28,8 @@ properties: - canaan,kd233-tft - const: ilitek,ili9341 - reg: true + reg: +maxItems: 1 dc-gpios: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/panel/innolux,ej030na.yaml b/Documentation/devicetree/bindings/display/panel/innolux,ej030na.yaml index 72788e3e6c59..c7df9a7f6589 100644 ---
[PATCH 1/3] dt-bindings: display: samsung,ams495qa01: add missing SPI properties ref
Samsung AMS495QA01 panel is a SPI device, so it should reference
spi-peripheral-props.yaml schema to allow and validate the SPI device
properties.
Fixes: 92be07c65b22 ("dt-bindings: display: panel: Add Samsung AMS495QA01")
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/display/panel/samsung,ams495qa01.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/display/panel/samsung,ams495qa01.yaml
b/Documentation/devicetree/bindings/display/panel/samsung,ams495qa01.yaml
index 58fa073ce258..a5ff4de74a15 100644
--- a/Documentation/devicetree/bindings/display/panel/samsung,ams495qa01.yaml
+++ b/Documentation/devicetree/bindings/display/panel/samsung,ams495qa01.yaml
@@ -11,6 +11,7 @@ maintainers:
allOf:
- $ref: panel-common.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
properties:
compatible:
--
2.43.0
[PATCH 0/3] dt-bindings: display: panel: constrain 'reg'
- Documentation/devicetree/bindings/display/panel/sony,acx565akm.yaml | 3 +++ .../devicetree/bindings/display/panel/sony,td4353-jdi.yaml | 3 ++- .../devicetree/bindings/display/panel/sony,tulip-truly-nt35521.yaml | 3 ++- .../devicetree/bindings/display/panel/synaptics,r63353.yaml | 6 -- Documentation/devicetree/bindings/display/panel/tpo,td.yaml | 4 +++- Documentation/devicetree/bindings/display/panel/tpo,tpg110.yaml | 3 ++- .../devicetree/bindings/display/panel/visionox,rm69299.yaml | 3 ++- .../devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml | 5 - 64 files changed, 187 insertions(+), 60 deletions(-) --- base-commit: b010817abf0197596fbfddf1957bac968facb991 change-id: 20240509-dt-bindings-dsi-panel-reg-a6e7d930b46f Best regards, -- Krzysztof Kozlowski
Re: [PATCH v2 6/6] drm/xe/client: Print runtime to fdinfo
On 08/05/2024 21:53, Lucas De Marchi wrote: On Wed, May 08, 2024 at 09:23:17AM GMT, Tvrtko Ursulin wrote: On 07/05/2024 22:35, Lucas De Marchi wrote: On Fri, Apr 26, 2024 at 11:47:37AM GMT, Tvrtko Ursulin wrote: On 24/04/2024 00:56, Lucas De Marchi wrote: Print the accumulated runtime for client when printing fdinfo. Each time a query is done it first does 2 things: 1) loop through all the exec queues for the current client and accumulate the runtime, per engine class. CTX_TIMESTAMP is used for that, being read from the context image. 2) Read a "GPU timestamp" that can be used for considering "how much GPU time has passed" and that has the same unit/refclock as the one recording the runtime. RING_TIMESTAMP is used for that via MMIO. Since for all current platforms RING_TIMESTAMP follows the same refclock, just read it once, using any first engine. This is exported to userspace as 2 numbers in fdinfo: drm-cycles-: drm-total-cycles-: Userspace is expected to collect at least 2 samples, which allows to know the client engine busyness as per: RUNTIME1 - RUNTIME0 busyness = - T1 - T0 Another thing to point out is that it's expected that userspace will read any 2 samples every few seconds. Given the update frequency of the counters involved and that CTX_TIMESTAMP is 32-bits, the counter for each exec_queue can wrap around (assuming 100% utilization) after ~200s. The wraparound is not perceived by userspace since it's just accumulated for all the exec_queues in a 64-bit counter), but the measurement will not be accurate if the samples are too far apart. This could be mitigated by adding a workqueue to accumulate the counters every so often, but it's additional complexity for something that is done already by userspace every few seconds in tools like gputop (from igt), htop, nvtop, etc with none of them really defaulting to 1 sample per minute or more. Signed-off-by: Lucas De Marchi --- Documentation/gpu/drm-usage-stats.rst | 16 ++- Documentation/gpu/xe/index.rst | 1 + Documentation/gpu/xe/xe-drm-usage-stats.rst | 10 ++ drivers/gpu/drm/xe/xe_drm_client.c | 138 +++- 4 files changed, 162 insertions(+), 3 deletions(-) create mode 100644 Documentation/gpu/xe/xe-drm-usage-stats.rst diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst index 6dc299343b48..421766289b78 100644 --- a/Documentation/gpu/drm-usage-stats.rst +++ b/Documentation/gpu/drm-usage-stats.rst @@ -112,6 +112,17 @@ larger value within a reasonable period. Upon observing a value lower than what was previously read, userspace is expected to stay with that larger previous value until a monotonic update is seen. +- drm-total-cycles-: + +Engine identifier string must be the same as the one specified in the +drm-cycles- tag and shall contain the total number cycles for the given +engine. + +This is a timestamp in GPU unspecified unit that matches the update rate +of drm-cycles-. For drivers that implement this interface, the engine +utilization can be calculated entirely on the GPU clock domain, without +considering the CPU sleep time between 2 samples. Two opens. 1) Do we need to explicity document that drm-total-cycles and drm-maxfreq are mutually exclusive? so userspace has a fallback mechanism to calculate utilization depending on what keys are available? No, to document all three at once do not make sense. Or at least are not expected. Or you envisage someone might legitimately emit all three? I don't see what would be the semantics. When we have cycles+maxfreq the latter is in Hz. And when we have cycles+total then it is unitless. All three? I don't follow what you mean here. *cycles* is actually a unit. The engine spent 10 cycles running this context (drm-cycles). In the same period there were 100 cycles available (drm-total-cycles). Current frequency is X MHz. Max frequency is Y MHz. For me all of them make sense if one wants to mix them together. For xe it doesn't make sense because the counter backing drm-cycles and drm-total-cycles is unrelated to the engine frequency. I can add something in the doc that we do not expected to see all of them together until we see a usecase. Each driver may implement a subset. I still don't quite see how a combination of cycles, total cycles and maxfreq makes sense together. It would require a driver where cycle period is equal to 1 / maxfreq, which also means total-cycles would be equal to maxfreq, making one of them redundant. So both for drivers like xe where cycle period is unrelated to maxfreq (or even the fataly misguided curfreq) it doens't make sense, and for driver like above is not needed. What use case am I missing? We need to document this properly so userspace knows how to do the right thing depending on what keys they discover. 2) Should drm-total-cycles for now be
Re: [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
Il 09/05/24 07:42, CK Hu (胡俊光) ha scritto: On Wed, 2024-05-08 at 15:03 +0200, AngeloGioacchino Del Regno wrote: Il 08/05/24 09:19, CK Hu (胡俊光) ha scritto: On Tue, 2024-05-07 at 16:07 +0200, AngeloGioacchino Del Regno wrote: Il 07/05/24 08:59, CK Hu (胡俊光) ha scritto: On Thu, 2024-05-02 at 10:50 +0200, AngeloGioacchino Del Regno wrote: Il 25/04/24 04:23, CK Hu (胡俊光) ha scritto: Hi, Angelo: On Tue, 2024-04-09 at 14:02 +0200, AngeloGioacchino Del Regno wrote: Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths per HW instance (so potentially up to six displays for multi- vdo SoCs). The MMSYS or VDOSYS is always the first component in the DDP pipeline, so it only supports an output port with multiple endpoints - where each endpoint defines the starting point for one of the (currently three) possible hardware paths. Signed-off-by: AngeloGioacchino Del Regno < angelogioacchino.delre...@collabora.com> --- .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++ 1 file changed, 23 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek ,mms ys.y aml b/Documentation/devicetree/bindings/arm/mediatek/mediatek ,mms ys.y aml index b3c6888c1457..4e9acd966aa5 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek ,mms ys.y aml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek ,mms ys.y aml @@ -93,6 +93,29 @@ properties: '#reset-cells': const: 1 + port: +$ref: /schemas/graph.yaml#/properties/port +description: + Output port node. This port connects the MMSYS/VDOSYS output to + the first component of one display pipeline, for example one of + the available OVL or RDMA blocks. + Some MediaTek SoCs support up to three display outputs per MMSYS. +properties: + endpoint@0: +$ref: /schemas/graph.yaml#/properties/endpoint +description: Output to the primary display pipeline + + endpoint@1: +$ref: /schemas/graph.yaml#/properties/endpoint +description: Output to the secondary display pipeline + + endpoint@2: +$ref: /schemas/graph.yaml#/properties/endpoint +description: Output to the tertiary display pipeline + +required: + - endpoint@0 + mmsys/vdosys does not output data to the first component of display pipeline, so this connection looks 'virtual'. Shall we add something virtual in device tree? You add this in order to decide which pipeline is 1st, 2nd, 3rd, but for device it don't care which one is first. In computer, software could change which display is the primary display. I'm not sure it's good to decide display order in device tree? Devicetree describes hardware, so nothing virtual can be present - and in any case, the primary/secondary/tertiary pipeline is in relation to MM/VDO SYS, not referred to software. Better explaining, the primary pipeline is not necessarily the primary display in DRM terms: that's a concept that is completely detached from the scope of this series and this graph - and it's something that shall be managed solely by the driver (mediatek-drm in this case). Coming back to the connection looking, but *not* being virtual: the sense here is that the MM/VDOSYS blocks are used in the display pipeline to "stitch" together the various display pipeline hardware blocks, or, said differently, setting up the routing between all of those (P.S.: mmsys_mt_routing_table!) through the VDO Input Selection (VDOx_SEL_IN) or Output Selection (VDOx_SEL_OUT) and with the assistance of the VDO Multiple Output Mask (VDOx_MOUT) for the multiple outputs usecase, both of which, are described by this graph. I agree this part, but this is related to display device OF graph. These display device would output video data from one device and input to another video device. These video device would not input or output video data to mmsys/vdosys. This means that the VDOSYS is really the "master" of the display pipeline since everything gets enabled, mixed and matched from there - and that's in the sense of hardware operation, so we are *really* (and not virtually!) flipping switches. I agree mmsys/vdosys is master of video pipeline, so let's define what the port in mmsys/vdosys is. If the port means the master relationship, mmsys/vdosys should output port to every display device. Or use a simply way to show the master relation ship mmsys-subdev = <, , , ...>, <, , , ...>; There's no need to list all of the VDO0/VDO1/mmsys devices in one big array property, because the actual possible devices can be defined: 1. In the bindings; and 2. In the actual OF graph that we write for each SoC+board combination. A graph cannot contain a connection to a device that cannot be connected to the previous, so, your "mmsys-subdev" list can be retrieved by looking at the graph: - Start from VDO0/1 or MMSYS - Walk through (visually, even) OUTPUT ports - VDO0 (read output ep)
Re: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ?
Hi, On Wed, 8 May 2024 at 16:49, Daniel Vetter wrote: > On Wed, May 08, 2024 at 09:38:33AM +0100, Daniel Stone wrote: > > Right now, if your platform requires CMA for display, then the app > > needs access to the GPU render node and the display node too, in order > > to allocate buffers which the compositor can scan out directly. If it > > only has access to the render nodes and not the display node, it won't > > be able to allocate correctly, so its content will need a composition > > pass, i.e. performance penalty for sandboxing. But if it can allocate > > correctly, then hey, it can exhaust CMA just like heaps can. > > > > Personally I think we'd be better off just allowing access and > > figuring out cgroups later. It's not like the OOM story is great > > generally, and hey, you can get there with just render nodes ... > > Imo the right fix is to ask the compositor to allocate the buffers in this > case, and then maybe have some kind of revoke/purge behaviour on these > buffers. Compositor has an actual idea of who's a candidate for direct > scanout after all, not the app. Or well at least force migrate the memory > from cma to shmem. > > If you only whack cgroups on this issue you're still stuck in the world > where either all apps together can ddos the display or no one can > realistically direct scanout. Mmm, back to DRI2. I can't say I'm wildly enthused about that, not least because a client using GPU/codec/etc for those buffers would have to communicate its requirements (alignment etc) forward to the compositor in order for the compositor to allocate for it. Obviously passing the constraints etc around isn't a solved problem yet, but it is at least contained down in clients rather than making it back and forth between client and compositor. I'm extremely not-wild about the compositor migrating memory from CMA to shmem behind the client's back, and tbh I'm not sure how that would even work if the client has it pinned through whatever API it's imported into. Anyway, like Laurent says, if we're deciding that heaps can't be used by generic apps (unlike DRM/V4L2/etc), then we need gralloc. Cheers, Daniel
Re: [RFC 1/5] drm/amdgpu: Fix migration rate limiting accounting
On 08/05/2024 20:08, Friedrich Vock wrote:
On 08.05.24 20:09, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
The logic assumed any migration attempt worked and therefore would over-
account the amount of data migrated during buffer re-validation. As a
consequence client can be unfairly penalised by incorrectly considering
its migration budget spent.
If the migration failed but data was still moved (which I think could be
the case when we try evicting everything but it still doesn't work?),
shouldn't the eviction movements count towards the ratelimit too?
Possibly, which path would that be?
I mean there are definitely more migration which *should not* be counted
which I think your mini-series approaches more accurately. What this
patch achieves, in its current RFC form, is reduces the "false-positive"
migration budget depletions.
So larger improvements aside, point of the series was to illustrate that
even the things which were said to be working do not seem to. See cover
letter to see what I thought does not work either well or at all.
Fix it by looking at the before and after buffer object backing store and
only account if there was a change.
FIXME:
I think this needs a better solution to account for migrations between
VRAM visible and non-visible portions.
FWIW, I have some WIP patches (not posted on any MLs yet though) that
attempt to solve this issue (+actually enforcing ratelimits) by moving
the ratelimit accounting/enforcement to TTM entirely.
By moving the accounting to TTM we can count moved bytes when we move
them, and don't have to rely on comparing resources to determine whether
moving actually happened. This should address your FIXME as well.
Yep, I've seen them. They are not necessarily conflicting with this
series, potentialy TTM placement flag aside. *If* something like this
can be kept small and still manage to fix up a few simple things which
do not appear to work at all at the moment.
For the larger re-work it is quite, well, large and it is not easy to be
certain the end result would work as expected. IMO it would be best to
sketch out a larger series which brings some practical and masurable
change in behaviour before commiting to merge things piecemeal.
For instance I have a niggling feeling the runtime games driver plays
with placements and domains are not great and wonder if things could be
cleaner if simplified by letting TTM manage things more, more
explicitly, and having the list of placements more static. Thinking
about it seems a step too far for now though.
Regards,
Tvrtko
Regards,
Friedrich
Signed-off-by: Tvrtko Ursulin
Cc: Christian König
Cc: Friedrich Vock
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index ec888fc6ead8..22708954ae68 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -784,12 +784,15 @@ static int amdgpu_cs_bo_validate(void *param,
struct amdgpu_bo *bo)
.no_wait_gpu = false,
.resv = bo->tbo.base.resv
};
+ struct ttm_resource *old_res;
uint32_t domain;
int r;
if (bo->tbo.pin_count)
return 0;
+ old_res = bo->tbo.resource;
+
/* Don't move this buffer if we have depleted our allowance
* to move it. Don't move anything if the threshold is zero.
*/
@@ -817,16 +820,29 @@ static int amdgpu_cs_bo_validate(void *param,
struct amdgpu_bo *bo)
amdgpu_bo_placement_from_domain(bo, domain);
r = ttm_bo_validate(>tbo, >placement, );
- p->bytes_moved += ctx.bytes_moved;
- if (!amdgpu_gmc_vram_full_visible(>gmc) &&
- amdgpu_res_cpu_visible(adev, bo->tbo.resource))
- p->bytes_moved_vis += ctx.bytes_moved;
-
if (unlikely(r == -ENOMEM) && domain != bo->allowed_domains) {
domain = bo->allowed_domains;
goto retry;
}
+ if (!r) {
+ struct ttm_resource *new_res = bo->tbo.resource;
+ bool moved = true;
+
+ if (old_res == new_res)
+ moved = false;
+ else if (old_res && new_res &&
+ old_res->mem_type == new_res->mem_type)
+ moved = false;
+
+ if (moved) {
+ p->bytes_moved += ctx.bytes_moved;
+ if (!amdgpu_gmc_vram_full_visible(>gmc) &&
+ amdgpu_res_cpu_visible(adev, bo->tbo.resource))
+ p->bytes_moved_vis += ctx.bytes_moved;
+ }
+ }
+
return r;
}
Re: [PATCH v1 1/2] dt-bindings: display: panel: Add Starry-er88577 support
On 09/05/2024 10:40, Krzysztof Kozlowski wrote: > >> + >> +maintainers: >> + - Zhaoxiong Lv >> + >> +allOf: >> + - $ref: panel-common.yaml# >> + >> +properties: >> + compatible: >> +const: starry,er88577 >> + >> + pp3300-supply: true >> + reg: true > > Hm, I wonder why we do not have constraints here in most of the bindings... > I'll send a patchset adding maxItems to other cases, so please use maxItems here instead. Best regards, Krzysztof
[PATCH] drm/hisilicon: Fix a NULL pointer access when call hibmc_unload
From: Shixiong Ou
If Calling hibmc_mm_init() failed in hibmc_load(), the hibmc_unload()
will access a NULL pointer, as it don't call ww_mutex_init() to
initialize mode_config.connection_mutex but try to lock it when
calling drm_atomic_helper_shutdown().
[ 50.939211][ 0] Unable to handle kernel NULL pointer dereference at virtual
address 0018
..
[ 51.149882][ 0] Call trace:
[ 51.152750][ 0] ww_mutex_lock+0xf0/0x1e0
[ 51.156829][ 0] drm_modeset_lock+0x184/0x2c0
[ 51.161254][ 0] drm_modeset_lock_all_ctx+0x98/0x188
[ 51.166284][ 0] drm_atomic_helper_shutdown+0xa4/0x128
[ 51.171487][ 0] hibmc_unload+0x50/0x2f0
[ 51.175479][ 0] hibmc_load+0x5d8/0x888
[ 51.179386][ 0] drm_dev_register+0x280/0x558
[ 51.183811][ 0] drm_get_pci_dev+0x140/0x3c8
[ 51.188150][ 0] hibmc_pci_probe+0x148/0x190
[ 51.192489][ 0] local_pci_probe+0xc4/0x180
[ 51.196742][ 0] pci_device_probe+0x328/0x530
[ 51.201167][ 0] really_probe+0x498/0x9a0
[ 51.205248][ 0] driver_probe_device+0x224/0x308
[ 51.209932][ 0] device_driver_attach+0xec/0x128
[ 51.214616][ 0] __driver_attach+0x144/0x280
[ 51.218955][ 0] bus_for_each_dev+0x120/0x1a0
[ 51.223380][ 0] driver_attach+0x48/0x60
[ 51.227372][ 0] bus_add_driver+0x328/0x578
[ 51.231625][ 0] driver_register+0x148/0x398
[ 51.235965][ 0] __pci_register_driver+0x15c/0x1c8
[ 51.240823][ 0] hibmc_init+0x2c/0x34
[ 51.244557][ 0] do_one_initcall+0xc8/0x4a8
[ 51.248810][ 0] kernel_init_freeable+0x678/0x75c
[ 51.253582][ 0] kernel_init+0x18/0x128
[ 51.257489][ 0] ret_from_fork+0x10/0x18
Add a initialized flag to avoid this.
Signed-off-by: Shixiong Ou
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 8 ++--
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 1 +
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 57c21ec452b7..343f64d66e75 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -99,6 +99,7 @@ static int hibmc_kms_init(struct hibmc_drm_private *priv)
ret = drmm_mode_config_init(dev);
if (ret)
return ret;
+ priv->mode_config_initialized = true;
dev->mode_config.min_width = 0;
dev->mode_config.min_height = 0;
@@ -240,9 +241,12 @@ static int hibmc_hw_init(struct hibmc_drm_private *priv)
static int hibmc_unload(struct drm_device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev->dev);
+ struct hibmc_drm_private *priv = to_hibmc_drm_private(dev);
- drm_atomic_helper_shutdown(dev);
-
+ if(priv->mode_config_initialized){
+ drm_atomic_helper_shutdown(dev);
+ priv->mode_config_initialized = false;
+ }
free_irq(pdev->irq, dev);
pci_disable_msi(to_pci_dev(dev->dev));
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index 207aa3f660b0..08fd7cb59bb5 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -37,6 +37,7 @@ struct hibmc_drm_private {
struct drm_crtc crtc;
struct drm_encoder encoder;
struct hibmc_connector connector;
+ bool mode_config_initialized;
};
static inline struct hibmc_connector *to_hibmc_connector(struct drm_connector
*connector)
--
2.25.1
[PATCH] drm/radeon: Delay Connector detecting when HPD singals is unstable
From: Shixiong Ou
In some causes, HPD signals will jitter when plugging in
or unplugging HDMI.
Rescheduling the hotplug work for a second when EDID may still be
readable but HDP is disconnected, and fixes this issue.
Signed-off-by: Shixiong Ou
---
drivers/gpu/drm/radeon/radeon_connectors.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index b84b58926106..cf0114ca59a4 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -1267,6 +1267,16 @@ radeon_dvi_detect(struct drm_connector *connector, bool
force)
goto exit;
}
}
+
+ if (dret && radeon_connector->hpd.hpd != RADEON_HPD_NONE &&
+ !radeon_hpd_sense(rdev, radeon_connector->hpd.hpd) &&
+ connector->connector_type == DRM_MODE_CONNECTOR_HDMIA) {
+ DRM_DEBUG_KMS("EDID is readable when HPD disconnected\n");
+ schedule_delayed_work(>hotplug_work,
msecs_to_jiffies(1000));
+ ret = connector_status_disconnected;
+ goto exit;
+ }
+
if (dret) {
radeon_connector->detected_by_load = false;
radeon_connector_free_edid(connector);
--
2.17.1
Re: [PATCH v2 1/2] dt-bindings: display: panel: Add Starry-er88577 support
On 09/05/2024 10:34, Zhaoxiong Lv wrote: > Create a new dt-scheam for the Starry-er88577. > > Signed-off-by: Zhaoxiong Lv > --- > Chage since V2: > > - Unmodified > > V1: > https://lore.kernel.org/all/20240509064959.23550-2-lvzhaoxi...@huaqin.corp-partner.google.com/ You just sent v1 2 hours before! Allow people to actually review your patches - one submission per 24h. Implement feedback you already got. Best regards, Krzysztof
Re: [PATCH v1 1/2] dt-bindings: display: panel: Add Starry-er88577 support
On 09/05/2024 08:49, Zhaoxiong Lv wrote:
> Create a new dt-scheam for the Starry-er88577.
typo, but anyway, this is not a "dt-schema".
Describe hardware instead in one sentence.
>
> Signed-off-by: Zhaoxiong Lv
> ---
> .../display/panel/starry,er88577.yaml | 59 +++
> 1 file changed, 59 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/starry,er88577.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/starry,er88577.yaml
> b/Documentation/devicetree/bindings/display/panel/starry,er88577.yaml
> new file mode 100644
> index ..6686beaf0f16
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/starry,er88577.yaml
> @@ -0,0 +1,59 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/starry,er88577.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Starry Display ER88577 based MIPI-DSI panels
> +
> +description: |
Do not need '|' unless you need to preserve formatting.
> + -This binding is for display panels using an ER88577 controller
No need to say binding is a binding. Describe hardware instead.
> +
> +maintainers:
> + - Zhaoxiong Lv
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +const: starry,er88577
> +
> + pp3300-supply: true
> + reg: true
Hm, I wonder why we do not have constraints here in most of the bindings...
Anyway, keep the same order as in required:
> +
> +required:
> + - compatible
> + - reg
> + - enable-gpios
> + - pp3300-supply
> + - backlight
> + - port
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> +#include
You include this header for?
> +
> +dsi {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +panel: panel@0 {
> +compatible = "starry,er88577";
> +reg = <0>;
> +enable-gpios = < 98 0>;
And here do not use it? Use the define.
Best regards,
Krzysztof
[PATCH v2 2/2] drm/panel: starry: add new panel driver
The starry panel is based on ER88577 controller.
Add a driver for it.
Signed-off-by: Zhaoxiong Lv
---
Chage since V2:
- add the Makefile and Kconfig files
V1:
https://lore.kernel.org/all/20240509064959.23550-3-lvzhaoxi...@huaqin.corp-partner.google.com/
---
drivers/gpu/drm/panel/Kconfig| 9 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-starry-er88577.c | 444 +++
3 files changed, 454 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-starry-er88577.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 2c73086cf102..c075b1875ca6 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -795,6 +795,15 @@ config DRM_PANEL_SONY_TULIP_TRULY_NT35521
NT35521 1280x720 video mode panel as found on Sony Xperia M4
Aqua phone.
+config DRM_PANEL_STARRY_ER88577
+ tristate "Starry er88577 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y if you want to enable support for panels based on the
+ Starry er88577 controller.
+
config DRM_PANEL_STARTEK_KD070FHFID015
tristate "STARTEK KD070FHFID015 panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index cbd414b98bb0..d18917e0e192 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -80,6 +80,7 @@ obj-$(CONFIG_DRM_PANEL_SHARP_LS060T1SX01) +=
panel-sharp-ls060t1sx01.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += panel-sitronix-st7701.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7703) += panel-sitronix-st7703.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
+obj-$(CONFIG_DRM_PANEL_STARRY_ER88577) += panel-starry-er88577.o
obj-$(CONFIG_DRM_PANEL_SYNAPTICS_R63353) += panel-synaptics-r63353.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
obj-$(CONFIG_DRM_PANEL_SONY_TD4353_JDI) += panel-sony-td4353-jdi.o
diff --git a/drivers/gpu/drm/panel/panel-starry-er88577.c
b/drivers/gpu/drm/panel/panel-starry-er88577.c
new file mode 100644
index ..dfeae549adc5
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-starry-er88577.c
@@ -0,0 +1,444 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Panels based on the ER88577B display controller.
+ * Author: Zhaoxiong Lv
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+struct panel_desc {
+ const struct drm_display_mode *modes;
+ unsigned int bpc;
+
+ /**
+* @width_mm: width of the panel's active display area
+* @height_mm: height of the panel's active display area
+*/
+ struct {
+ unsigned int width_mm;
+ unsigned int height_mm;
+ } size;
+
+ unsigned long mode_flags;
+ enum mipi_dsi_pixel_format format;
+ const struct panel_init_cmd *init_cmds;
+ unsigned int lanes;
+ bool discharge_on_disable;
+ bool lp11_before_reset;
+};
+
+struct starry_panel {
+ struct drm_panel base;
+ struct mipi_dsi_device *dsi;
+
+ const struct panel_desc *desc;
+
+ enum drm_panel_orientation orientation;
+ struct regulator *pp3300;
+ struct gpio_desc *enable_gpio;
+};
+
+enum dsi_cmd_type {
+ INIT_DCS_CMD,
+ DELAY_CMD,
+};
+
+struct panel_init_cmd {
+ enum dsi_cmd_type type;
+ size_t len;
+ const char *data;
+};
+
+#define _INIT_DCS_CMD(...) { \
+ .type = INIT_DCS_CMD, \
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+#define _INIT_DELAY_CMD(...) { \
+ .type = DELAY_CMD,\
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+static const struct panel_init_cmd starry_er88577_init_cmd[] = {
+ _INIT_DELAY_CMD(120),
+ _INIT_DCS_CMD(0xE0, 0xAB, 0xBA),
+ _INIT_DCS_CMD(0xE1, 0xBA, 0xAB),
+ _INIT_DCS_CMD(0xB1, 0x10, 0x01, 0x47, 0xFF),
+ _INIT_DCS_CMD(0xB2, 0x0C, 0x14, 0x04, 0x50, 0x50, 0x14),
+ _INIT_DCS_CMD(0xB3, 0x56, 0x53, 0x00),
+ _INIT_DCS_CMD(0xB4, 0x33, 0x30, 0x04),
+ _INIT_DCS_CMD(0xB6, 0xB0, 0x00, 0x00, 0x10, 0x00, 0x10, 0x00),
+ _INIT_DCS_CMD(0xB8, 0x05, 0x12, 0x29, 0x49, 0x40),
+ _INIT_DCS_CMD(0xB9, 0x7C, 0x61, 0x4F, 0x42, 0x3E, 0x2D, 0x31, 0x1A,
0x33, 0x33, 0x33, 0x52, 0x40, 0x47, 0x38, 0x34, 0x26, 0x0E, 0x06, 0x7C, 0x61,
0x4F, 0x42, 0x3E, 0x2D, 0x31, 0x1A, 0x33, 0x33, 0x33, 0x52, 0x40, 0x47, 0x38,
0x34, 0x26, 0x0E, 0x06),
+ _INIT_DCS_CMD(0xC0, 0xCC, 0x76, 0x12, 0x34, 0x44, 0x44, 0x44, 0x44,
0x98, 0x04, 0x98, 0x04, 0x0F, 0x00, 0x00, 0xC1),
+ _INIT_DCS_CMD(0xC1, 0x54, 0x94, 0x02, 0x85, 0x9F, 0x00, 0x6F, 0x00,
0x54, 0x00),
+ _INIT_DCS_CMD(0xC2, 0x17, 0x09, 0x08, 0x89, 0x08, 0x11, 0x22, 0x20,
0x44, 0xFF, 0x18, 0x00),
+
[PATCH v2 1/2] dt-bindings: display: panel: Add Starry-er88577 support
Create a new dt-scheam for the Starry-er88577.
Signed-off-by: Zhaoxiong Lv
---
Chage since V2:
- Unmodified
V1:
https://lore.kernel.org/all/20240509064959.23550-2-lvzhaoxi...@huaqin.corp-partner.google.com/
---
.../display/panel/starry,er88577.yaml | 59 +++
1 file changed, 59 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/starry,er88577.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/starry,er88577.yaml
b/Documentation/devicetree/bindings/display/panel/starry,er88577.yaml
new file mode 100644
index ..6686beaf0f16
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/starry,er88577.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/starry,er88577.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Starry Display ER88577 based MIPI-DSI panels
+
+description: |
+ -This binding is for display panels using an ER88577 controller
+
+maintainers:
+ - Zhaoxiong Lv
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: starry,er88577
+
+ pp3300-supply: true
+ reg: true
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - pp3300-supply
+ - backlight
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel: panel@0 {
+compatible = "starry,er88577";
+reg = <0>;
+enable-gpios = < 98 0>;
+pinctrl-names = "default";
+pinctrl-0 = <_pins_default>;
+pp3300-supply = <_pp6000_mipi_disp>;
+backlight = <_lcd0>;
+rotation = <90>;
+port {
+panel_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
+
+...
--
2.17.1
[PATCH v2 0/2] Add starry bindings and driver
Add bindings and driver for starry. --- Modifications between V1 and V2: Kconfig and Makefile configurations added for starry driver --- Zhaoxiong Lv (2): dt-bindings: display: panel: Add Starry-er88577 support drm/panel: starry: add new panel driver .../display/panel/starry,er88577.yaml | 59 +++ drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + drivers/gpu/drm/panel/panel-starry-er88577.c | 444 ++ 4 files changed, 513 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/starry,er88577.yaml create mode 100644 drivers/gpu/drm/panel/panel-starry-er88577.c -- 2.17.1
Re: [PATCH v1 1/2] dt-bindings: input: i2c-hid: Introduce Ilitek ili2900
On 09/05/2024 08:43, Zhaoxiong Lv wrote: > From: lvzhaoxiong > > The ili2900 touch screen chip same as ilitek ili9882t controller > has a reset gpio. > > Signed-off-by: lvzhaoxiong You just sent the same, ignoring entire feedback. That's a shortcut to get ignored on your contributions... :( Best regards, Krzysztof
Re: [PATCH v1 1/2] dt-bindings: input: i2c-hid: Introduce Ilitek ili2900
On Thu, 09 May 2024 14:43:35 +0800, Zhaoxiong Lv wrote: > From: lvzhaoxiong > > The ili2900 touch screen chip same as ilitek ili9882t controller > has a reset gpio. > > Signed-off-by: lvzhaoxiong > --- > Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml | 1 + > 1 file changed, 1 insertion(+) > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: ./Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml:22:5: [error] duplication of key "const" in mapping (key-duplicates) dtschema/dtc warnings/errors: make[2]: *** Deleting file 'Documentation/devicetree/bindings/input/ilitek,ili9882t.example.dts' Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml:22:5: found duplicate key "const" with value "ilitek,ili2900" (original value: "ilitek,ili9882t") make[2]: *** [Documentation/devicetree/bindings/Makefile:26: Documentation/devicetree/bindings/input/ilitek,ili9882t.example.dts] Error 1 make[2]: *** Waiting for unfinished jobs ./Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml:22:5: found duplicate key "const" with value "ilitek,ili2900" (original value: "ilitek,ili9882t") /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml: ignoring, error parsing file make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1430: dt_binding_check] Error 2 make: *** [Makefile:240: __sub-make] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240509064336.9803-1-lvzhaoxi...@huaqin.corp-partner.google.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
