Re: [PATCH 3/8] dt-bindings: msm: qcom,mdss: Include ommited fam-b compatible
On 21/01/2024 20:41, Adam Skladowski wrote: > During conversion 28nm-hpm-fam-b compat got lost, add it. > > Signed-off-by: Adam Skladowski > --- Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH 3/8] dt-bindings: msm: qcom, mdss: Include ommited fam-b compatible
On Mon, 22 Jan 2024 at 10:48, Krzysztof Kozlowski
wrote:
>
> On 21/01/2024 20:41, Adam Skladowski wrote:
> > During conversion 28nm-hpm-fam-b compat got lost, add it.
>
> Please add Fixes tag and put this commit as first in your patchset or
> even as separate one.
Fixes: f7d46c5efee2 ("dt-bindings: display/msm: split qcom, mdss bindings")
Krzysztof, if that was the only issue, could you please ack this
patch, I can then merge it
--
With best wishes
Dmitry
[PATCH V3] drm/loongson: Error out if no VRAM detected
If there is no VRAM (it can be true if there is a discreted card, this is probably a hardware configuration issue in BIOS but it is observed in GDC-1401 laptop, L71 laptop and some Loongson-3C5000L based servers), we get such an error and Xorg fails to start: [ 136.401131] loongson :00:06.1: [drm] *ERROR* Requesting(0MiB) failed [ 137.444342] loongson :00:06.1: [drm] *ERROR* Requesting(0MiB) failed [ 138.871166] loongson :00:06.1: [drm] *ERROR* Requesting(0MiB) failed [ 140.444078] loongson :00:06.1: [drm] *ERROR* Requesting(0MiB) failed [ 142.403993] loongson :00:06.1: [drm] *ERROR* Requesting(0MiB) failed [ 143.970625] loongson :00:06.1: [drm] *ERROR* Requesting(0MiB) failed [ 145.862013] loongson :00:06.1: [drm] *ERROR* Requesting(0MiB) failed So in lsdc_get_dedicated_vram() we error out if no VRAM (or VRAM is less than 1MB which is also an unusable case) detected. Tested-by: Xiaotian Wu Signed-off-by: Huacai Chen --- V2: Update commit message. V3: Return -ENOSPC rather than -ENODEV. drivers/gpu/drm/loongson/lsdc_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/loongson/lsdc_drv.c b/drivers/gpu/drm/loongson/lsdc_drv.c index 89ccc0c43169..d8ff60b46abe 100644 --- a/drivers/gpu/drm/loongson/lsdc_drv.c +++ b/drivers/gpu/drm/loongson/lsdc_drv.c @@ -184,7 +184,7 @@ static int lsdc_get_dedicated_vram(struct lsdc_device *ldev, drm_info(ddev, "Dedicated vram start: 0x%llx, size: %uMiB\n", (u64)base, (u32)(size >> 20)); - return 0; + return (size > SZ_1M) ? 0 : -ENOSPC; } static struct lsdc_device * -- 2.43.0
[PATCH v3 2/2] drm/bridge: cdns-dsi: Add support for StarFive JH7110 SoC
From: Keith Zhao
Add display bridge support for dsi on StarFive JH7110 SoC.
The mainly modification is followed:
1.Add extra clock and reset operation for JH7110.
2.Add callback for JH7110.
Signed-off-by: Keith Zhao
Signed-off-by: Shengyang Chen
---
drivers/gpu/drm/bridge/cadence/Kconfig| 7 +
drivers/gpu/drm/bridge/cadence/Makefile | 1 +
.../gpu/drm/bridge/cadence/cdns-dsi-core.c| 29 ++-
.../gpu/drm/bridge/cadence/cdns-dsi-core.h| 21 ++
.../gpu/drm/bridge/cadence/cdns-dsi-jh7110.c | 193 ++
.../gpu/drm/bridge/cadence/cdns-dsi-jh7110.h | 16 ++
6 files changed, 266 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-jh7110.c
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-jh7110.h
diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
b/drivers/gpu/drm/bridge/cadence/Kconfig
index cced81633ddc..ad9f572f4720 100644
--- a/drivers/gpu/drm/bridge/cadence/Kconfig
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -19,6 +19,13 @@ config DRM_CDNS_DSI_J721E
help
Support J721E Cadence DSI wrapper. The wrapper manages
the routing of the DSS DPI signal to the Cadence DSI.
+
+config DRM_CDNS_DSI_JH7110
+ bool "JH7110 SOC Cadence DSI support"
+ default n
+ help
+ Cadence DPI to DSI bridge which is embedded in the
+ StarFive JH7110 SoC.
endif
config DRM_CDNS_MHDP8546
diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
b/drivers/gpu/drm/bridge/cadence/Makefile
index c95fd5b81d13..87f603a9f4ad 100644
--- a/drivers/gpu/drm/bridge/cadence/Makefile
+++ b/drivers/gpu/drm/bridge/cadence/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
cdns-dsi-y := cdns-dsi-core.o
cdns-dsi-$(CONFIG_DRM_CDNS_DSI_J721E) += cdns-dsi-j721e.o
+cdns-dsi-$(CONFIG_DRM_CDNS_DSI_JH7110) += cdns-dsi-jh7110.o
obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
cdns-mhdp8546-y := cdns-mhdp8546-core.o cdns-mhdp8546-hdcp.o
cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) += cdns-mhdp8546-j721e.o
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
index 7457d38622b0..c0c81745e765 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
@@ -27,6 +27,10 @@
#include "cdns-dsi-j721e.h"
#endif
+#ifdef CONFIG_DRM_CDNS_DSI_JH7110
+#include "cdns-dsi-jh7110.h"
+#endif
+
#define IP_CONF0x0
#define SP_HS_FIFO_DEPTH(x)(((x) & GENMASK(30, 26)) >> 26)
#define SP_LP_FIFO_DEPTH(x)(((x) & GENMASK(25, 21)) >> 21)
@@ -552,6 +556,10 @@ static int cdns_dsi_adjust_phy_config(struct cdns_dsi *dsi,
/* data rate was in bytes/sec, convert to bits/sec. */
phy_cfg->hs_clk_rate = dlane_bps * 8;
+ if (dsi->platform_ops && dsi->platform_ops->mode_fixup)
+ adj_dsi_htotal = dsi->platform_ops->mode_fixup(dsi, dsi_cfg,
phy_cfg,
+ dpi_hz, dpi_htotal,
dsi_htotal);
+
dsi_hfp_ext = adj_dsi_htotal - dsi_htotal;
dsi_cfg->hfp += dsi_hfp_ext;
dsi_cfg->htotal = dsi_htotal + dsi_hfp_ext;
@@ -683,7 +691,7 @@ static void cdns_dsi_bridge_post_disable(struct drm_bridge
*bridge)
pm_runtime_put(dsi->base.dev);
}
-static void cdns_dsi_hs_init(struct cdns_dsi *dsi)
+void cdns_dsi_hs_init(struct cdns_dsi *dsi)
{
struct cdns_dsi_output *output = &dsi->output;
u32 status;
@@ -1026,6 +1034,14 @@ static ssize_t cdns_dsi_transfer(struct mipi_dsi_host
*host,
cdns_dsi_init_link(dsi);
+ /*
+* on JH7110 SoC , when transfer dsi command ,
+* cdns_dsi_hs_init is needed.
+* or the final ret will be error value.
+*/
+ if (dsi->platform_ops && dsi->platform_ops->transfer)
+ dsi->platform_ops->transfer(dsi);
+
ret = mipi_dsi_create_packet(&packet, msg);
if (ret)
goto out;
@@ -1142,6 +1158,9 @@ static int __maybe_unused cdns_dsi_resume(struct device
*dev)
clk_prepare_enable(dsi->dsi_p_clk);
clk_prepare_enable(dsi->dsi_sys_clk);
+ if (dsi->platform_ops && dsi->platform_ops->resume)
+ dsi->platform_ops->resume(dsi);
+
return 0;
}
@@ -1152,6 +1171,10 @@ static int __maybe_unused cdns_dsi_suspend(struct device
*dev)
clk_disable_unprepare(dsi->dsi_sys_clk);
clk_disable_unprepare(dsi->dsi_p_clk);
reset_control_assert(dsi->dsi_p_rst);
+
+ if (dsi->platform_ops && dsi->platform_ops->suspend)
+ dsi->platform_ops->suspend(dsi);
+
dsi->link_initialized = false;
return 0;
}
@@ -1294,6 +1317,10 @@ static const struct of_device_id cdns_dsi_of_match[] = {
#ifdef CONFIG_DRM_CDNS_DSI_J721E
{ .compatible = "ti,j721e-dsi", .data = &dsi_ti_j721e_ops, },
#endif
+#ifdef CONFIG_DRM_CDNS_DSI_JH7110
+ { .compa
[PATCH v3 0/2] Add StarFive JH7110 SoC DSI support
This series is the series that attempts to support the CDNS DSI driver used to converts DPI to DSI. CDNS DSI is embedded in StarFive JH7110 SoC. The series has been tested on the VisionFive 2 board. change since v2: - Rebased on tag v6.8-rc3. patch 1: - Modify commit message and patch subject - Change 'starfve,jh7110-dsi' to 'starfive,jh7110-dsi' - Add constraints for reset-names and clock names - Add resets, reset-names attribute - Correct reset and clock names patch 2: - Modify commit message and patch subject - Drop useless MAINTAINERS modification - Change callback name from 'update' to 'mode_fixup' - Optimize the mode_fixup function. - Change devm_reset_control_get() to devm_reset_control_get_exclusive() - Correct reset and clock names v2: https://patchwork.kernel.org/project/dri-devel/cover/20240109072516.24328-1-shengyang.c...@starfivetech.com/ changes since v1: - Rebased on tag v6.7. patch 1: - Changed the 'starfive,cdns-dsi' to 'starfve,jh7110-dsi'. - Changed the compatible enum alphabetical order. - Restrict other variants. - Drop 'dsi_' prefix. patch 2: - Optimize the calculation process. - Drop useless definition. v1: https://patchwork.kernel.org/project/dri-devel/cover/20231127113436.57361-1-shengyang.c...@starfivetech.com/ Keith Zhao (2): dt-bindings: display: bridge: cdns: Add display bridge support for dsi on StarFive JH7110 SoC drm/bridge: cdns-dsi: Add support for StarFive JH7110 SoC .../bindings/display/bridge/cdns,dsi.yaml | 56 - drivers/gpu/drm/bridge/cadence/Kconfig| 7 + drivers/gpu/drm/bridge/cadence/Makefile | 1 + .../gpu/drm/bridge/cadence/cdns-dsi-core.c| 29 ++- .../gpu/drm/bridge/cadence/cdns-dsi-core.h| 21 ++ .../gpu/drm/bridge/cadence/cdns-dsi-jh7110.c | 193 ++ .../gpu/drm/bridge/cadence/cdns-dsi-jh7110.h | 16 ++ 7 files changed, 320 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-jh7110.c create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-jh7110.h -- 2.17.1
[PATCH v3 1/2] dt-bindings: display: bridge: cdns: Add display bridge support for dsi on StarFive JH7110 SoC
From: Keith Zhao Add compatible to support dsi bridge on StarFive JH7110 SoC Signed-off-by: Keith Zhao Signed-off-by: Shengyang Chen --- .../bindings/display/bridge/cdns,dsi.yaml | 56 ++- 1 file changed, 54 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml index 23060324d16e..4ad0ecaacaae 100644 --- a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml +++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml @@ -16,6 +16,7 @@ properties: compatible: enum: - cdns,dsi + - starfive,jh7110-dsi - ti,j721e-dsi reg: @@ -27,14 +28,20 @@ properties: Register block for wrapper settings registers in case of TI J7 SoCs. clocks: +minItems: 2 items: - description: PSM clock, used by the IP - description: sys clock, used by the IP + - description: dpi clock, used by the IP + - description: txesc clock, used by the IP clock-names: +minItems: 2 items: - const: dsi_p_clk - const: dsi_sys_clk + - const: dpi + - const: txesc phys: maxItems: 1 @@ -46,10 +53,22 @@ properties: maxItems: 1 resets: -maxItems: 1 +minItems: 1 +items: + - description: apb reset, associated to dsi_p_clk + - description: sys reset, associated to sys clock + - description: dpi reset, associated to dpi clock + - description: txesc reset, associated to txesc clock + - description: txbytehs reset, associated to txbytehs clock reset-names: -const: dsi_p_rst +minItems: 1 +items: + - const: dsi_p_rst + - const: sys + - const: dpi + - const: txesc + - const: txbytehs ports: $ref: /schemas/graph.yaml#/properties/ports @@ -90,6 +109,39 @@ allOf: reg: maxItems: 1 + - if: + properties: +compatible: + contains: +const: starfive,jh7110-dsi +then: + properties: +clocks: + minItems: 4 + maxItems: 4 +clock-names: + minItems: 4 + maxItems: 4 +resets: + minItems: 5 + maxItems: 5 +reset-names: + minItems: 5 + maxItems: 5 + required: +- resets +- reset-names +else: + properties: +clocks: + maxItems: 2 +clock-names: + maxItems: 2 +resets: + maxItems: 1 +reset-names: + maxItems: 1 + required: - compatible - reg -- 2.17.1
Re: linux-next: Tree for Feb 6 (gpu/drm/amd/display/ kernel-doc warnings)
On 2/5/24 20:43, Stephen Rothwell wrote: > Hi all, > > Changes since 20240205: > Hi Rodrigo, Are you aware of these kernel-doc warnings? I think they are due to commit b8c1c3a82e75 Author: Rodrigo Siqueira Date: Mon Jan 22 14:24:57 2024 -0700 Documentation/gpu: Add kernel doc entry for MPC ../drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h:1: warning: no structured comments found ../drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h:1: warning: no structured comments found ../drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h:1: warning: no structured comments found ../drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h:1: warning: no structured comments found ../drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h:1: warning: no structured comments found ../drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h:1: warning: no structured comments found ../drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:1: warning: no structured comments found ../drivers/gpu/drm/amd/display/dc/inc/hw/opp.h:1: warning: no structured comments found ../drivers/gpu/drm/amd/display/dc/inc/hw/opp.h:1: warning: no structured comments found ../drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_dio.h:1: warning: no structured comments found ../drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_dio.h:1: warning: no structured comments found ../drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:132: warning: Incorrect use of kernel-doc format: * @@overlap_only: Whether overlapping of different planes is allowed. ../drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:132: warning: Incorrect use of kernel-doc format: * @@overlap_only: Whether overlapping of different planes is allowed. ../drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:132: warning: Incorrect use of kernel-doc format: * @@overlap_only: Whether overlapping of different planes is allowed. ../drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:162: warning: Function parameter or struct member 'pre_multiplied_alpha' not described in 'mpcc_blnd_cfg' ../drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:162: warning: Function parameter or struct member 'overlap_only' not described in 'mpcc_blnd_cfg' ../drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter or struct member 'read_mpcc_state' not described in 'mpc_funcs' ../drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter or struct member 'mpc_init_single_inst' not described in 'mpc_funcs' ../drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter or struct member 'get_mpcc_for_dpp_from_secondary' not described in 'mpc_funcs' ../drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter or struct member 'get_mpcc_for_dpp' not described in 'mpc_funcs' ../drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter or struct member 'wait_for_idle' not described in 'mpc_funcs' ../drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter or struct member 'assert_mpcc_idle_before_connect' not described in 'mpc_funcs' ../drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter or struct member 'init_mpcc_list_from_hw' not described in 'mpc_funcs' ../drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter or struct member 'set_denorm' not described in 'mpc_funcs' ../drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter or struct member 'set_denorm_clamp' not described in 'mpc_funcs' ../drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter or struct member 'set_output_csc' not described in 'mpc_funcs' ../drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter or struct member 'set_ocsc_default' not described in 'mpc_funcs' ../drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter or struct member 'set_output_gamma' not described in 'mpc_funcs' ../drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter or struct member 'power_on_mpc_mem_pwr' not described in 'mpc_funcs' ../drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter or struct member 'set_dwb_mux' not described in 'mpc_funcs' ../drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter or struct member 'disable_dwb_mux' not described in 'mpc_funcs' ../drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter or struct member 'is_dwb_idle' not described in 'mpc_funcs' ../drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter or struct member 'set_out_
linux-next: build failure after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (i386 defconfig)
failed like this:
In function 'i915_ttm_placement_from_obj',
inlined from 'i915_ttm_get_pages' at
drivers/gpu/drm/i915/gem/i915_gem_ttm.c:847:2:
drivers/gpu/drm/i915/gem/i915_gem_ttm.c:165:18: error: 'places[0].flags' is
used uninitialized [-Werror=uninitialized]
165 | places[0].flags |= TTM_PL_FLAG_DESIRED;
| ~^~
drivers/gpu/drm/i915/gem/i915_gem_ttm.c: In function 'i915_ttm_get_pages':
drivers/gpu/drm/i915/gem/i915_gem_ttm.c:837:26: note: 'places' declared here
837 | struct ttm_place places[I915_TTM_MAX_PLACEMENTS + 1];
| ^~
Caused by commit
a78a8da51b36 ("drm/ttm: replace busy placement with flags v6")
I applied the following hack for today:
From: Stephen Rothwell
Date: Tue, 6 Feb 2024 15:17:54 +1100
Subject: [PATCH] drm/ttm: initialise places
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 80c6cafc8887..34e699e67c25 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -834,7 +834,7 @@ static int __i915_ttm_get_pages(struct drm_i915_gem_object
*obj,
static int i915_ttm_get_pages(struct drm_i915_gem_object *obj)
{
- struct ttm_place places[I915_TTM_MAX_PLACEMENTS + 1];
+ struct ttm_place places[I915_TTM_MAX_PLACEMENTS + 1] = {};
struct ttm_placement placement;
/* restricted by sg_alloc_table */
--
2.43.0
--
Cheers,
Stephen Rothwell
pgp3TAQUfY8Bn.pgp
Description: OpenPGP digital signature
Re: drm/loongson: Error out if no VRAM detected
On Sat, Feb 3, 2024 at 1:24 AM Sui Jingfeng wrote: > > > On 2024/1/19 18:40, Huacai Chen wrote: > > If there is no VRAM (it is true if there is a discreted card), we get > > such an error and Xorg fails to start: > > > > [ 136.401131] loongson :00:06.1: [drm] *ERROR* Requesting(0MiB) failed > > [ 137.444342] loongson :00:06.1: [drm] *ERROR* Requesting(0MiB) failed > > [ 138.871166] loongson :00:06.1: [drm] *ERROR* Requesting(0MiB) failed > > [ 140.444078] loongson :00:06.1: [drm] *ERROR* Requesting(0MiB) failed > > [ 142.403993] loongson :00:06.1: [drm] *ERROR* Requesting(0MiB) failed > > [ 143.970625] loongson :00:06.1: [drm] *ERROR* Requesting(0MiB) failed > > [ 145.862013] loongson :00:06.1: [drm] *ERROR* Requesting(0MiB) failed > > > > So in lsdc_get_dedicated_vram() we error out if no VRAM (or VRAM is less > > than 1MB which is also an unusable case) detected. > > > > Signed-off-by: Huacai Chen > > --- > > drivers/gpu/drm/loongson/lsdc_drv.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/loongson/lsdc_drv.c > > b/drivers/gpu/drm/loongson/lsdc_drv.c > > index 89ccc0c43169..d8ff60b46abe 100644 > > --- a/drivers/gpu/drm/loongson/lsdc_drv.c > > +++ b/drivers/gpu/drm/loongson/lsdc_drv.c > > @@ -184,7 +184,7 @@ static int lsdc_get_dedicated_vram(struct lsdc_device > > *ldev, > > drm_info(ddev, "Dedicated vram start: 0x%llx, size: %uMiB\n", > >(u64)base, (u32)(size >> 20)); > > > > - return 0; > > + return (size > SZ_1M) ? 0 : -ENODEV; > > > I forget to tell you that you probably should return ENOSPC at here, > which stand for no space left on device, not the ENODEV. Make sense, will do. Huacai >
Re: [PATCH V8 02/12] phy: freescale: add Samsung HDMI PHY
On Mon, Feb 5, 2024 at 2:17 AM Marco Felsch wrote:
>
> On 24-02-04, Dmitry Baryshkov wrote:
> > On Sat, 3 Feb 2024 at 17:53, Adam Ford wrote:
> > >
> > > From: Lucas Stach
> > >
> > > This adds the driver for the Samsung HDMI PHY found on the
> > > i.MX8MP SoC.
> > >
> > > Signed-off-by: Lucas Stach
> > > Signed-off-by: Adam Ford
> > > Tested-by: Alexander Stein
> > > ---
> > > V4: Make lookup table hex values lower case.
> > >
> > > V3: Re-order the Makefile to keep it alphabetical
> > > Remove unused defines
> > >
> > > V2: Fixed some whitespace found from checkpatch
> > > Change error handling when enabling apbclk to use dev_err_probe
> > > Rebase on Linux-Next
> > >
> > > I (Adam) tried to help move this along, so I took Lucas' patch and
> > > attempted to apply fixes based on feedback. I don't have
> > > all the history, so apologies for that.
> > > ---
> > > drivers/phy/freescale/Kconfig|6 +
> > > drivers/phy/freescale/Makefile |1 +
> > > drivers/phy/freescale/phy-fsl-samsung-hdmi.c | 1075 ++
> > > 3 files changed, 1082 insertions(+)
> > > create mode 100644 drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > >
> > > diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
> > > index 853958fb2c06..5c2b73042dfc 100644
> > > --- a/drivers/phy/freescale/Kconfig
> > > +++ b/drivers/phy/freescale/Kconfig
> > > @@ -35,6 +35,12 @@ config PHY_FSL_IMX8M_PCIE
> > > Enable this to add support for the PCIE PHY as found on
> > > i.MX8M family of SOCs.
> > >
> > > +config PHY_FSL_SAMSUNG_HDMI_PHY
> > > + tristate "Samsung HDMI PHY support"
> > > + depends on OF && HAS_IOMEM
> > > + help
> > > + Enable this to add support for the Samsung HDMI PHY in i.MX8MP.
> > > +
> > > endif
> > >
> > > config PHY_FSL_LYNX_28G
> > > diff --git a/drivers/phy/freescale/Makefile
> > > b/drivers/phy/freescale/Makefile
> > > index cedb328bc4d2..79e5f16d3ce8 100644
> > > --- a/drivers/phy/freescale/Makefile
> > > +++ b/drivers/phy/freescale/Makefile
> > > @@ -4,3 +4,4 @@ obj-$(CONFIG_PHY_MIXEL_LVDS_PHY)+=
> > > phy-fsl-imx8qm-lvds-phy.o
> > > obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY) += phy-fsl-imx8-mipi-dphy.o
> > > obj-$(CONFIG_PHY_FSL_IMX8M_PCIE) += phy-fsl-imx8m-pcie.o
> > > obj-$(CONFIG_PHY_FSL_LYNX_28G) += phy-fsl-lynx-28g.o
> > > +obj-$(CONFIG_PHY_FSL_SAMSUNG_HDMI_PHY) += phy-fsl-samsung-hdmi.o
> > > diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > > b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > > new file mode 100644
> > > index ..bf0e2299d00f
> > > --- /dev/null
> > > +++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > > @@ -0,0 +1,1075 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * Copyright 2020 NXP
> > > + * Copyright 2022 Pengutronix, Lucas Stach
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#define PHY_REG_33 0x84
> > > +#define REG33_MODE_SET_DONE BIT(7)
> > > +#define REG33_FIX_DA BIT(1)
> > > +
> > > +#define PHY_REG_34 0x88
> > > +#define REG34_PHY_READY BIT(7)
> > > +#define REG34_PLL_LOCKBIT(6)
> > > +#define REG34_PHY_CLK_READY BIT(5)
> > > +
> > > +
> > > +#define PHY_PLL_REGS_NUM 48
> > > +
> > > +struct phy_config {
> > > + u32 clk_rate;
> > > + u8 regs[PHY_PLL_REGS_NUM];
> > > +};
> > > +
> > > +const struct phy_config phy_pll_cfg[] = {
> > > + { 2225, {
> > > + 0x00, 0xd1, 0x4b, 0xf1, 0x89, 0x88, 0x80, 0x40,
> > > + 0x4f, 0x30, 0x33, 0x65, 0x00, 0x15, 0x25, 0x80,
> > > + 0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
> > > + 0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> > > + 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > + 0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
> > > + },
> > > + }, {
> > > + 2375, {
> > > + 0x00, 0xd1, 0x50, 0xf1, 0x86, 0x85, 0x80, 0x40,
> > > + 0x4f, 0x30, 0x33, 0x65, 0x00, 0x03, 0x25, 0x80,
> > > + 0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
> > > + 0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> > > + 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > + 0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
> > > + },
> >
> > Generally I see that these entries contain a high level of duplication.
> > Could you please extract the common part and a rate-dependent part.
> > Next, it would be best if instead of writing the register values via
> > the rate LUT, the driver
[PATCH 4/4] video: fbdev: replace of_graph_get_next_endpoint()
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+ of_graph_get_endpoint_by_regs(xxx, 0, -1);
Link: https://lore.kernel.org/r/20240202174941.ga310089-r...@kernel.org
Signed-off-by: Kuninori Morimoto
---
drivers/video/fbdev/amba-clcd.c | 2 +-
drivers/video/fbdev/omap2/omapfb/dss/dsi.c| 3 ++-
drivers/video/fbdev/omap2/omapfb/dss/dss-of.c | 20 +--
drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c | 3 ++-
drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c | 3 ++-
drivers/video/fbdev/omap2/omapfb/dss/venc.c | 3 ++-
drivers/video/fbdev/pxafb.c | 2 +-
include/video/omapfb_dss.h| 3 ---
8 files changed, 11 insertions(+), 28 deletions(-)
diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 0399db369e70..2371b204cfd2 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -691,7 +691,7 @@ static int clcdfb_of_init_display(struct clcd_fb *fb)
/*
* Fetch the panel endpoint.
*/
- endpoint = of_graph_get_next_endpoint(fb->dev->dev.of_node, NULL);
+ endpoint = of_graph_get_endpoint_by_regs(fb->dev->dev.of_node, 0, -1);
if (!endpoint)
return -ENODEV;
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
index b7eb17a16ec4..1f13bcf73da5 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -5079,7 +5080,7 @@ static int dsi_probe_of(struct platform_device *pdev)
struct device_node *ep;
struct omap_dsi_pin_config pin_cfg;
- ep = omapdss_of_get_first_endpoint(node);
+ ep = of_graph_get_endpoint_by_regs(node, 0, -1);
if (!ep)
return 0;
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
b/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
index 0282d4eef139..14965a3fd05b 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
@@ -130,24 +130,6 @@ static struct device_node
*omapdss_of_get_remote_port(const struct device_node *
return np;
}
-struct device_node *
-omapdss_of_get_first_endpoint(const struct device_node *parent)
-{
- struct device_node *port, *ep;
-
- port = omapdss_of_get_next_port(parent, NULL);
-
- if (!port)
- return NULL;
-
- ep = omapdss_of_get_next_endpoint(port, NULL);
-
- of_node_put(port);
-
- return ep;
-}
-EXPORT_SYMBOL_GPL(omapdss_of_get_first_endpoint);
-
struct omap_dss_device *
omapdss_of_find_source_for_first_ep(struct device_node *node)
{
@@ -155,7 +137,7 @@ omapdss_of_find_source_for_first_ep(struct device_node
*node)
struct device_node *src_port;
struct omap_dss_device *src;
- ep = omapdss_of_get_first_endpoint(node);
+ ep = of_graph_get_endpoint_by_regs(node, 0, -1);
if (!ep)
return ERR_PTR(-EINVAL);
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
index f05b4e35a842..8f407ec134dc 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -529,7 +530,7 @@ static int hdmi_probe_of(struct platform_device *pdev)
struct device_node *ep;
int r;
- ep = omapdss_of_get_first_endpoint(node);
+ ep = of_graph_get_endpoint_by_regs(node, 0, -1);
if (!ep)
return 0;
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c
b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c
index 03292945b1d4..4ad219f522b9 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -561,7 +562,7 @@ static int hdmi_probe_of(struct platform_device *pdev)
struct device_node *ep;
int r;
- ep = omapdss_of_get_first_endpoint(node);
+ ep = of_graph_get_endpoint_by_regs(node, 0, -1);
if (!ep)
return 0;
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/venc.c
b/drivers/video/fbdev/omap2/omapfb/dss/venc.c
index c9d40e28a06f..0bd80d3b8f1b 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/venc.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/venc.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -764,7 +765,7 @@ static int venc_probe_of(struct platform_device *pdev)
u32 channels;
int r;
-
[PATCH 3/4] media: platform: replace of_graph_get_next_endpoint()
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+ of_graph_get_endpoint_by_regs(xxx, 0, -1);
Link: https://lore.kernel.org/r/20240202174941.ga310089-r...@kernel.org
Signed-off-by: Kuninori Morimoto
---
drivers/media/platform/atmel/atmel-isi.c | 4 ++--
drivers/media/platform/intel/pxa_camera.c | 2 +-
drivers/media/platform/samsung/exynos4-is/fimc-is.c | 2 +-
drivers/media/platform/samsung/exynos4-is/mipi-csis.c | 2 +-
drivers/media/platform/st/stm32/stm32-dcmi.c | 4 ++--
drivers/media/platform/ti/davinci/vpif.c | 3 +--
6 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/atmel/atmel-isi.c
b/drivers/media/platform/atmel/atmel-isi.c
index 4046212d48b4..f615aee85968 100644
--- a/drivers/media/platform/atmel/atmel-isi.c
+++ b/drivers/media/platform/atmel/atmel-isi.c
@@ -831,7 +831,7 @@ static int atmel_isi_parse_dt(struct atmel_isi *isi,
isi->pdata.full_mode = 1;
isi->pdata.frate = ISI_CFG1_FRATE_CAPTURE_ALL;
- np = of_graph_get_next_endpoint(np, NULL);
+ np = of_graph_get_endpoint_by_regs(np, 0, -1);
if (!np) {
dev_err(&pdev->dev, "Could not find the endpoint\n");
return -EINVAL;
@@ -1155,7 +1155,7 @@ static int isi_graph_init(struct atmel_isi *isi)
struct device_node *ep;
int ret;
- ep = of_graph_get_next_endpoint(isi->dev->of_node, NULL);
+ ep = of_graph_get_endpoint_by_regs(isi->dev->of_node, 0, -1);
if (!ep)
return -EINVAL;
diff --git a/drivers/media/platform/intel/pxa_camera.c
b/drivers/media/platform/intel/pxa_camera.c
index 59b89e421dc2..d904952bf00e 100644
--- a/drivers/media/platform/intel/pxa_camera.c
+++ b/drivers/media/platform/intel/pxa_camera.c
@@ -2207,7 +2207,7 @@ static int pxa_camera_pdata_from_dt(struct device *dev,
pcdev->mclk = mclk_rate;
}
- np = of_graph_get_next_endpoint(np, NULL);
+ np = of_graph_get_endpoint_by_regs(np, 0, -1);
if (!np) {
dev_err(dev, "could not find endpoint\n");
return -EINVAL;
diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-is.c
b/drivers/media/platform/samsung/exynos4-is/fimc-is.c
index a08c87ef6e2d..39aab667910d 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-is.c
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-is.c
@@ -175,7 +175,7 @@ static int fimc_is_parse_sensor_config(struct fimc_is *is,
unsigned int index,
return -EINVAL;
}
- ep = of_graph_get_next_endpoint(node, NULL);
+ ep = of_graph_get_endpoint_by_regs(node, 0, -1);
if (!ep)
return -ENXIO;
diff --git a/drivers/media/platform/samsung/exynos4-is/mipi-csis.c
b/drivers/media/platform/samsung/exynos4-is/mipi-csis.c
index 686ca8753ba2..3f8bea2e3934 100644
--- a/drivers/media/platform/samsung/exynos4-is/mipi-csis.c
+++ b/drivers/media/platform/samsung/exynos4-is/mipi-csis.c
@@ -728,7 +728,7 @@ static int s5pcsis_parse_dt(struct platform_device *pdev,
&state->max_num_lanes))
return -EINVAL;
- node = of_graph_get_next_endpoint(node, NULL);
+ node = of_graph_get_endpoint_by_regs(node, 0, -1);
if (!node) {
dev_err(&pdev->dev, "No port node at %pOF\n",
pdev->dev.of_node);
diff --git a/drivers/media/platform/st/stm32/stm32-dcmi.c
b/drivers/media/platform/st/stm32/stm32-dcmi.c
index 8cb4fdcae137..4c00aae013af 100644
--- a/drivers/media/platform/st/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/st/stm32/stm32-dcmi.c
@@ -1856,7 +1856,7 @@ static int dcmi_graph_init(struct stm32_dcmi *dcmi)
struct device_node *ep;
int ret;
- ep = of_graph_get_next_endpoint(dcmi->dev->of_node, NULL);
+ ep = of_graph_get_endpoint_by_regs(dcmi->dev->of_node, 0, -1);
if (!ep) {
dev_err(dcmi->dev, "Failed to get next endpoint\n");
return -EINVAL;
@@ -1915,7 +1915,7 @@ static int dcmi_probe(struct platform_device *pdev)
"Could not get reset control\n");
/* Get bus characteristics from devicetree */
- np = of_graph_get_next_endpoint(np, NULL);
+ np = of_graph_get_endpoint_by_regs(np, 0, -1);
if (!np) {
dev_err(&pdev->dev, "Could not find the endpoint\n");
return -ENODEV;
diff --git a/drivers/media/platform/ti/davinci/vpif.c
b/drivers/media/platform/ti/davinci/vpif.c
index 63cdfed37bc9..f4e1fa76bf37 100644
--- a/drivers/media/platform/ti/davinci/vpif.c
+++ b/drivers/media/platform/ti/davinci/vpif.c
@@ -465,8 +465,7 @@ static int vpif_probe(struct platfor
[PATCH 2/4] media: i2c: replace of_graph_get_next_endpoint()
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+ of_graph_get_endpoint_by_regs(xxx, 0, -1);
Link: https://lore.kernel.org/r/20240202174941.ga310089-r...@kernel.org
Signed-off-by: Kuninori Morimoto
---
drivers/media/i2c/adv7343.c | 2 +-
drivers/media/i2c/adv7604.c | 2 +-
drivers/media/i2c/mt9p031.c | 2 +-
drivers/media/i2c/mt9v032.c | 2 +-
drivers/media/i2c/ov2659.c | 2 +-
drivers/media/i2c/ov5645.c | 2 +-
drivers/media/i2c/ov5647.c | 2 +-
drivers/media/i2c/s5c73m3/s5c73m3-core.c | 2 +-
drivers/media/i2c/s5k5baf.c | 2 +-
drivers/media/i2c/tc358743.c | 2 +-
drivers/media/i2c/tda1997x.c | 2 +-
drivers/media/i2c/tvp514x.c | 2 +-
drivers/media/i2c/tvp7002.c | 2 +-
13 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/media/i2c/adv7343.c b/drivers/media/i2c/adv7343.c
index ff21cd4744d3..4fbe4e18570e 100644
--- a/drivers/media/i2c/adv7343.c
+++ b/drivers/media/i2c/adv7343.c
@@ -403,7 +403,7 @@ adv7343_get_pdata(struct i2c_client *client)
if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
return client->dev.platform_data;
- np = of_graph_get_next_endpoint(client->dev.of_node, NULL);
+ np = of_graph_get_endpoint_by_regs(client->dev.of_node, 0, -1);
if (!np)
return NULL;
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index b202a85fbeaa..dcfdbb975473 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -3205,7 +3205,7 @@ static int adv76xx_parse_dt(struct adv76xx_state *state)
np = state->i2c_clients[ADV76XX_PAGE_IO]->dev.of_node;
/* Parse the endpoint. */
- endpoint = of_graph_get_next_endpoint(np, NULL);
+ endpoint = of_graph_get_endpoint_by_regs(np, 0, -1);
if (!endpoint)
return -EINVAL;
diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c
index 348f1e1098fb..c57a0d436421 100644
--- a/drivers/media/i2c/mt9p031.c
+++ b/drivers/media/i2c/mt9p031.c
@@ -1080,7 +1080,7 @@ mt9p031_get_pdata(struct i2c_client *client)
if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
return client->dev.platform_data;
- np = of_graph_get_next_endpoint(client->dev.of_node, NULL);
+ np = of_graph_get_endpoint_by_regs(client->dev.of_node, 0, -1);
if (!np)
return NULL;
diff --git a/drivers/media/i2c/mt9v032.c b/drivers/media/i2c/mt9v032.c
index 1c6f6cea1204..14d277680fa2 100644
--- a/drivers/media/i2c/mt9v032.c
+++ b/drivers/media/i2c/mt9v032.c
@@ -1008,7 +1008,7 @@ mt9v032_get_pdata(struct i2c_client *client)
if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
return client->dev.platform_data;
- np = of_graph_get_next_endpoint(client->dev.of_node, NULL);
+ np = of_graph_get_endpoint_by_regs(client->dev.of_node, 0, -1);
if (!np)
return NULL;
diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
index 2c3dbe164eb6..edea62a02320 100644
--- a/drivers/media/i2c/ov2659.c
+++ b/drivers/media/i2c/ov2659.c
@@ -1388,7 +1388,7 @@ ov2659_get_pdata(struct i2c_client *client)
if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
return client->dev.platform_data;
- endpoint = of_graph_get_next_endpoint(client->dev.of_node, NULL);
+ endpoint = of_graph_get_endpoint_by_regs(client->dev.of_node, 0, -1);
if (!endpoint)
return NULL;
diff --git a/drivers/media/i2c/ov5645.c b/drivers/media/i2c/ov5645.c
index a70db7e601a4..31d214bd4a83 100644
--- a/drivers/media/i2c/ov5645.c
+++ b/drivers/media/i2c/ov5645.c
@@ -1053,7 +1053,7 @@ static int ov5645_probe(struct i2c_client *client)
ov5645->i2c_client = client;
ov5645->dev = dev;
- endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
+ endpoint = of_graph_get_endpoint_by_regs(dev->of_node, 0, -1);
if (!endpoint) {
dev_err(dev, "endpoint node not found\n");
return -EINVAL;
diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c
index dcfe3129c63a..beab2813c672 100644
--- a/drivers/media/i2c/ov5647.c
+++ b/drivers/media/i2c/ov5647.c
@@ -1363,7 +1363,7 @@ static int ov5647_parse_dt(struct ov5647 *sensor, struct
device_node *np)
struct device_node *ep;
int ret;
- ep = of_graph_get_next_endpoint(np, NULL);
+ ep = of_graph_get_endpoint_by_regs(np, 0, -1);
if (!ep)
return -EINVAL;
diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-core.c
b/drivers/media/i2c/s5c73m3/s5c73m3-core.c
index ed
[PATCH 1/4] gpu: drm: replace of_graph_get_next_endpoint()
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+ of_graph_get_endpoint_by_regs(xxx, 0, -1);
Link: https://lore.kernel.org/r/20240202174941.ga310089-r...@kernel.org
Signed-off-by: Kuninori Morimoto
---
drivers/gpu/drm/drm_of.c | 2 +-
drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c | 2 +-
drivers/gpu/drm/tiny/arcpgu.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 177b600895d3..c2eae9296012 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -516,7 +516,7 @@ struct mipi_dsi_host *drm_of_get_dsi_bus(struct device *dev)
/*
* Get first endpoint child from device.
*/
- endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
+ endpoint = of_graph_get_endpoint_by_regs(dev->of_node, 0, -1);
if (!endpoint)
return ERR_PTR(-ENODEV);
diff --git a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
index 4618c892cdd6..e10e469aa7a6 100644
--- a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
+++ b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
@@ -400,7 +400,7 @@ static int rpi_touchscreen_probe(struct i2c_client *i2c)
rpi_touchscreen_i2c_write(ts, REG_POWERON, 0);
/* Look up the DSI host. It needs to probe before we do. */
- endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
+ endpoint = of_graph_get_endpoint_by_regs(dev->of_node, 0, -1);
if (!endpoint)
return -ENODEV;
diff --git a/drivers/gpu/drm/tiny/arcpgu.c b/drivers/gpu/drm/tiny/arcpgu.c
index e5b10e41554a..04d0053b9315 100644
--- a/drivers/gpu/drm/tiny/arcpgu.c
+++ b/drivers/gpu/drm/tiny/arcpgu.c
@@ -288,7 +288,7 @@ static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
* There is only one output port inside each device. It is linked with
* encoder endpoint.
*/
- endpoint_node = of_graph_get_next_endpoint(pdev->dev.of_node, NULL);
+ endpoint_node = of_graph_get_endpoint_by_regs(pdev->dev.of_node, 0, -1);
if (endpoint_node) {
encoder_node = of_graph_get_remote_port_parent(endpoint_node);
of_node_put(endpoint_node);
--
2.25.1
[PATCH 0/4] of: replace of_graph_get_next_endpoint()
Hi Rob We should get rid of or minimize of_graph_get_next_endpoint() in its current form. In general, drivers should be asking for a specific port number because their function is fixed in the binding. https://lore.kernel.org/r/20240131184347.ga1906672-r...@kernel.org This patch-set replace of_graph_get_next_endpoint() by of_graph_get_endpoint_by_regs(). There are still next_endpoint() after this patch-set, but it will be replaced by for_each_endpoint_of_node() in next patch-set (A) [*] this patch-set [o] done [o] tidyup of_graph_get_endpoint_count() [*] replace endpoint func - use endpoint_by_regs() (A) [ ] replace endpoint func - use for_each() [ ] rename endpoint func to device_endpoint [ ] add new port function [ ] add new endpont function [ ] remove of_graph_get_next_device_endpoint() Kuninori Morimoto (4): gpu: drm: replace of_graph_get_next_endpoint() media: i2c: replace of_graph_get_next_endpoint() media: platform: replace of_graph_get_next_endpoint() video: fbdev: replace of_graph_get_next_endpoint() drivers/gpu/drm/drm_of.c | 2 +- .../drm/panel/panel-raspberrypi-touchscreen.c | 2 +- drivers/gpu/drm/tiny/arcpgu.c | 2 +- drivers/media/i2c/adv7343.c | 2 +- drivers/media/i2c/adv7604.c | 2 +- drivers/media/i2c/mt9p031.c | 2 +- drivers/media/i2c/mt9v032.c | 2 +- drivers/media/i2c/ov2659.c| 2 +- drivers/media/i2c/ov5645.c| 2 +- drivers/media/i2c/ov5647.c| 2 +- drivers/media/i2c/s5c73m3/s5c73m3-core.c | 2 +- drivers/media/i2c/s5k5baf.c | 2 +- drivers/media/i2c/tc358743.c | 2 +- drivers/media/i2c/tda1997x.c | 2 +- drivers/media/i2c/tvp514x.c | 2 +- drivers/media/i2c/tvp7002.c | 2 +- drivers/media/platform/atmel/atmel-isi.c | 4 ++-- drivers/media/platform/intel/pxa_camera.c | 2 +- .../platform/samsung/exynos4-is/fimc-is.c | 2 +- .../platform/samsung/exynos4-is/mipi-csis.c | 2 +- drivers/media/platform/st/stm32/stm32-dcmi.c | 4 ++-- drivers/media/platform/ti/davinci/vpif.c | 3 +-- drivers/video/fbdev/amba-clcd.c | 2 +- drivers/video/fbdev/omap2/omapfb/dss/dsi.c| 3 ++- drivers/video/fbdev/omap2/omapfb/dss/dss-of.c | 20 +-- drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c | 3 ++- drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c | 3 ++- drivers/video/fbdev/omap2/omapfb/dss/venc.c | 3 ++- drivers/video/fbdev/pxafb.c | 2 +- include/video/omapfb_dss.h| 3 --- 30 files changed, 35 insertions(+), 53 deletions(-) -- 2.25.1
Re: Build regressions/improvements in v6.8-rc1
On 1/23/2024 3:45 AM, Geert Uytterhoeven wrote:
> in drivers/net/ethernet/intel/ice/ice_base.c
>
> powerpc-gcc5/ppc32_allmodconfig
> in drivers/net/ethernet/intel/ice/ice_nvm.c
>
> aarcharm64-gcc5/arm64-allmodconfig
> powerpc-gcc5/ppc32_allmodconfig
> powerpc-gcc5/powerpc-allmodconfig
> powerpc-gcc5/ppc64le_allmodconfig
>
> in drivers/net/ethernet/intel/ice/ice_common.c
>
> arm64-gcc5/arm64-allmodconfig
> powerpc-gcc5/ppc32_allmodconfig
>
> in drivers/net/ethernet/intel/i40e/i40e_dcb.c
>
> powerpc-gcc5/powerpc-allmodconfig
> powerpc-gcc5/ppc32_allmodconfig
> powerpc-gcc5/ppc64_book3e_allmodconfig
>
>
> arm64-gcc5/arm64-allmodconfig
> powerpc-gcc5/powerpc-all{mod,yes}config
> powerpc-gcc5/ppc{32,64le,64_book3e}_allmodconfig
>
Fixes for intel/i40e and intel/ice posted here:
https://lore.kernel.org/lkml/20240206022906.2194214-1-jesse.brandeb...@intel.com/
Re: [PATCH V8 05/12] arm64: dts: imx8mp: add HDMI power-domains
On Mon, Feb 5, 2024 at 1:26 AM Alexander Stein
wrote:
>
> Hi Adam,
>
> thanks for working on this.
>
> Am Samstag, 3. Februar 2024, 17:52:45 CET schrieb Adam Ford:
> > From: Lucas Stach
> >
> > This adds the PGC and HDMI blk-ctrl nodes providing power control for
> > HDMI subsystem peripherals.
> >
> > Signed-off-by: Adam Ford
> > Signed-off-by: Lucas Stach
> > ---
> > V2: Add missing power-domains hdcp and hrv
> > ---
> > arch/arm64/boot/dts/freescale/imx8mp.dtsi | 38 +++
> > 1 file changed, 38 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8mp.dtsi index
> > 76c73daf546b..5c54073de615 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > @@ -836,6 +836,23 @@ pgc_mediamix: power-domain@10 {
> ><&clk
> IMX8MP_CLK_MEDIA_APB_ROOT>;
> > };
> >
> > + pgc_hdmimix: power-
> domains@14 {
>
Alexander,
Thanks for the feedback.
> As per Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml the node
> should be called power-domain@.
>
> > + #power-domain-
> cells = <0>;
> > + reg =
> ;
> > + clocks = <&clk
> IMX8MP_CLK_HDMI_ROOT>,
> > + <&clk
> IMX8MP_CLK_HDMI_APB>;
> > + assigned-clocks =
> <&clk IMX8MP_CLK_HDMI_AXI>,
> > +
> <&clk IMX8MP_CLK_HDMI_APB>;
> > + assigned-clock-
> parents = <&clk IMX8MP_SYS_PLL2_500M>,
> > +
> <&clk IMX8MP_SYS_PLL1_133M>;
> > + assigned-clock-
> rates = <5>, <13300>;
> > + };
> > +
> > + pgc_hdmi_phy: power-
> domains@15 {
>
> As per Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml the node
> should be called power-domain@.
Whoops. I totally missed these when I applied them. I'll have them
fixed on the next spin.
>
> > + #power-domain-
> cells = <0>;
> > + reg =
> ;
> > + };
> > +
> > pgc_mipi_phy2: power-
> domain@16 {
> > #power-domain-
> cells = <0>;
> > reg =
> ;
> > @@ -1361,6 +1378,27 @@ eqos: ethernet@30bf {
> > intf_mode = <&gpr 0x4>;
> > status = "disabled";
> > };
> > +
> > + hdmi_blk_ctrl: blk-ctrl@32fc {
> > + compatible = "fsl,imx8mp-hdmi-blk-
> ctrl", "syscon";
> > + reg = <0x32fc 0x23c>;
> > + clocks = <&clk IMX8MP_CLK_HDMI_APB>,
> > + <&clk
> IMX8MP_CLK_HDMI_ROOT>,
> > + <&clk
> IMX8MP_CLK_HDMI_REF_266M>,
> > + <&clk IMX8MP_CLK_HDMI_24M>,
> > + <&clk
> IMX8MP_CLK_HDMI_FDCC_TST>;
> > + clock-names = "apb", "axi",
> "ref_266m", "ref_24m", "fdcc";
> > + power-domains = <&pgc_hdmimix>,
> <&pgc_hdmimix>,
> > + <&pgc_hdmimix>,
> <&pgc_hdmimix>,
> > + <&pgc_hdmimix>,
> <&pgc_hdmimix>,
> > + <&pgc_hdmimix>,
> <&pgc_hdmi_phy>,
> > + <&pgc_hdmimix>,
> <&pgc_hdmimix>;
> > + power-domain-names = "bus",
> "irqsteer", "lcdif",
> > + "pai", "pvi",
> "trng",
> > + "hdmi-tx",
> "hdmi-tx-phy",
> > + "hdcp",
> "hrv";
> > + #power-domain-cells = <1>;
> > + };
> > };
> >
>
> According to RM this block is part of AIPS4, so it should be below
> hsio_blk_ctrl.
This is how it was when I got it, but I should have caught it. Thanks
for that. It looks like the subsequent HDMI, IRQ_steerting, LCDIF and
PHY ones are also out of place.
adam
>
> Best regards,
> Alexander
>
> > aips5: bus@30c0 {
>
>
> --
> TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> Amtsgericht München, HRB 105018
> Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
> http://www.tq-group.com/
>
>
Re: (subset) [PATCH 00/42] Fix coccicheck warnings
On Tue, 16 Jan 2024 12:10:47 +0800, Li Zhijian wrote:
> make coccicheck COCCI=$PWD/scripts/coccinelle/api/device_attr_show.cocci`
> complians some warnnings as following[1]:
>
> Not sure if someone had tried these fixes, feel free to ignore this
> patch set if we have come to a *NOT-FIX* conclusion before :)
>
> This patch set also fix a few snprintf() beside coccicheck reported.
> For example, some thing like
> xxx_show() {
> rc = snprintf();
> ...
> return rc;
> }
>
> [...]
Applied to 6.9/scsi-queue, thanks!
[22/42] drivers/scsi/fnic: Convert snprintf to sysfs_emit
https://git.kernel.org/mkp/scsi/c/1ad717c92925
[25/42] drivers/scsi/ibmvscsi: Convert snprintf to sysfs_emit
https://git.kernel.org/mkp/scsi/c/29ff822f466e
[26/42] drivers/scsi/ibmvscsi_tgt: Convert snprintf to sysfs_emit
https://git.kernel.org/mkp/scsi/c/01105c23de42
[27/42] drivers/scsi/isci: Convert snprintf to sysfs_emit
https://git.kernel.org/mkp/scsi/c/5fbf37e53091
[34/42] drivers/scsi/pm8001: Convert snprintf to sysfs_emit
https://git.kernel.org/mkp/scsi/c/8179041f801d
--
Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] drm/sched: Re-queue run job worker when drm_sched_entity_pop_job() returns NULL
On Tue, 6 Feb 2024 at 10:56, Luben Tuikov wrote:
>
> On 2024-02-05 08:33, Rodrigo Vivi wrote:
> > On Mon, Feb 05, 2024 at 09:44:56AM +0100, Christian König wrote:
> >> Am 02.02.24 um 22:58 schrieb Rodrigo Vivi:
> >>> On Tue, Jan 30, 2024 at 08:05:29AM +0100, Christian König wrote:
> Am 30.01.24 um 04:04 schrieb Matthew Brost:
> > Rather then loop over entities until one with a ready job is found,
> > re-queue the run job worker when drm_sched_entity_pop_job() returns
> > NULL.
> >
> > Fixes: 6dbd9004a55 ("drm/sched: Drain all entities in DRM sched run job
> > worker")
> >>> First of all there's a small typo in this Fixes tag that needs to be
> >>> fixed.
> >>> The correct one is:
> >>>
> >>> Fixes: 66dbd9004a55 ("drm/sched: Drain all entities in DRM sched run job
> >>> worker")
> >
> > Cc: Dave Airlie
> >
> >>>
> >>> But I couldn't apply this right now in any of our drm-tip trees because it
> >>> is not clear where this is coming from originally.
> >>>
> >>> likely amd tree?!
> >>
> >> No, this comes from Matthews work on the DRM scheduler.
> >>
> >> Matthews patches were most likely merged through drm-misc.
> >
> > the original is not there in drm-misc-next.
> > it looks like Dave had taken that one directly to drm-next.
> > So we either need the drm-misc maintainers to have a backmerge or
> > Dave to take this through the drm-fixes directly.
>
> This is indeed the case.
>
> I was going to push this patch through drm-misc-next, but the original/base
> patch
> (<20240124210811.1639040-1-matthew.br...@intel.com>) isn't there.
>
> If drm-misc maintainers back merge drm-fixes into drm-misc-next,
> I'll push this patch into drm-misc-next right away, so that it is complete,
> and people can run and test it fully.
>
> Else, Dave will have to pull this patch directly into drm-fixes with our tags,
> as was done for the base patch.
>
I'll pull this into drm-fixes now, as that is where the base patch went.
Dave.
> Reviewed-by: Luben Tuikov
>
> Regards,
> Luben
>
> >
> >>
> >> Regards,
> >> Christian.
> >>
> >>>
> > Signed-off-by: Matthew Brost
> Reviewed-by: Christian König
> >>> Christian, if this came from the amd, could you please apply it there and
> >>> propagate through your fixes flow?
> >>>
> >>> Thanks,
> >>> Rodrigo.
> >>>
> > ---
> >drivers/gpu/drm/scheduler/sched_main.c | 15 +--
> >1 file changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> > b/drivers/gpu/drm/scheduler/sched_main.c
> > index 8acbef7ae53d..7e90c9f95611 100644
> > --- a/drivers/gpu/drm/scheduler/sched_main.c
> > +++ b/drivers/gpu/drm/scheduler/sched_main.c
> > @@ -1178,21 +1178,24 @@ static void drm_sched_run_job_work(struct
> > work_struct *w)
> > struct drm_sched_entity *entity;
> > struct dma_fence *fence;
> > struct drm_sched_fence *s_fence;
> > - struct drm_sched_job *sched_job = NULL;
> > + struct drm_sched_job *sched_job;
> > int r;
> > if (READ_ONCE(sched->pause_submit))
> > return;
> > /* Find entity with a ready job */
> > - while (!sched_job && (entity = drm_sched_select_entity(sched))) {
> > - sched_job = drm_sched_entity_pop_job(entity);
> > - if (!sched_job)
> > - complete_all(&entity->entity_idle);
> > - }
> > + entity = drm_sched_select_entity(sched);
> > if (!entity)
> > return; /* No more work */
> > + sched_job = drm_sched_entity_pop_job(entity);
> > + if (!sched_job) {
> > + complete_all(&entity->entity_idle);
> > + drm_sched_run_job_queue(sched);
> > + return;
> > + }
> > +
> > s_fence = sched_job->s_fence;
> > atomic_add(sched_job->credits, &sched->credit_count);
> >>
>
> --
> Regards,
> Luben
linux-next: build failure after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
Caused by commit
a78a8da51b36 ("drm/ttm: replace busy placement with flags v6")
interacting with commit
dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
(and maybe others) from Linus' tree (v6.8-rc1).
I have applied the following merge fix patch for today. This makes it build,
but more is likely needed ...
From: Stephen Rothwell
Date: Tue, 6 Feb 2024 12:21:07 +1100
Subject: [PATCH] fix up for "drm/ttm: replace busy placement with flags v6"
interacting with commit
dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/xe/xe_bo.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
index 0b0e262e2166..280dbda8ae5a 100644
--- a/drivers/gpu/drm/xe/xe_bo.c
+++ b/drivers/gpu/drm/xe/xe_bo.c
@@ -38,8 +38,6 @@ static const struct ttm_place sys_placement_flags = {
static struct ttm_placement sys_placement = {
.num_placement = 1,
.placement = &sys_placement_flags,
- .num_busy_placement = 1,
- .busy_placement = &sys_placement_flags,
};
static const struct ttm_place tt_placement_flags = {
@@ -52,8 +50,6 @@ static const struct ttm_place tt_placement_flags = {
static struct ttm_placement tt_placement = {
.num_placement = 1,
.placement = &tt_placement_flags,
- .num_busy_placement = 1,
- .busy_placement = &sys_placement_flags,
};
bool mem_type_is_vram(u32 mem_type)
@@ -230,8 +226,6 @@ static int __xe_bo_placement_for_flags(struct xe_device
*xe, struct xe_bo *bo,
bo->placement = (struct ttm_placement) {
.num_placement = c,
.placement = bo->placements,
- .num_busy_placement = c,
- .busy_placement = bo->placements,
};
return 0;
@@ -251,7 +245,6 @@ static void xe_evict_flags(struct ttm_buffer_object *tbo,
/* Don't handle scatter gather BOs */
if (tbo->type == ttm_bo_type_sg) {
placement->num_placement = 0;
- placement->num_busy_placement = 0;
return;
}
@@ -1353,8 +1346,6 @@ static int __xe_bo_fixed_placement(struct xe_device *xe,
bo->placement = (struct ttm_placement) {
.num_placement = 1,
.placement = place,
- .num_busy_placement = 1,
- .busy_placement = place,
};
return 0;
@@ -2112,9 +2103,7 @@ int xe_bo_migrate(struct xe_bo *bo, u32 mem_type)
xe_place_from_ttm_type(mem_type, &requested);
placement.num_placement = 1;
- placement.num_busy_placement = 1;
placement.placement = &requested;
- placement.busy_placement = &requested;
/*
* Stolen needs to be handled like below VRAM handling if we ever need
--
2.43.0
--
Cheers,
Stephen Rothwell
pgpU6KgcbixK3.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the drm-misc tree with Linus' tree
Hi all,
On Tue, 6 Feb 2024 11:59:56 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
>
> drivers/gpu/drm/bridge/samsung-dsim.c
>
> between commit:
>
> ff3d5d04db07 ("drm: bridge: samsung-dsim: Don't use FORCE_STOP_STATE")
>
> from Linus' tree and commit:
>
> b2fe2292624a ("drm: bridge: samsung-dsim: enter display mode in the
> enable() callback")
>
> from the drm-misc tree.
>
> I fixed it up (see below, please check) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
I changed my mind and just used the latter version of this file.
--
Cheers,
Stephen Rothwell
pgpQ4uREN7GHJ.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the drm-misc tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/bridge/samsung-dsim.c
between commit:
ff3d5d04db07 ("drm: bridge: samsung-dsim: Don't use FORCE_STOP_STATE")
from Linus' tree and commit:
b2fe2292624a ("drm: bridge: samsung-dsim: enter display mode in the enable()
callback")
from the drm-misc tree.
I fixed it up (see below, please check) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/bridge/samsung-dsim.c
index 6a10aa5c85f5,f9d85fe1df7e..
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@@ -1498,6 -1526,11 +1503,8 @@@ static void samsung_dsim_atomic_disable
if (!(dsi->state & DSIM_STATE_ENABLED))
return;
- if (!samsung_dsim_hw_is_exynos(dsi->plat_data->hw_type))
- samsung_dsim_set_stop_state(dsi, true);
-
+ samsung_dsim_set_display_enable(dsi, false);
+
dsi->state &= ~DSIM_STATE_VIDOUT_AVAILABLE;
}
pgpbdUOiUbJQg.pgp
Description: OpenPGP digital signature
Re: [PATCH] drm/sched: Re-queue run job worker when drm_sched_entity_pop_job() returns NULL
On 2024-02-05 08:33, Rodrigo Vivi wrote:
> On Mon, Feb 05, 2024 at 09:44:56AM +0100, Christian König wrote:
>> Am 02.02.24 um 22:58 schrieb Rodrigo Vivi:
>>> On Tue, Jan 30, 2024 at 08:05:29AM +0100, Christian König wrote:
Am 30.01.24 um 04:04 schrieb Matthew Brost:
> Rather then loop over entities until one with a ready job is found,
> re-queue the run job worker when drm_sched_entity_pop_job() returns NULL.
>
> Fixes: 6dbd9004a55 ("drm/sched: Drain all entities in DRM sched run job
> worker")
>>> First of all there's a small typo in this Fixes tag that needs to be fixed.
>>> The correct one is:
>>>
>>> Fixes: 66dbd9004a55 ("drm/sched: Drain all entities in DRM sched run job
>>> worker")
>
> Cc: Dave Airlie
>
>>>
>>> But I couldn't apply this right now in any of our drm-tip trees because it
>>> is not clear where this is coming from originally.
>>>
>>> likely amd tree?!
>>
>> No, this comes from Matthews work on the DRM scheduler.
>>
>> Matthews patches were most likely merged through drm-misc.
>
> the original is not there in drm-misc-next.
> it looks like Dave had taken that one directly to drm-next.
> So we either need the drm-misc maintainers to have a backmerge or
> Dave to take this through the drm-fixes directly.
This is indeed the case.
I was going to push this patch through drm-misc-next, but the original/base
patch
(<20240124210811.1639040-1-matthew.br...@intel.com>) isn't there.
If drm-misc maintainers back merge drm-fixes into drm-misc-next,
I'll push this patch into drm-misc-next right away, so that it is complete,
and people can run and test it fully.
Else, Dave will have to pull this patch directly into drm-fixes with our tags,
as was done for the base patch.
Reviewed-by: Luben Tuikov
Regards,
Luben
>
>>
>> Regards,
>> Christian.
>>
>>>
> Signed-off-by: Matthew Brost
Reviewed-by: Christian König
>>> Christian, if this came from the amd, could you please apply it there and
>>> propagate through your fixes flow?
>>>
>>> Thanks,
>>> Rodrigo.
>>>
> ---
>drivers/gpu/drm/scheduler/sched_main.c | 15 +--
>1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> index 8acbef7ae53d..7e90c9f95611 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -1178,21 +1178,24 @@ static void drm_sched_run_job_work(struct
> work_struct *w)
> struct drm_sched_entity *entity;
> struct dma_fence *fence;
> struct drm_sched_fence *s_fence;
> - struct drm_sched_job *sched_job = NULL;
> + struct drm_sched_job *sched_job;
> int r;
> if (READ_ONCE(sched->pause_submit))
> return;
> /* Find entity with a ready job */
> - while (!sched_job && (entity = drm_sched_select_entity(sched))) {
> - sched_job = drm_sched_entity_pop_job(entity);
> - if (!sched_job)
> - complete_all(&entity->entity_idle);
> - }
> + entity = drm_sched_select_entity(sched);
> if (!entity)
> return; /* No more work */
> + sched_job = drm_sched_entity_pop_job(entity);
> + if (!sched_job) {
> + complete_all(&entity->entity_idle);
> + drm_sched_run_job_queue(sched);
> + return;
> + }
> +
> s_fence = sched_job->s_fence;
> atomic_add(sched_job->credits, &sched->credit_count);
>>
--
Regards,
Luben
OpenPGP_0x4C15479431A334AF.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [PATCH] drm/sched: Re-queue run job worker when drm_sched_entity_pop_job() returns NULL
On 2024-01-29 22:04, Matthew Brost wrote:
> Rather then loop over entities until one with a ready job is found,
> re-queue the run job worker when drm_sched_entity_pop_job() returns NULL.
>
> Fixes: 6dbd9004a55 ("drm/sched: Drain all entities in DRM sched run job
> worker")
> Signed-off-by: Matthew Brost
Indeed, we cannot have any loops in the GPU scheduler work items, as we need to
bounce
between submit and free in the same work queue. (Coming from the original
design before
work items/queues were introduced).
Thanks for fixing this, Matt!
Reviewed-by: Luben Tuikov
--
Regards,
Luben
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 15 +--
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> index 8acbef7ae53d..7e90c9f95611 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -1178,21 +1178,24 @@ static void drm_sched_run_job_work(struct work_struct
> *w)
> struct drm_sched_entity *entity;
> struct dma_fence *fence;
> struct drm_sched_fence *s_fence;
> - struct drm_sched_job *sched_job = NULL;
> + struct drm_sched_job *sched_job;
> int r;
>
> if (READ_ONCE(sched->pause_submit))
> return;
>
> /* Find entity with a ready job */
> - while (!sched_job && (entity = drm_sched_select_entity(sched))) {
> - sched_job = drm_sched_entity_pop_job(entity);
> - if (!sched_job)
> - complete_all(&entity->entity_idle);
> - }
> + entity = drm_sched_select_entity(sched);
> if (!entity)
> return; /* No more work */
>
> + sched_job = drm_sched_entity_pop_job(entity);
> + if (!sched_job) {
> + complete_all(&entity->entity_idle);
> + drm_sched_run_job_queue(sched);
> + return;
> + }
> +
> s_fence = sched_job->s_fence;
>
> atomic_add(sched_job->credits, &sched->credit_count);
OpenPGP_0x4C15479431A334AF.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [PATCH] drm/sched: Add Matthew Brost to maintainers
On 2024-02-05 19:06, Luben Tuikov wrote: > On 2024-02-01 07:56, Christian König wrote: >> Am 31.01.24 um 18:11 schrieb Daniel Vetter: >>> On Tue, Jan 30, 2024 at 07:03:02PM -0800, Matthew Brost wrote: Add Matthew Brost to DRM scheduler maintainers. Cc: Luben Tuikov Cc: Daniel Vetter Cc: Dave Airlie Cc: Christian König Signed-off-by: Matthew Brost >>> Definitely need more people taking care of drm/sched, so thanks for >>> volunteering! >>> >>> Acked-by: Daniel Vetter > > Yeah, that's a good idea. > > Acked-by: Luben Tuikov This patch has been pushed to drm-misc-next. Regards, Luben > > Regards, > Luben > >>> >>> I think this also needs an ack from Luben and Christian. And you also need >>> drm-misc commit rights first, or it's going to be a bit tricky to take >>> care of maintainer duties for merging patches. But since your sched >>> patches now have landed in upstream this should be just a formality. >> >> Ack from my side, I don't have time to look into scheduler stuff anyway. >> >> Maybe I can get somebody from Leo's team to volunteer as another >> reviewer for scheduler related stuff. >> >> Cheers, >> Christian. >> >>> >>> Cheers, Sima >>> --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 5c00fad59e91..e968d68a96c8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7308,6 +7308,7 @@ F: drivers/gpu/drm/xlnx/ DRM GPU SCHEDULER M: Luben Tuikov +M:Matthew Brost L: dri-devel@lists.freedesktop.org S: Maintained T: git git://anongit.freedesktop.org/drm/drm-misc -- 2.34.1 >> > -- Regards, Luben OpenPGP_0x4C15479431A334AF.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PATCH] drm/sched: Add Matthew Brost to maintainers
On 2024-02-01 07:56, Christian König wrote: > Am 31.01.24 um 18:11 schrieb Daniel Vetter: >> On Tue, Jan 30, 2024 at 07:03:02PM -0800, Matthew Brost wrote: >>> Add Matthew Brost to DRM scheduler maintainers. >>> >>> Cc: Luben Tuikov >>> Cc: Daniel Vetter >>> Cc: Dave Airlie >>> Cc: Christian König >>> Signed-off-by: Matthew Brost >> Definitely need more people taking care of drm/sched, so thanks for >> volunteering! >> >> Acked-by: Daniel Vetter Yeah, that's a good idea. Acked-by: Luben Tuikov Regards, Luben >> >> I think this also needs an ack from Luben and Christian. And you also need >> drm-misc commit rights first, or it's going to be a bit tricky to take >> care of maintainer duties for merging patches. But since your sched >> patches now have landed in upstream this should be just a formality. > > Ack from my side, I don't have time to look into scheduler stuff anyway. > > Maybe I can get somebody from Leo's team to volunteer as another > reviewer for scheduler related stuff. > > Cheers, > Christian. > >> >> Cheers, Sima >> >>> --- >>> MAINTAINERS | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/MAINTAINERS b/MAINTAINERS >>> index 5c00fad59e91..e968d68a96c8 100644 >>> --- a/MAINTAINERS >>> +++ b/MAINTAINERS >>> @@ -7308,6 +7308,7 @@ F:drivers/gpu/drm/xlnx/ >>> >>> DRM GPU SCHEDULER >>> M:Luben Tuikov >>> +M: Matthew Brost >>> L:dri-devel@lists.freedesktop.org >>> S:Maintained >>> T:git git://anongit.freedesktop.org/drm/drm-misc >>> -- >>> 2.34.1 >>> > -- Regards, Luben OpenPGP_0x4C15479431A334AF.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 05/24] media: i2c: switch to use of_graph_get_next_device_endpoint()
Hi Rob > I've read the threads already and think you should skip the rename. Just > put 'port' in the name of the new one. OK > That and taking a port number param should be enough distinction. I think we want to use "port" directly instead of "port number" on new function. Thank you for your help !! Best regards --- Renesas Electronics Ph.D. Kuninori Morimoto
[PATCH] drm: panel-orientation-quirks: Add quirk for Aya Neo KUN
From: Tobias Jakobi
Similar to the other Aya Neo devices this one features
again a portrait screen, here with a native resolution
of 1600x2560.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index d5c15292ae93..03224f8860ce 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -196,6 +196,12 @@ static const struct dmi_system_id orientation_data[] = {
DMI_MATCH(DMI_BOARD_NAME, "NEXT"),
},
.driver_data = (void *)&lcd800x1280_rightside_up,
+ }, {/* AYA NEO KUN */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "AYANEO"),
+ DMI_MATCH(DMI_BOARD_NAME, "KUN"),
+ },
+ .driver_data = (void *)&lcd1600x2560_rightside_up,
}, {/* Chuwi HiBook (CWI514) */
.matches = {
DMI_MATCH(DMI_BOARD_VENDOR, "Hampoo"),
--
2.43.0
Re: [PATCH v3 05/24] media: i2c: switch to use of_graph_get_next_device_endpoint()
On Sun, Feb 04, 2024 at 11:44:39PM +, Kuninori Morimoto wrote:
>
> Hi Rob
>
> > This is assuming there's just 1 port and 1 endpoint, but let's be
> > specific as the bindings are (first endpoint on port 0):
> >
> > of_graph_get_endpoint_by_regs(client->dev.of_node, 0, -1);
> >
> > Note we could ask for endpoint 0 here, but the bindings generally allow
> > for more than 1.
> >
> > I imagine most of the other cases here are the same.
>
> I will do it on new patch-set
>
> > > - for_each_endpoint_of_node(state->dev->of_node, ep_np) {
> > > + for_each_device_endpoint_of_node(state->dev->of_node, ep_np) {
> >
> > I would skip the rename.
>
> It is needed to avoid confuse, because new function will add
> another endpoint loop.
>
> see
> https://lore.kernel.org/r/20240131100701.754a95ee@booty
I've read the threads already and think you should skip the rename. Just
put 'port' in the name of the new one. That and taking a port number
param should be enough distinction.
Rob
Re: [PATCH 11/19] drm/i915/dp: Add support for DP tunnel BW allocation
On Tue, Jan 23, 2024 at 12:28:42PM +0200, Imre Deak wrote:
> +static int check_inherited_tunnel_state(struct intel_atomic_state *state,
> + struct intel_dp *intel_dp,
> + const struct
> intel_digital_connector_state *old_conn_state)
> +{
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
> + const struct intel_connector *connector =
> + to_intel_connector(old_conn_state->base.connector);
> + struct intel_crtc *old_crtc;
> + const struct intel_crtc_state *old_crtc_state;
> +
> + /*
> + * If a BWA tunnel gets detected only after the corresponding
> + * connector got enabled already without a BWA tunnel, or a different
> + * BWA tunnel (which was removed meanwhile) the old CRTC state won't
> + * contain the state of the current tunnel. This tunnel still has a
> + * reserved BW, which needs to be released, add the state for such
> + * inherited tunnels separately only to this atomic state.
> + */
> + if (!intel_dp_tunnel_bw_alloc_is_enabled(intel_dp))
> + return 0;
> +
> + if (!old_conn_state->base.crtc)
> + return 0;
> +
> + old_crtc = to_intel_crtc(old_conn_state->base.crtc);
> + old_crtc_state = intel_atomic_get_old_crtc_state(state, old_crtc);
> +
> + if (!old_crtc_state->hw.active ||
> + old_crtc_state->dp_tunnel_ref.tunnel == intel_dp->tunnel)
> + return 0;
> +
> + drm_dbg_kms(&i915->drm,
> + "[DPTUN %s][CONNECTOR:%d:%s][ENCODER:%d:%s][CRTC:%d:%s]
> Adding state for inherited tunnel %p\n",
> + drm_dp_tunnel_name(intel_dp->tunnel),
> + connector->base.base.id,
> + connector->base.name,
> + encoder->base.base.id,
> + encoder->base.name,
> + old_crtc->base.base.id,
> + old_crtc->base.name,
> + intel_dp->tunnel);
> +
> + return add_inherited_tunnel_state(state, intel_dp->tunnel, old_crtc);
I still strongly dislike this "tunnels are magically created by detect
behind our back" approach. IMO in an ideal world we'd only ever create the
tunnels during modeset/sanitize. What was the reason that didn't work again?
I think you explained it to me in person at least once already, but can't
remember anymore...
--
Ville Syrjälä
Intel
RE: [PATCH v3 2/5] drm: xlnx: zynqmp_dpsub: Fix timing for live mode
Hi Laurent, Thanks a lot for the review. > -Original Message- > From: Laurent Pinchart > Sent: Monday, February 5, 2024 12:08 AM > To: Klymenko, Anatoliy > Cc: maarten.lankho...@linux.intel.com; mrip...@kernel.org; > tzimmerm...@suse.de; airl...@gmail.com; dan...@ffwll.ch; Simek, Michal > ; dri-devel@lists.freedesktop.org; linux-arm- > ker...@lists.infradead.org; linux-ker...@vger.kernel.org > Subject: Re: [PATCH v3 2/5] drm: xlnx: zynqmp_dpsub: Fix timing for live mode > > Caution: This message originated from an External Source. Use proper caution > when opening attachments, clicking links, or responding. > > > Hi Anatoliy, > > Thank you for the patch. > > On Tue, Jan 23, 2024 at 06:53:59PM -0800, Anatoliy Klymenko wrote: > > Expect external video timing in live video input mode, program DPSUB > > acordingly. > > Are there no designs where the DPSUB operates in non-live mode, but uses a > video clock from the PL, for instance to use a different clock frequency ? > > I don't think that use case is very common, so I'm fine with this patch in > order to > properly support the more common use case of live input, and leave the PL > clock > without live input use case for later. > Theoretically, we can create such a design, but it wouldn't make too much sense since the PS clock is the best choice here. Probably, in some complicated scenarios like hybrid live-in/DMA or live-out, we would consider using the PL video clock, but the DPSUB driver is not supporting them yet. > > > > Reviewed-by: Tomi Valkeinen > > > > No need for a blank line here. > Sure, I'll fix this in the new version. Thank you. > > Signed-off-by: Anatoliy Klymenko > > Reviewed-by: Laurent Pinchart > > > --- > > drivers/gpu/drm/xlnx/zynqmp_disp.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c > > b/drivers/gpu/drm/xlnx/zynqmp_disp.c > > index 407bc07cec69..8a39b3accce5 100644 > > --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c > > +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c > > @@ -1166,7 +1166,7 @@ void zynqmp_disp_enable(struct zynqmp_disp *disp) > > /* Choose clock source based on the DT clock handle. */ > > zynqmp_disp_avbuf_set_clocks_sources(disp, disp->dpsub- > >vid_clk_from_ps, > >disp->dpsub->aud_clk_from_ps, > > - true); > > + > > + disp->dpsub->vid_clk_from_ps); > > zynqmp_disp_avbuf_enable_channels(disp); > > zynqmp_disp_avbuf_enable_audio(disp); > > > > -- > Regards, > > Laurent Pinchart
Re: [PATCH 02/19] drm/dp: Add support for DP tunneling
On Mon, Feb 05, 2024 at 07:15:17PM +0200, Imre Deak wrote:
> On Mon, Feb 05, 2024 at 06:13:30PM +0200, Ville Syrjälä wrote:
> > On Wed, Jan 31, 2024 at 08:49:16PM +0200, Imre Deak wrote:
> > > On Wed, Jan 31, 2024 at 06:09:04PM +0200, Ville Syrjälä wrote:
> > > > On Tue, Jan 23, 2024 at 12:28:33PM +0200, Imre Deak wrote:
> > > > > +static void untrack_tunnel_ref(struct drm_dp_tunnel *tunnel,
> > > > > +struct ref_tracker **tracker)
> > > > > +{
> > > > > + ref_tracker_free(&tunnel->group->mgr->ref_tracker,
> > > > > + tracker);
> > > > > +}
> > > > > +
> > > > > +struct drm_dp_tunnel *
> > > > > +drm_dp_tunnel_get_untracked(struct drm_dp_tunnel *tunnel)
> > > > > +{
> > > > > + track_tunnel_ref(tunnel, NULL);
> > > > > +
> > > > > + return tunnel_get(tunnel);
> > > > > +}
> > > > > +EXPORT_SYMBOL(drm_dp_tunnel_get_untracked);
> > > >
> > > > Why do these exist?
> > >
> > > They implement drm_dp_tunnel_get()/put() if
> > > CONFIG_DRM_DISPLAY_DEBUG_DP_TUNNEL_STATE=n.
> >
> > Why does that kind of irrelevant detail need to be visible
> > in the exported api?
>
> In non-debug builds the ref_tracker object isn't needed and so
> drm_dp_tunnel_ref won't contain a pointer to it either.
Since it's just a pointer I don't see much point in making
things more complicated by leaving it out.
> drm_dp_tunnel_get/put_untracked() provide a way to get/put a tunnel
> reference without having to pass a ref_tracker pointer.
>
> >
> > --
> > Ville Syrjälä
> > Intel
--
Ville Syrjälä
Intel
Re: [PATCH] nouveau: offload fence uevents work to workqueue
On 2/5/24 22:08, Dave Airlie wrote: On Tue, 6 Feb 2024 at 02:22, Danilo Krummrich wrote: On 1/29/24 02:50, Dave Airlie wrote: From: Dave Airlie This should break the deadlock between the fctx lock and the irq lock. This offloads the processing off the work from the irq into a workqueue. Signed-off-by: Dave Airlie Nouveau's scheduler uses a dedicated wq, hence from this perspective it's safe deferring fence signalling to the kernel global wq. However, I wonder if we could create deadlocks by building dependency chains into other drivers / kernel code that, by chance, makes use of the kernel global wq as well. Admittedly, even if, it's gonna be extremely unlikely given that WQ_MAX_ACTIVE == 512. But maybe it'd be safer to use a dedicated wq. Also, do we need to CC stable? I pushed this to Linus at the end of last week, since the hangs in 6.7 take out the complete system and I wanted it in stable. It might be safer to use a dedicated wq, is the concern someone is waiting on a fence in a workqueue somewhere else so we will never signal it? Yes, if some other work is waiting for this fence (or something else in the same dependency chain) to signal it can prevent executing the work signaling this fence, in case both are scheduled on the same wq. As mentioned, with the kernel global wq this would be rather unlikely to lead to an actual stall with WQ_MAX_ACTIVE == 512, but formally the race condition exists. I guess a malicious attacker could try to intentionally push jobs directly or indirectly depending on this fence to a driver which queues them up on a scheduler using the kernel global wq. Dave.
[PATCH] drm/amd/display: Increase frame-larger-than for all display_mode_vba files
After a recent change in LLVM, allmodconfig (which has CONFIG_KCSAN=y
and CONFIG_WERROR=y enabled) has a few new instances of
-Wframe-larger-than for the mode support and system configuration
functions:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20v2.c:3393:6:
error: stack frame size (2144) exceeds limit (2048) in
'dml20v2_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
3393 | void dml20v2_ModeSupportAndSystemConfigurationFull(struct
display_mode_lib *mode_lib)
| ^
1 error generated.
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn21/display_mode_vba_21.c:3520:6:
error: stack frame size (2192) exceeds limit (2048) in
'dml21_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
3520 | void dml21_ModeSupportAndSystemConfigurationFull(struct
display_mode_lib *mode_lib)
| ^
1 error generated.
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20.c:3286:6:
error: stack frame size (2128) exceeds limit (2048) in
'dml20_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
3286 | void dml20_ModeSupportAndSystemConfigurationFull(struct
display_mode_lib *mode_lib)
| ^
1 error generated.
Without the sanitizers enabled, there are no warnings.
This was the catalyst for commit 6740ec97bcdb ("drm/amd/display:
Increase frame warning limit with KASAN or KCSAN in dml2") and that same
change was made to dml in commit 5b750b22530f ("drm/amd/display:
Increase frame warning limit with KASAN or KCSAN in dml") but the
frame_warn_flag variable was not applied to all files. Do so now to
clear up the warnings and make all these files consistent.
Cc: sta...@vger.kernel.org
Closes: https://github.com/ClangBuiltLinux/linux/issue/1990
Signed-off-by: Nathan Chancellor
---
drivers/gpu/drm/amd/display/dc/dml/Makefile | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile
b/drivers/gpu/drm/amd/display/dc/dml/Makefile
index 6042a5a6a44f..59ade76ffb18 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
@@ -72,11 +72,11 @@ CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_lib.o :=
$(dml_ccflags)
CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_vba.o := $(dml_ccflags)
CFLAGS_$(AMDDALPATH)/dc/dml/dcn10/dcn10_fpu.o := $(dml_ccflags)
CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/dcn20_fpu.o := $(dml_ccflags)
-CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20.o := $(dml_ccflags)
+CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20.o := $(dml_ccflags)
$(frame_warn_flag)
CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_rq_dlg_calc_20.o := $(dml_ccflags)
-CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20v2.o := $(dml_ccflags)
+CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20v2.o := $(dml_ccflags)
$(frame_warn_flag)
CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_rq_dlg_calc_20v2.o := $(dml_ccflags)
-CFLAGS_$(AMDDALPATH)/dc/dml/dcn21/display_mode_vba_21.o := $(dml_ccflags)
+CFLAGS_$(AMDDALPATH)/dc/dml/dcn21/display_mode_vba_21.o := $(dml_ccflags)
$(frame_warn_flag)
CFLAGS_$(AMDDALPATH)/dc/dml/dcn21/display_rq_dlg_calc_21.o := $(dml_ccflags)
CFLAGS_$(AMDDALPATH)/dc/dml/dcn30/display_mode_vba_30.o := $(dml_ccflags)
$(frame_warn_flag)
CFLAGS_$(AMDDALPATH)/dc/dml/dcn30/display_rq_dlg_calc_30.o := $(dml_ccflags)
---
base-commit: 6813cdca4ab94a238f8eb0cef3d3f3fcbdfb0ee0
change-id: 20240205-amdgpu-raise-flt-for-dml-vba-files-ee5b5a9c5e43
Best regards,
--
Nathan Chancellor
Re: [PATCH] nouveau: offload fence uevents work to workqueue
On Tue, 6 Feb 2024 at 02:22, Danilo Krummrich wrote: > > On 1/29/24 02:50, Dave Airlie wrote: > > From: Dave Airlie > > > > This should break the deadlock between the fctx lock and the irq lock. > > > > This offloads the processing off the work from the irq into a workqueue. > > > > Signed-off-by: Dave Airlie > > Nouveau's scheduler uses a dedicated wq, hence from this perspective it's > safe deferring fence signalling to the kernel global wq. However, I wonder > if we could create deadlocks by building dependency chains into other > drivers / kernel code that, by chance, makes use of the kernel global wq as > well. > > Admittedly, even if, it's gonna be extremely unlikely given that > WQ_MAX_ACTIVE == 512. But maybe it'd be safer to use a dedicated wq. > > Also, do we need to CC stable? I pushed this to Linus at the end of last week, since the hangs in 6.7 take out the complete system and I wanted it in stable. It might be safer to use a dedicated wq, is the concern someone is waiting on a fence in a workqueue somewhere else so we will never signal it? Dave.
Re: [PATCH v2 3/6] clk: sunxi-ng: nkm: Support minimum and maximum rate
On 2024-02-05 at 18:56:09 +0100, Jernej Škrabec
wrote:
> Dne ponedeljek, 05. februar 2024 ob 16:22:26 CET je Frank Oltmanns napisal(a):
>> According to the Allwinner User Manual, the Allwinner A64 requires
>> PLL-MIPI to run at 500MHz-1.4GHz. Add support for that to ccu_nkm.
>>
>> Signed-off-by: Frank Oltmanns
>> ---
>> drivers/clk/sunxi-ng/ccu_nkm.c | 13 +
>> drivers/clk/sunxi-ng/ccu_nkm.h | 2 ++
>> 2 files changed, 15 insertions(+)
>>
>> diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
>> index 1168d894d636..7d135908d6e0 100644
>> --- a/drivers/clk/sunxi-ng/ccu_nkm.c
>> +++ b/drivers/clk/sunxi-ng/ccu_nkm.c
>> @@ -181,6 +181,12 @@ static unsigned long ccu_nkm_round_rate(struct
>> ccu_mux_internal *mux,
>> if (nkm->common.features & CCU_FEATURE_FIXED_POSTDIV)
>> rate *= nkm->fixed_post_div;
>>
>> +if (nkm->min_rate && rate < nkm->min_rate)
>> +rate = nkm->min_rate;
>> +
>> +if (nkm->max_rate && rate > nkm->max_rate)
>> +rate = nkm->max_rate;
>
> Please take a look at ccu_nm_round_rate() code. You need to consider postdiv
> and you can return immediately.
There is a difference here insofar that ccu_nm is always connected to a
fixed rate parent (at least that's my understanding). Therefore, in
ccu_nm_round_rate() we can be sure that the min or max rate can really
be set. In ccu_nkm we don't have that luxury, we actually have to find a
rate that is approximately equal to the min and max rate, based on the
parent rate. Therefore, we can't return immediately.
Also, I'm not sure what you mean about me needing to consider postdiv.
That's what I did. The check is after multiplying with the postdiv. It's
the same as in ccu_nm_round_rate() (just minus the immediate return).
>
>> +
>> if (!clk_hw_can_set_rate_parent(&nkm->common.hw))
>> rate = ccu_nkm_find_best(*parent_rate, rate, &_nkm,
>> &nkm->common);
>> else
>> @@ -220,6 +226,13 @@ static int ccu_nkm_set_rate(struct clk_hw *hw, unsigned
>> long rate,
>> _nkm.min_m = 1;
>> _nkm.max_m = nkm->m.max ?: 1 << nkm->m.width;
>>
>> +
>> +if (nkm->min_rate && rate < nkm->min_rate)
>> +rate = nkm->min_rate;
>> +
>> +if (nkm->max_rate && rate > nkm->max_rate)
>> +rate = nkm->max_rate;
>> +
>
> No need for this, clk subsystem calls round rate before setting actual clock
> rate.
I'll remove the checks in V3.
Best regards,
Frank
>
> Best regards,
> Jernej
>
>> ccu_nkm_find_best(parent_rate, rate, &_nkm, &nkm->common);
>>
>> spin_lock_irqsave(nkm->common.lock, flags);
>> diff --git a/drivers/clk/sunxi-ng/ccu_nkm.h b/drivers/clk/sunxi-ng/ccu_nkm.h
>> index c409212ee40e..358a9df6b6a0 100644
>> --- a/drivers/clk/sunxi-ng/ccu_nkm.h
>> +++ b/drivers/clk/sunxi-ng/ccu_nkm.h
>> @@ -27,6 +27,8 @@ struct ccu_nkm {
>> struct ccu_mux_internal mux;
>>
>> unsigned intfixed_post_div;
>> +unsigned long min_rate;
>> +unsigned long max_rate;
>> unsigned long max_m_n_ratio;
>> unsigned long min_parent_m_ratio;
>>
>>
>>
Re: [PATCH v3 03/11] drm/mediatek: Add secure buffer control flow to mtk_drm_gem
On Fri, Jan 12, 2024 at 5:13 AM Daniel Vetter wrote:
>
> On Sun, Dec 24, 2023 at 02:29:24AM +0800, Jason-JH.Lin wrote:
> > Add secure buffer control flow to mtk_drm_gem.
> >
> > When user space takes DRM_MTK_GEM_CREATE_ENCRYPTED flag and size
> > to create a mtk_drm_gem object, mtk_drm_gem will find a matched size
> > dma buffer from secure dma-heap and bind it to mtk_drm_gem object.
> >
> > Signed-off-by: Jason-JH.Lin
>
> Apologies for jumping rather late, but last year was a mess here.
>
> There's the fundamental issue that this is new uapi, and it needs open
> userspace, and I haven't seen that.
The open userspace for it is currently in minigbm for ChromeOS here:
https://chromium.googlesource.com/chromiumos/platform/minigbm/+/main/mediatek.c#322
Does that satisfy that particular requirement?
>
> What's more, this is a pure kms api so there's no precedent at all for
> adding special ioctl to those - all the existing support for
> protected/restricted content buffers in upstream has used render nodes and
> EGL_EXT_protected_content in mesa3d to enable this feature on the drm/kms
> side. So I'm not exactly sure what your plan here is, but you need one,
> and it needs to be more than a testcase/demo.
I'm probably not understanding something here, but for the Intel
protected content allocation there was a specific structure
(drm_i915_gem_create_ext_protected_content) added to the
DRM_IOCTL_I915_GEM_CREATE_EXT ioctl in order to enable allocation of
protected buffers. So wouldn't that be precedent for using an ioctl
like this to allocate a GEM object?
>
> The other issue, and the reason I've looked into the mtk code, is that the
> dma-buf implementation breaks the dma-buf api. So that needs to be
> changed.
Yeah, agreed here...I do see now that attaching dma_bufs for content
that is completely inaccessible by the kernel will be a no-go.
>
> Finally I think the primary way to display a protected content buffer on a
> pure kms driver should be by using prime fd2handle buffer importing.
> Because you're adding a dma-buf heap it's already possible for userspace
> to use this path (or at least try), and so we have to make this path work
> anyway.
Is what you're getting at here having MTK implement their own
gem_prime_import in order to work around having to do the dma_buf
attach operation? (from looking at the code, this appears to be the
only place in non-vendor specific code that dma_buf_attach is called)
>
> Once we have the prime import path working correctly for protected content
> buffers (which should shake out all the dma-api issues I've explained in
> the dma-buf heaps thread), it should be possible to implement the direct
> allocation function in a generic helper:
>
> struct drm_gem_object * drm_gem_create_object_from_heap(struct drm_device
> *dev,
> struct drm_file *file,
> struct drm_buf_heap
> *heap);
>
> Which does roughly:
>
> - allocate a dma-buf from the desired heap
> - import that dma-buf into the device using prime for the drm_file
> - using the already implemented driver import code for special cases like
> protected content buffers
>
> There should be no need to hand-roll all this code here, and especially
> not have any special-casing for the heap string name or things like that.
> That all must be handled in the dma-buf prime import code.
>
> Cheers, Sima
>
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_gem.c | 85 +-
> > drivers/gpu/drm/mediatek/mtk_drm_gem.h | 4 ++
> > 2 files changed, 88 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> > index 30e347adcbe9..858f34a735f8 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> > @@ -4,6 +4,8 @@
> > */
> >
> > #include
> > +#include
> > +#include
> > #include
> >
> > #include
> > @@ -55,6 +57,81 @@ static struct mtk_drm_gem_obj *mtk_drm_gem_init(struct
> > drm_device *dev,
> > return mtk_gem_obj;
> > }
> >
> > +struct mtk_drm_gem_obj *mtk_drm_gem_create_from_heap(struct drm_device
> > *dev,
> > + const char *heap, size_t
> > size)
> > +{
> > + struct mtk_drm_private *priv = dev->dev_private;
> > + struct mtk_drm_gem_obj *mtk_gem;
> > + struct drm_gem_object *obj;
> > + struct dma_heap *dma_heap;
> > + struct dma_buf *dma_buf;
> > + struct dma_buf_attachment *attach;
> > + struct sg_table *sgt;
> > + struct iosys_map map = {};
> > + int ret;
> > +
> > + mtk_gem = mtk_drm_gem_init(dev, size);
> > + if (IS_ERR(mtk_gem))
> > + return ERR_CAST(mtk_gem);
> > +
> > + obj = &mtk_gem->base;
> > +
> > + dma_heap = dma_heap_find(heap);
> > + if (!dma_heap) {
> > + DRM_ERROR("heap find fail\n");
> > + goto err_ge
Re: [linux][PATCH v2 1/4] dt-bindings: display: bridge: add sam9x75-lvds compatible
On Mon, 05 Feb 2024 16:36:06 +0530, Dharma Balasubiramani wrote: > Add the 'sam9x75-lvds' compatible binding, which describes the Low Voltage > Differential Signaling (LVDS) Controller found on some Microchip's sam9x7 > series System-on-Chip (SoC) devices. This binding will be used to define > the properties and configuration for the LVDS Controller in DT. > > Signed-off-by: Dharma Balasubiramani > --- > Changelog > v1 -> v2 > - Remove '|' in description, as there is no formatting to preserve. > - Remove 'gclk' from clock-names as there is only one clock(pclk). > - Remove the unused headers and include only used ones. > - Change the compatible name specific to SoC (sam9x75) instead of entire > series. > - Change file name to match the compatible name. > --- > .../bridge/microchip,sam9x75-lvds.yaml| 55 +++ > 1 file changed, 55 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml > Reviewed-by: Rob Herring
Re: [PATCH V8 09/12] dt-bindings: display: imx: add binding for i.MX8MP HDMI TX
On Sat, 03 Feb 2024 10:52:49 -0600, Adam Ford wrote: > From: Lucas Stach > > The HDMI TX controller on the i.MX8MP SoC is a Synopsys designware IP > core with a little bit of SoC integration around it. > > Signed-off-by: Lucas Stach > Signed-off-by: Adam Ford > > --- > V3: Change name and location to better idenfity as a bridge and > HDMI 2.0a transmitter > > Fix typos and feedback from Rob and added ports. > --- > .../display/bridge/fsl,imx8mp-hdmi-tx.yaml| 102 ++ > 1 file changed, 102 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml > Reviewed-by: Rob Herring
Re: [PATCH V8 03/12] dt-bindings: soc: imx: add missing clock and power-domains to imx8mp-hdmi-blk-ctrl
On Sat, 03 Feb 2024 10:52:43 -0600, Adam Ford wrote: > Per guidance from the NXP downstream kernel, if the clock is > disabled before HDMI/LCDIF probe, LCDIF will not get pixel > clock from HDMI PHY and throw an error: > > [CRTC:39:crtc-2] vblank wait timed out > WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_atomic_helper.c: > 1634 drm_atomic_helper_wait_for_vblanks.part.0+0x23c/0x260 > > Fix this by adding the fdcc clock to the hdmi_blk_ctrl. This > should be safe, since neither this power domain nor the dependent > HDMI and LCDIF drivers been enabled or added to the SoC device > tree yet. > > According to Sandor Yu from NXP, "the FDCC clock is not for HDMITX > in desgin, but it is part of HDMI domain that needed by HDMITX. > So I think it is reasonable added it to the power domain driver." > > The driver also supports two power domains which are missing from the binding > that also fix an issue with resuming from suspend. > > Signed-off-by: Adam Ford > --- > V2: Update commit message to both show error and give a bit more > background. > Add missing power domains hdcp and hdrv as pointed out by Marek Vasut > --- > .../soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml | 22 --- > 1 file changed, 14 insertions(+), 8 deletions(-) > Reviewed-by: Rob Herring
Re: [PATCH] dt-bindings: drm/bridge: ti-sn65dsi86: Fix bouncing @codeaurora address
Hi, On Fri, Feb 2, 2024 at 12:25 PM Jeffrey Hugo wrote: > > The servers for the @codeaurora domain are long retired and any messages > sent there bounce. Sandeep Panda's email address is no longer valid and > should be repleaced. However Sandeep has left the company and has not > been active sice, therefore it looks like this binding is orphaned. > > Doug is listed as the reviewer for this file in MAINTAINERS and has > volunteered to be listed within the file as the binding maintainer. > Therefore replace Sandeep with Doug to make the documentation current. > > Signed-off-by: Jeffrey Hugo > --- > .../devicetree/bindings/display/bridge/ti,sn65dsi86.yaml| 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Pushed to drm-misc-next: 2592a36d9569 dt-bindings: drm/bridge: ti-sn65dsi86: Fix bouncing @codeaurora address -Doug
Re: [PATCH] dt-bindings: drm/bridge: ti-sn65dsi86: Fix bouncing @codeaurora address
On Fri, 02 Feb 2024 13:23:29 -0700, Jeffrey Hugo wrote: > The servers for the @codeaurora domain are long retired and any messages > sent there bounce. Sandeep Panda's email address is no longer valid and > should be repleaced. However Sandeep has left the company and has not > been active sice, therefore it looks like this binding is orphaned. > > Doug is listed as the reviewer for this file in MAINTAINERS and has > volunteered to be listed within the file as the binding maintainer. > Therefore replace Sandeep with Doug to make the documentation current. > > Signed-off-by: Jeffrey Hugo > --- > .../devicetree/bindings/display/bridge/ti,sn65dsi86.yaml| 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Acked-by: Rob Herring
Re: [PATCH] dt-bindings: backlight: qcom-wled: Fix bouncing email addresses
On Fri, 02 Feb 2024 11:01:51 -0700, Jeffrey Hugo wrote: > Bjorn is no longer at Linaro. Update his email address to @kernel to > match the .mailmap entry. > > The servers for @codeaurora are long retired and messages sent there > will bounce. Update Kiran's email address to match the .mailmap entry. > > This will help anyone that is looking to reach out about this binding > and is not using .mailmap to pre-process their message. > > Signed-off-by: Jeffrey Hugo > --- > .../devicetree/bindings/leds/backlight/qcom-wled.yaml | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Acked-by: Rob Herring
Re: [PATCH] drm/hisilicon: Use devm_platform_get_and_ioremap_resource() in dsi_parse_dt()
Hi,
On Mon, Feb 5, 2024 at 12:13 AM Markus Elfring wrote:
>
> From: Markus Elfring
> Date: Mon, 5 Feb 2024 08:58:21 +0100
>
> A wrapper function is available since the commit
> 890cc39a879906b63912482dfc41944579df2dc6
> ("drivers: provide devm_platform_get_and_ioremap_resource()").
> Thus reuse existing functionality instead of keeping duplicate source code.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
> ---
> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
> b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
> index 566de4658719..1edf429c49d7 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
> @@ -834,8 +834,7 @@ static int dsi_parse_dt(struct platform_device *pdev,
> struct dw_dsi *dsi)
> return PTR_ERR(ctx->pclk);
> }
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - ctx->base = devm_ioremap_resource(&pdev->dev, res);
> + ctx->base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
> if (IS_ERR(ctx->base)) {
> DRM_ERROR("failed to remap dsi io region\n");
> return PTR_ERR(ctx->base);
This function no longer needs the local variable "res". Remove it and
then change the function call to devm_platform_ioremap_resource().
With that:
Reviewed-by: Douglas Anderson
Re: [PATCH v2 5/6] drm/panel: st7703: Drive XBD599 panel at higher clock rate
Dne ponedeljek, 05. februar 2024 ob 16:22:28 CET je Frank Oltmanns napisal(a):
> This panel is used in the pinephone that runs on a Allwinner A64 SOC.
> The SOC requires pll-mipi to run at more than 500 MHz.
>
> This is the relevant clock tree:
> pll-mipi
> tcon0
>tcon-data-clock
>
> tcon-data-clock has to run at 1/4 the DSI per-lane bit rate. The XBD599
> has 24 bpp and 4 lanes. Therefore, the resulting requested
> tcon-data-clock rate is:
> crtc_clock * 1000 * (24 / 4) / 4
>
> tcon-data-clock runs at tcon0 / 4 (fixed divisor), so it requests a
> parent rate of
> 4 * (crtc_clock * 1000 * (24 / 4) / 4)
>
> Since tcon0 is a ccu_mux, the rate of tcon0 equals the rate of pll-mipi.
>
> pll-mipi's constraint to run at 500MHz or higher forces us to have a
> crtc_clock >= 8 kHz if we want a 60 Hz vertical refresh rate.
>
> Change [hv]sync_(start|end) so that we reach a clock rate of 83502 kHz
> so that it is high enough to align with pll-pipi limits.
Typo: pll-pipi -> pll-mipi
Best regards,
Jernej
>
> Signed-off-by: Frank Oltmanns
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index b55bafd1a8be..6886fd7f765e 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -320,14 +320,14 @@ static int xbd599_init_sequence(struct st7703 *ctx)
>
> static const struct drm_display_mode xbd599_mode = {
> .hdisplay= 720,
> - .hsync_start = 720 + 40,
> - .hsync_end = 720 + 40 + 40,
> - .htotal = 720 + 40 + 40 + 40,
> + .hsync_start = 720 + 65,
> + .hsync_end = 720 + 65 + 65,
> + .htotal = 720 + 65 + 65 + 65,
> .vdisplay= 1440,
> - .vsync_start = 1440 + 18,
> - .vsync_end = 1440 + 18 + 10,
> - .vtotal = 1440 + 18 + 10 + 17,
> - .clock = 69000,
> + .vsync_start = 1440 + 30,
> + .vsync_end = 1440 + 30 + 22,
> + .vtotal = 1440 + 30 + 22 + 29,
> + .clock = (720 + 65 + 65 + 65) * (1440 + 30 + 22 + 29) * 60 / 1000,
> .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> .width_mm= 68,
> .height_mm = 136,
>
>
Re: [PATCH v2 4/6] clk: sunxi-ng: a64: Set minimum and maximum rate for PLL-MIPI
Dne ponedeljek, 05. februar 2024 ob 16:22:27 CET je Frank Oltmanns napisal(a): > Set the minimum and maximum rate of Allwinner A64's PLL-MIPI according > to the Allwinner User Manual. > > Signed-off-by: Frank Oltmanns Reviewed-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH v2 3/6] clk: sunxi-ng: nkm: Support minimum and maximum rate
Dne ponedeljek, 05. februar 2024 ob 16:22:26 CET je Frank Oltmanns napisal(a):
> According to the Allwinner User Manual, the Allwinner A64 requires
> PLL-MIPI to run at 500MHz-1.4GHz. Add support for that to ccu_nkm.
>
> Signed-off-by: Frank Oltmanns
> ---
> drivers/clk/sunxi-ng/ccu_nkm.c | 13 +
> drivers/clk/sunxi-ng/ccu_nkm.h | 2 ++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
> index 1168d894d636..7d135908d6e0 100644
> --- a/drivers/clk/sunxi-ng/ccu_nkm.c
> +++ b/drivers/clk/sunxi-ng/ccu_nkm.c
> @@ -181,6 +181,12 @@ static unsigned long ccu_nkm_round_rate(struct
> ccu_mux_internal *mux,
> if (nkm->common.features & CCU_FEATURE_FIXED_POSTDIV)
> rate *= nkm->fixed_post_div;
>
> + if (nkm->min_rate && rate < nkm->min_rate)
> + rate = nkm->min_rate;
> +
> + if (nkm->max_rate && rate > nkm->max_rate)
> + rate = nkm->max_rate;
Please take a look at ccu_nm_round_rate() code. You need to consider postdiv
and you can return immediately.
> +
> if (!clk_hw_can_set_rate_parent(&nkm->common.hw))
> rate = ccu_nkm_find_best(*parent_rate, rate, &_nkm,
> &nkm->common);
> else
> @@ -220,6 +226,13 @@ static int ccu_nkm_set_rate(struct clk_hw *hw, unsigned
> long rate,
> _nkm.min_m = 1;
> _nkm.max_m = nkm->m.max ?: 1 << nkm->m.width;
>
> +
> + if (nkm->min_rate && rate < nkm->min_rate)
> + rate = nkm->min_rate;
> +
> + if (nkm->max_rate && rate > nkm->max_rate)
> + rate = nkm->max_rate;
> +
No need for this, clk subsystem calls round rate before setting actual clock
rate.
Best regards,
Jernej
> ccu_nkm_find_best(parent_rate, rate, &_nkm, &nkm->common);
>
> spin_lock_irqsave(nkm->common.lock, flags);
> diff --git a/drivers/clk/sunxi-ng/ccu_nkm.h b/drivers/clk/sunxi-ng/ccu_nkm.h
> index c409212ee40e..358a9df6b6a0 100644
> --- a/drivers/clk/sunxi-ng/ccu_nkm.h
> +++ b/drivers/clk/sunxi-ng/ccu_nkm.h
> @@ -27,6 +27,8 @@ struct ccu_nkm {
> struct ccu_mux_internal mux;
>
> unsigned intfixed_post_div;
> + unsigned long min_rate;
> + unsigned long max_rate;
> unsigned long max_m_n_ratio;
> unsigned long min_parent_m_ratio;
>
>
>
Re: [PATCH] drm/hisilicon: Use devm_platform_get_and_ioremap_resource() in dsi_parse_dt()
On Mon, Feb 5, 2024 at 12:13 AM Markus Elfring wrote:
>
> From: Markus Elfring
> Date: Mon, 5 Feb 2024 08:58:21 +0100
>
> A wrapper function is available since the commit
> 890cc39a879906b63912482dfc41944579df2dc6
> ("drivers: provide devm_platform_get_and_ioremap_resource()").
> Thus reuse existing functionality instead of keeping duplicate source code.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
I no longer have hardware to test with this, but this looks reasonable to me.
Acked-by: John Stultz
thanks
-john
[PATCH v10 4/7] drm/meson: gate px_clk when setting rate
Disable the px_clk when setting the rate to recover a fully
configured and correctly reset VCLK clock tree after the rate
is set.
Fixes: 77d9e1e6b846 ("drm/meson: add support for MIPI-DSI transceiver")
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
index a6bc1bdb3d0d..a10cff3ca1fe 100644
--- a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
+++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
@@ -95,6 +95,7 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
return ret;
}
+ clk_disable_unprepare(mipi_dsi->px_clk);
ret = clk_set_rate(mipi_dsi->px_clk, mipi_dsi->mode->clock * 1000);
if (ret) {
@@ -103,6 +104,12 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
return ret;
}
+ ret = clk_prepare_enable(mipi_dsi->px_clk);
+ if (ret) {
+ dev_err(mipi_dsi->dev, "Failed to enable DSI Pixel clock (ret
%d)\n", ret);
+ return ret;
+ }
+
switch (mipi_dsi->dsi_device->format) {
case MIPI_DSI_FMT_RGB888:
dpi_data_format = DPI_COLOR_24BIT;
--
2.34.1
[PATCH v10 7/7] arm64: dts: amlogic: meson-g12b-bananapi-cm4: add support for MNT Reform2 with CM4 adaper
This adds a basic devicetree for the MNT Reform2 DIY laptop when using a
CM4 adapter and a BPI-CM4 module.
Co-developed-by: Lukas F. Hartmann
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../meson-g12b-bananapi-cm4-mnt-reform2.dts| 384 +
2 files changed, 385 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/Makefile
b/arch/arm64/boot/dts/amlogic/Makefile
index 5e5ea0f14fe2..0d819a63b15e 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -15,6 +15,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-g12a-x96-max.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-bananapi-m2s.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-khadas-vim3.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-bananapi-cm4-cm4io.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-g12b-bananapi-cm4-mnt-reform2.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gsking-x.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gtking-pro.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gtking.dtb
diff --git
a/arch/arm64/boot/dts/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dts
b/arch/arm64/boot/dts/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dts
new file mode 100644
index ..003efed529ba
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dts
@@ -0,0 +1,384 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Neil Armstrong
+ * Copyright 2023 MNT Research GmbH
+ */
+
+/dts-v1/;
+
+#include "meson-g12b-bananapi-cm4.dtsi"
+#include
+#include
+#include
+
+/ {
+ model = "MNT Reform 2 with BPI-CM4 Module";
+ compatible = "mntre,reform2-cm4", "bananapi,bpi-cm4", "amlogic,a311d",
"amlogic,g12b";
+ chassis-type = "laptop";
+
+ aliases {
+ ethernet0 = ðmac;
+ i2c0 = &i2c1;
+ i2c1 = &i2c3;
+ };
+
+ hdmi_connector: hdmi-connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&hdmi_tx_tmds_out>;
+ };
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-blue {
+ color = ;
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio_ao GPIOAO_7 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ led-green {
+ color = ;
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio_ao GPIOAO_2 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ sound {
+ compatible = "amlogic,axg-sound-card";
+ model = "MNT-REFORM2-BPI-CM4";
+ audio-widgets = "Headphone", "Headphone Jack",
+ "Speaker", "External Speaker",
+ "Microphone", "Mic Jack";
+ audio-aux-devs = <&tdmout_a>, <&tdmout_b>, <&tdmin_b>;
+ audio-routing = "TDMOUT_A IN 0", "FRDDR_A OUT 0",
+ "TDMOUT_A IN 1", "FRDDR_B OUT 0",
+ "TDMOUT_A IN 2", "FRDDR_C OUT 0",
+ "TDM_A Playback", "TDMOUT_A OUT",
+ "TDMOUT_B IN 0", "FRDDR_A OUT 1",
+ "TDMOUT_B IN 1", "FRDDR_B OUT 1",
+ "TDMOUT_B IN 2", "FRDDR_C OUT 1",
+ "TDM_B Playback", "TDMOUT_B OUT",
+ "TDMIN_B IN 1", "TDM_B Capture",
+ "TDMIN_B IN 4", "TDM_B Loopback",
+ "TODDR_A IN 1", "TDMIN_B OUT",
+ "TODDR_B IN 1", "TDMIN_B OUT",
+ "TODDR_C IN 1", "TDMIN_B OUT",
+ "Headphone Jack", "HP_L",
+ "Headphone Jack", "HP_R",
+ "External Speaker", "SPK_LP",
+ "External Speaker", "SPK_LN",
+ "External Speaker", "SPK_RP",
+ "External Speaker", "SPK_RN",
+ "LINPUT1", "Mic Jack",
+ "Mic Jack", "MICB";
+
+ assigned-clocks = <&clkc CLKID_MPLL2>,
+ <&clkc CLKID_MPLL0>,
+ <&clkc CLKID_MPLL1>;
+ assigned-clock-parents = <0>, <0>, <0>;
+ assigned-clock-rates = <294912000>,
+ <270950400>,
+ <393216000>;
+
+ dai-link-0 {
+ sound-dai = <&frddr_a>;
+ };
+
+ dai-link-1 {
+
[PATCH v10 6/7] arm64: meson: khadas-vim3l: add TS050 DSI panel overlay
This add dtbo overlay to support the Khadas TS050 panel on the
Khadas VIM3 & VIM3L boards.
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/amlogic/Makefile | 3 +
.../boot/dts/amlogic/meson-khadas-vim3-ts050.dtso | 108 +
2 files changed, 111 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/Makefile
b/arch/arm64/boot/dts/amlogic/Makefile
index cc8b34bd583d..5e5ea0f14fe2 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -80,3 +80,6 @@ dtb-$(CONFIG_ARCH_MESON) += meson-sm1-odroid-hc4.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-sei610.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-x96-air-gbit.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-x96-air.dtb
+
+# Overlays
+dtb-$(CONFIG_ARCH_MESON) += meson-khadas-vim3-ts050.dtbo
diff --git a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3-ts050.dtso
b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3-ts050.dtso
new file mode 100644
index ..a41b4e619580
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3-ts050.dtso
@@ -0,0 +1,108 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS
+ * Author: Neil Armstrong
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/dts-v1/;
+/plugin/;
+
+/*
+ * Enable Khadas TS050 DSI Panel + Touch Controller
+ * on Khadas VIM3 (A311D) and VIM3L (S905D3)
+ */
+
+&{/} {
+ panel_backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm_AO_cd 0 25000 0>;
+ brightness-levels = <0 255>;
+ num-interpolated-steps = <255>;
+ default-brightness-level = <200>;
+ };
+};
+
+&i2c3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-0 = <&i2c3_sda_a_pins>, <&i2c3_sck_a_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ touch-controller@38 {
+ compatible = "edt,edt-ft5206";
+ reg = <0x38>;
+ interrupt-parent = <&gpio_intc>;
+ interrupts = ;
+ reset-gpios = <&gpio_expander 6 GPIO_ACTIVE_LOW>;
+ touchscreen-size-x = <1080>;
+ touchscreen-size-y = <1920>;
+ status = "okay";
+ };
+};
+
+&mipi_dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ assigned-clocks = <&clkc CLKID_GP0_PLL>,
+ <&clkc CLKID_MIPI_DSI_PXCLK_SEL>,
+ <&clkc CLKID_MIPI_DSI_PXCLK>,
+ <&clkc CLKID_CTS_ENCL_SEL>,
+ <&clkc CLKID_VCLK2_SEL>;
+ assigned-clock-parents = <0>,
+<&clkc CLKID_GP0_PLL>,
+<0>,
+<&clkc CLKID_VCLK2_DIV1>,
+<&clkc CLKID_GP0_PLL>;
+ assigned-clock-rates = <96000>,
+ <0>,
+ <96000>,
+ <0>,
+ <0>;
+
+ panel@0 {
+ compatible = "khadas,ts050";
+ reset-gpios = <&gpio_expander 0 GPIO_ACTIVE_LOW>;
+ enable-gpios = <&gpio_expander 1 GPIO_ACTIVE_HIGH>;
+ power-supply = <&vcc_3v3>;
+ backlight = <&panel_backlight>;
+ reg = <0>;
+
+ port {
+ mipi_in_panel: endpoint {
+ remote-endpoint = <&mipi_out_panel>;
+ };
+ };
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ mipi_out_panel: endpoint {
+ remote-endpoint = <&mipi_in_panel>;
+ };
+ };
+ };
+};
+
+&mipi_analog_dphy {
+ status = "okay";
+};
+
+&mipi_dphy {
+ status = "okay";
+};
+
+&pwm_AO_cd {
+ pinctrl-0 = <&pwm_ao_c_6_pins>, <&pwm_ao_d_e_pins>;
+};
--
2.34.1
[PATCH v10 5/7] arm64: meson: g12-common: add the MIPI DSI nodes
Add the MIPI DSI Analog & Digital PHY nodes and the DSI control
nodes with proper port endpoint to the VPU.
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 70 +++
1 file changed, 70 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
index ff68b911b729..7300408262d5 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
@@ -1663,9 +1663,28 @@ pwrc: power-controller {
<25000>,
<0>; /*
Do Nothing */
};
+
+ mipi_analog_dphy: phy {
+ compatible =
"amlogic,g12a-mipi-dphy-analog";
+ #phy-cells = <0>;
+ status = "disabled";
+ };
};
};
+ mipi_dphy: phy@44000 {
+ compatible = "amlogic,axg-mipi-dphy";
+ reg = <0x0 0x44000 0x0 0x2000>;
+ clocks = <&clkc CLKID_MIPI_DSI_PHY>;
+ clock-names = "pclk";
+ resets = <&reset RESET_MIPI_DSI_PHY>;
+ reset-names = "phy";
+ phys = <&mipi_analog_dphy>;
+ phy-names = "analog";
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
usb3_pcie_phy: phy@46000 {
compatible = "amlogic,g12a-usb3-pcie-phy";
reg = <0x0 0x46000 0x0 0x2000>;
@@ -2152,6 +2171,15 @@ hdmi_tx_out: endpoint {
remote-endpoint = <&hdmi_tx_in>;
};
};
+
+ /* DPI output port */
+ dpi_port: port@2 {
+ reg = <2>;
+
+ dpi_out: endpoint {
+ remote-endpoint = <&mipi_dsi_in>;
+ };
+ };
};
gic: interrupt-controller@ffc01000 {
@@ -2189,6 +2217,48 @@ gpio_intc: interrupt-controller@f080 {
amlogic,channel-interrupts = <64 65 66 67 68 69
70 71>;
};
+ mipi_dsi: dsi@7000 {
+ compatible = "amlogic,meson-g12a-dw-mipi-dsi";
+ reg = <0x0 0x7000 0x0 0x1000>;
+ resets = <&reset RESET_MIPI_DSI_HOST>;
+ reset-names = "top";
+ clocks = <&clkc CLKID_MIPI_DSI_HOST>,
+<&clkc CLKID_MIPI_DSI_PXCLK>,
+<&clkc CLKID_CTS_ENCL>;
+ clock-names = "pclk", "bit", "px";
+ phys = <&mipi_dphy>;
+ phy-names = "dphy";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ assigned-clocks = <&clkc
CLKID_MIPI_DSI_PXCLK_SEL>,
+<&clkc CLKID_CTS_ENCL_SEL>,
+<&clkc CLKID_VCLK2_SEL>;
+ assigned-clock-parents = <&clkc CLKID_GP0_PLL>,
+<&clkc CLKID_VCLK2_DIV1>,
+<&clkc CLKID_GP0_PLL>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* VPU VENC Input */
+ mipi_dsi_venc_port: port@0 {
+ reg = <0>;
+
+ mipi_dsi_in: endpoint {
+ remote-endpoint =
<&dpi_out>;
+ };
+ };
+
+ /* DSI Output */
+ mipi_dsi_panel_port: port@1 {
+ reg = <1>;
+ };
+ };
+
[PATCH v10 2/7] clk: meson: add vclk driver
The VCLK and VCLK_DIV clocks have supplementary bits.
The VCLK gate has a "SOFT RESET" bit to toggle after the whole
VCLK sub-tree rate has been set, this is implemented in
the gate enable callback.
The VCLK_DIV clocks as enable and reset bits used to disable
and reset the divider, associated with CLK_SET_RATE_GATE it ensures
the rate is set while the divider is disabled and in reset mode.
The VCLK_DIV enable bit isn't implemented as a gate since it's part
of the divider logic and vendor does this exact sequence to ensure
the divider is correctly set.
Signed-off-by: Neil Armstrong
---
drivers/clk/meson/Kconfig | 4 ++
drivers/clk/meson/Makefile | 1 +
drivers/clk/meson/vclk.c | 141 +
drivers/clk/meson/vclk.h | 51
4 files changed, 197 insertions(+)
diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
index 29ffd14d267b..8a9823789fa3 100644
--- a/drivers/clk/meson/Kconfig
+++ b/drivers/clk/meson/Kconfig
@@ -30,6 +30,10 @@ config COMMON_CLK_MESON_VID_PLL_DIV
tristate
select COMMON_CLK_MESON_REGMAP
+config COMMON_CLK_MESON_VCLK
+ tristate
+ select COMMON_CLK_MESON_REGMAP
+
config COMMON_CLK_MESON_CLKC_UTILS
tristate
diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
index 9ee4b954c896..9ba43fe7a07a 100644
--- a/drivers/clk/meson/Makefile
+++ b/drivers/clk/meson/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_COMMON_CLK_MESON_PLL) += clk-pll.o
obj-$(CONFIG_COMMON_CLK_MESON_REGMAP) += clk-regmap.o
obj-$(CONFIG_COMMON_CLK_MESON_SCLK_DIV) += sclk-div.o
obj-$(CONFIG_COMMON_CLK_MESON_VID_PLL_DIV) += vid-pll-div.o
+obj-$(CONFIG_COMMON_CLK_MESON_VCLK) += vclk.o
# Amlogic Clock controllers
diff --git a/drivers/clk/meson/vclk.c b/drivers/clk/meson/vclk.c
new file mode 100644
index ..3ea813a0a995
--- /dev/null
+++ b/drivers/clk/meson/vclk.c
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2024 Neil Armstrong
+ */
+
+#include
+#include "vclk.h"
+
+/* The VCLK gate has a supplementary reset bit to pulse after ungating */
+
+static inline struct meson_vclk_gate_data *
+clk_get_meson_vclk_gate_data(struct clk_regmap *clk)
+{
+ return (struct meson_vclk_gate_data *)clk->data;
+}
+
+static int meson_vclk_gate_enable(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
+
+ meson_parm_write(clk->map, &vclk->enable, 1);
+
+ /* Do a reset pulse */
+ meson_parm_write(clk->map, &vclk->reset, 1);
+ meson_parm_write(clk->map, &vclk->reset, 0);
+
+ return 0;
+}
+
+static void meson_vclk_gate_disable(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
+
+ meson_parm_write(clk->map, &vclk->enable, 0);
+}
+
+static int meson_vclk_gate_is_enabled(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
+
+ return meson_parm_read(clk->map, &vclk->enable);
+}
+
+const struct clk_ops meson_vclk_gate_ops = {
+ .enable = meson_vclk_gate_enable,
+ .disable = meson_vclk_gate_disable,
+ .is_enabled = meson_vclk_gate_is_enabled,
+};
+EXPORT_SYMBOL_GPL(meson_vclk_gate_ops);
+
+/* The VCLK Divider has supplementary reset & enable bits */
+
+static inline struct meson_vclk_div_data *
+clk_get_meson_vclk_div_data(struct clk_regmap *clk)
+{
+ return (struct meson_vclk_div_data *)clk->data;
+}
+
+static unsigned long meson_vclk_div_recalc_rate(struct clk_hw *hw,
+unsigned long prate)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
+
+ return divider_recalc_rate(hw, prate, meson_parm_read(clk->map,
&vclk->div),
+ vclk->table, vclk->flags, vclk->div.width);
+}
+
+static int meson_vclk_div_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
+
+ return divider_determine_rate(hw, req, vclk->table, vclk->div.width,
+ vclk->flags);
+}
+
+static int meson_vclk_div_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
+ int ret;
+
+ ret = divider_get_val(rate, parent_rate, vclk->table, vclk->div.width,
+ vclk->flags);
+ if (ret < 0)
+ return ret;
+
+ meson
[PATCH v10 3/7] clk: meson: g12a: make VCLK2 and ENCL clock path configurable by CCF
In order to setup the DSI clock, let's make the unused VCLK2 clock path
configuration via CCF.
The nocache option is removed from following clocks:
- vclk2_sel
- vclk2_input
- vclk2_div
- vclk2
- vclk_div1
- vclk2_div2_en
- vclk2_div4_en
- vclk2_div6_en
- vclk2_div12_en
- vclk2_div2
- vclk2_div4
- vclk2_div6
- vclk2_div12
- cts_encl_sel
vclk2 and vclk2_div uses the newly introduced vclk regmap driver
to handle the enable and reset bits.
In order to set a rate on cts_encl via the vclk2 clock path,
the NO_REPARENT flag is set on cts_encl_sel & vclk2_sel in order
to keep CCF from selection a parent.
The parents of cts_encl_sel & vclk2_sel are expected to be defined
in DT or manually set by the display driver at some point.
The following clock scheme is to be used for DSI:
xtal
\_ gp0_pll_dco
\_ gp0_pll
|- vclk2_sel
| \_ vclk2_input
| \_ vclk2_div
|\_ vclk2
| \_ vclk2_div1
| \_ cts_encl_sel
| \_ cts_encl -> to VPU LCD Encoder
|- mipi_dsi_pxclk_sel
\_ mipi_dsi_pxclk_div
\_ mipi_dsi_pxclk -> to DSI controller
The mipi_dsi_pxclk_div is set as bypass with a single /1 entry in div_table
in order to use the same GP0 for mipi_dsi_pxclk and vclk2_input.
The SET_RATE_PARENT is only set on the mipi_dsi_pxclk_sel clock so the
DSI bitclock is the reference base clock to calculate the vclk2_div value
when pixel clock is set on the cts_encl endpoint.
Signed-off-by: Neil Armstrong
---
drivers/clk/meson/Kconfig | 1 +
drivers/clk/meson/g12a.c | 72 ++-
2 files changed, 53 insertions(+), 20 deletions(-)
diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
index 8a9823789fa3..59a40a49f8e1 100644
--- a/drivers/clk/meson/Kconfig
+++ b/drivers/clk/meson/Kconfig
@@ -144,6 +144,7 @@ config COMMON_CLK_G12A
select COMMON_CLK_MESON_EE_CLKC
select COMMON_CLK_MESON_CPU_DYNDIV
select COMMON_CLK_MESON_VID_PLL_DIV
+ select COMMON_CLK_MESON_VCLK
select MFD_SYSCON
help
Support for the clock controller on Amlogic S905D2, S905X2 and S905Y2
diff --git a/drivers/clk/meson/g12a.c b/drivers/clk/meson/g12a.c
index 90f4c6103014..083882e53b65 100644
--- a/drivers/clk/meson/g12a.c
+++ b/drivers/clk/meson/g12a.c
@@ -22,6 +22,7 @@
#include "clk-regmap.h"
#include "clk-cpu-dyndiv.h"
#include "vid-pll-div.h"
+#include "vclk.h"
#include "meson-eeclk.h"
#include "g12a.h"
@@ -3165,7 +3166,7 @@ static struct clk_regmap g12a_vclk2_sel = {
.ops = &clk_regmap_mux_ops,
.parent_hws = g12a_vclk_parent_hws,
.num_parents = ARRAY_SIZE(g12a_vclk_parent_hws),
- .flags = CLK_SET_RATE_NO_REPARENT | CLK_GET_RATE_NOCACHE,
+ .flags = CLK_SET_RATE_NO_REPARENT,
},
};
@@ -3193,7 +3194,6 @@ static struct clk_regmap g12a_vclk2_input = {
.ops = &clk_regmap_gate_ops,
.parent_hws = (const struct clk_hw *[]) { &g12a_vclk2_sel.hw },
.num_parents = 1,
- .flags = CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED,
},
};
@@ -3215,19 +3215,32 @@ static struct clk_regmap g12a_vclk_div = {
};
static struct clk_regmap g12a_vclk2_div = {
- .data = &(struct clk_regmap_div_data){
- .offset = HHI_VIID_CLK_DIV,
- .shift = 0,
- .width = 8,
+ .data = &(struct meson_vclk_div_data){
+ .div = {
+ .reg_off = HHI_VIID_CLK_DIV,
+ .shift = 0,
+ .width = 8,
+ },
+ .enable = {
+ .reg_off = HHI_VIID_CLK_DIV,
+ .shift = 16,
+ .width = 1,
+ },
+ .reset = {
+ .reg_off = HHI_VIID_CLK_DIV,
+ .shift = 17,
+ .width = 1,
+ },
+ .flags = CLK_DIVIDER_ROUND_CLOSEST,
},
.hw.init = &(struct clk_init_data){
.name = "vclk2_div",
- .ops = &clk_regmap_divider_ops,
+ .ops = &meson_vclk_div_ops,
.parent_hws = (const struct clk_hw *[]) {
&g12a_vclk2_input.hw
},
.num_parents = 1,
- .flags = CLK_GET_RATE_NOCACHE,
+ .flags = CLK_SET_RATE_GATE,
},
};
@@ -3246,16 +3259,24 @@ static struct clk_regmap g12a_vclk = {
};
static struct clk_regmap g12a_vclk2 = {
- .data = &(struct clk_regmap_gate_data){
- .offset = HHI_VIID_CLK_CNTL,
- .bit_idx = 19,
+ .data = &(struct meson_vclk_gate_data){
+ .enable = {
+ .reg_off = HHI_VIID_CLK_CNTL,
+ .shift = 19,
+ .width = 1,
+
[PATCH v10 1/7] dt-bindings: arm: amlogic: Document the MNT Reform 2 CM4 adapter with a BPI-CM4 Module
The MNT Reform 2 CM4 adapter can be populated with any Raspberry Pi CM4 compatible module such as a BPI-CM4 Module, document that. Acked-by: Conor Dooley Signed-off-by: Neil Armstrong --- Documentation/devicetree/bindings/arm/amlogic.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index caab7ceeda45..2154a4614fda 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -164,6 +164,7 @@ properties: items: - enum: - bananapi,bpi-cm4io + - mntre,reform2-cm4 - const: bananapi,bpi-cm4 - const: amlogic,a311d - const: amlogic,g12b -- 2.34.1
[PATCH v10 0/7] drm/meson: add support for MIPI DSI Display
The Amlogic G12A, G12B & SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 1.21a), with a custom glue managing the IP resets, clock and data input similar to the DW-HDMI glue on the same Amlogic SoCs. This is a follow-up of v5 now the DRM patches are applied, the clk & DT changes remains for a full DSI support on G12A & SM1 platforms. The DW-MIPI-DSI transceiver + D-PHY are clocked by the GP0 PLL, and the ENCL encoder + VIU pixel reader by the VCLK2 clock using the HDMI PLL. The DW-MIPI-DSI transceiver gets this pixel stream as input clocked with the VCLK2 clock. An optional "MEAS" clock can be enabled to measure the delay between each vsync feeding the DW-MIPI-DSI transceiver. The clock setup has been redesigned to use CCF, a common PLL (GP0) and the VCLK2 clock path for DSI in preparation of full CCF support and possibly dual display with HDMI. The change from v5 is that now we use a "VCLK" driver instead of notifier and rely on CLK_SET_RATE_GATE to ensure the VCLK gate operation are called. Signed-off-by: Neil Armstrong --- Changes in v10: - Rename regmap_vclk to meson_clk and add _gate for the gate - Move COMMON_CLK_MESON_VCLK to following patch - Remove CLK_SET_RATE_PARENT from g12a_vclk2_sel, keep it only on mipi_dsi_pxclk_sel - Add more info on commit message to specify how clock setup is designed - Remove forgotten CLK_IGNORE_UNUSED on g12a_vclk2_input - Remove useless CLK_SET_RATE_PARENT on g12a_vclk2_div to stop propagatting rate _after_ vclk2_div - Remove invalid CLK_SET_RATE_GATE on g12a_vclk2 since it's not a divider... - Drop already applied patches - move Khadas TS050 changes as an overlay - Link to v9: https://lore.kernel.org/r/20231124-amlogic-v6-4-upstream-dsi-ccf-vim3-v9-0-95256ed13...@linaro.org Changes in v9: - Colledte reviewed-bys - Fixed patches 2 & 4, commit messages and bindings format - Link to v8: https://lore.kernel.org/r/20231109-amlogic-v6-4-upstream-dsi-ccf-vim3-v8-0-81e4aeeda...@linaro.org Changes in v8: - Switch vclk clk driver to parm as requested by Jerome - Added bindings fixes to amlogic,meson-axg-mipi-pcie-analog & amlogic,g12a-mipi-dphy-analog - Fixed DT errors in vim3 example and MNT Reform DT - Rebased on next-20231107, successfully tested on VIM3L - Link to v7: https://lore.kernel.org/r/20230803-amlogic-v6-4-upstream-dsi-ccf-vim3-v7-0-762219fc5...@linaro.org Changes in v7: - Added review tags - Fixed patch 5 thanks to George - Link to v6: https://lore.kernel.org/r/20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v6-0-fd2ac9845...@linaro.org Changes in v6: - dropped applied DRM patches - dropped clk private prefix patches - rebased on top of 20230607-topic-amlogic-upstream-clkid-public-migration-v2-0-38172d17c...@linaro.org - re-ordered/cleaned ENCL patches to match clkid public migration - Added new "vclk" driver - uses vclk driver instead of notifier - cleaned VCLK2 clk flags - add px_clk gating from DSI driver - Link to v5: https://lore.kernel.org/r/20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v5-0-56eb7a4d5...@linaro.org Changes in v5: - Aded PRIV all the G12 internal clk IDS to simplify public exposing - Fixed the DSI bindings - Fixed the DSI HSYNC/VSYNC polarity handling - Fixed the DSI clock setup - Fixed the DSI phy timings - Dropped components for DSI, only keeping it for HDMI - Added MNT Reform 2 CM4 DT - Dropped already applied PHY fix - Link to v4: https://lore.kernel.org/r/20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v4-0-2592c29ea...@linaro.org Changes from v3 at [3]: - switched all clk setup via CCF - using single PLL for DSI controller & ENCL encoder - added ENCL clocks to CCF - make the VCLK2 clocks configuration by CCF - fixed probe/bind of DSI controller to work with panels & bridges - added bit_clk to controller to it can setup the BIT clock aswell - added fix for components unbind - added fix for analog phy setup value - added TS050 timings fix - dropped previous clk control patch Changes from v2 at [2]: - Fixed patch 3 - Added reviews from Jagan - Rebased on v5.19-rc1 Changes from v1 at [1]: - fixed DSI host bindings - add reviewed-by tags for bindings - moved magic values to defines thanks to Martin's searches - added proper prefixes to defines - moved phy_configure to phy_init() dw-mipi-dsi callback - moved phy_on to a new phy_power_on() dw-mipi-dsi callback - correctly return phy_init/configure errors to callback returns [1] https://lore.kernel.org/r/20200907081825.1654-1-narmstr...@baylibre.com [2] https://lore.kernel.org/r/20220120083357.1541262-1-narmstr...@baylibre.com [3] https://lore.kernel.org/r/20220617072723.1742668-1-narmstr...@baylibre.com --- Neil Armstrong (7): dt-bindings: arm: amlogic: Document the MNT Reform 2 CM4 adapter with a BPI-CM4 Module clk: meson: add vclk driver clk: meson: g12a: make VCLK2 and ENCL clock path configurable by CCF drm/meson: gate px_clk when setting rate arm64: meson: g12-common: add the MIPI DSI nodes arm64: meson: khadas-vim3l
Re: [PATCH 12/19] drm/i915/dp: Add DP tunnel atomic state and check BW limit
On Mon, Feb 05, 2024 at 06:11:00PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 23, 2024 at 12:28:43PM +0200, Imre Deak wrote:
> > Add the atomic state during a modeset required to enable the DP tunnel
> > BW allocation mode on links where such a tunnel was detected.
> >
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/display/intel_atomic.c | 8
> > drivers/gpu/drm/i915/display/intel_display.c | 19 +++
> > drivers/gpu/drm/i915/display/intel_link_bw.c | 5 +
> > 3 files changed, 32 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> > b/drivers/gpu/drm/i915/display/intel_atomic.c
> > index 96ab37e158995..4236740ede9ed 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> > @@ -260,6 +260,10 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> > if (crtc_state->post_csc_lut)
> > drm_property_blob_get(crtc_state->post_csc_lut);
> >
> > + if (crtc_state->dp_tunnel_ref.tunnel)
> > + drm_dp_tunnel_ref_get(old_crtc_state->dp_tunnel_ref.tunnel,
>
> I'd probably s/old_crtc_state/crtc_state/ here. Same pointer, but
> looks out of place given everyone else just operates on 'crtc_state'
> here.
Ok, will change that.
> > + &crtc_state->dp_tunnel_ref);
>
> Shame we have to have this ref wrapper. But I guess no clean
> way to have a magic tracked pointer type that works like a
> normal pointer in C...
I suppose returning a pointer to a kmalloced drm_dp_tunnel_ref from
drm_tunnel_get() and freeing this in drm_tunnel_put() would be one way,
but that imo defeats the purpose of the tracker information being valid
even after put() (so that ref_tracker can print information about where
a particular reference was already dropped).
>
> > +
> > crtc_state->update_pipe = false;
> > crtc_state->update_m_n = false;
> > crtc_state->update_lrr = false;
> > @@ -311,6 +315,8 @@ intel_crtc_destroy_state(struct drm_crtc *crtc,
> >
> > __drm_atomic_helper_crtc_destroy_state(&crtc_state->uapi);
> > intel_crtc_free_hw_state(crtc_state);
> > + if (crtc_state->dp_tunnel_ref.tunnel)
> > + drm_dp_tunnel_ref_put(&crtc_state->dp_tunnel_ref);
> > kfree(crtc_state);
> > }
> >
> > @@ -346,6 +352,8 @@ void intel_atomic_state_clear(struct drm_atomic_state
> > *s)
> > /* state->internal not reset on purpose */
> >
> > state->dpll_set = state->modeset = false;
> > +
> > + intel_dp_tunnel_atomic_cleanup_inherited_state(state);
>
> This seems to be in the wrong patch?
Yes, I guess a more logical place is in
[PATCH 14/19] drm/i915/dp: Compute DP tunel BW during encoder state computation
where the state is added, will move it there.
>
> > }
> >
> > struct intel_crtc_state *
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index b9f985a5e705b..46b27a32c8640 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -33,6 +33,7 @@
> > #include
> >
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -73,6 +74,7 @@
> > #include "intel_dp.h"
> > #include "intel_dp_link_training.h"
> > #include "intel_dp_mst.h"
> > +#include "intel_dp_tunnel.h"
> > #include "intel_dpll.h"
> > #include "intel_dpll_mgr.h"
> > #include "intel_dpt.h"
> > @@ -4490,6 +4492,8 @@ copy_bigjoiner_crtc_state_modeset(struct
> > intel_atomic_state *state,
> > saved_state->crc_enabled = slave_crtc_state->crc_enabled;
> >
> > intel_crtc_free_hw_state(slave_crtc_state);
> > + if (slave_crtc_state->dp_tunnel_ref.tunnel)
> > + drm_dp_tunnel_ref_put(&slave_crtc_state->dp_tunnel_ref);
> > memcpy(slave_crtc_state, saved_state, sizeof(*slave_crtc_state));
> > kfree(saved_state);
> >
> > @@ -4505,6 +4509,10 @@ copy_bigjoiner_crtc_state_modeset(struct
> > intel_atomic_state *state,
> > &master_crtc_state->hw.adjusted_mode);
> > slave_crtc_state->hw.scaling_filter =
> > master_crtc_state->hw.scaling_filter;
> >
> > + if (master_crtc_state->dp_tunnel_ref.tunnel)
> > + drm_dp_tunnel_ref_get(master_crtc_state->dp_tunnel_ref.tunnel,
> > + &slave_crtc_state->dp_tunnel_ref);
> > +
> > copy_bigjoiner_crtc_state_nomodeset(state, slave_crtc);
> >
> > slave_crtc_state->uapi.mode_changed =
> > master_crtc_state->uapi.mode_changed;
> > @@ -4533,6 +4541,13 @@ intel_crtc_prepare_cleared_state(struct
> > intel_atomic_state *state,
> > /* free the old crtc_state->hw members */
> > intel_crtc_free_hw_state(crtc_state);
> >
> > + if (crtc_state->dp_tunnel_ref.tunnel) {
> > + drm_dp_tunnel_atomic_set_stream_bw(&state->base,
> > +
> > crtc_state->dp_tunnel_ref.tunnel,
> > +
Re: [PATCH v2 1/6] clk: sunxi-ng: nkm: Support constraints on m/n ratio and parent rate
Hi Jernej,
On 2024-02-05 at 18:45:27 +0100, Jernej Škrabec
wrote:
> Dne ponedeljek, 05. februar 2024 ob 16:22:24 CET je Frank Oltmanns napisal(a):
>> The Allwinner A64 manual lists the following constraints for the
>> PLL-MIPI clock:
>> - M/N <= 3
>> - (PLL_VIDEO0)/M >= 24MHz
>>
>> The PLL-MIPI clock is implemented as ccu_nkm. Therefore, add support for
>> these constraints.
>>
>> Signed-off-by: Frank Oltmanns
>
> Haven't we discussed that this patch is unnecessary because same effect can
> be reached by limiting minimum frequency?
The patch for ccu_nm was unnecessary:
https://lore.kernel.org/all/87jzoug2jz@oltmanns.dev/
Unfortunately, we still need this one.
Best regards,
Frank
>
> Best regards,
> Jernej
>
>> ---
>> drivers/clk/sunxi-ng/ccu_nkm.c | 21 +
>> drivers/clk/sunxi-ng/ccu_nkm.h | 2 ++
>> 2 files changed, 23 insertions(+)
>>
>> diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
>> index 853f84398e2b..1168d894d636 100644
>> --- a/drivers/clk/sunxi-ng/ccu_nkm.c
>> +++ b/drivers/clk/sunxi-ng/ccu_nkm.c
>> @@ -16,6 +16,20 @@ struct _ccu_nkm {
>> unsigned long m, min_m, max_m;
>> };
>>
>> +static bool ccu_nkm_is_valid_rate(struct ccu_common *common, unsigned long
>> parent,
>> + unsigned long n, unsigned long m)
>> +{
>> +struct ccu_nkm *nkm = container_of(common, struct ccu_nkm, common);
>> +
>> +if (nkm->max_m_n_ratio && (m > nkm->max_m_n_ratio * n))
>> +return false;
>> +
>> +if (nkm->min_parent_m_ratio && (parent < nkm->min_parent_m_ratio * m))
>> +return false;
>> +
>> +return true;
>> +}
>> +
>> static unsigned long ccu_nkm_find_best_with_parent_adj(struct ccu_common
>> *common,
>> struct clk_hw *parent_hw,
>> unsigned long *parent,
>> unsigned long rate,
>> @@ -31,6 +45,10 @@ static unsigned long
>> ccu_nkm_find_best_with_parent_adj(struct ccu_common *common
>> unsigned long tmp_rate, tmp_parent;
>>
>> tmp_parent = clk_hw_round_rate(parent_hw, rate
>> * _m / (_n * _k));
>> +
>> +if (!ccu_nkm_is_valid_rate(common, tmp_parent,
>> _n, _m))
>> +continue;
>> +
>> tmp_rate = tmp_parent * _n * _k / _m;
>>
>> if (ccu_is_better_rate(common, rate, tmp_rate,
>> best_rate) ||
>> @@ -64,6 +82,9 @@ static unsigned long ccu_nkm_find_best(unsigned long
>> parent, unsigned long rate,
>> for (_k = nkm->min_k; _k <= nkm->max_k; _k++) {
>> for (_n = nkm->min_n; _n <= nkm->max_n; _n++) {
>> for (_m = nkm->min_m; _m <= nkm->max_m; _m++) {
>> +if (!ccu_nkm_is_valid_rate(common, parent, _n,
>> _m))
>> +continue;
>> +
>> unsigned long tmp_rate;
>>
>> tmp_rate = parent * _n * _k / _m;
>> diff --git a/drivers/clk/sunxi-ng/ccu_nkm.h b/drivers/clk/sunxi-ng/ccu_nkm.h
>> index 6601defb3f38..c409212ee40e 100644
>> --- a/drivers/clk/sunxi-ng/ccu_nkm.h
>> +++ b/drivers/clk/sunxi-ng/ccu_nkm.h
>> @@ -27,6 +27,8 @@ struct ccu_nkm {
>> struct ccu_mux_internal mux;
>>
>> unsigned intfixed_post_div;
>> +unsigned long max_m_n_ratio;
>> +unsigned long min_parent_m_ratio;
>>
>> struct ccu_common common;
>> };
>>
>>
Re: [PATCH v2 1/6] clk: sunxi-ng: nkm: Support constraints on m/n ratio and parent rate
Dne ponedeljek, 05. februar 2024 ob 16:22:24 CET je Frank Oltmanns napisal(a):
> The Allwinner A64 manual lists the following constraints for the
> PLL-MIPI clock:
> - M/N <= 3
> - (PLL_VIDEO0)/M >= 24MHz
>
> The PLL-MIPI clock is implemented as ccu_nkm. Therefore, add support for
> these constraints.
>
> Signed-off-by: Frank Oltmanns
Haven't we discussed that this patch is unnecessary because same effect can
be reached by limiting minimum frequency?
Best regards,
Jernej
> ---
> drivers/clk/sunxi-ng/ccu_nkm.c | 21 +
> drivers/clk/sunxi-ng/ccu_nkm.h | 2 ++
> 2 files changed, 23 insertions(+)
>
> diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
> index 853f84398e2b..1168d894d636 100644
> --- a/drivers/clk/sunxi-ng/ccu_nkm.c
> +++ b/drivers/clk/sunxi-ng/ccu_nkm.c
> @@ -16,6 +16,20 @@ struct _ccu_nkm {
> unsigned long m, min_m, max_m;
> };
>
> +static bool ccu_nkm_is_valid_rate(struct ccu_common *common, unsigned long
> parent,
> + unsigned long n, unsigned long m)
> +{
> + struct ccu_nkm *nkm = container_of(common, struct ccu_nkm, common);
> +
> + if (nkm->max_m_n_ratio && (m > nkm->max_m_n_ratio * n))
> + return false;
> +
> + if (nkm->min_parent_m_ratio && (parent < nkm->min_parent_m_ratio * m))
> + return false;
> +
> + return true;
> +}
> +
> static unsigned long ccu_nkm_find_best_with_parent_adj(struct ccu_common
> *common,
> struct clk_hw *parent_hw,
> unsigned long *parent,
> unsigned long rate,
> @@ -31,6 +45,10 @@ static unsigned long
> ccu_nkm_find_best_with_parent_adj(struct ccu_common *common
> unsigned long tmp_rate, tmp_parent;
>
> tmp_parent = clk_hw_round_rate(parent_hw, rate
> * _m / (_n * _k));
> +
> + if (!ccu_nkm_is_valid_rate(common, tmp_parent,
> _n, _m))
> + continue;
> +
> tmp_rate = tmp_parent * _n * _k / _m;
>
> if (ccu_is_better_rate(common, rate, tmp_rate,
> best_rate) ||
> @@ -64,6 +82,9 @@ static unsigned long ccu_nkm_find_best(unsigned long
> parent, unsigned long rate,
> for (_k = nkm->min_k; _k <= nkm->max_k; _k++) {
> for (_n = nkm->min_n; _n <= nkm->max_n; _n++) {
> for (_m = nkm->min_m; _m <= nkm->max_m; _m++) {
> + if (!ccu_nkm_is_valid_rate(common, parent, _n,
> _m))
> + continue;
> +
> unsigned long tmp_rate;
>
> tmp_rate = parent * _n * _k / _m;
> diff --git a/drivers/clk/sunxi-ng/ccu_nkm.h b/drivers/clk/sunxi-ng/ccu_nkm.h
> index 6601defb3f38..c409212ee40e 100644
> --- a/drivers/clk/sunxi-ng/ccu_nkm.h
> +++ b/drivers/clk/sunxi-ng/ccu_nkm.h
> @@ -27,6 +27,8 @@ struct ccu_nkm {
> struct ccu_mux_internal mux;
>
> unsigned intfixed_post_div;
> + unsigned long max_m_n_ratio;
> + unsigned long min_parent_m_ratio;
>
> struct ccu_common common;
> };
>
>
Re: [PATCH v9 07/12] clk: meson: add vclk driver
On 27/11/2023 17:24, Jerome Brunet wrote:
On Mon 27 Nov 2023 at 17:14, Neil Armstrong wrote:
On 24/11/2023 15:41, Jerome Brunet wrote:
On Fri 24 Nov 2023 at 09:41, Neil Armstrong
wrote:
The VCLK and VCLK_DIV clocks have supplementary bits.
The VCLK has a "SOFT RESET" bit to toggle after the whole
VCLK sub-tree rate has been set, this is implemented in
the gate enable callback.
The VCLK_DIV clocks as enable and reset bits used to disable
and reset the divider, associated with CLK_SET_RATE_GATE it ensures
the rate is set while the divider is disabled and in reset mode.
The VCLK_DIV enable bit isn't implemented as a gate since it's part
of the divider logic and vendor does this exact sequence to ensure
the divider is correctly set.
Signed-off-by: Neil Armstrong
---
drivers/clk/meson/Kconfig | 5 ++
drivers/clk/meson/Makefile | 1 +
drivers/clk/meson/vclk.c | 141
+
drivers/clk/meson/vclk.h | 51
4 files changed, 198 insertions(+)
diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
index 29ffd14d267b..59a40a49f8e1 100644
--- a/drivers/clk/meson/Kconfig
+++ b/drivers/clk/meson/Kconfig
@@ -30,6 +30,10 @@ config COMMON_CLK_MESON_VID_PLL_DIV
tristate
select COMMON_CLK_MESON_REGMAP
+config COMMON_CLK_MESON_VCLK
+ tristate
+ select COMMON_CLK_MESON_REGMAP
+
config COMMON_CLK_MESON_CLKC_UTILS
tristate
@@ -140,6 +144,7 @@ config COMMON_CLK_G12A
select COMMON_CLK_MESON_EE_CLKC
select COMMON_CLK_MESON_CPU_DYNDIV
select COMMON_CLK_MESON_VID_PLL_DIV
+ select COMMON_CLK_MESON_VCLK
This particular line belong in the next patch
select MFD_SYSCON
help
Support for the clock controller on Amlogic S905D2, S905X2 and S905Y2
diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
index 9ee4b954c896..9ba43fe7a07a 100644
--- a/drivers/clk/meson/Makefile
+++ b/drivers/clk/meson/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_COMMON_CLK_MESON_PLL) += clk-pll.o
obj-$(CONFIG_COMMON_CLK_MESON_REGMAP) += clk-regmap.o
obj-$(CONFIG_COMMON_CLK_MESON_SCLK_DIV) += sclk-div.o
obj-$(CONFIG_COMMON_CLK_MESON_VID_PLL_DIV) += vid-pll-div.o
+obj-$(CONFIG_COMMON_CLK_MESON_VCLK) += vclk.o
# Amlogic Clock controllers
diff --git a/drivers/clk/meson/vclk.c b/drivers/clk/meson/vclk.c
new file mode 100644
index ..47f08a52b49f
--- /dev/null
+++ b/drivers/clk/meson/vclk.c
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 Neil Armstrong
+ */
+
+#include
+#include "vclk.h"
+
+/* The VCLK gate has a supplementary reset bit to pulse after ungating */
+
+static inline struct clk_regmap_vclk_data *
+clk_get_regmap_vclk_data(struct clk_regmap *clk)
+{
+ return (struct clk_regmap_vclk_data *)clk->data;
+}
+
+static int clk_regmap_vclk_enable(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct clk_regmap_vclk_data *vclk = clk_get_regmap_vclk_data(clk);
+
+ meson_parm_write(clk->map, &vclk->enable, 1);
+
+ /* Do a reset pulse */
+ meson_parm_write(clk->map, &vclk->reset, 1);
+ meson_parm_write(clk->map, &vclk->reset, 0);
+
+ return 0;
+}
+
+static void clk_regmap_vclk_disable(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct clk_regmap_vclk_data *vclk = clk_get_regmap_vclk_data(clk);
+
+ meson_parm_write(clk->map, &vclk->enable, 0);
+}
+
+static int clk_regmap_vclk_is_enabled(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct clk_regmap_vclk_data *vclk = clk_get_regmap_vclk_data(clk);
+
+ return meson_parm_read(clk->map, &vclk->enable);
+}
+
+const struct clk_ops clk_regmap_vclk_ops = {
+ .enable = clk_regmap_vclk_enable,
+ .disable = clk_regmap_vclk_disable,
+ .is_enabled = clk_regmap_vclk_is_enabled,
+};
+EXPORT_SYMBOL_GPL(clk_regmap_vclk_ops);
s/clk_regmap_vclk/meson_vclk at least for what is exported, ideally most
all the code.
I get clk_regmap_ comes from code copied from clk_regmap.c.
The reason the this part is different (and not using parm) if that when
I converted amlogic to regmap, I hope we could make this generic,
possibly converging between aml and qcom (which was the only other
platform using regmap for clock at the time). This is why clk_regmap.c
is a bit different from the other driver.
For the aml specific drivers, best to look at the mpll or cpu-dyndiv one.
+
+/* The VCLK Divider has supplementary reset & enable bits */
+
+static inline struct clk_regmap_vclk_div_data *
+clk_get_regmap_vclk_div_data(struct clk_regmap *clk)
+{
+ return (struct clk_regmap_vclk_div_data *)clk->data;
+}
+
+static unsigned long clk_regmap_vclk_div_recalc_rate(struct clk_hw *hw,
+unsigned long prate)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+
Re: [PATCH 02/19] drm/dp: Add support for DP tunneling
On Mon, Feb 05, 2024 at 06:13:30PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 31, 2024 at 08:49:16PM +0200, Imre Deak wrote:
> > On Wed, Jan 31, 2024 at 06:09:04PM +0200, Ville Syrjälä wrote:
> > > On Tue, Jan 23, 2024 at 12:28:33PM +0200, Imre Deak wrote:
> > > > +static void untrack_tunnel_ref(struct drm_dp_tunnel *tunnel,
> > > > + struct ref_tracker **tracker)
> > > > +{
> > > > + ref_tracker_free(&tunnel->group->mgr->ref_tracker,
> > > > +tracker);
> > > > +}
> > > > +
> > > > +struct drm_dp_tunnel *
> > > > +drm_dp_tunnel_get_untracked(struct drm_dp_tunnel *tunnel)
> > > > +{
> > > > + track_tunnel_ref(tunnel, NULL);
> > > > +
> > > > + return tunnel_get(tunnel);
> > > > +}
> > > > +EXPORT_SYMBOL(drm_dp_tunnel_get_untracked);
> > >
> > > Why do these exist?
> >
> > They implement drm_dp_tunnel_get()/put() if
> > CONFIG_DRM_DISPLAY_DEBUG_DP_TUNNEL_STATE=n.
>
> Why does that kind of irrelevant detail need to be visible
> in the exported api?
In non-debug builds the ref_tracker object isn't needed and so
drm_dp_tunnel_ref won't contain a pointer to it either.
drm_dp_tunnel_get/put_untracked() provide a way to get/put a tunnel
reference without having to pass a ref_tracker pointer.
>
> --
> Ville Syrjälä
> Intel
Re: [PATCH] nouveau/gsp: use correct size for registry rpc.
On 1/30/24 04:26, Dave Airlie wrote:
From: Dave Airlie
Timur pointed this out before, and it just slipped my mind,
but this might help some things work better, around pcie power
management.
Fixes: 8d55b0a940bb ("nouveau/gsp: add some basic registry entries.")
Signed-off-by: Dave Airlie
Added stable CC for v6.7 and applied it to drm-misc-fixes.
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
index 9ee58e2a0eb2..5e1fa176aac4 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
@@ -1078,7 +1078,6 @@ r535_gsp_rpc_set_registry(struct nvkm_gsp *gsp)
if (IS_ERR(rpc))
return PTR_ERR(rpc);
- rpc->size = sizeof(*rpc);
rpc->numEntries = NV_GSP_REG_NUM_ENTRIES;
str_offset = offsetof(typeof(*rpc), entries[NV_GSP_REG_NUM_ENTRIES]);
@@ -1094,6 +1093,7 @@ r535_gsp_rpc_set_registry(struct nvkm_gsp *gsp)
strings += name_len;
str_offset += name_len;
}
+ rpc->size = str_offset;
return nvkm_gsp_rpc_wr(gsp, rpc, false);
}
Re: [PATCH] drm/dp: Don't attempt AUX transfers when eDP panels are not powered
Hi, On Mon, Feb 5, 2024 at 3:17 AM Jani Nikula wrote: > > On Fri, 02 Feb 2024, Douglas Anderson wrote: > > If an eDP panel is not powered on then any attempts to talk to it over > > the DP AUX channel will timeout. Unfortunately these attempts may be > > quite slow. Userspace can initiate these attempts either via a > > /dev/drm_dp_auxN device or via the created i2c device. > > > > Making the DP AUX drivers timeout faster is a difficult proposition. > > In theory we could just poll the panel's HPD line in the AUX transfer > > function and immediately return an error there. However, this is > > easier said than done. For one thing, there's no hard requirement to > > hook the HPD line up for eDP panels and it's OK to just delay a fixed > > amount. For another thing, the HPD line may not be fast to probe. On > > parade-ps8640 we need to wait for the bridge chip's firmware to boot > > before we can get the HPD line and this is a slow process. > > > > The fact that the transfers are taking so long to timeout is causing > > real problems. The open source fwupd daemon sometimes scans DP busses > > looking for devices whose firmware need updating. If it happens to > > scan while a panel is turned off this scan can take a long time. The > > fwupd daemon could try to be smarter and only scan when eDP panels are > > turned on, but we can also improve the behavior in the kernel. > > > > Let's let eDP panels drivers specify that a panel is turned off and > > then modify the common AUX transfer code not to attempt a transfer in > > this case. > > I guess my question is, why not make the aux->transfer function handle > the powered down case and return the appropriate error? The basic problem is that the aux->transfer() function doesn't have knowledge of the power state of the eDP panel and that's the component whose power state matters here. The aux->transfer() function is implemented by the DP controller driver and can't access the internal state of the eDP panel driver. The traditional solution here would be to use the "HPD" pin to know if the DP device is powered and ready to accept AUX commands. That works fine for external DP devices where HPD is mandatory, but it has issues for eDP as talked about in my commit description. If nothing else, the eDP spec lists "HPD" as optional. In addition to that, however, we have additional difficulties for eDP because of the "connected but not powered on" state that eDP panels can be in. For DP if you see HPD you know that the device is connected+powered on. If you don't see HPD then the device is disconnected and/or powered off. For eDP you may power off components (like the controller / eDP panel) when the device is still physically connected and that adds complexities. Another possible solution someone could come up with would be to use the DRM state of the DP controller driver and fail all AUX commands if the DP controller isn't powered. Unfortunately this doesn't work either. Specifically at panel probe time we need to do AUX transfers even though the full DRM bridge isn't powered. We had many discussions about this on the mailing lists when coming up with the generic eDP panel driver and this is fairly well documented in the kernel-docs of the transfer() function in "struct drm_dp_aux". As documented, an eDP controller driver needs to return an error for transfer() if the panel isn't powered, but nothing says that it needs to do it quickly. The slowness is what we're trying to solve here. > For example, the transfer hook in i915 checks whether the display is > connected and bails out early if not. I'm not massively familiar with the i915 code, so I'd love a pointer to the exact code you're referring to. I took a quick look and found a Type-C specific check in intel_dp_aux_xfer(). That doesn't help here since we're not Type-C, though the comments do back up my argument that the long timeouts are something worth avoiding. After that I don't see anything obvious so I'd love a pointer. > Having to track and set the state all over the place seems more > complicated to me than dynamically checking where needed i.e. in the > transfer hook. Huh. I was actually surprised by how simple/straightforward my patch was compared to how ugly I thought it was going to be. I guess it's just a different perspective? Specifically it can be noted that there aren't many distinct eDP panel drivers out there since all but one of them was able to use the generic "panel-edp.c". However, there are quite a number of eDP controller drivers, especially considering all the bridge chips out there. That means that this short patch means we don't need to add weird logic/hacks to all of the eDP controller drivers... -Doug
Re: [PATCH] nouveau: offload fence uevents work to workqueue
On 1/29/24 02:50, Dave Airlie wrote:
From: Dave Airlie
This should break the deadlock between the fctx lock and the irq lock.
This offloads the processing off the work from the irq into a workqueue.
Signed-off-by: Dave Airlie
Nouveau's scheduler uses a dedicated wq, hence from this perspective it's
safe deferring fence signalling to the kernel global wq. However, I wonder
if we could create deadlocks by building dependency chains into other
drivers / kernel code that, by chance, makes use of the kernel global wq as
well.
Admittedly, even if, it's gonna be extremely unlikely given that
WQ_MAX_ACTIVE == 512. But maybe it'd be safer to use a dedicated wq.
Also, do we need to CC stable?
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 24 ++--
drivers/gpu/drm/nouveau/nouveau_fence.h | 1 +
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index ca762ea55413..93f08f9479d8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -103,6 +103,7 @@ nouveau_fence_context_kill(struct nouveau_fence_chan *fctx,
int error)
void
nouveau_fence_context_del(struct nouveau_fence_chan *fctx)
{
+ cancel_work_sync(&fctx->uevent_work);
nouveau_fence_context_kill(fctx, 0);
nvif_event_dtor(&fctx->event);
fctx->dead = 1;
@@ -145,12 +146,13 @@ nouveau_fence_update(struct nouveau_channel *chan, struct
nouveau_fence_chan *fc
return drop;
}
-static int
-nouveau_fence_wait_uevent_handler(struct nvif_event *event, void *repv, u32
repc)
+static void
+nouveau_fence_uevent_work(struct work_struct *work)
{
- struct nouveau_fence_chan *fctx = container_of(event, typeof(*fctx),
event);
+ struct nouveau_fence_chan *fctx = container_of(work, struct
nouveau_fence_chan,
+ uevent_work);
unsigned long flags;
- int ret = NVIF_EVENT_KEEP;
+ int drop = 0;
spin_lock_irqsave(&fctx->lock, flags);
if (!list_empty(&fctx->pending)) {
@@ -160,11 +162,20 @@ nouveau_fence_wait_uevent_handler(struct nvif_event
*event, void *repv, u32 repc
fence = list_entry(fctx->pending.next, typeof(*fence), head);
chan = rcu_dereference_protected(fence->channel,
lockdep_is_held(&fctx->lock));
if (nouveau_fence_update(chan, fctx))
- ret = NVIF_EVENT_DROP;
+ drop = 1;
}
+ if (drop)
+ nvif_event_block(&fctx->event);
+
spin_unlock_irqrestore(&fctx->lock, flags);
+}
- return ret;
+static int
+nouveau_fence_wait_uevent_handler(struct nvif_event *event, void *repv, u32
repc)
+{
+ struct nouveau_fence_chan *fctx = container_of(event, typeof(*fctx),
event);
+ schedule_work(&fctx->uevent_work);
+ return NVIF_EVENT_KEEP;
}
void
@@ -178,6 +189,7 @@ nouveau_fence_context_new(struct nouveau_channel *chan,
struct nouveau_fence_cha
} args;
int ret;
+ INIT_WORK(&fctx->uevent_work, nouveau_fence_uevent_work);
INIT_LIST_HEAD(&fctx->flip);
INIT_LIST_HEAD(&fctx->pending);
spin_lock_init(&fctx->lock);
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.h
b/drivers/gpu/drm/nouveau/nouveau_fence.h
index 64d33ae7f356..8bc065acfe35 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.h
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.h
@@ -44,6 +44,7 @@ struct nouveau_fence_chan {
u32 context;
char name[32];
+ struct work_struct uevent_work;
struct nvif_event event;
int notify_ref, dead, killed;
};
Re: [PATCH v2 1/3] Subject: [PATCH] drm/mediatek/dp: Add tee client application for HDCP feature
Hi mac.shen,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on pza/reset/next linus/master v6.8-rc3 next-20240205]
[cannot apply to pza/imx-drm/next]
[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/mac-shen/Subject-PATCH-drm-mediatek-dp-Add-tee-client-application-for-HDCP-feature/20240205-163727
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240205055055.25340-2-mac.shen%40mediatek.com
patch subject: [PATCH v2 1/3] Subject: [PATCH] drm/mediatek/dp: Add tee client
application for HDCP feature
config: arm64-defconfig
(https://download.01.org/0day-ci/archive/20240205/202402052342.y5awt1t2-...@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240205/202402052342.y5awt1t2-...@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/202402052342.y5awt1t2-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/mediatek/tlc_dp_hdcp.c:34: warning: Function parameter or
>> struct member 'dp_tee_priv' not described in 'dp_tee_op_send'
>> drivers/gpu/drm/mediatek/tlc_dp_hdcp.c:34: warning: Function parameter or
>> struct member 'cmd_id' not described in 'dp_tee_op_send'
vim +34 drivers/gpu/drm/mediatek/tlc_dp_hdcp.c
13
14 /*
15 * TA_FTPM_UUID: 99975014-3c7c-54ea-8487-a80d215ea92c
16 *
17 * Randomly generated, and must correspond to the GUID on the TA side.
18 * Defined here in the reference implementation:
19 *
https://github.com/microsoft/ms-tpm-20-ref/blob/master/Samples/ARM32-FirmwareTPM/optee_ta/fTPM/include/fTPM.h#L42
20 */
21 static const uuid_t dp_ta_uuid =
22 UUID_INIT(0x99975014, 0x3c7c, 0x54ea,
230x84, 0x87, 0xa8, 0x0d, 0x21, 0x5e, 0xa9, 0x2c);
24
25 /**
26 * dp_tee_op_send() - send dp commands through the TEE shared memory.
27 * @len:the number of bytes to send.
28 *
29 * Return:
30 * In case of success, returns 0.
31 * On failure, -errno
32 */
33 static int dp_tee_op_send(struct dp_tee_private *dp_tee_priv, size_t
len, u32 cmd_id)
> 34 {
35 int rc;
36 u8 *temp_buf;
37 struct tee_ioctl_invoke_arg transceive_args;
38 struct tee_param command_params[4];
39 struct tee_shm *shm = dp_tee_priv->shm;
40
41 if (len > MAX_COMMAND_SIZE) {
42 TLCERR("%s: len=%zd exceeds MAX_COMMAND_SIZE supported
by dp TA\n", __func__, len);
43 return -EIO;
44 }
45
46 memset(&transceive_args, 0, sizeof(transceive_args));
47 memset(command_params, 0, sizeof(command_params));
48 dp_tee_priv->resp_len = 0;
49
50 /* Invoke FTPM_OPTEE_TA_SUBMIT_COMMAND function of dp TA */
51 transceive_args = (struct tee_ioctl_invoke_arg) {
52 .func = cmd_id,
53 .session = dp_tee_priv->session,
54 .num_params = 4,
55 };
56
57 /* Fill FTPM_OPTEE_TA_SUBMIT_COMMAND parameters */
58 command_params[0] = (struct tee_param) {
59 .attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT,
60 .u.memref = {
61 .shm = shm,
62 .size = len,
63 .shm_offs = 0,
64 },
65 };
66
67 command_params[1] = (struct tee_param) {
68 .attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT,
69 .u.memref = {
70 .shm = shm,
71 .size = MAX_RESPONSE_SIZE,
72 .shm_offs = MAX_COMMAND_SIZE,
73 },
74 };
75
76 rc = tee_client_invoke_func(dp_tee_priv->ctx, &transceive_args,
command_params);
77 if (rc < 0 || transceive_args.ret != 0) {
78 TLCERR("%s: invoke error: 0x%x\n", __func__,
transceive_args.ret);
79 return (rc < 0) ? rc : transceive_args.ret;
80 }
81
82 temp_buf = tee_shm_get_va(shm,
command_params[
Re: [PATCH 02/19] drm/dp: Add support for DP tunneling
On Wed, Jan 31, 2024 at 08:49:16PM +0200, Imre Deak wrote:
> On Wed, Jan 31, 2024 at 06:09:04PM +0200, Ville Syrjälä wrote:
> > On Tue, Jan 23, 2024 at 12:28:33PM +0200, Imre Deak wrote:
> > > +static void untrack_tunnel_ref(struct drm_dp_tunnel *tunnel,
> > > +struct ref_tracker **tracker)
> > > +{
> > > + ref_tracker_free(&tunnel->group->mgr->ref_tracker,
> > > + tracker);
> > > +}
> > > +
> > > +struct drm_dp_tunnel *
> > > +drm_dp_tunnel_get_untracked(struct drm_dp_tunnel *tunnel)
> > > +{
> > > + track_tunnel_ref(tunnel, NULL);
> > > +
> > > + return tunnel_get(tunnel);
> > > +}
> > > +EXPORT_SYMBOL(drm_dp_tunnel_get_untracked);
> >
> > Why do these exist?
>
> They implement drm_dp_tunnel_get()/put() if
> CONFIG_DRM_DISPLAY_DEBUG_DP_TUNNEL_STATE=n.
Why does that kind of irrelevant detail need to be visible
in the exported api?
--
Ville Syrjälä
Intel
Re: [PATCH 12/19] drm/i915/dp: Add DP tunnel atomic state and check BW limit
On Tue, Jan 23, 2024 at 12:28:43PM +0200, Imre Deak wrote:
> Add the atomic state during a modeset required to enable the DP tunnel
> BW allocation mode on links where such a tunnel was detected.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_atomic.c | 8
> drivers/gpu/drm/i915/display/intel_display.c | 19 +++
> drivers/gpu/drm/i915/display/intel_link_bw.c | 5 +
> 3 files changed, 32 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index 96ab37e158995..4236740ede9ed 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -260,6 +260,10 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> if (crtc_state->post_csc_lut)
> drm_property_blob_get(crtc_state->post_csc_lut);
>
> + if (crtc_state->dp_tunnel_ref.tunnel)
> + drm_dp_tunnel_ref_get(old_crtc_state->dp_tunnel_ref.tunnel,
I'd probably s/old_crtc_state/crtc_state/ here. Same pointer, but
looks out of place given everyone else just operates on 'crtc_state'
here.
> + &crtc_state->dp_tunnel_ref);
Shame we have to have this ref wrapper. But I guess no clean
way to have a magic tracked pointer type that works like a
normal pointer in C...
> +
> crtc_state->update_pipe = false;
> crtc_state->update_m_n = false;
> crtc_state->update_lrr = false;
> @@ -311,6 +315,8 @@ intel_crtc_destroy_state(struct drm_crtc *crtc,
>
> __drm_atomic_helper_crtc_destroy_state(&crtc_state->uapi);
> intel_crtc_free_hw_state(crtc_state);
> + if (crtc_state->dp_tunnel_ref.tunnel)
> + drm_dp_tunnel_ref_put(&crtc_state->dp_tunnel_ref);
> kfree(crtc_state);
> }
>
> @@ -346,6 +352,8 @@ void intel_atomic_state_clear(struct drm_atomic_state *s)
> /* state->internal not reset on purpose */
>
> state->dpll_set = state->modeset = false;
> +
> + intel_dp_tunnel_atomic_cleanup_inherited_state(state);
This seems to be in the wrong patch?
> }
>
> struct intel_crtc_state *
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index b9f985a5e705b..46b27a32c8640 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -33,6 +33,7 @@
> #include
>
> #include
> +#include
> #include
> #include
> #include
> @@ -73,6 +74,7 @@
> #include "intel_dp.h"
> #include "intel_dp_link_training.h"
> #include "intel_dp_mst.h"
> +#include "intel_dp_tunnel.h"
> #include "intel_dpll.h"
> #include "intel_dpll_mgr.h"
> #include "intel_dpt.h"
> @@ -4490,6 +4492,8 @@ copy_bigjoiner_crtc_state_modeset(struct
> intel_atomic_state *state,
> saved_state->crc_enabled = slave_crtc_state->crc_enabled;
>
> intel_crtc_free_hw_state(slave_crtc_state);
> + if (slave_crtc_state->dp_tunnel_ref.tunnel)
> + drm_dp_tunnel_ref_put(&slave_crtc_state->dp_tunnel_ref);
> memcpy(slave_crtc_state, saved_state, sizeof(*slave_crtc_state));
> kfree(saved_state);
>
> @@ -4505,6 +4509,10 @@ copy_bigjoiner_crtc_state_modeset(struct
> intel_atomic_state *state,
> &master_crtc_state->hw.adjusted_mode);
> slave_crtc_state->hw.scaling_filter =
> master_crtc_state->hw.scaling_filter;
>
> + if (master_crtc_state->dp_tunnel_ref.tunnel)
> + drm_dp_tunnel_ref_get(master_crtc_state->dp_tunnel_ref.tunnel,
> + &slave_crtc_state->dp_tunnel_ref);
> +
> copy_bigjoiner_crtc_state_nomodeset(state, slave_crtc);
>
> slave_crtc_state->uapi.mode_changed =
> master_crtc_state->uapi.mode_changed;
> @@ -4533,6 +4541,13 @@ intel_crtc_prepare_cleared_state(struct
> intel_atomic_state *state,
> /* free the old crtc_state->hw members */
> intel_crtc_free_hw_state(crtc_state);
>
> + if (crtc_state->dp_tunnel_ref.tunnel) {
> + drm_dp_tunnel_atomic_set_stream_bw(&state->base,
> +
> crtc_state->dp_tunnel_ref.tunnel,
> +crtc->pipe, 0);
> + drm_dp_tunnel_ref_put(&crtc_state->dp_tunnel_ref);
> + }
> +
> /* FIXME: before the switch to atomic started, a new pipe_config was
>* kzalloc'd. Code that depends on any field being zero should be
>* fixed, so that the crtc_state can be safely duplicated. For now,
> @@ -5374,6 +5389,10 @@ static int intel_modeset_pipe(struct
> intel_atomic_state *state,
> if (ret)
> return ret;
>
> + ret = intel_dp_tunnel_atomic_add_state_for_crtc(state, crtc);
> + if (ret)
> + return ret;
> +
> ret = intel_dp_mst_add_topology_state_for_crtc(state, crtc);
> if (ret)
> return ret;
> diff --git a/drivers/gpu/d
[lvc-project] [PATCH v2] drm/amd/pm: check return value of amdgpu_irq_add_id()
amdgpu_irq_ad_id() may fail and the irq handlers will not be registered.
This patch adds error code check.
Found by Linux Verification Center (linuxtesting.org).
Signed-off-by: Igor Artemiev
---
v2: Free the source as Alexey Khoroshilov suggested.
.../drm/amd/pm/powerplay/hwmgr/smu_helper.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu_helper.c
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu_helper.c
index 79a566f3564a..109df1039d5c 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu_helper.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu_helper.c
@@ -647,28 +647,41 @@ int smu9_register_irq_handlers(struct pp_hwmgr *hwmgr)
{
struct amdgpu_irq_src *source =
kzalloc(sizeof(struct amdgpu_irq_src), GFP_KERNEL);
+ int ret;
if (!source)
return -ENOMEM;
source->funcs = &smu9_irq_funcs;
- amdgpu_irq_add_id((struct amdgpu_device *)(hwmgr->adev),
+ ret = amdgpu_irq_add_id((struct amdgpu_device *)(hwmgr->adev),
SOC15_IH_CLIENTID_THM,
THM_9_0__SRCID__THM_DIG_THERM_L2H,
source);
- amdgpu_irq_add_id((struct amdgpu_device *)(hwmgr->adev),
+ if (ret)
+ goto err;
+
+ ret = amdgpu_irq_add_id((struct amdgpu_device *)(hwmgr->adev),
SOC15_IH_CLIENTID_THM,
THM_9_0__SRCID__THM_DIG_THERM_H2L,
source);
+ if (ret)
+ goto err;
/* Register CTF(GPIO_19) interrupt */
- amdgpu_irq_add_id((struct amdgpu_device *)(hwmgr->adev),
+ ret = amdgpu_irq_add_id((struct amdgpu_device *)(hwmgr->adev),
SOC15_IH_CLIENTID_ROM_SMUIO,
SMUIO_9_0__SRCID__SMUIO_GPIO19,
source);
+ if (ret)
+ goto err;
return 0;
+
+err:
+ kfree(source);
+
+ return ret;
}
void *smu_atom_get_data_table(void *dev, uint32_t table, uint16_t *size,
--
2.39.2
Re: [PATCH v2 0/6] Pinephone video out fixes (flipping between two frames)
On Mon, Feb 05, 2024 at 04:54:07PM +0100, Ondřej Jirman wrote: > On Mon, Feb 05, 2024 at 04:22:23PM +0100, Frank Oltmanns wrote: > > On some pinephones the video output sometimes freezes (flips between two > > frames) [1]. It seems to be that the reason for this behaviour is that > > PLL-MIPI, PLL-GPU and GPU are operating outside their limits. > > > > In this patch series I propose the followin changes: > > 1. sunxi-ng: Adhere to the following constraints given in the > > Allwinner A64 Manual regarding PLL-MIPI: > > * M/N <= 3 > > * (PLL_VIDEO0)/M >= 24MHz > > * 500MHz <= clockrate <= 1400MHz > > > > 2. Choose a higher clock rate for the ST7703 based XDB599 panel, so > > that the panel function well with the Allwinner A64 SOC. PLL-MIPI > > must run between 500 MHz and 1.4 GHz. As PLL-MIPI runs at 6 times > > the panel's clock rate, we need the panel's clock to be at least > > 83.333 MHz. > > > > 3. Increase the minimum frequency in the A64 DTS OPPs from 120 MHz to > > 192 MHz. This further reduces the issue. > > > > Unfortunately, with these patches the issue [1] is not completely gone, > > but becomes less likely. > > > > Note, that when pinning the GPU to 432 MHz the issue completely > > disappears for me. I've searched the BSP and could not find any > > indication that supports the idea of having the three OPPs. The only > > frequency I found in the BPSs for A64 is 432 MHz, that has also proven > > stable for me. So, while increasing the minimum frequency to 192 MHz > > reduces the issue, should we maybe instead set the GPU to a fixed 432 > > MHz instead? > > Per A64 User Manual 1.1 page 81: > > (9). Clock output of PLL_GPU can be used for GPU;and dynamic frequency > scaling is not supported; You may be able to elegantly work around this by pinning PLL_GPU to a certain frequency (assing it in DT and then don't decalre gpu clock as CLK_SET_RATE_PARENT). Say 432 MHz for PLL and then do the scaling via GPU_CLK_REG N divider between 432MHz and 216MHz and maybe 108MHz if that brings any gains. Then you can perhaps sidestep all these potential issues with PLL_GPU and lack of DVFS support decalred in the manual. regards, o. > Also sunxi-ng clk driver does apply NM factors at once to PLL_GPU clock, > which can cause sudden frequency increase beyond intended output frequency, > because division is applied immediately while multiplication is reflected > slowly. > > Eg. if you're changing divider from 7 to 1, you can get a sudden 7x output > frequency spike, before PLL VCO manages to lower the frequency through N clk > divider feedback loop and lock on again. This can mess up whatever's connected > to the output quite badly. > > You'd have to put logging on kernel writes to PLL_GPU register to see what > is written in there and if divider is lowered significantly on some GPU > devfreq frequency transitions. > > It's also unclear what happens when FRAC_CLK_OUT or PLL_MODE_SEL changes. > Maybe not much because M is supposed to be set to 1, but you still need to > care when enabling fractional mode, and setting M to 1 because that's exactly > the bad scenario if M was previously higher than 1. > > It's tricky. > > Having GPU module clock gated during PLL config changes may help! You can > do that without locking yourself out, unlike with the CPU PLL. > > There's a gate enable bit for it at GPU_CLK_REG.SCLK_GATING. (page 122) > > Kind regards, > o. > > > I very much appreciate your feedback! > > > > [1] https://gitlab.com/postmarketOS/pmaports/-/issues/805 > > > > Signed-off-by: Frank Oltmanns > > --- > > Changes in v2: > > - dts: Increase minimum GPU frequency to 192 MHz. > > - nkm and a64: Add minimum and maximum rate for PLL-MIPI. > > - nkm: Use the same approach for skipping invalid rates in > > ccu_nkm_find_best() as in ccu_nkm_find_best_with_parent_adj(). > > - nkm: Improve names for ratio struct members and hence get rid of > > describing comments. > > - nkm and a64: Correct description in the commit messages: M/N <= 3 > > - Remove patches for nm as they were not needed. > > - st7703: Rework the commit message to cover more background for the > > change. > > - Link to v1: > > https://lore.kernel.org/r/20231218-pinephone-pll-fixes-v1-0-e238b6ed6...@oltmanns.dev > > > > --- > > Frank Oltmanns (6): > > clk: sunxi-ng: nkm: Support constraints on m/n ratio and parent rate > > clk: sunxi-ng: a64: Add constraints on PLL-MIPI's n/m ratio and > > parent rate > > clk: sunxi-ng: nkm: Support minimum and maximum rate > > clk: sunxi-ng: a64: Set minimum and maximum rate for PLL-MIPI > > drm/panel: st7703: Drive XBD599 panel at higher clock rate > > arm64: dts: allwinner: a64: Fix minimum GPU OPP rate > > > > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 4 ++-- > > drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 14 +++ > > drivers/clk/sunxi-ng/ccu_nkm.c| 34
Re: [PATCH v2 0/6] Pinephone video out fixes (flipping between two frames)
On Mon, Feb 05, 2024 at 04:22:23PM +0100, Frank Oltmanns wrote: > On some pinephones the video output sometimes freezes (flips between two > frames) [1]. It seems to be that the reason for this behaviour is that > PLL-MIPI, PLL-GPU and GPU are operating outside their limits. > > In this patch series I propose the followin changes: > 1. sunxi-ng: Adhere to the following constraints given in the > Allwinner A64 Manual regarding PLL-MIPI: > * M/N <= 3 > * (PLL_VIDEO0)/M >= 24MHz > * 500MHz <= clockrate <= 1400MHz > > 2. Choose a higher clock rate for the ST7703 based XDB599 panel, so > that the panel function well with the Allwinner A64 SOC. PLL-MIPI > must run between 500 MHz and 1.4 GHz. As PLL-MIPI runs at 6 times > the panel's clock rate, we need the panel's clock to be at least > 83.333 MHz. > > 3. Increase the minimum frequency in the A64 DTS OPPs from 120 MHz to > 192 MHz. This further reduces the issue. > > Unfortunately, with these patches the issue [1] is not completely gone, > but becomes less likely. > > Note, that when pinning the GPU to 432 MHz the issue completely > disappears for me. I've searched the BSP and could not find any > indication that supports the idea of having the three OPPs. The only > frequency I found in the BPSs for A64 is 432 MHz, that has also proven > stable for me. So, while increasing the minimum frequency to 192 MHz > reduces the issue, should we maybe instead set the GPU to a fixed 432 > MHz instead? Per A64 User Manual 1.1 page 81: (9). Clock output of PLL_GPU can be used for GPU;and dynamic frequency scaling is not supported; Also sunxi-ng clk driver does apply NM factors at once to PLL_GPU clock, which can cause sudden frequency increase beyond intended output frequency, because division is applied immediately while multiplication is reflected slowly. Eg. if you're changing divider from 7 to 1, you can get a sudden 7x output frequency spike, before PLL VCO manages to lower the frequency through N clk divider feedback loop and lock on again. This can mess up whatever's connected to the output quite badly. You'd have to put logging on kernel writes to PLL_GPU register to see what is written in there and if divider is lowered significantly on some GPU devfreq frequency transitions. It's also unclear what happens when FRAC_CLK_OUT or PLL_MODE_SEL changes. Maybe not much because M is supposed to be set to 1, but you still need to care when enabling fractional mode, and setting M to 1 because that's exactly the bad scenario if M was previously higher than 1. It's tricky. Having GPU module clock gated during PLL config changes may help! You can do that without locking yourself out, unlike with the CPU PLL. There's a gate enable bit for it at GPU_CLK_REG.SCLK_GATING. (page 122) Kind regards, o. > I very much appreciate your feedback! > > [1] https://gitlab.com/postmarketOS/pmaports/-/issues/805 > > Signed-off-by: Frank Oltmanns > --- > Changes in v2: > - dts: Increase minimum GPU frequency to 192 MHz. > - nkm and a64: Add minimum and maximum rate for PLL-MIPI. > - nkm: Use the same approach for skipping invalid rates in > ccu_nkm_find_best() as in ccu_nkm_find_best_with_parent_adj(). > - nkm: Improve names for ratio struct members and hence get rid of > describing comments. > - nkm and a64: Correct description in the commit messages: M/N <= 3 > - Remove patches for nm as they were not needed. > - st7703: Rework the commit message to cover more background for the > change. > - Link to v1: > https://lore.kernel.org/r/20231218-pinephone-pll-fixes-v1-0-e238b6ed6...@oltmanns.dev > > --- > Frank Oltmanns (6): > clk: sunxi-ng: nkm: Support constraints on m/n ratio and parent rate > clk: sunxi-ng: a64: Add constraints on PLL-MIPI's n/m ratio and parent > rate > clk: sunxi-ng: nkm: Support minimum and maximum rate > clk: sunxi-ng: a64: Set minimum and maximum rate for PLL-MIPI > drm/panel: st7703: Drive XBD599 panel at higher clock rate > arm64: dts: allwinner: a64: Fix minimum GPU OPP rate > > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 4 ++-- > drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 14 +++ > drivers/clk/sunxi-ng/ccu_nkm.c| 34 > +++ > drivers/clk/sunxi-ng/ccu_nkm.h| 4 > drivers/gpu/drm/panel/panel-sitronix-st7703.c | 14 +-- > 5 files changed, 56 insertions(+), 14 deletions(-) > --- > base-commit: 059c53e877ca6e723e10490c27c1487a63e66efe > change-id: 20231218-pinephone-pll-fixes-0ccdfde273e4 > > Best regards, > -- > Frank Oltmanns >
[PATCH v2 4/6] clk: sunxi-ng: a64: Set minimum and maximum rate for PLL-MIPI
Set the minimum and maximum rate of Allwinner A64's PLL-MIPI according
to the Allwinner User Manual.
Signed-off-by: Frank Oltmanns
---
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index df679dada792..99c2ce11da74 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -178,6 +178,8 @@ static struct ccu_nkm pll_mipi_clk = {
.m = _SUNXI_CCU_DIV(0, 4),
.max_m_n_ratio = 3,
.min_parent_m_ratio = 2400,
+ .min_rate = 5,
+ .max_rate = 14,
.common = {
.reg= 0x040,
.hw.init= CLK_HW_INIT("pll-mipi", "pll-video0",
--
2.43.0
[PATCH v2 6/6] arm64: dts: allwinner: a64: Fix minimum GPU OPP rate
The PLL-GPU has a minimum rate of 192 MHz according to the A64 manual.
If run at less than 192 MHz the pinephone (based on the A64) sometimes
replays the last few frames that were displayed over and over (see first
link below).
Note, that running PLL-GPU at 240 MHz and using a divisor of 2 *should*
circumvent this problem as well. But unfortunately, the GPU shows the
erratic behaviour even more often, even though its parent is driven at a
supported range. This might be due to a similar issue to the one
observed on the Allwinner H6 (see second link).
Running both the GPU and PLL-GPU at more then 192 MHz reduces the
occurrenc of the issue.
Therefore, increase the minimum rate in the GPU OPP table to 192 MHz.
Link: https://gitlab.com/postmarketOS/pmaports/-/issues/805
Link: https://lore.kernel.org/linux-arm-kernel/2562485.k3LOHGUjKi@kista/T/
Signed-off-by: Frank Oltmanns
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 57ac18738c99..448d7fbdd1a9 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -107,8 +107,8 @@ de: display-engine {
gpu_opp_table: opp-table-gpu {
compatible = "operating-points-v2";
- opp-12000 {
- opp-hz = /bits/ 64 <12000>;
+ opp-19200 {
+ opp-hz = /bits/ 64 <19200>;
};
opp-31200 {
--
2.43.0
[PATCH v2 3/6] clk: sunxi-ng: nkm: Support minimum and maximum rate
According to the Allwinner User Manual, the Allwinner A64 requires
PLL-MIPI to run at 500MHz-1.4GHz. Add support for that to ccu_nkm.
Signed-off-by: Frank Oltmanns
---
drivers/clk/sunxi-ng/ccu_nkm.c | 13 +
drivers/clk/sunxi-ng/ccu_nkm.h | 2 ++
2 files changed, 15 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
index 1168d894d636..7d135908d6e0 100644
--- a/drivers/clk/sunxi-ng/ccu_nkm.c
+++ b/drivers/clk/sunxi-ng/ccu_nkm.c
@@ -181,6 +181,12 @@ static unsigned long ccu_nkm_round_rate(struct
ccu_mux_internal *mux,
if (nkm->common.features & CCU_FEATURE_FIXED_POSTDIV)
rate *= nkm->fixed_post_div;
+ if (nkm->min_rate && rate < nkm->min_rate)
+ rate = nkm->min_rate;
+
+ if (nkm->max_rate && rate > nkm->max_rate)
+ rate = nkm->max_rate;
+
if (!clk_hw_can_set_rate_parent(&nkm->common.hw))
rate = ccu_nkm_find_best(*parent_rate, rate, &_nkm,
&nkm->common);
else
@@ -220,6 +226,13 @@ static int ccu_nkm_set_rate(struct clk_hw *hw, unsigned
long rate,
_nkm.min_m = 1;
_nkm.max_m = nkm->m.max ?: 1 << nkm->m.width;
+
+ if (nkm->min_rate && rate < nkm->min_rate)
+ rate = nkm->min_rate;
+
+ if (nkm->max_rate && rate > nkm->max_rate)
+ rate = nkm->max_rate;
+
ccu_nkm_find_best(parent_rate, rate, &_nkm, &nkm->common);
spin_lock_irqsave(nkm->common.lock, flags);
diff --git a/drivers/clk/sunxi-ng/ccu_nkm.h b/drivers/clk/sunxi-ng/ccu_nkm.h
index c409212ee40e..358a9df6b6a0 100644
--- a/drivers/clk/sunxi-ng/ccu_nkm.h
+++ b/drivers/clk/sunxi-ng/ccu_nkm.h
@@ -27,6 +27,8 @@ struct ccu_nkm {
struct ccu_mux_internal mux;
unsigned intfixed_post_div;
+ unsigned long min_rate;
+ unsigned long max_rate;
unsigned long max_m_n_ratio;
unsigned long min_parent_m_ratio;
--
2.43.0
[PATCH v2 5/6] drm/panel: st7703: Drive XBD599 panel at higher clock rate
This panel is used in the pinephone that runs on a Allwinner A64 SOC.
The SOC requires pll-mipi to run at more than 500 MHz.
This is the relevant clock tree:
pll-mipi
tcon0
tcon-data-clock
tcon-data-clock has to run at 1/4 the DSI per-lane bit rate. The XBD599
has 24 bpp and 4 lanes. Therefore, the resulting requested
tcon-data-clock rate is:
crtc_clock * 1000 * (24 / 4) / 4
tcon-data-clock runs at tcon0 / 4 (fixed divisor), so it requests a
parent rate of
4 * (crtc_clock * 1000 * (24 / 4) / 4)
Since tcon0 is a ccu_mux, the rate of tcon0 equals the rate of pll-mipi.
pll-mipi's constraint to run at 500MHz or higher forces us to have a
crtc_clock >= 8 kHz if we want a 60 Hz vertical refresh rate.
Change [hv]sync_(start|end) so that we reach a clock rate of 83502 kHz
so that it is high enough to align with pll-pipi limits.
Signed-off-by: Frank Oltmanns
---
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
index b55bafd1a8be..6886fd7f765e 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
@@ -320,14 +320,14 @@ static int xbd599_init_sequence(struct st7703 *ctx)
static const struct drm_display_mode xbd599_mode = {
.hdisplay= 720,
- .hsync_start = 720 + 40,
- .hsync_end = 720 + 40 + 40,
- .htotal = 720 + 40 + 40 + 40,
+ .hsync_start = 720 + 65,
+ .hsync_end = 720 + 65 + 65,
+ .htotal = 720 + 65 + 65 + 65,
.vdisplay= 1440,
- .vsync_start = 1440 + 18,
- .vsync_end = 1440 + 18 + 10,
- .vtotal = 1440 + 18 + 10 + 17,
- .clock = 69000,
+ .vsync_start = 1440 + 30,
+ .vsync_end = 1440 + 30 + 22,
+ .vtotal = 1440 + 30 + 22 + 29,
+ .clock = (720 + 65 + 65 + 65) * (1440 + 30 + 22 + 29) * 60 / 1000,
.flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
.width_mm= 68,
.height_mm = 136,
--
2.43.0
[PATCH v2 1/6] clk: sunxi-ng: nkm: Support constraints on m/n ratio and parent rate
The Allwinner A64 manual lists the following constraints for the
PLL-MIPI clock:
- M/N <= 3
- (PLL_VIDEO0)/M >= 24MHz
The PLL-MIPI clock is implemented as ccu_nkm. Therefore, add support for
these constraints.
Signed-off-by: Frank Oltmanns
---
drivers/clk/sunxi-ng/ccu_nkm.c | 21 +
drivers/clk/sunxi-ng/ccu_nkm.h | 2 ++
2 files changed, 23 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
index 853f84398e2b..1168d894d636 100644
--- a/drivers/clk/sunxi-ng/ccu_nkm.c
+++ b/drivers/clk/sunxi-ng/ccu_nkm.c
@@ -16,6 +16,20 @@ struct _ccu_nkm {
unsigned long m, min_m, max_m;
};
+static bool ccu_nkm_is_valid_rate(struct ccu_common *common, unsigned long
parent,
+ unsigned long n, unsigned long m)
+{
+ struct ccu_nkm *nkm = container_of(common, struct ccu_nkm, common);
+
+ if (nkm->max_m_n_ratio && (m > nkm->max_m_n_ratio * n))
+ return false;
+
+ if (nkm->min_parent_m_ratio && (parent < nkm->min_parent_m_ratio * m))
+ return false;
+
+ return true;
+}
+
static unsigned long ccu_nkm_find_best_with_parent_adj(struct ccu_common
*common,
struct clk_hw *parent_hw,
unsigned long *parent,
unsigned long rate,
@@ -31,6 +45,10 @@ static unsigned long
ccu_nkm_find_best_with_parent_adj(struct ccu_common *common
unsigned long tmp_rate, tmp_parent;
tmp_parent = clk_hw_round_rate(parent_hw, rate
* _m / (_n * _k));
+
+ if (!ccu_nkm_is_valid_rate(common, tmp_parent,
_n, _m))
+ continue;
+
tmp_rate = tmp_parent * _n * _k / _m;
if (ccu_is_better_rate(common, rate, tmp_rate,
best_rate) ||
@@ -64,6 +82,9 @@ static unsigned long ccu_nkm_find_best(unsigned long parent,
unsigned long rate,
for (_k = nkm->min_k; _k <= nkm->max_k; _k++) {
for (_n = nkm->min_n; _n <= nkm->max_n; _n++) {
for (_m = nkm->min_m; _m <= nkm->max_m; _m++) {
+ if (!ccu_nkm_is_valid_rate(common, parent, _n,
_m))
+ continue;
+
unsigned long tmp_rate;
tmp_rate = parent * _n * _k / _m;
diff --git a/drivers/clk/sunxi-ng/ccu_nkm.h b/drivers/clk/sunxi-ng/ccu_nkm.h
index 6601defb3f38..c409212ee40e 100644
--- a/drivers/clk/sunxi-ng/ccu_nkm.h
+++ b/drivers/clk/sunxi-ng/ccu_nkm.h
@@ -27,6 +27,8 @@ struct ccu_nkm {
struct ccu_mux_internal mux;
unsigned intfixed_post_div;
+ unsigned long max_m_n_ratio;
+ unsigned long min_parent_m_ratio;
struct ccu_common common;
};
--
2.43.0
[PATCH v2 0/6] Pinephone video out fixes (flipping between two frames)
On some pinephones the video output sometimes freezes (flips between two frames) [1]. It seems to be that the reason for this behaviour is that PLL-MIPI, PLL-GPU and GPU are operating outside their limits. In this patch series I propose the followin changes: 1. sunxi-ng: Adhere to the following constraints given in the Allwinner A64 Manual regarding PLL-MIPI: * M/N <= 3 * (PLL_VIDEO0)/M >= 24MHz * 500MHz <= clockrate <= 1400MHz 2. Choose a higher clock rate for the ST7703 based XDB599 panel, so that the panel function well with the Allwinner A64 SOC. PLL-MIPI must run between 500 MHz and 1.4 GHz. As PLL-MIPI runs at 6 times the panel's clock rate, we need the panel's clock to be at least 83.333 MHz. 3. Increase the minimum frequency in the A64 DTS OPPs from 120 MHz to 192 MHz. This further reduces the issue. Unfortunately, with these patches the issue [1] is not completely gone, but becomes less likely. Note, that when pinning the GPU to 432 MHz the issue completely disappears for me. I've searched the BSP and could not find any indication that supports the idea of having the three OPPs. The only frequency I found in the BPSs for A64 is 432 MHz, that has also proven stable for me. So, while increasing the minimum frequency to 192 MHz reduces the issue, should we maybe instead set the GPU to a fixed 432 MHz instead? I very much appreciate your feedback! [1] https://gitlab.com/postmarketOS/pmaports/-/issues/805 Signed-off-by: Frank Oltmanns --- Changes in v2: - dts: Increase minimum GPU frequency to 192 MHz. - nkm and a64: Add minimum and maximum rate for PLL-MIPI. - nkm: Use the same approach for skipping invalid rates in ccu_nkm_find_best() as in ccu_nkm_find_best_with_parent_adj(). - nkm: Improve names for ratio struct members and hence get rid of describing comments. - nkm and a64: Correct description in the commit messages: M/N <= 3 - Remove patches for nm as they were not needed. - st7703: Rework the commit message to cover more background for the change. - Link to v1: https://lore.kernel.org/r/20231218-pinephone-pll-fixes-v1-0-e238b6ed6...@oltmanns.dev --- Frank Oltmanns (6): clk: sunxi-ng: nkm: Support constraints on m/n ratio and parent rate clk: sunxi-ng: a64: Add constraints on PLL-MIPI's n/m ratio and parent rate clk: sunxi-ng: nkm: Support minimum and maximum rate clk: sunxi-ng: a64: Set minimum and maximum rate for PLL-MIPI drm/panel: st7703: Drive XBD599 panel at higher clock rate arm64: dts: allwinner: a64: Fix minimum GPU OPP rate arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 4 ++-- drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 14 +++ drivers/clk/sunxi-ng/ccu_nkm.c| 34 +++ drivers/clk/sunxi-ng/ccu_nkm.h| 4 drivers/gpu/drm/panel/panel-sitronix-st7703.c | 14 +-- 5 files changed, 56 insertions(+), 14 deletions(-) --- base-commit: 059c53e877ca6e723e10490c27c1487a63e66efe change-id: 20231218-pinephone-pll-fixes-0ccdfde273e4 Best regards, -- Frank Oltmanns
[PATCH v2 2/6] clk: sunxi-ng: a64: Add constraints on PLL-MIPI's n/m ratio and parent rate
The Allwinner A64 manual lists the following constraints for the
PLL-MIPI clock:
- M/N <= 3
- (PLL_VIDEO0)/M >= 24MHz
Use these constraints.
Signed-off-by: Frank Oltmanns
---
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index 8951ffc14ff5..df679dada792 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -171,11 +171,13 @@ static struct ccu_nkm pll_mipi_clk = {
* user manual, and by experiments the PLL doesn't work without
* these bits toggled.
*/
- .enable = BIT(31) | BIT(23) | BIT(22),
- .lock = BIT(28),
- .n = _SUNXI_CCU_MULT(8, 4),
- .k = _SUNXI_CCU_MULT_MIN(4, 2, 2),
- .m = _SUNXI_CCU_DIV(0, 4),
+ .enable = BIT(31) | BIT(23) | BIT(22),
+ .lock = BIT(28),
+ .n = _SUNXI_CCU_MULT(8, 4),
+ .k = _SUNXI_CCU_MULT_MIN(4, 2, 2),
+ .m = _SUNXI_CCU_DIV(0, 4),
+ .max_m_n_ratio = 3,
+ .min_parent_m_ratio = 2400,
.common = {
.reg= 0x040,
.hw.init= CLK_HW_INIT("pll-mipi", "pll-video0",
--
2.43.0
Re: [RFC PATCH 2/2] drm/amd/display: switch amdgpu_dm_connector to use struct drm_edid
On 01/26, Alex Hung wrote:
>
>
> On 2024-01-26 09:28, Melissa Wen wrote:
> > Replace raw edid handling (struct edid) with the opaque EDID type
> > (struct drm_edid) on amdgpu_dm_connector for consistency. It may also
> > prevent mismatch of approaches in different parts of the driver code.
> > Working in progress. There are a couple of cast warnings and it was only
> > tested with IGT.
> >
> > Signed-off-by: Melissa Wen
> > ---
> > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 63 ++-
> > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 4 +-
> > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 9 +--
> > .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 23 +++
> > 4 files changed, 51 insertions(+), 48 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index 68e71e2ea472..741081d73bb3 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -3277,12 +3277,12 @@ void amdgpu_dm_update_connector_after_detect(
> > &aconnector->dm_dp_aux.aux);
> > }
> > } else {
> > - aconnector->edid =
> > - (struct edid *)sink->dc_edid.raw_edid;
> > + const struct edid *edid = (const struct edid
> > *)sink->dc_edid.raw_edid;
> > + aconnector->edid = drm_edid_alloc(edid,
> > (edid->extensions + 1) * EDID_LENGTH);
> > if (aconnector->dc_link->aux_mode)
> > drm_dp_cec_set_edid(&aconnector->dm_dp_aux.aux,
> > - aconnector->edid);
> > +
> > drm_edid_raw(aconnector->edid));
> > }
> > if (!aconnector->timing_requested) {
> > @@ -3293,13 +3293,13 @@ void amdgpu_dm_update_connector_after_detect(
> > "failed to create
> > aconnector->requested_timing\n");
> > }
> > - drm_connector_update_edid_property(connector, aconnector->edid);
> > + drm_edid_connector_update(connector, aconnector->edid);
> > amdgpu_dm_update_freesync_caps(connector, aconnector->edid);
> > update_connector_ext_caps(aconnector);
> > } else {
> > drm_dp_cec_unset_edid(&aconnector->dm_dp_aux.aux);
> > amdgpu_dm_update_freesync_caps(connector, NULL);
> > - drm_connector_update_edid_property(connector, NULL);
> > + drm_edid_connector_update(connector, NULL);
> > aconnector->num_modes = 0;
> > dc_sink_release(aconnector->dc_sink);
> > aconnector->dc_sink = NULL;
> > @@ -6564,7 +6564,6 @@ static void amdgpu_dm_connector_funcs_force(struct
> > drm_connector *connector)
> > struct dc_link *dc_link = aconnector->dc_link;
> > struct dc_sink *dc_em_sink = aconnector->dc_em_sink;
> > const struct drm_edid *drm_edid;
> > - const struct edid *edid;
> > /*
> > * Note: drm_get_edid gets edid in the following order:
> > @@ -6578,11 +6577,12 @@ static void amdgpu_dm_connector_funcs_force(struct
> > drm_connector *connector)
> > DRM_ERROR("No EDID found on connector: %s.\n", connector->name);
> > return;
> > }
> > - edid = drm_edid_raw(drm_edid);
> > - aconnector->edid = edid;
> > -
> > + aconnector->edid = drm_edid;
> > + drm_edid_connector_update(connector, drm_edid);
> > /* Update emulated (virtual) sink's EDID */
> > if (dc_em_sink && dc_link) {
> > + const struct edid *edid = drm_edid_raw(drm_edid);
> > +
> > memset(&dc_em_sink->edid_caps, 0, sizeof(struct dc_edid_caps));
> > memmove(dc_em_sink->dc_edid.raw_edid, (uint8_t *)edid,
> > (edid->extensions + 1) * EDID_LENGTH);
> > dm_helpers_parse_edid_caps(
> > @@ -6633,13 +6633,13 @@ static void create_eml_sink(struct
> > amdgpu_dm_connector *aconnector)
> > return;
> > }
> > - edid = drm_edid_raw(drm_edid);
> > -
> > - if (drm_detect_hdmi_monitor(edid))
> > + if (connector->display_info.is_hdmi)
> > init_params.sink_signal = SIGNAL_TYPE_HDMI_TYPE_A;
> > - aconnector->edid = edid;
> > + aconnector->edid = drm_edid;
> > + drm_edid_connector_update(connector, drm_edid);
> > + edid = drm_edid_raw(drm_edid);
> > aconnector->dc_em_sink = dc_link_add_remote_sink(
> > aconnector->dc_link,
> > (uint8_t *)edid,
> > @@ -7322,16 +7322,16 @@ static void amdgpu_set_panel_orientation(struct
> > drm_connector *connector)
> > }
> > static void amdgpu_dm_connector_ddc_get_modes(struct drm_connector
> > *connector,
> > - struct edid *edid)
> > + const struct drm_edid *drm_edid)
> > {
> > struct a
Re: [RFC PATCH 0/2] drm/amd/display: switch amdgpu_dm_connector to
On 01/29, Jani Nikula wrote:
> On Fri, 26 Jan 2024, Mario Limonciello wrote:
> > On 1/26/2024 10:28, Melissa Wen wrote:
> >> Hi,
> >>
> >> I'm debugging a null-pointer dereference when running
> >> igt@kms_connector_force_edid and the way I found to solve the bug is to
> >> stop using raw edid handler in amdgpu_connector_funcs_force and
> >> create_eml_sink in favor of managing resouces via sruct drm_edid helpers
> >> (Patch 1). The proper solution seems to be switch amdgpu_dm_connector
> >> from struct edid to struct drm_edid and avoid the usage of different
> >> approaches in the driver (Patch 2). However, doing it implies a good
> >> amount of work and validation, therefore I decided to send this RFC
> >> first to collect opinions and check if there is any parallel work on
> >> this side. It's a working in progress.
> >>
> >> The null-pointer error trigger by the igt@kms_connector_force_edid test
> >> was introduced by:
> >> - e54ed41620f ("drm/amd/display: Remove unwanted drm edid references")
> >>
> >> You can check the error trace in the first patch.
> >>
> >> This series was tested with kms_hdmi_inject and kms_force_connector. No
> >> null-pointer error, kms_hdmi_inject is successul and kms_force_connector
> >> is sucessful after the second execution - the force-edid subtest
> >> still fails in the first run (I'm still investigating).
> >>
> >> There is also a couple of cast warnings to be addressed - I'm looking
> >> for the best replacement.
> >>
> >> I appreciate any feedback and testing.
> >
> > So I'm actually a little bit worried by hardcoding EDID_LENGTH in this
> > series.
> >
> > I have some other patches that I'm posting later on that let you get the
> > EDID from _DDC BIOS method too. My observation was that the EDID can be
> > anywhere up to 512 bytes according to the ACPI spec.
> >
> > An earlier version of my patch was using EDID_LENGTH when fetching it
> > and the EDID checksum failed.
> >
> > I'll CC you on the post, we probably want to get your changes and mine
> > merged together.
>
> One of the main points of struct drm_edid is that it tracks the
> allocation size separately.
>
> We should simply not trust edid->extensions, because most of the time it
> originates from outside the kernel.
>
> Using drm_edid and immediately drm_edid_raw() falls short. That function
> should only be used during migration to help. And yeah, it also means
> EDID parsing should be done in drm_edid.c, and not spread out all over
> the subsystem.
Hi Mario and Jani,
Thanks for the feedback.
I agree with you. I used the drm_edid_raw() as an intermediate step to
assess/validate this migration, but I'll work on removing this hack.
So, I understand that the transition from edid to drm_edid is the right
path, so I'll improve this work (keeping the points you raised in mind)
and send a version.
BR,
Melissa
>
>
> BR,
> Jani.
>
>
> >
> >>
> >> Melissa
> >>
> >> Melissa Wen (2):
> >>drm/amd/display: fix null-pointer dereference on edid reading
> >>drm/amd/display: switch amdgpu_dm_connector to use struct drm_edid
> >>
> >> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 78 ++-
> >> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 4 +-
> >> .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 9 ++-
> >> .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 23 +++---
> >> 4 files changed, 60 insertions(+), 54 deletions(-)
> >>
> >
>
> --
> Jani Nikula, Intel
Re: [PATCH] dt-bindings: display: msm: sm8650-mdss: Add missing explicit "additionalProperties"
On Sat, Feb 03, 2024 at 03:55:54AM +0100, Dmitry Baryshkov wrote: > On Fri, 2 Feb 2024 at 23:23, Rob Herring wrote: > > > > In order to check schemas for missing additionalProperties or > > unevaluatedProperties, cases allowing extra properties must be explicit. > > > > Signed-off-by: Rob Herring > > Reviewed-by: Dmitry Baryshkov > > Rob, if you need it for some rework, please feel free to pick it into > your tree, otherwise I'll pick it for msm-next in the next few days. msm-next is fine. Rob
Re: [lvc-project] [PATCH] drm/amd/pm: check return value of amdgpu_irq_add_id()
On 05.02.2024 15:25, Igor Artemiev wrote: > amdgpu_irq_ad_id() may fail and the irq handlers will not be registered. > This patch adds error code check. But what is about deallocation of already allocated memory? -- Alexey
Re: [PATCH] drm/sched: Re-queue run job worker when drm_sched_entity_pop_job() returns NULL
On Mon, Feb 05, 2024 at 09:44:56AM +0100, Christian König wrote:
> Am 02.02.24 um 22:58 schrieb Rodrigo Vivi:
> > On Tue, Jan 30, 2024 at 08:05:29AM +0100, Christian König wrote:
> > > Am 30.01.24 um 04:04 schrieb Matthew Brost:
> > > > Rather then loop over entities until one with a ready job is found,
> > > > re-queue the run job worker when drm_sched_entity_pop_job() returns
> > > > NULL.
> > > >
> > > > Fixes: 6dbd9004a55 ("drm/sched: Drain all entities in DRM sched run job
> > > > worker")
> > First of all there's a small typo in this Fixes tag that needs to be fixed.
> > The correct one is:
> >
> > Fixes: 66dbd9004a55 ("drm/sched: Drain all entities in DRM sched run job
> > worker")
Cc: Dave Airlie
> >
> > But I couldn't apply this right now in any of our drm-tip trees because it
> > is not clear where this is coming from originally.
> >
> > likely amd tree?!
>
> No, this comes from Matthews work on the DRM scheduler.
>
> Matthews patches were most likely merged through drm-misc.
the original is not there in drm-misc-next.
it looks like Dave had taken that one directly to drm-next.
So we either need the drm-misc maintainers to have a backmerge or
Dave to take this through the drm-fixes directly.
>
> Regards,
> Christian.
>
> >
> > > > Signed-off-by: Matthew Brost
> > > Reviewed-by: Christian König
> > Christian, if this came from the amd, could you please apply it there and
> > propagate through your fixes flow?
> >
> > Thanks,
> > Rodrigo.
> >
> > > > ---
> > > >drivers/gpu/drm/scheduler/sched_main.c | 15 +--
> > > >1 file changed, 9 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> > > > b/drivers/gpu/drm/scheduler/sched_main.c
> > > > index 8acbef7ae53d..7e90c9f95611 100644
> > > > --- a/drivers/gpu/drm/scheduler/sched_main.c
> > > > +++ b/drivers/gpu/drm/scheduler/sched_main.c
> > > > @@ -1178,21 +1178,24 @@ static void drm_sched_run_job_work(struct
> > > > work_struct *w)
> > > > struct drm_sched_entity *entity;
> > > > struct dma_fence *fence;
> > > > struct drm_sched_fence *s_fence;
> > > > - struct drm_sched_job *sched_job = NULL;
> > > > + struct drm_sched_job *sched_job;
> > > > int r;
> > > > if (READ_ONCE(sched->pause_submit))
> > > > return;
> > > > /* Find entity with a ready job */
> > > > - while (!sched_job && (entity = drm_sched_select_entity(sched)))
> > > > {
> > > > - sched_job = drm_sched_entity_pop_job(entity);
> > > > - if (!sched_job)
> > > > - complete_all(&entity->entity_idle);
> > > > - }
> > > > + entity = drm_sched_select_entity(sched);
> > > > if (!entity)
> > > > return; /* No more work */
> > > > + sched_job = drm_sched_entity_pop_job(entity);
> > > > + if (!sched_job) {
> > > > + complete_all(&entity->entity_idle);
> > > > + drm_sched_run_job_queue(sched);
> > > > + return;
> > > > + }
> > > > +
> > > > s_fence = sched_job->s_fence;
> > > > atomic_add(sched_job->credits, &sched->credit_count);
>
RE: [PATCH 40/46] dma-buf: move dma-buf symbols into the DMA_BUF module namespace.
Hi Greg, Thanks for your inputs and patience in reviewing the patch. By mistakenly this internal patch has been sent for review as the reference commit ID is from opensource, email has been sent to those who are all involved in that commit. Please ignore this patch as it is for internal usage. Thanks and Regards Kolanupaka Naveena Graphics Software Engineer | GSE OSGC M +918374415216 Intel Corporation | intel.com > -Original Message- > From: Greg Kroah-Hartman > Sent: Friday, February 2, 2024 9:46 PM > To: Kolanupaka Naveena > Cc: gfx-internal-de...@eclists.intel.com; Wilson, Chris P > ; Siddiqui, Ayaz A ; > Muqthyar Ahmed, Syed Abdul ; > Sagar Chormale ; Pan, Xinhui > ; David Airlie ; Maarten Lankhorst > ; Maxime Ripard ; > Thomas Zimmermann ; Mauro Carvalho Chehab > ; dri-devel@lists.freedesktop.org; Daniel Vetter > ; Christian König ; Arnd > Bergmann ; Sumit Semwal ; > Alex Deucher > Subject: Re: [PATCH 40/46] dma-buf: move dma-buf symbols into the > DMA_BUF module namespace. > > On Fri, Feb 02, 2024 at 02:01:47PM +0530, Kolanupaka Naveena wrote: > > +#ifdef BPM_MODULE_IMPORT_NS_SUPPORT > > +#include > > +#endif > > No #ifdef in .c files please, this should not be an issue, just include the > .h file. > > > #include > > > > #include "gem/i915_gem_dmabuf.h" > > @@ -23,6 +26,10 @@ > > #include "i915_trace.h" > > #include "intel_iaf.h" > > > > +#ifdef BPM_MODULE_IMPORT_NS_SUPPORT > > +MODULE_IMPORT_NS(DMA_BUF); > > +#endif > > Why is a #ifdef needed here? If this isn't built as a module, it's not an > issue, > please just make it simpler. > > But really, why is this a #define at all in the first place? > > thanks, > > greg k-h
Re: [linux][PATCH v2 4/4] ARM: configs: at91: Enable LVDS serializer support
On 05/02/2024 at 12:06, Dharma B - I70843 wrote: Enable LVDS serializer support for display pipeline. Signed-off-by: Dharma Balasubiramani Acked-by: Hari Prasath Gujulan Elango Acked-by: Nicolas Ferre --- arch/arm/configs/at91_dt_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/at91_dt_defconfig b/arch/arm/configs/at91_dt_defconfig index 71b5acc78187..6a7714beb099 100644 --- a/arch/arm/configs/at91_dt_defconfig +++ b/arch/arm/configs/at91_dt_defconfig @@ -143,6 +143,7 @@ CONFIG_VIDEO_OV2640=m CONFIG_VIDEO_OV7740=m CONFIG_DRM=y CONFIG_DRM_ATMEL_HLCDC=y +CONFIG_DRM_MICROCHIP_LVDS_SERIALIZER=y CONFIG_DRM_PANEL_SIMPLE=y CONFIG_DRM_PANEL_EDP=y CONFIG_FB_ATMEL=y
Re: [linux][PATCH v2 3/4] MAINTAINERS: add SAM9X7 SoC's LVDS controller
On 05/02/2024 at 12:06, Dharma B - I70843 wrote: Add the newly added LVDS controller for the SAM9X7 SoC to the existing MAINTAINERS entry. Signed-off-by: Dharma Balasubiramani If new series is to be done, this entry should be placed before this one "MICROCHIP SAMA5D2-COMPATIBLE ADC DRIVER" Otherwise: Acked-by: Nicolas Ferre Regards, Nicolas --- Changelog v1 -> v2 - No Changes. --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index a7c4cf8201e0..24a266d20df6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -14230,6 +14230,14 @@ S: Supported F:Documentation/devicetree/bindings/power/reset/atmel,sama5d2-shdwc.yaml F:drivers/power/reset/at91-sama5d2_shdwc.c +MICROCHIP SAM9x7-COMPATIBLE LVDS CONTROLLER +M: Manikandan Muralidharan +M: Dharma Balasubiramani +L: dri-devel@lists.freedesktop.org +S: Supported +F: Documentation/devicetree/bindings/display/bridge/microchip,sam9x7-lvds.yaml +F: drivers/gpu/drm/bridge/microchip-lvds.c + MICROCHIP SOC DRIVERS M:Conor Dooley S:Supported
[lvc-project] [PATCH] drm/amd/pm: check return value of amdgpu_irq_add_id()
amdgpu_irq_ad_id() may fail and the irq handlers will not be registered.
This patch adds error code check.
Found by Linux Verification Center (linuxtesting.org).
Signed-off-by: Igor Artemiev
---
.../gpu/drm/amd/pm/powerplay/hwmgr/smu_helper.c| 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu_helper.c
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu_helper.c
index 79a566f3564a..9cb965479dd8 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu_helper.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu_helper.c
@@ -647,26 +647,34 @@ int smu9_register_irq_handlers(struct pp_hwmgr *hwmgr)
{
struct amdgpu_irq_src *source =
kzalloc(sizeof(struct amdgpu_irq_src), GFP_KERNEL);
+ int ret;
if (!source)
return -ENOMEM;
source->funcs = &smu9_irq_funcs;
- amdgpu_irq_add_id((struct amdgpu_device *)(hwmgr->adev),
+ ret = amdgpu_irq_add_id((struct amdgpu_device *)(hwmgr->adev),
SOC15_IH_CLIENTID_THM,
THM_9_0__SRCID__THM_DIG_THERM_L2H,
source);
- amdgpu_irq_add_id((struct amdgpu_device *)(hwmgr->adev),
+ if (ret)
+ return ret;
+
+ ret = amdgpu_irq_add_id((struct amdgpu_device *)(hwmgr->adev),
SOC15_IH_CLIENTID_THM,
THM_9_0__SRCID__THM_DIG_THERM_H2L,
source);
+ if (ret)
+ return ret;
/* Register CTF(GPIO_19) interrupt */
- amdgpu_irq_add_id((struct amdgpu_device *)(hwmgr->adev),
+ ret = amdgpu_irq_add_id((struct amdgpu_device *)(hwmgr->adev),
SOC15_IH_CLIENTID_ROM_SMUIO,
SMUIO_9_0__SRCID__SMUIO_GPIO19,
source);
+ if (ret)
+ return ret;
return 0;
}
--
2.39.2
Re: [v2,2/8] video: Provide screen_info_get_pci_dev() to find screen_info's PCI device
Hi
Am 05.02.24 um 11:05 schrieb Sui Jingfeng:
Hi,
On 2024/2/5 16:17, Thomas Zimmermann wrote:
Hi
Am 02.02.24 um 18:03 schrieb Sui Jingfeng:
Hi,
On 2024/2/2 19:58, Thomas Zimmermann wrote:
+
+/**
+ * screen_info_pci_dev() - Return PCI parent device that contains
screen_info's framebuffer
+ * @si: the screen_info
+ *
+ * Returns:
+ * The screen_info's parent device on success, or NULL otherwise.
+ */
+struct pci_dev *screen_info_pci_dev(const struct screen_info *si)
+{
+ struct resource res[SCREEN_INFO_MAX_RESOURCES];
+ ssize_t i, numres;
+
+ numres = screen_info_resources(si, res, ARRAY_SIZE(res));
+ if (numres < 0)
+ return ERR_PTR(numres);
Please return NULL at here, otherwise we have to use the IS_ERR or
IS_ERR_OR_NULL()
in the caller function to check the returned value. Meanwhile, I
noticed that you
didn't actually call IS_ERR() in the sysfb_parent_dev() function
(introduced by the
3/8 patch), so I think we probably should return NULL at here.
Please also consider that the comments of this function says that it
return NULL on
the otherwise cases.
Right. The idea is to return NULL is there is no parent device.
return NULL is more easier and clear, it stand for "None" or "don't exist".
There is another reason that I want to tell you:
Some systems which don't have a good UEFI firmware support for uncommon
GPUs.
the word "uncommon" means "not very popular GPU" or "extremely new GPU" or
"just refer to the GPUs that UEFI firmware don't know(recognize) about"
On such cases, there is no firmware framebuffer support. I means it is
possible
that screen_info_resources() return -EINVAL because of not support yet.
Then,
the screen_info_pci_dev(si) returns ERR_PTR(-EINVAL) and
sysfb_pci_dev_is_enabled()
will take this error code as a pointer and de-reference it, cause the
following
problem:
Right, that's part of the bug you already pointed out. As I said, I need
to review the callers of screen_info_pci_dev() and fix them.
But returning an errno pointer is useful in cases where a possible
parent device would have been detected, but something did not work out.
For example, screen_info_resources() does not support all VIDEO_TYPE_
constants. In such a case, it's better to tell the caller about the
problem than to silently return NULL.
Best regards
Thomas
And even the x86-64 motherboard will not likely support all GPU(for
example the one
with a old UEFI BIOS). And for an example, The intel Xe is the
"extremely new GPU".
[ 5.031966] CPU 4 Unable to handle kernel paging request at virtual
address 081a, era == 9329b448, ra == 9329b440
[ 5.044587] Oops[#1]:
[ 5.046837] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc1+ #7
[ 5.053062] Hardware name: Loongson
Loongson-3A6000-HV-7A2000-XA61200/Loongson-3A6000-HV-7A2000-XA61200,
BIOS Loongson-UDK2018-V4.0.05636-stable202311 12/
[ 5.066803] pc 9329b448 ra 9329b440 tp
9001000d sp 9001000d3d40
[ 5.075100] a0 ffea a1 9001000d3c38 a2
0003 a3 93867ce8
[ 5.083398] a4 93867ce0 a5 9001000d3a80 a6
0001 a7 0001
[ 5.091695] t0 ac81f55e34713962 t1 ac81f55e34713962 t2
t3 0001
[ 5.02] t4 0004 t5 t6
0030 t7
[ 5.108290] t8 70b1 u0 s9
0008 s0 93d58b48
[ 5.116587] s1 93c0b4a8 s2 93787000 s3
93778000 s4 932c0578
[ 5.124884] s5 ffea s6 932c0560 s7
932df900 s8 c000
[ 5.133182] ra: 9329b440 sysfb_init+0x80/0x1f0
[ 5.138545] ERA: 9329b448 sysfb_init+0x88/0x1f0
[ 5.143905] CRMD: 00b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
[ 5.150048] PRMD: 0004 (PPLV0 +PIE -PWE)
[ 5.154373] EUEN: (-FPE -SXE -ASXE -BTE)
[ 5.159131] ECFG: 00071c1c (LIE=2-4,10-12 VS=7)
[ 5.163717] ESTAT: 0001 [PIL] (IS= ECode=1 EsubCode=0)
[ 5.169164] BADV: 081a
[ 5.172623] PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV)
[ 5.178587] Modules linked in:
[ 5.181614] Process swapper/0 (pid: 1, threadinfo=(ptrval),
task=(ptrval))
[ 5.189827] Stack :
[ 5.197782] ac81f55e34713962
932c 93778000
[ 5.205736] 932c0578
9329b3c0 93c54000
[ 5.213691] 9001000d3db8 92260154
0006
[ 5.221645]
[ 5.229599]
ac81f55e34713962
[ 5.237553] 937468f8 937468f8
932c0578 936a7658
[ 5.245508]
Re: (subset) [PATCH V8 00/12] soc: imx8mp: Add support for HDMI
Hi, On Sat, 03 Feb 2024 10:52:40 -0600, Adam Ford wrote: > The i.MX8M Plus has an HDMI controller, but it depends on two > other systems, the Parallel Video Interface (PVI) and the > HDMI PHY from Samsung. The LCDIF controller generates the display > and routes it to the PVI which converts passes the parallel video > to the HDMI bridge. The HDMI system has a corresponding power > domain controller whose driver was partially written, but the > device tree for it was never applied, so some changes to the > power domain should be harmless because they've not really been > used yet. > > [...] Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next) [07/12] dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI https://cgit.freedesktop.org/drm/drm-misc/commit/?id=f490d0cb9360466f6df0def3eccc47fabba9775b [08/12] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface https://cgit.freedesktop.org/drm/drm-misc/commit/?id=059c53e877ca6e723e10490c27c1487a63e66efe -- Neil
Re: [PATCH] drm/panel: visionox-r66451: Set prepare_prev_first flag
Hi, On Fri, 02 Feb 2024 13:50:21 -0800, Jessica Zhang wrote: > The DSI host needs to be enabled for the panel to be initialized in > prepare(). Ensure this happens by setting prepare_prev_first. > > Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next) [1/1] drm/panel: visionox-r66451: Set prepare_prev_first flag https://cgit.freedesktop.org/drm/drm-misc/commit/?id=bb3bc3eac316b7c388733e625cc2343131b69dee -- Neil
Re: [PATCH V8 09/12] dt-bindings: display: imx: add binding for i.MX8MP HDMI TX
On 03/02/2024 17:52, Adam Ford wrote:
From: Lucas Stach
The HDMI TX controller on the i.MX8MP SoC is a Synopsys designware IP
core with a little bit of SoC integration around it.
Signed-off-by: Lucas Stach
Signed-off-by: Adam Ford
---
V3: Change name and location to better idenfity as a bridge and
HDMI 2.0a transmitter
Fix typos and feedback from Rob and added ports.
---
.../display/bridge/fsl,imx8mp-hdmi-tx.yaml| 102 ++
1 file changed, 102 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
new file mode 100644
index ..3791c9f4ebab
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
@@ -0,0 +1,102 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/fsl,imx8mp-hdmi-tx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8MP DWC HDMI TX Encoder
+
+maintainers:
+ - Lucas Stach
+
+description:
+ The i.MX8MP HDMI transmitter is a Synopsys DesignWare
+ HDMI 2.0a TX controller IP.
+
+allOf:
+ - $ref: /schemas/display/bridge/synopsys,dw-hdmi.yaml#
+
+properties:
+ compatible:
+enum:
+ - fsl,imx8mp-hdmi-tx
+
+ reg-io-width:
+const: 1
+
+ clocks:
+maxItems: 4
+
+ clock-names:
+items:
+ - const: iahb
+ - const: isfr
+ - const: cec
+ - const: pix
+
+ power-domains:
+maxItems: 1
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Parallel RGB input port
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: HDMI output port
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - power-domains
+ - ports
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+
+hdmi@32fd8000 {
+compatible = "fsl,imx8mp-hdmi-tx";
+reg = <0x32fd8000 0x7eff>;
+interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+clocks = <&clk IMX8MP_CLK_HDMI_APB>,
+ <&clk IMX8MP_CLK_HDMI_REF_266M>,
+ <&clk IMX8MP_CLK_32K>,
+ <&hdmi_tx_phy>;
+clock-names = "iahb", "isfr", "cec", "pix";
+power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_HDMI_TX>;
+reg-io-width = <1>;
+ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+
+ hdmi_tx_from_pvi: endpoint {
+ remote-endpoint = <&pvi_to_hdmi_tx>;
+ };
+ };
+
+ port@1 {
+reg = <1>;
+ hdmi_tx_out: endpoint {
+remote-endpoint = <&hdmi0_con>;
+ };
+ };
+};
+};
I'll apply patches 9 & 10 once this one is properly reviewed
Thanks,
Neil
Re: [PATCH] drm/dp: Don't attempt AUX transfers when eDP panels are not powered
On Fri, 02 Feb 2024, Douglas Anderson wrote:
> If an eDP panel is not powered on then any attempts to talk to it over
> the DP AUX channel will timeout. Unfortunately these attempts may be
> quite slow. Userspace can initiate these attempts either via a
> /dev/drm_dp_auxN device or via the created i2c device.
>
> Making the DP AUX drivers timeout faster is a difficult proposition.
> In theory we could just poll the panel's HPD line in the AUX transfer
> function and immediately return an error there. However, this is
> easier said than done. For one thing, there's no hard requirement to
> hook the HPD line up for eDP panels and it's OK to just delay a fixed
> amount. For another thing, the HPD line may not be fast to probe. On
> parade-ps8640 we need to wait for the bridge chip's firmware to boot
> before we can get the HPD line and this is a slow process.
>
> The fact that the transfers are taking so long to timeout is causing
> real problems. The open source fwupd daemon sometimes scans DP busses
> looking for devices whose firmware need updating. If it happens to
> scan while a panel is turned off this scan can take a long time. The
> fwupd daemon could try to be smarter and only scan when eDP panels are
> turned on, but we can also improve the behavior in the kernel.
>
> Let's let eDP panels drivers specify that a panel is turned off and
> then modify the common AUX transfer code not to attempt a transfer in
> this case.
I guess my question is, why not make the aux->transfer function handle
the powered down case and return the appropriate error?
For example, the transfer hook in i915 checks whether the display is
connected and bails out early if not.
Having to track and set the state all over the place seems more
complicated to me than dynamically checking where needed i.e. in the
transfer hook.
BR,
Jani.
>
> Signed-off-by: Douglas Anderson
> ---
>
> drivers/gpu/drm/display/drm_dp_helper.c | 35 +++
> drivers/gpu/drm/panel/panel-edp.c | 3 ++
> .../gpu/drm/panel/panel-samsung-atna33xc20.c | 2 ++
> include/drm/display/drm_dp_helper.h | 6
> 4 files changed, 46 insertions(+)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> b/drivers/gpu/drm/display/drm_dp_helper.c
> index b1ca3a1100da..6fa705d82c8f 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -532,6 +532,15 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
> request,
>
> mutex_lock(&aux->hw_mutex);
>
> + /*
> + * If the device attached to the aux bus is powered down then there's
> + * no reason to attempt a transfer. Error out immediately.
> + */
> + if (aux->powered_down) {
> + ret = -EBUSY;
> + goto unlock;
> + }
> +
> /*
>* The specification doesn't give any recommendation on how often to
>* retry native transactions. We used to retry 7 times like for
> @@ -599,6 +608,29 @@ int drm_dp_dpcd_probe(struct drm_dp_aux *aux, unsigned
> int offset)
> }
> EXPORT_SYMBOL(drm_dp_dpcd_probe);
>
> +/**
> + * drm_dp_dpcd_set_powered() - Set whether the DP device is powered
> + * @aux: DisplayPort AUX channel; for convenience it's OK to pass NULL here
> + * and the function will be a no-op.
> + * @powered: true if powered; false if not
> + *
> + * If the endpoint device on the DP AUX bus is known to be powered down
> + * then this function can be called to make future transfers fail immediately
> + * instead of needing to time out.
> + *
> + * If this function is never called then a device defaults to being powered.
> + */
> +void drm_dp_dpcd_set_powered(struct drm_dp_aux *aux, bool powered)
> +{
> + if (!aux)
> + return;
> +
> + mutex_lock(&aux->hw_mutex);
> + aux->powered_down = !powered;
> + mutex_unlock(&aux->hw_mutex);
> +}
> +EXPORT_SYMBOL(drm_dp_dpcd_set_powered);
> +
> /**
> * drm_dp_dpcd_read() - read a series of bytes from the DPCD
> * @aux: DisplayPort AUX channel (SST or MST)
> @@ -1858,6 +1890,9 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter,
> struct i2c_msg *msgs,
> struct drm_dp_aux_msg msg;
> int err = 0;
>
> + if (aux->powered_down)
> + return -EBUSY;
> +
> dp_aux_i2c_transfer_size = clamp(dp_aux_i2c_transfer_size, 1,
> DP_AUX_MAX_PAYLOAD_BYTES);
>
> memset(&msg, 0, sizeof(msg));
> diff --git a/drivers/gpu/drm/panel/panel-edp.c
> b/drivers/gpu/drm/panel/panel-edp.c
> index 7d556b1bfa82..d2a4e514d8fd 100644
> --- a/drivers/gpu/drm/panel/panel-edp.c
> +++ b/drivers/gpu/drm/panel/panel-edp.c
> @@ -413,6 +413,7 @@ static int panel_edp_suspend(struct device *dev)
> {
> struct panel_edp *p = dev_get_drvdata(dev);
>
> + drm_dp_dpcd_set_powered(p->aux, false);
> gpiod_set_value_cansleep(p->enable_gpio, 0);
> regulator_disable(p->supply);
> p->unprepared_time = ktime_get_boottime();
> @@ -469,6 +470,
Re: [linux][PATCH v2 3/4] MAINTAINERS: add SAM9X7 SoC's LVDS controller
On 05/02/2024 12:06, Dharma Balasubiramani wrote: Add the newly added LVDS controller for the SAM9X7 SoC to the existing MAINTAINERS entry. Signed-off-by: Dharma Balasubiramani --- Changelog v1 -> v2 - No Changes. --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index a7c4cf8201e0..24a266d20df6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -14230,6 +14230,14 @@ S: Supported F:Documentation/devicetree/bindings/power/reset/atmel,sama5d2-shdwc.yaml F:drivers/power/reset/at91-sama5d2_shdwc.c +MICROCHIP SAM9x7-COMPATIBLE LVDS CONTROLLER +M: Manikandan Muralidharan +M: Dharma Balasubiramani +L: dri-devel@lists.freedesktop.org +S: Supported +F: Documentation/devicetree/bindings/display/bridge/microchip,sam9x7-lvds.yaml +F: drivers/gpu/drm/bridge/microchip-lvds.c + MICROCHIP SOC DRIVERS M:Conor Dooley S:Supported Reviewed-by: Neil Armstrong
Re: [linux][PATCH v2 2/4] drm/bridge: add lvds controller support for sam9x7
Hi,
On 05/02/2024 12:06, Dharma Balasubiramani wrote:
Add a new LVDS controller driver for sam9x7 which does the following:
- Prepares and enables the LVDS Peripheral clock
- Defines its connector type as DRM_MODE_CONNECTOR_LVDS and adds itself
to the global bridge list.
- Identifies its output endpoint as panel and adds it to the encoder
display pipeline
- Enables the LVDS serializer
Signed-off-by: Manikandan Muralidharan
Signed-off-by: Dharma Balasubiramani
---
Changelog
v1 -> v2
- Drop 'res' variable and combine two lines into one.
- Handle deferred probe properly, use dev_err_probe().
- Don't print anything on deferred probe. Dropped print.
- Remove the MODULE_ALIAS and add MODULE_DEVICE_TABLE().
- symbol 'mchp_lvds_driver' was not declared. It should be static.
---
drivers/gpu/drm/bridge/Kconfig | 7 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/microchip-lvds.c | 246
3 files changed, 254 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/microchip-lvds.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3e6a4e2044c0..200afb36e421 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -173,6 +173,13 @@ config DRM_MEGACHIPS_STDP_GE_B850V3_FW
to DP++. This is used with the i.MX6 imx-ldb
driver. You are likely to say N here.
+config DRM_MICROCHIP_LVDS_SERIALIZER
+ tristate "Microchip LVDS serailzer support"
-/\
Should be serializer
+ depends on OF
+ depends on DRM_ATMEL_HLCDC
+ help
+ Support for Microchip's LVDS serializer.
+
config DRM_NWL_MIPI_DSI
tristate "Northwest Logic MIPI DSI Host controller"
depends on DRM
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 2b892b7ed59e..e3804e93d324 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) += lontium-lt9611uxc.o
obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
+obj-$(CONFIG_DRM_MICROCHIP_LVDS_SERIALIZER) += microchip-lvds.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
diff --git a/drivers/gpu/drm/bridge/microchip-lvds.c
b/drivers/gpu/drm/bridge/microchip-lvds.c
new file mode 100644
index ..508321ad0f66
--- /dev/null
+++ b/drivers/gpu/drm/bridge/microchip-lvds.c
@@ -0,0 +1,246 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023 Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Manikandan Muralidharan
+ * Author: Dharma Balasubiramani
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LVDS_POLL_TIMEOUT_MS 1000
+
+/* LVDSC register offsets */
+#define LVDSC_CR 0x00
+#define LVDSC_CFGR 0x04
+#define LVDSC_SR 0x0C
+#define LVDSC_WPMR 0xE4
+
+/* Bitfields in LVDSC_CR (Control Register) */
+#define LVDSC_CR_SER_ENBIT(0)
+
+/* Bitfields in LVDSC_CFGR (Configuration Register) */
+#define LVDSC_CFGR_PIXSIZE_24BITS 0
+#define LVDSC_CFGR_DEN_POL_HIGH0
+#define LVDSC_CFGR_DC_UNBALANCED 0
+#define LVDSC_CFGR_MAPPING_JEIDA BIT(6)
+
+/*Bitfields in LVDSC_SR */
+#define LVDSC_SR_CSBIT(0)
+
+/* Bitfields in LVDSC_WPMR (Write Protection Mode Register) */
+#define LVDSC_WPMR_WPKEY_MASK GENMASK(31, 8)
+#define LVDSC_WPMR_WPKEY_PSSWD 0x4C5644
+
+struct mchp_lvds {
+ struct device *dev;
+ void __iomem *regs;
+ struct clk *pclk;
+ int format; /* vesa or jeida format */
+ struct drm_panel *panel;
+ struct drm_bridge bridge;
+ struct drm_bridge *panel_bridge;
+};
+
+static inline struct mchp_lvds *bridge_to_lvds(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct mchp_lvds, bridge);
+}
+
+static inline u32 lvds_readl(struct mchp_lvds *lvds, u32 offset)
+{
+ return readl_relaxed(lvds->regs + offset);
+}
+
+static inline void lvds_writel(struct mchp_lvds *lvds, u32 offset, u32 val)
+{
+ writel_relaxed(val, lvds->regs + offset);
+}
+
+static void lvds_serialiser_on(struct mchp_lvds *lvds)
+{
+ unsigned long timeout = jiffies +
msecs_to_jiffies(LVDS_POLL_TIMEOUT_MS);
+
+ /* The LVDSC registers can only be written if WPEN is cleared */
+ lvds_writel(lvds, LVDSC_WPMR, (LVDSC_WPMR_WPKEY_PSSWD &
+ LVDSC_WPMR_WPKEY_MASK));
+
+ /* Wait for the status of configuration registers to be changed */
+ while (lvds_readl(lvds, LVDSC_SR) & LVDSC_SR_CS
[linux][PATCH v2 1/4] dt-bindings: display: bridge: add sam9x75-lvds compatible
Add the 'sam9x75-lvds' compatible binding, which describes the Low Voltage
Differential Signaling (LVDS) Controller found on some Microchip's sam9x7
series System-on-Chip (SoC) devices. This binding will be used to define
the properties and configuration for the LVDS Controller in DT.
Signed-off-by: Dharma Balasubiramani
---
Changelog
v1 -> v2
- Remove '|' in description, as there is no formatting to preserve.
- Remove 'gclk' from clock-names as there is only one clock(pclk).
- Remove the unused headers and include only used ones.
- Change the compatible name specific to SoC (sam9x75) instead of entire series.
- Change file name to match the compatible name.
---
.../bridge/microchip,sam9x75-lvds.yaml| 55 +++
1 file changed, 55 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml
b/Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml
new file mode 100644
index ..862ef441ac9f
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/microchip,sam9x75-lvds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip SAM9X75 LVDS Controller
+
+maintainers:
+ - Dharma Balasubiramani
+
+description:
+ The Low Voltage Differential Signaling Controller (LVDSC) manages data
+ format conversion from the LCD Controller internal DPI bus to OpenLDI
+ LVDS output signals. LVDSC functions include bit mapping, balanced mode
+ management, and serializer.
+
+properties:
+ compatible:
+const: microchip,sam9x75-lvds
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+items:
+ - description: Peripheral Bus Clock
+
+ clock-names:
+items:
+ - const: pclk
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+lvds-controller@f806 {
+ compatible = "microchip,sam9x75-lvds";
+ reg = <0xf806 0x100>;
+ interrupts = <56 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 56>;
+ clock-names = "pclk";
+};
--
2.25.1
[linux][PATCH v2 4/4] ARM: configs: at91: Enable LVDS serializer support
Enable LVDS serializer support for display pipeline. Signed-off-by: Dharma Balasubiramani Acked-by: Hari Prasath Gujulan Elango --- arch/arm/configs/at91_dt_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/at91_dt_defconfig b/arch/arm/configs/at91_dt_defconfig index 71b5acc78187..6a7714beb099 100644 --- a/arch/arm/configs/at91_dt_defconfig +++ b/arch/arm/configs/at91_dt_defconfig @@ -143,6 +143,7 @@ CONFIG_VIDEO_OV2640=m CONFIG_VIDEO_OV7740=m CONFIG_DRM=y CONFIG_DRM_ATMEL_HLCDC=y +CONFIG_DRM_MICROCHIP_LVDS_SERIALIZER=y CONFIG_DRM_PANEL_SIMPLE=y CONFIG_DRM_PANEL_EDP=y CONFIG_FB_ATMEL=y -- 2.25.1
[linux][PATCH v2 3/4] MAINTAINERS: add SAM9X7 SoC's LVDS controller
Add the newly added LVDS controller for the SAM9X7 SoC to the existing MAINTAINERS entry. Signed-off-by: Dharma Balasubiramani --- Changelog v1 -> v2 - No Changes. --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index a7c4cf8201e0..24a266d20df6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -14230,6 +14230,14 @@ S: Supported F: Documentation/devicetree/bindings/power/reset/atmel,sama5d2-shdwc.yaml F: drivers/power/reset/at91-sama5d2_shdwc.c +MICROCHIP SAM9x7-COMPATIBLE LVDS CONTROLLER +M: Manikandan Muralidharan +M: Dharma Balasubiramani +L: dri-devel@lists.freedesktop.org +S: Supported +F: Documentation/devicetree/bindings/display/bridge/microchip,sam9x7-lvds.yaml +F: drivers/gpu/drm/bridge/microchip-lvds.c + MICROCHIP SOC DRIVERS M: Conor Dooley S: Supported -- 2.25.1
[linux][PATCH v2 0/4] LVDS Controller Support for SAM9X75 SoC
This patch series introduces LVDS controller support for the SAM9X75 SoC. The LVDS controller is designed to work with Microchip's sam9x7 series System-on-Chip (SoC) devices, providing Low Voltage Differential Signaling capabilities. Patch series Changelog: - Include configs: at91: Enable LVDS serializer The Individual Changelogs are available on the respective patches. Dharma Balasubiramani (4): dt-bindings: display: bridge: add sam9x75-lvds compatible drm/bridge: add lvds controller support for sam9x7 MAINTAINERS: add SAM9X7 SoC's LVDS controller ARM: configs: at91: Enable LVDS serializer support .../bridge/microchip,sam9x75-lvds.yaml| 55 MAINTAINERS | 8 + arch/arm/configs/at91_dt_defconfig| 1 + drivers/gpu/drm/bridge/Kconfig| 7 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/microchip-lvds.c | 246 ++ 6 files changed, 318 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml create mode 100644 drivers/gpu/drm/bridge/microchip-lvds.c base-commit: 0dd3ee31125508cd67f7e7172247f05b7fd1753a -- 2.25.1
[linux][PATCH v2 2/4] drm/bridge: add lvds controller support for sam9x7
Add a new LVDS controller driver for sam9x7 which does the following:
- Prepares and enables the LVDS Peripheral clock
- Defines its connector type as DRM_MODE_CONNECTOR_LVDS and adds itself
to the global bridge list.
- Identifies its output endpoint as panel and adds it to the encoder
display pipeline
- Enables the LVDS serializer
Signed-off-by: Manikandan Muralidharan
Signed-off-by: Dharma Balasubiramani
---
Changelog
v1 -> v2
- Drop 'res' variable and combine two lines into one.
- Handle deferred probe properly, use dev_err_probe().
- Don't print anything on deferred probe. Dropped print.
- Remove the MODULE_ALIAS and add MODULE_DEVICE_TABLE().
- symbol 'mchp_lvds_driver' was not declared. It should be static.
---
drivers/gpu/drm/bridge/Kconfig | 7 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/microchip-lvds.c | 246
3 files changed, 254 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/microchip-lvds.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3e6a4e2044c0..200afb36e421 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -173,6 +173,13 @@ config DRM_MEGACHIPS_STDP_GE_B850V3_FW
to DP++. This is used with the i.MX6 imx-ldb
driver. You are likely to say N here.
+config DRM_MICROCHIP_LVDS_SERIALIZER
+ tristate "Microchip LVDS serailzer support"
+ depends on OF
+ depends on DRM_ATMEL_HLCDC
+ help
+ Support for Microchip's LVDS serializer.
+
config DRM_NWL_MIPI_DSI
tristate "Northwest Logic MIPI DSI Host controller"
depends on DRM
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 2b892b7ed59e..e3804e93d324 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) += lontium-lt9611uxc.o
obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
+obj-$(CONFIG_DRM_MICROCHIP_LVDS_SERIALIZER) += microchip-lvds.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
diff --git a/drivers/gpu/drm/bridge/microchip-lvds.c
b/drivers/gpu/drm/bridge/microchip-lvds.c
new file mode 100644
index ..508321ad0f66
--- /dev/null
+++ b/drivers/gpu/drm/bridge/microchip-lvds.c
@@ -0,0 +1,246 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023 Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Manikandan Muralidharan
+ * Author: Dharma Balasubiramani
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LVDS_POLL_TIMEOUT_MS 1000
+
+/* LVDSC register offsets */
+#define LVDSC_CR 0x00
+#define LVDSC_CFGR 0x04
+#define LVDSC_SR 0x0C
+#define LVDSC_WPMR 0xE4
+
+/* Bitfields in LVDSC_CR (Control Register) */
+#define LVDSC_CR_SER_ENBIT(0)
+
+/* Bitfields in LVDSC_CFGR (Configuration Register) */
+#define LVDSC_CFGR_PIXSIZE_24BITS 0
+#define LVDSC_CFGR_DEN_POL_HIGH0
+#define LVDSC_CFGR_DC_UNBALANCED 0
+#define LVDSC_CFGR_MAPPING_JEIDA BIT(6)
+
+/*Bitfields in LVDSC_SR */
+#define LVDSC_SR_CSBIT(0)
+
+/* Bitfields in LVDSC_WPMR (Write Protection Mode Register) */
+#define LVDSC_WPMR_WPKEY_MASK GENMASK(31, 8)
+#define LVDSC_WPMR_WPKEY_PSSWD 0x4C5644
+
+struct mchp_lvds {
+ struct device *dev;
+ void __iomem *regs;
+ struct clk *pclk;
+ int format; /* vesa or jeida format */
+ struct drm_panel *panel;
+ struct drm_bridge bridge;
+ struct drm_bridge *panel_bridge;
+};
+
+static inline struct mchp_lvds *bridge_to_lvds(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct mchp_lvds, bridge);
+}
+
+static inline u32 lvds_readl(struct mchp_lvds *lvds, u32 offset)
+{
+ return readl_relaxed(lvds->regs + offset);
+}
+
+static inline void lvds_writel(struct mchp_lvds *lvds, u32 offset, u32 val)
+{
+ writel_relaxed(val, lvds->regs + offset);
+}
+
+static void lvds_serialiser_on(struct mchp_lvds *lvds)
+{
+ unsigned long timeout = jiffies +
msecs_to_jiffies(LVDS_POLL_TIMEOUT_MS);
+
+ /* The LVDSC registers can only be written if WPEN is cleared */
+ lvds_writel(lvds, LVDSC_WPMR, (LVDSC_WPMR_WPKEY_PSSWD &
+ LVDSC_WPMR_WPKEY_MASK));
+
+ /* Wait for the status of configuration registers to be changed */
+ while (lvds_readl(lvds, LVDSC_SR) & LVDSC_SR_CS) {
+ if (time_after(jiffies, timeout)) {
+ dev_err(lvds->dev, "%s: timeout error\n", __func__);
Re: [PATCH v4 00/14] drm: Add a driver for CSF-based Mali GPUs
On Mon, 5 Feb 2024 10:54:05 +0100
Danilo Krummrich wrote:
> On 2/5/24 10:03, Boris Brezillon wrote:
> > +Danilo for the panthor gpuvm-needs update.
> >
> > On Sun, 4 Feb 2024 09:14:44 +0800 (CST)
> > "Andy Yan" wrote:
> >
> >> Hi Boris：
> >> I saw this warning sometimes（Run on a armbain based bookworm），not sure is
> >> a know issue or something else。
> >> [15368.293031] systemd-journald[715]: Received client request to
> >> relinquish /var/log/journal/1bc4a340506142af9bd31a6a3d2170ba access.
> >> [37743.040737] [ cut here ]
> >> [37743.040764] panthor fb00.gpu: drm_WARN_ON(shmem->pages_use_count)
> >> [37743.040890] WARNING: CPU: 2 PID: 5702 at
> >> drivers/gpu/drm/drm_gem_shmem_helper.c:158 drm_gem_shmem_free+0x144/0x14c
> >> [drm_shmem_helper]
> >> [37743.040929] Modules linked in: joydev rfkill sunrpc lz4hc lz4 zram
> >> binfmt_misc hantro_vpu crct10dif_ce v4l2_vp9 v4l2_h264
> >> snd_soc_simple_amplifier v4l2_mem2mem videobuf2_dma_contig
> >> snd_soc_es8328_i2c videobuf2_memops rk_crypto2 snd_soc_es8328
> >> videobuf2_v4l2 sm3_generic videodev crypto_engine sm3 rockchip_rng
> >> videobuf2_common nvmem_rockchip_otp snd_soc_rockchip_i2s_tdm
> >> snd_soc_hdmi_codec snd_soc_simple_card mc snd_soc_simple_card_utils
> >> snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine snd_pcm snd_timer snd
> >> soundcore dm_mod ip_tables x_tables autofs4 dw_hdmi_qp_i2s_audio
> >> dw_hdmi_qp_cec rk808_regulator rockchipdrm dw_mipi_dsi dw_hdmi_qp dw_hdmi
> >> analogix_dp drm_dma_helper fusb302 display_connector rk8xx_spi
> >> drm_display_helper phy_rockchip_snps_pcie3 phy_rockchip_samsung_hdptx_hdmi
> >> panthor tcpm rk8xx_core cec drm_gpuvm gpu_sched drm_kms_helper
> >> drm_shmem_helper drm_exec r8169 drm pwm_bl adc_keys
> >> [37743.041108] CPU: 2 PID: 5702 Comm: kworker/u16:8 Not tainted
> >> 6.8.0-rc1-edge-rockchip-rk3588 #2
> >> [37743.041115] Hardware name: Rockchip RK3588 EVB1 V10 Board (DT)
> >> [37743.041120] Workqueue: panthor-cleanup
> >> panthor_vm_bind_job_cleanup_op_ctx_work [panthor]
> >> [37743.041151] pstate: 6049 (nZCv daif +PAN -UAO -TCO -DIT -SSBS
> >> BTYPE=--)
> >> [37743.041157] pc : drm_gem_shmem_free+0x144/0x14c [drm_shmem_helper]
> >> [37743.041169] lr : drm_gem_shmem_free+0x144/0x14c [drm_shmem_helper]
> >> [37743.041181] sp : 80008d37bcc0
> >> [37743.041184] x29: 80008d37bcc0 x28: 800081d379c0 x27:
> >> 800081d37000
> >> [37743.041196] x26: 00019909a280 x25: 00019909a2c0 x24:
> >> 0001017a4c05
> >> [37743.041206] x23: dead0100 x22: dead0122 x21:
> >> 0001627ac1a0
> >> [37743.041217] x20: x19: 0001627ac000 x18:
> >>
> >> [37743.041227] x17: 00040044 x16: 005000f2b5503510 x15:
> >> fff91b77
> >> [37743.041238] x14: 0001 x13: 03c5 x12:
> >> ffea
> >> [37743.041248] x11: dfff x10: dfff x9 :
> >> 800081e0e818
> >> [37743.041259] x8 : 0002ffe8 x7 : c000dfff x6 :
> >> 000affa8
> >> [37743.041269] x5 : 1fff x4 : x3 :
> >> 8000819a6008
> >> [37743.041279] x2 : x1 : x0 :
> >> 00018465e900
> >> [37743.041290] Call trace:
> >> [37743.041293] drm_gem_shmem_free+0x144/0x14c [drm_shmem_helper]
> >> [37743.041306] panthor_gem_free_object+0x24/0xa0 [panthor]
> >> [37743.041321] drm_gem_object_free+0x1c/0x30 [drm]
> >> [37743.041452] panthor_vm_bo_put+0xc4/0x12c [panthor]
> >> [37743.041475] panthor_vm_cleanup_op_ctx.constprop.0+0xb0/0x104 [panthor]
> >> [37743.041491] panthor_vm_bind_job_cleanup_op_ctx_work+0x28/0xd0
> >> [panthor]
> >
> > Ok, I think I found the culprit: there's a race between
> > the drm_gpuvm_bo_put() call in panthor_vm_bo_put() and the list
> > iteration done by drm_gpuvm_prepare_objects(). Because we're not
> > setting DRM_GPUVM_RESV_PROTECTED, the code goes through the 'lockless'
> > iteration loop, and takes/release a vm_bo ref at each iteration. This
> > means our 'were we the last vm_bo user?' test in panthor_vm_bo_put()
> > might return false even if we were actually the last user, and when
> > for_each_vm_bo_in_list() releases the ref it acquired, it not only leaks
> > the pin reference, thus leaving GEM pages pinned (which explains this
> > WARN_ON() splat), but it also calls drm_gpuvm_bo_destroy() in a path
> > where we don't hold the GPUVA list lock, which is bad.
>
> IIUC, GPUVM generally behaves correctly. It's just that the return value
> of drm_gpuvm_bo_put() needs to be treated with care.
>
> Maybe we should extend c50a291d621a ("drm/gpuvm: Let drm_gpuvm_bo_put()
> report when the vm_bo object is destroyed") by a note explaining this
> unexpected case,
I can do that.
> or, if not required anymore, simply revert the patch.
Having drm_gpuvm_bo_put() reflect when it released the last ref is
definitely needed in panthor, it's just that it ca
[PATCH] drm/arcpgu: Use devm_platform_get_and_ioremap_resource() in arcpgu_load()
From: Markus Elfring
Date: Mon, 5 Feb 2024 11:16:27 +0100
A wrapper function is available since the commit
890cc39a879906b63912482dfc41944579df2dc6
("drivers: provide devm_platform_get_and_ioremap_resource()").
Thus reuse existing functionality instead of keeping duplicate source code.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/tiny/arcpgu.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tiny/arcpgu.c b/drivers/gpu/drm/tiny/arcpgu.c
index 4f8f3172379e..29929f093d55 100644
--- a/drivers/gpu/drm/tiny/arcpgu.c
+++ b/drivers/gpu/drm/tiny/arcpgu.c
@@ -268,8 +268,7 @@ static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
drm->mode_config.max_height = 1080;
drm->mode_config.funcs = &arcpgu_drm_modecfg_funcs;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- arcpgu->regs = devm_ioremap_resource(&pdev->dev, res);
+ arcpgu->regs = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
if (IS_ERR(arcpgu->regs))
return PTR_ERR(arcpgu->regs);
--
2.43.0
