Re: [PATCH v5 5/9] drm/mediatek: dsi: Replace open-coded instance of HZ_PER_MHZ
Re: [PATCH] drm/msm: Wire up tlb ops
On Tue, Feb 13, 2024 at 09:23:40AM -0800, Rob Clark wrote:
> From: Rob Clark
>
> The brute force iommu_flush_iotlb_all() was good enough for unmap, but
> in some cases a map operation could require removing a table pte entry
> to replace with a block entry. This also requires tlb invalidation.
> Missing this was resulting an obscure iova fault on what should be a
> valid buffer address.
>
> Thanks to Robin Murphy for helping me understand the cause of the fault.
>
> Cc: Robin Murphy
> Fixes: b145c6e65eb0 ("drm/msm: Add support to create a local pagetable")
Sounds like you're missing a
Cc: sta...@vger.kernel.org
here? Or is there some reason not to backport this fix (to 5.9 and later
kernels)?
> Signed-off-by: Rob Clark
Johan
Re: [PATCH v5 4/9] drm/mediatek: dsi: Use bitfield macros where useful
Re: [PATCH v5 3/9] drm/mediatek: dsi: Cleanup functions mtk_dsi_ps_control{_vact}()
Re: [PATCH v6 152/164] drm/bridge: ti-sn65dsi86: Make use of pwmchip_parent() accessor
Hi Doug, On Wed, Feb 14, 2024 at 12:44:23PM -0800, Doug Anderson wrote: > On Wed, Feb 14, 2024 at 1:34 AM Uwe Kleine-König > wrote: > > > > struct pwm_chip::dev is about to change. To not have to touch this > > driver in the same commit as struct pwm_chip::dev, use the accessor > > function provided for exactly this purpose. > > > > Signed-off-by: Uwe Kleine-König > > --- > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 10 +- > > 1 file changed, 5 insertions(+), 5 deletions(-) > > I don't see any differences from v5, so not sure why you didn't carry > forward my Ack [1] on this one. Maybe because of the questions I > asked? Your answers from v5 seemed fine to me. In any case: Indeed, I should have kept the Ack. I cannot say why I dropped it, something wrong on my end for sure as the patch ids match: $ v5=5ff5120f2b4ef6442a1d7c05916a772ec59a8c34.1706182805.git.u.kleine-koe...@pengutronix.de $ v6=10a8d55110fc48a4759e65cc19556858587e94cc.1707900770.git.u.kleine-koe...@pengutronix.de $ $ for v in $v5 $v6; do curl -s https://lore.kernel.org/all/$v/raw | git patch-id; done 9b067a056fd203dd4b37d69b5aff202f42d970f1 9b067a056fd203dd4b37d69b5aff202f42d970f1 Thanks for looking again, I readded your Ack, Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Re: [PATCH v5 2/9] drm/mediatek: dsi: Fix DSI RGB666 formats and definitions
Re: [PATCH v5 1/9] drm/mediatek: dsi: Use GENMASK() for register mask definitions
Re: Bug#1061449: linux-image-6.7-amd64: a boot message from amdgpu
On 27.01.24 14:14, Salvatore Bonaccorso wrote:
>
> In Debian (https://bugs.debian.org/1061449) we got the following
> quotred report:
>
> On Wed, Jan 24, 2024 at 07:38:16PM +0100, Patrice Duroux wrote:
>> Package: src:linux
>> Version: 6.7.1-1~exp1
>> Severity: normal
>>
>> Giving a try to 6.7, here is a message extracted from dmesg:
>>
>> [4.177226] [ cut here ]
>> [4.177227] WARNING: CPU: 6 PID: 248 at
>> drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_factory.c:387
>> construct_phy+0xb26/0xd60 [amdgpu]
>
> Analysis showed that this appears to be a regression from b17ef04bf3a4
> ("drm/amd/display: Pass pwrseq inst for backlight and ABM"). Does that
> ring some bells?
>
> See: https://bugs.debian.org/1061449#27
>
> #regzbot introduced: b17ef04bf3a4
> #regzbot link: https://bugs.debian.org/1061449
> #regzbot title: Regression by b17ef04bf3a4 ("drm/amd/display: Pass pwrseq
> inst for backlight and ABM")
#regzbot monitor:
https://lore.kernel.org/amd-gfx/20240214184006.1356137-8-rodrigo.sique...@amd.com/
#regzbot fix: drm/amd/display: Only allow dig mapping to pwrseq in new asic
#regzbot ignore-activity
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.
[linux-next:master] BUILD REGRESSION 2c3b09aac00d7835023bbc4473ee06696be64fa8
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 2c3b09aac00d7835023bbc4473ee06696be64fa8 Add linux-next specific
files for 20240214
Error/Warning: (recently discovered and may have been fixed)
iptable_nat.c:(.ref.text+0x1a): undefined reference to
`ipt_unregister_table_exit'
xtensa-linux-ld: iptable_nat.c:(.text+0x2b4): undefined reference to
`ipt_register_table'
xtensa-linux-ld: iptable_nat.c:(.text+0x2b8): undefined reference to
`ipt_unregister_table_exit'
xtensa-linux-ld: iptable_nat.c:(.text+0x2cf): undefined reference to
`ipt_alloc_initial_table'
xtensa-linux-ld: net/ipv4/netfilter/iptable_nat.o:(.ref.text+0x4): undefined
reference to `ipt_unregister_table_exit'
xtensa-linux-ld: net/ipv4/netfilter/iptable_nat.o:(.rodata+0x88): undefined
reference to `ipt_do_table'
Unverified Error/Warning (likely false positive, please contact us if
interested):
{standard input}:508: Warning: overflow in branch to .L76; converted into
longer instruction sequence
{standard input}:631: Warning: overflow in branch to .L88; converted into
longer instruction sequence
Error/Warning ids grouped by kconfigs:
gcc_recent_errors
|-- alpha-allyesconfig
| |--
drivers-gpu-drm-amd-amdgpu-ih_v7_0.c:warning:Function-parameter-or-struct-member-ih-not-described-in-ih_v7_0_get_wptr
| |--
drivers-gpu-drm-amd-amdgpu-ih_v7_0.c:warning:Function-parameter-or-struct-member-ih-not-described-in-ih_v7_0_irq_rearm
| |--
drivers-gpu-drm-amd-amdgpu-ih_v7_0.c:warning:Function-parameter-or-struct-member-ih-not-described-in-ih_v7_0_set_rptr
| `--
drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg
|-- arc-allmodconfig
| |--
drivers-gpu-drm-amd-amdgpu-ih_v7_0.c:warning:Function-parameter-or-struct-member-ih-not-described-in-ih_v7_0_get_wptr
| |--
drivers-gpu-drm-amd-amdgpu-ih_v7_0.c:warning:Function-parameter-or-struct-member-ih-not-described-in-ih_v7_0_irq_rearm
| |--
drivers-gpu-drm-amd-amdgpu-ih_v7_0.c:warning:Function-parameter-or-struct-member-ih-not-described-in-ih_v7_0_set_rptr
| `--
drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg
|-- arc-allyesconfig
| |--
drivers-gpu-drm-amd-amdgpu-ih_v7_0.c:warning:Function-parameter-or-struct-member-ih-not-described-in-ih_v7_0_get_wptr
| |--
drivers-gpu-drm-amd-amdgpu-ih_v7_0.c:warning:Function-parameter-or-struct-member-ih-not-described-in-ih_v7_0_irq_rearm
| |--
drivers-gpu-drm-amd-amdgpu-ih_v7_0.c:warning:Function-parameter-or-struct-member-ih-not-described-in-ih_v7_0_set_rptr
| `--
drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg
|-- arm-allmodconfig
| |--
drivers-gpu-drm-amd-amdgpu-ih_v7_0.c:warning:Function-parameter-or-struct-member-ih-not-described-in-ih_v7_0_get_wptr
| |--
drivers-gpu-drm-amd-amdgpu-ih_v7_0.c:warning:Function-parameter-or-struct-member-ih-not-described-in-ih_v7_0_irq_rearm
| |--
drivers-gpu-drm-amd-amdgpu-ih_v7_0.c:warning:Function-parameter-or-struct-member-ih-not-described-in-ih_v7_0_set_rptr
| `--
drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg
|-- arm-allyesconfig
| |--
drivers-gpu-drm-amd-amdgpu-ih_v7_0.c:warning:Function-parameter-or-struct-member-ih-not-described-in-ih_v7_0_get_wptr
| |--
drivers-gpu-drm-amd-amdgpu-ih_v7_0.c:warning:Function-parameter-or-struct-member-ih-not-described-in-ih_v7_0_irq_rearm
| |--
drivers-gpu-drm-amd-amdgpu-ih_v7_0.c:warning:Function-parameter-or-struct-member-ih-not-described-in-ih_v7_0_set_rptr
| `--
drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg
|-- arm64-defconfig
| `--
drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg
|-- csky-allmodconfig
| |--
drivers-gpu-drm-amd-amdgpu-ih_v7_0.c:warning:Function-parameter-or-struct-member-ih-not-described-in-ih_v7_0_get_wptr
| |--
drivers-gpu-drm-amd-amdgpu-ih_v7_0.c:warning:Function-parameter-or-struct-member-ih-not-described-in-ih_v7_0_irq_rearm
| |--
drivers-gpu-drm-amd-amdgpu-ih_v7_0.c:warning:Function-parameter-or-struct-member-ih-not-described-in-ih_v7_0_set_rptr
| `--
drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg
|-- csky-allyesconfig
| |--
drivers-gpu-drm-amd-amdgpu-ih_v7_0.c:warning:Function-parameter-or-struct-member-ih-not-described-in-ih_v7_0_get_wptr
| |--
drivers-gpu-drm-amd-amdgpu-ih_v7_0.c:warning:Function-parameter-or-struct-member-ih-not-described-in-ih_v7_0_irq_rearm
| |--
drivers-gpu-drm-amd-amdgpu-ih_v7_0.c:warning:Function-parameter-or-struct-member-ih
Re: [PATCH v2 2/4] dt-bindings: display/msm: Document the DPU for X1E80100
On Wed, Feb 14, 2024 at 11:24:31PM +0200, Abel Vesa wrote: > Document the DPU for Qualcomm X1E80100 platform in the SM8650 schema, as > they are similar. > > Signed-off-by: Abel Vesa > --- > Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml > b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml > index a01d15a03317..c4087cc5abbd 100644 > --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml > +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml > @@ -13,7 +13,9 @@ $ref: /schemas/display/msm/dpu-common.yaml# > > properties: >compatible: > -const: qcom,sm8650-dpu > +enum: > + - qcom,sm8650-dpu > + - qcom,x1e80100-dpu Patch 1 uses this in the example, so this patch needs to come first. > >reg: > items: > > -- > 2.34.1 >
Re: [PATCH v2 1/4] dt-bindings: display/msm: document MDSS on X1E80100
On Wed, Feb 14, 2024 at 11:24:30PM +0200, Abel Vesa wrote:
> Document the MDSS hardware found on the Qualcomm X1E80100 platform.
>
> Reviewed-by: Krzysztof Kozlowski
> Signed-off-by: Abel Vesa
> ---
> .../bindings/display/msm/qcom,x1e80100-mdss.yaml | 252
> +
> 1 file changed, 252 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.yaml
> b/Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.yaml
> new file mode 100644
> index ..c3e38afab76e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.yaml
> @@ -0,0 +1,252 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/msm/qcom,x1e80100-mdss.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm X1E80100 Display MDSS
> +
> +maintainers:
> + - Abel Vesa
> +
> +description:
> + X1E80100 MSM Mobile Display Subsystem(MDSS), which encapsulates sub-blocks
> like
> + DPU display controller, DP interfaces, etc.
> +
> +$ref: /schemas/display/msm/mdss-common.yaml#
> +
> +properties:
> + compatible:
> +const: qcom,x1e80100-mdss
> +
> + clocks:
> +items:
> + - description: Display AHB
> + - description: Display hf AXI
> + - description: Display core
> +
> + iommus:
> +maxItems: 1
> +
> + interconnects:
> +maxItems: 3
> +
> + interconnect-names:
> +maxItems: 3
> +
> +patternProperties:
> + "^display-controller@[0-9a-f]+$":
> +type: object
additionalProperties: true
> +properties:
> + compatible:
> +const: qcom,x1e80100-dpu
> +
> + "^displayport-controller@[0-9a-f]+$":
> +type: object
additionalProperties: true
> +properties:
> + compatible:
> +const: qcom,x1e80100-dp
> +
> + "^phy@[0-9a-f]+$":
> +type: object
additionalProperties: true
> +properties:
> + compatible:
> +const: qcom,x1e80100-dp-phy
> +
> +required:
> + - compatible
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +display-subsystem@ae0 {
> +compatible = "qcom,x1e80100-mdss";
> +reg = <0x0ae0 0x1000>;
> +reg-names = "mdss";
> +
> +interconnects = <_noc MASTER_MDP 0 _noc SLAVE_LLCC 0>,
> +<_virt MASTER_LLCC 0 _virt SLAVE_EBI1 0>,
> +<_noc MASTER_APPSS_PROC 0 _noc
> SLAVE_DISPLAY_CFG 0>;
> +interconnect-names = "mdp0-mem", "mdp1-mem", "cpu-cfg";
> +
> +resets = <_core_bcr>;
> +
> +power-domains = <_gdsc>;
> +
> +clocks = < DISP_CC_MDSS_AHB_CLK>,
> + < GCC_DISP_HF_AXI_CLK>,
> + < DISP_CC_MDSS_MDP_CLK>;
> +clock-names = "bus", "nrt_bus", "core";
> +
> +interrupts = ;
> +interrupt-controller;
> +#interrupt-cells = <1>;
> +
> +iommus = <_smmu 0x1c00 0x2>;
> +
> +#address-cells = <1>;
> +#size-cells = <1>;
> +ranges;
> +
> +display-controller@ae01000 {
> +compatible = "qcom,x1e80100-dpu";
> +reg = <0x0ae01000 0x8f000>,
> + <0x0aeb 0x2008>;
> +reg-names = "mdp", "vbif";
> +
> +clocks = <_axi_clk>,
> + <_ahb_clk>,
> + <_mdp_lut_clk>,
> + <_mdp_clk>,
> + <_mdp_vsync_clk>;
> +clock-names = "nrt_bus",
> + "iface",
> + "lut",
> + "core",
> + "vsync";
> +
> +assigned-clocks = <_mdp_vsync_clk>;
> +assigned-clock-rates = <1920>;
> +
> +operating-points-v2 = <_opp_table>;
> +power-domains = < RPMHPD_MMCX>;
> +
> +interrupt-parent = <>;
> +interrupts = <0>;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +dpu_intf1_out: endpoint {
> +remote-endpoint = <_in>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +dpu_intf2_out: endpoint {
> +remote-endpoint = <_in>;
> +};
> +};
> +};
> +
> +mdp_opp_table: opp-table {
> +compatible = "operating-points-v2";
> +
> +opp-2 {
> +opp-hz = /bits/ 64 <2>;
> +required-opps = <_opp_low_svs>;
> +};
> +
> +opp-32500 {
> +opp-hz = /bits/ 64
Re: [PATCH 1/2] drm/nouveau: don't fini scheduler if not initialized
On Fri, 2024-02-02 at 17:14 +, Timur Tabi wrote: > On Fri, 2024-02-02 at 01:05 +0100, Danilo Krummrich wrote: > > nouveau_abi16_ioctl_channel_alloc() and nouveau_cli_init() simply call > > their corresponding *_fini() counterpart. This can lead to > > nouveau_sched_fini() being called without struct nouveau_sched ever > > being initialized in the first place. > > Thanks, I've confirmed that these patches do fix the problem. Looks like I spoke too soon, I just hit the problem with the drm-next tree. I'm able to repro the problem by having r535_gsp_init() return an error. r535_gsp_rpc_poll return -EINVAL (I'm testing my own GSP-RM build) and nouveau_sched_fini() is called even though nouveau_sched_init() was never called.
[PATCH 0/3] drm/amd/display: fix codestyle for some dmub files
Marcelo Mendes Spessoto Junior (3): drm/amd/display: clean codestyle errors drm/amd/display: clean codestyle errors drm/amd/display: clean codestyle errors drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 6 +++--- drivers/gpu/drm/amd/display/dmub/src/dmub_dcn32.c | 2 +- drivers/gpu/drm/amd/display/dmub/src/dmub_dcn35.c | 5 +++-- 3 files changed, 7 insertions(+), 6 deletions(-) -- 2.39.2
[PATCH 3/3] drm/amd/display: clean codestyle errors
Use () for macro and adjust initial brace for dmub/src/dmub_dcn35.c
Signed-off-by: Marcelo Mendes Spessoto Junior
---
drivers/gpu/drm/amd/display/dmub/src/dmub_dcn35.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn35.c
b/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn35.c
index 60223efc6..fa38a5ae6 100644
--- a/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn35.c
+++ b/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn35.c
@@ -35,9 +35,10 @@
#define BASE_INNER(seg) ctx->dcn_reg_offsets[seg]
#define CTX dmub
#define REGS dmub->regs_dcn35
-#define REG_OFFSET_EXP(reg_name) BASE(reg##reg_name##_BASE_IDX) + reg##reg_name
+#define REG_OFFSET_EXP(reg_name) (BASE(reg##reg_name##_BASE_IDX) +
reg##reg_name)
-void dmub_srv_dcn35_regs_init(struct dmub_srv *dmub, struct dc_context *ctx) {
+void dmub_srv_dcn35_regs_init(struct dmub_srv *dmub, struct dc_context *ctx)
+{
struct dmub_srv_dcn35_regs *regs = dmub->regs_dcn35;
#define REG_STRUCT regs
--
2.39.2
[PATCH 2/3] drm/amd/display: clean codestyle error
Use () for complex macro in dmub/src/dmub_dcn32.c
Signed-off-by: Marcelo Mendes Spessoto Junior
---
drivers/gpu/drm/amd/display/dmub/src/dmub_dcn32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn32.c
b/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn32.c
index 0d521eeda..db9bf55f5 100644
--- a/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn32.c
+++ b/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn32.c
@@ -35,7 +35,7 @@
#define BASE_INNER(seg) ctx->dcn_reg_offsets[seg]
#define CTX dmub
#define REGS dmub->regs_dcn32
-#define REG_OFFSET_EXP(reg_name) BASE(reg##reg_name##_BASE_IDX) + reg##reg_name
+#define REG_OFFSET_EXP(reg_name) (BASE(reg##reg_name##_BASE_IDX) +
reg##reg_name)
void dmub_srv_dcn32_regs_init(struct dmub_srv *dmub, struct dc_context *ctx)
{
--
2.39.2
[PATCH 1/3] drm/amd/display: clean codestyle errors
Use flexible array members in dmub/inc/dmub_cmd.h
Signed-off-by: Marcelo Mendes Spessoto Junior
---
drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
b/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
index a529e369b..d748bedda 100644
--- a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
+++ b/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
@@ -1588,7 +1588,7 @@ struct dmub_rb_cmd_idle_opt_dcn_restore {
*/
struct dmub_dcn_notify_idle_cntl_data {
uint8_t driver_idle;
- uint8_t pad[1];
+ uint8_t pad[];
};
/**
@@ -2421,7 +2421,7 @@ struct dmub_cmd_psr_copy_settings_data {
/**
* @ rate_control_caps : Indicate FreeSync PSR Sink Capabilities
*/
- uint8_t rate_control_caps ;
+ uint8_t rate_control_caps;
/*
* Force PSRSU always doing full frame update
*/
@@ -3921,7 +3921,7 @@ struct dmub_cmd_abm_pause_data {
/**
* Explicit padding to 4 byte boundary.
*/
- uint8_t pad[1];
+ uint8_t pad[];
};
/**
--
2.39.2
Re: [PATCH v6 3/5] drm: Add support to get EDID from ACPI
On Wed, Feb 14, 2024 at 03:57:54PM -0600, Mario Limonciello wrote:
> Some manufacturers have intentionally put an EDID that differs from
> the EDID on the internal panel on laptops. Drivers that prefer to
> fetch this EDID can set a bit on the drm_connector to indicate that
> the DRM EDID helpers should try to fetch it and it is preferred if
> it's present.
>
> Signed-off-by: Mario Limonciello
> ---
> drivers/gpu/drm/Kconfig | 1 +
> drivers/gpu/drm/drm_edid.c | 109 +---
> include/drm/drm_connector.h | 6 ++
> include/drm/drm_edid.h | 1 +
> 4 files changed, 109 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 872edb47bb53..3db89e6af01d 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -8,6 +8,7 @@
> menuconfig DRM
> tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI
> support)"
> depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA
> + depends on (ACPI_VIDEO || ACPI_VIDEO=n)
> select DRM_PANEL_ORIENTATION_QUIRKS
> select DRM_KMS_HELPER if DRM_FBDEV_EMULATION
> select FB_CORE if DRM_FBDEV_EMULATION
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 923c4423151c..cdc30c6d05d5 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -28,6 +28,7 @@
> * DEALINGS IN THE SOFTWARE.
> */
>
> +#include
> #include
> #include
> #include
> @@ -2188,6 +2189,58 @@ drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned
> int block, size_t len)
> return ret == xfers ? 0 : -1;
> }
>
> +/**
> + * drm_do_probe_acpi_edid() - get EDID information via ACPI _DDC
> + * @data: struct drm_connector
> + * @buf: EDID data buffer to be filled
> + * @block: 128 byte EDID block to start fetching from
> + * @len: EDID data buffer length to fetch
> + *
> + * Try to fetch EDID information by calling acpi_video_get_edid() function.
> + *
> + * Return: 0 on success or error code on failure.
> + */
> +static int
> +drm_do_probe_acpi_edid(void *data, u8 *buf, unsigned int block, size_t len)
> +{
> + struct drm_connector *connector = data;
> + struct drm_device *ddev = connector->dev;
> + struct acpi_device *acpidev = ACPI_COMPANION(ddev->dev);
> + unsigned char start = block * EDID_LENGTH;
> + void *edid;
> + int r;
> +
> + if (!acpidev)
> + return -ENODEV;
> +
> + switch (connector->connector_type) {
> + case DRM_MODE_CONNECTOR_LVDS:
> + case DRM_MODE_CONNECTOR_eDP:
> + break;
> + default:
> + return -EINVAL;
> + }
We could have other types of connectors that want this too.
I don't see any real benefit in having this check tbh. Drivers
should simply notset the flag on connectors where it won't work,
and only the driver can really know that.
> + /* fetch the entire edid from BIOS */
> + r = acpi_video_get_edid(acpidev, ACPI_VIDEO_DISPLAY_LCD, -1, );
> + if (r < 0) {
> + DRM_DEBUG_KMS("Failed to get EDID from ACPI: %d\n", r);
> + return r;
> + }
> + if (len > r || start > r || start + len > r) {
> + r = -EINVAL;
> + goto cleanup;
> + }
> +
> + memcpy(buf, edid + start, len);
> + r = 0;
> +
> +cleanup:
> + kfree(edid);
> +
> + return r;
> +}
> +
> static void connector_bad_edid(struct drm_connector *connector,
> const struct edid *edid, int num_blocks)
> {
> @@ -2621,7 +2674,8 @@ EXPORT_SYMBOL(drm_probe_ddc);
> * @connector: connector we're probing
> * @adapter: I2C adapter to use for DDC
> *
> - * Poke the given I2C channel to grab EDID data if possible. If found,
> + * If the connector allows it, try to fetch EDID data using ACPI. If not
> found
> + * poke the given I2C channel to grab EDID data if possible. If found,
> * attach it to the connector.
> *
> * Return: Pointer to valid EDID or NULL if we couldn't find any.
> @@ -2629,20 +2683,50 @@ EXPORT_SYMBOL(drm_probe_ddc);
> struct edid *drm_get_edid(struct drm_connector *connector,
> struct i2c_adapter *adapter)
> {
> - struct edid *edid;
> + struct edid *edid = NULL;
>
> if (connector->force == DRM_FORCE_OFF)
> return NULL;
>
> - if (connector->force == DRM_FORCE_UNSPECIFIED &&
> !drm_probe_ddc(adapter))
> - return NULL;
> + if (connector->acpi_edid_allowed)
> + edid = _drm_do_get_edid(connector, drm_do_probe_acpi_edid,
> connector, NULL);
> +
> + if (!edid) {
> + if (connector->force == DRM_FORCE_UNSPECIFIED &&
> !drm_probe_ddc(adapter))
> + return NULL;
> + edid = _drm_do_get_edid(connector, drm_do_probe_ddc_edid,
> adapter, NULL);
> + }
>
> - edid = _drm_do_get_edid(connector, drm_do_probe_ddc_edid, adapter,
> NULL);
>
Re: [PATCH] drm/dp: Don't attempt AUX transfers when eDP panels are not powered
Hi, On Tue, Feb 13, 2024 at 10:25 PM Hsin-Yi Wang wrote: > > On Wed, Feb 14, 2024 at 2:23 PM 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. > > > > Signed-off-by: Douglas Anderson > > --- > > Reviewed-by: Hsin-Yi Wang Thanks for the review! Given that this touches core DRM code and that I never got confirmation that Jani's concerns were addressed with my previous response, I'm still going to wait a little while before applying. I'm on vacation for most of next week, but if there are no further replies between now and then I'll plan to apply this to "drm-misc-next" the week of Feb 26th. If someone else wants to apply this before I do then I certainly won't object. Jani: if you feel this needs more discussion or otherwise object to this patch landing then please yell. Likewise if anyone else in the community wants to throw in their opinion, feel free. -Doug
Re: [PATCH v2 2/4] dt-bindings: display/msm: Document the DPU for X1E80100
On Wed, 14 Feb 2024 23:24:31 +0200, Abel Vesa wrote: > Document the DPU for Qualcomm X1E80100 platform in the SM8650 schema, as > they are similar. > > Signed-off-by: Abel Vesa > --- > Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240214-x1e80100-display-v2-2-cf05ba887...@linaro.org The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v2 1/4] dt-bindings: display/msm: document MDSS on X1E80100
On Wed, 14 Feb 2024 23:24:30 +0200, Abel Vesa wrote: > Document the MDSS hardware found on the Qualcomm X1E80100 platform. > > Reviewed-by: Krzysztof Kozlowski > Signed-off-by: Abel Vesa > --- > .../bindings/display/msm/qcom,x1e80100-mdss.yaml | 252 > + > 1 file changed, 252 insertions(+) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.example.dts:24:18: fatal error: dt-bindings/clock/qcom,x1e80100-dispcc.h: No such file or directory 24 | #include | ^~ compilation terminated. make[2]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.example.dtb] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1428: dt_binding_check] Error 2 make: *** [Makefile:240: __sub-make] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240214-x1e80100-display-v2-1-cf05ba887...@linaro.org The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
[PATCH v6 4/5] drm/amd: Fetch the EDID from _DDC if available for eDP
Some manufacturers have intentionally put an EDID that differs from
the EDID on the internal panel on laptops.
Attempt to fetch this EDID if it exists and prefer it over the EDID
that is provided by the panel. If a user prefers to use the EDID from
the panel, offer a module parameter that would disable this.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c| 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 8
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +++-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 ++
5 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 312dfaec7b4a..fcec39a62a39 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -215,6 +215,7 @@ extern int amdgpu_smartshift_bias;
extern int amdgpu_use_xgmi_p2p;
extern int amdgpu_mtype_local;
extern bool enforce_isolation;
+extern bool acpi_edid;
#ifdef CONFIG_HSA_AMD
extern int sched_policy;
extern bool debug_evictions;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index 9caba10315a8..9165a199ac9b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -281,6 +281,9 @@ static void amdgpu_connector_get_edid(struct drm_connector
*connector)
if (amdgpu_connector->edid)
return;
+ /* if the BIOS specifies the EDID via _DDC, prefer this */
+ connector->acpi_edid_allowed = acpi_edid;
+
/* on hw with routers, select right port */
if (amdgpu_connector->router.ddc_valid)
amdgpu_i2c_router_select_ddc_port(amdgpu_connector);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 161ecf9b4174..9676df447a57 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -166,6 +166,7 @@ uint amdgpu_sdma_phase_quantum = 32;
char *amdgpu_disable_cu;
char *amdgpu_virtual_display;
bool enforce_isolation;
+bool acpi_edid = true;
/*
* OverDrive(bit 14) disabled by default
* GFX DCS(bit 19) disabled by default
@@ -990,6 +991,13 @@ MODULE_PARM_DESC(wbrf,
"Enable Wifi RFI interference mitigation (0 = disabled, 1 = enabled, -1
= auto(default)");
module_param_named(wbrf, amdgpu_wbrf, int, 0444);
+/**
+ * DOC: acpi_edid (bool)
+ * Try to fetch EDID for eDP display from BIOS using ACPI _DDC method.
+ */
+module_param(acpi_edid, bool, 0444);
+MODULE_PARM_DESC(acpi_edid, "Fetch EDID for eDP display from BIOS");
+
/* These devices are not supported by amdgpu.
* They are supported by the mach64, r128, radeon drivers
*/
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 467796d97313..504577ea36e7 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6649,8 +6649,10 @@ static void amdgpu_dm_connector_funcs_force(struct
drm_connector *connector)
* Note: drm_get_edid gets edid in the following order:
* 1) override EDID if set via edid_override debugfs,
* 2) firmware EDID if set via edid_firmware module parameter
-* 3) regular DDC read.
+* 3) ACPI EDID if allowed via module parameter
+* 4) regular DDC read.
*/
+ connector->acpi_edid_allowed = acpi_edid;
edid = drm_get_edid(connector, _connector->ddc_bus->aux.ddc);
if (!edid) {
DRM_ERROR("No EDID found on connector: %s.\n", connector->name);
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 85b7f58a7f35..d570a1b6141b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -910,6 +910,8 @@ enum dc_edid_status dm_helpers_read_local_edid(
* do check sum and retry to make sure read correct edid.
*/
do {
+ /* prefer ACPI over panel for eDP */
+ connector->acpi_edid_allowed = acpi_edid;
edid = drm_get_edid(>base, ddc);
--
2.34.1
[PATCH v6 5/5] drm/nouveau: Use drm_edid_read_acpi() helper
Rather than inventing a wrapper to acpi_video_get_edid() use the
one provided by drm. This fixes two problems:
1. A memory leak that the memory provided by the ACPI call was
never freed.
2. Validation of the BIOS provided blob.
Convert the usage in nouveau_connector_detect_lvds() to use
struct drm_edid at the same time.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 27
drivers/gpu/drm/nouveau/nouveau_acpi.h | 2 --
drivers/gpu/drm/nouveau/nouveau_connector.c | 35 +
3 files changed, 14 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index 8f0c69aad248..de9daafb3fbb 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -360,33 +360,6 @@ void nouveau_unregister_dsm_handler(void) {}
void nouveau_switcheroo_optimus_dsm(void) {}
#endif
-void *
-nouveau_acpi_edid(struct drm_device *dev, struct drm_connector *connector)
-{
- struct acpi_device *acpidev;
- int type, ret;
- void *edid;
-
- switch (connector->connector_type) {
- case DRM_MODE_CONNECTOR_LVDS:
- case DRM_MODE_CONNECTOR_eDP:
- type = ACPI_VIDEO_DISPLAY_LCD;
- break;
- default:
- return NULL;
- }
-
- acpidev = ACPI_COMPANION(dev->dev);
- if (!acpidev)
- return NULL;
-
- ret = acpi_video_get_edid(acpidev, type, -1, );
- if (ret < 0)
- return NULL;
-
- return kmemdup(edid, EDID_LENGTH, GFP_KERNEL);
-}
-
bool nouveau_acpi_video_backlight_use_native(void)
{
return acpi_video_backlight_use_native();
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.h
b/drivers/gpu/drm/nouveau/nouveau_acpi.h
index e39dd8b94b8b..6a3def8e6cca 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.h
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.h
@@ -10,7 +10,6 @@ bool nouveau_is_v1_dsm(void);
void nouveau_register_dsm_handler(void);
void nouveau_unregister_dsm_handler(void);
void nouveau_switcheroo_optimus_dsm(void);
-void *nouveau_acpi_edid(struct drm_device *, struct drm_connector *);
bool nouveau_acpi_video_backlight_use_native(void);
void nouveau_acpi_video_register_backlight(void);
#else
@@ -19,7 +18,6 @@ static inline bool nouveau_is_v1_dsm(void) { return false; };
static inline void nouveau_register_dsm_handler(void) {}
static inline void nouveau_unregister_dsm_handler(void) {}
static inline void nouveau_switcheroo_optimus_dsm(void) {}
-static inline void *nouveau_acpi_edid(struct drm_device *dev, struct
drm_connector *connector) { return NULL; }
static inline bool nouveau_acpi_video_backlight_use_native(void) { return
true; }
static inline void nouveau_acpi_video_register_backlight(void) {}
#endif
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 856b3ef5edb8..492035dc8453 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -687,22 +687,13 @@ nouveau_connector_detect_lvds(struct drm_connector
*connector, bool force)
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_connector *nv_connector = nouveau_connector(connector);
struct nouveau_encoder *nv_encoder = NULL;
- struct edid *edid = NULL;
+ const struct drm_edid *drm_edid = NULL;
enum drm_connector_status status = connector_status_disconnected;
nv_encoder = find_encoder(connector, DCB_OUTPUT_LVDS);
if (!nv_encoder)
goto out;
- /* Try retrieving EDID via DDC */
- if (!drm->vbios.fp_no_ddc) {
- status = nouveau_connector_detect(connector, force);
- if (status == connector_status_connected) {
- edid = nv_connector->edid;
- goto out;
- }
- }
-
/* On some laptops (Sony, i'm looking at you) there appears to
* be no direct way of accessing the panel's EDID. The only
* option available to us appears to be to ask ACPI for help..
@@ -712,10 +703,14 @@ nouveau_connector_detect_lvds(struct drm_connector
*connector, bool force)
* the nouveau decides an entry in the VBIOS FP mode table is
* valid - it's not (rh#613284)
*/
- if (nv_encoder->dcb->lvdsconf.use_acpi_for_edid) {
- edid = nouveau_acpi_edid(dev, connector);
- if (edid) {
- status = connector_status_connected;
+ if (nv_encoder->dcb->lvdsconf.use_acpi_for_edid)
+ connector->acpi_edid_allowed = true;
+
+ /* Try retrieving EDID via BIOS or DDC */
+ if (!drm->vbios.fp_no_ddc ||
nv_encoder->dcb->lvdsconf.use_acpi_for_edid) {
+ status = nouveau_connector_detect(connector, force);
+ if (status == connector_status_connected) {
+
[PATCH v6 2/5] drm: Stop using `select BACKLIGHT_CLASS_DEVICE`
Many drivers ab(use) `select BACKLIGHT_CLASS_DEVICE` to avoid dependency problems. This however makes it impossible for DRM core to be able to add a dependency on ACPI_VIDEO. Switch users of `select BACKLIGHT_CLASS_DEVICE` to `depends on BACKLIGHT_CLASS_DEVICE`. Signed-off-by: Mario Limonciello --- drivers/gpu/drm/bridge/Kconfig | 2 +- drivers/gpu/drm/fsl-dcu/Kconfig | 2 +- drivers/gpu/drm/gud/Kconfig | 2 +- drivers/gpu/drm/renesas/shmobile/Kconfig | 2 +- drivers/gpu/drm/solomon/Kconfig | 2 +- drivers/gpu/drm/tilcdc/Kconfig | 2 +- drivers/gpu/drm/tiny/Kconfig | 14 +++--- drivers/platform/x86/Kconfig | 4 ++-- drivers/usb/misc/Kconfig | 2 +- 9 files changed, 16 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index efd996f6c138..c4e0d506a389 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -218,9 +218,9 @@ config DRM_NXP_PTN3460 config DRM_PARADE_PS8622 tristate "Parade eDP/LVDS bridge" depends on OF + depends on BACKLIGHT_CLASS_DEVICE select DRM_PANEL select DRM_KMS_HELPER - select BACKLIGHT_CLASS_DEVICE help Parade eDP-LVDS bridge chip driver. diff --git a/drivers/gpu/drm/fsl-dcu/Kconfig b/drivers/gpu/drm/fsl-dcu/Kconfig index 5ca71ef87325..93202786bec5 100644 --- a/drivers/gpu/drm/fsl-dcu/Kconfig +++ b/drivers/gpu/drm/fsl-dcu/Kconfig @@ -2,7 +2,7 @@ config DRM_FSL_DCU tristate "DRM Support for Freescale DCU" depends on DRM && OF && ARM && COMMON_CLK - select BACKLIGHT_CLASS_DEVICE + depends on BACKLIGHT_CLASS_DEVICE select DRM_GEM_DMA_HELPER select DRM_KMS_HELPER select DRM_PANEL diff --git a/drivers/gpu/drm/gud/Kconfig b/drivers/gpu/drm/gud/Kconfig index 9c1e61f9eec3..44553514ad64 100644 --- a/drivers/gpu/drm/gud/Kconfig +++ b/drivers/gpu/drm/gud/Kconfig @@ -3,10 +3,10 @@ config DRM_GUD tristate "GUD USB Display" depends on DRM && USB && MMU + depends on BACKLIGHT_CLASS_DEVICE select LZ4_COMPRESS select DRM_KMS_HELPER select DRM_GEM_SHMEM_HELPER - select BACKLIGHT_CLASS_DEVICE help This is a DRM display driver for GUD USB Displays or display adapters. diff --git a/drivers/gpu/drm/renesas/shmobile/Kconfig b/drivers/gpu/drm/renesas/shmobile/Kconfig index 027220b8fe1c..6b36dee443eb 100644 --- a/drivers/gpu/drm/renesas/shmobile/Kconfig +++ b/drivers/gpu/drm/renesas/shmobile/Kconfig @@ -3,7 +3,7 @@ config DRM_SHMOBILE tristate "DRM Support for SH Mobile" depends on DRM && PM depends on ARCH_RENESAS || ARCH_SHMOBILE || COMPILE_TEST - select BACKLIGHT_CLASS_DEVICE + depends on BACKLIGHT_CLASS_DEVICE select DRM_KMS_HELPER select DRM_GEM_DMA_HELPER select VIDEOMODE_HELPERS diff --git a/drivers/gpu/drm/solomon/Kconfig b/drivers/gpu/drm/solomon/Kconfig index c3ee956c2bb9..2b36ac8e0913 100644 --- a/drivers/gpu/drm/solomon/Kconfig +++ b/drivers/gpu/drm/solomon/Kconfig @@ -1,7 +1,7 @@ config DRM_SSD130X tristate "DRM support for Solomon SSD13xx OLED displays" depends on DRM && MMU - select BACKLIGHT_CLASS_DEVICE + depends on BACKLIGHT_CLASS_DEVICE select DRM_GEM_SHMEM_HELPER select DRM_KMS_HELPER help diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig index d3bd2d7a181e..640adf075bba 100644 --- a/drivers/gpu/drm/tilcdc/Kconfig +++ b/drivers/gpu/drm/tilcdc/Kconfig @@ -2,12 +2,12 @@ config DRM_TILCDC tristate "DRM Support for TI LCDC Display Controller" depends on DRM && OF && ARM + depends on BACKLIGHT_CLASS_DEVICE select DRM_KMS_HELPER select DRM_GEM_DMA_HELPER select DRM_BRIDGE select DRM_PANEL_BRIDGE select VIDEOMODE_HELPERS - select BACKLIGHT_CLASS_DEVICE help Choose this option if you have an TI SoC with LCDC display controller, for example AM33xx in beagle-bone, DA8xx, or diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig index f6889f649bc1..d5160a6b5d72 100644 --- a/drivers/gpu/drm/tiny/Kconfig +++ b/drivers/gpu/drm/tiny/Kconfig @@ -67,10 +67,10 @@ config DRM_OFDRM config DRM_PANEL_MIPI_DBI tristate "DRM support for MIPI DBI compatible panels" depends on DRM && SPI + depends on BACKLIGHT_CLASS_DEVICE select DRM_KMS_HELPER select DRM_GEM_DMA_HELPER select DRM_MIPI_DBI - select BACKLIGHT_CLASS_DEVICE select VIDEOMODE_HELPERS help Say Y here if you want to enable support for MIPI DBI compatible @@ -99,10 +99,10 @@ config DRM_SIMPLEDRM config TINYDRM_HX8357D tristate "DRM support for HX8357D display panels" depends on DRM && SPI + depends on
[PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers
Many DRM drivers (ab)use `select ACPI_VIDEO` and to avoid problems will then select all the dependencies for ACPI_VIDEO. This creates a soft dependency, but makes it very hard to use ACPI_VIDEO in DRM core. Switch everything else over to use `depends on ACPI_VIDEO` instead. Signed-off-by: Mario Limonciello --- drivers/gpu/drm/amd/amdgpu/Kconfig | 9 + drivers/gpu/drm/gma500/Kconfig | 7 +-- drivers/gpu/drm/i915/Kconfig | 9 + drivers/gpu/drm/nouveau/Kconfig| 9 + drivers/gpu/drm/radeon/Kconfig | 9 + drivers/gpu/drm/xe/Kconfig | 8 +--- drivers/platform/loongarch/Kconfig | 2 +- drivers/staging/olpc_dcon/Kconfig | 2 +- drivers/video/fbdev/core/Kconfig | 2 +- 9 files changed, 9 insertions(+), 48 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig b/drivers/gpu/drm/amd/amdgpu/Kconfig index 22d88f8ef527..49c3b6eeef76 100644 --- a/drivers/gpu/drm/amd/amdgpu/Kconfig +++ b/drivers/gpu/drm/amd/amdgpu/Kconfig @@ -4,6 +4,7 @@ config DRM_AMDGPU tristate "AMD GPU" depends on DRM && PCI && MMU depends on !UML + depends on ACPI_VIDEO || !ACPI select FW_LOADER select DRM_DISPLAY_DP_HELPER select DRM_DISPLAY_HDMI_HELPER @@ -17,18 +18,10 @@ config DRM_AMDGPU select HWMON select I2C select I2C_ALGOBIT - select BACKLIGHT_CLASS_DEVICE select INTERVAL_TREE select DRM_BUDDY select DRM_SUBALLOC_HELPER select DRM_EXEC - # amdgpu depends on ACPI_VIDEO when ACPI is enabled, for select to work - # ACPI_VIDEO's dependencies must also be selected. - select INPUT if ACPI - select ACPI_VIDEO if ACPI - # On x86 ACPI_VIDEO also needs ACPI_WMI - select X86_PLATFORM_DEVICES if ACPI && X86 - select ACPI_WMI if ACPI && X86 help Choose this option if you have a recent AMD Radeon graphics card. diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig index efb4a2dd2f80..a974cdde4b9c 100644 --- a/drivers/gpu/drm/gma500/Kconfig +++ b/drivers/gpu/drm/gma500/Kconfig @@ -2,16 +2,11 @@ config DRM_GMA500 tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" depends on DRM && PCI && X86 && MMU + depends on ACPI_VIDEO || !ACPI select DRM_KMS_HELPER select FB_IOMEM_HELPERS if DRM_FBDEV_EMULATION select I2C select I2C_ALGOBIT - # GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like i915 - select ACPI_VIDEO if ACPI - select BACKLIGHT_CLASS_DEVICE if ACPI - select INPUT if ACPI - select X86_PLATFORM_DEVICES if ACPI - select ACPI_WMI if ACPI help Say yes for an experimental 2D KMS framebuffer driver for the Intel GMA500 (Poulsbo), Intel GMA600 (Moorestown/Oak Trail) and diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index b5d6e3352071..e99405c18c22 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -4,6 +4,7 @@ config DRM_I915 depends on DRM depends on X86 && PCI depends on !PREEMPT_RT + depends on ACPI_VIDEO || !ACPI select INTEL_GTT if X86 select INTERVAL_TREE # we need shmfs for the swappable backing store, and in particular @@ -22,14 +23,6 @@ config DRM_I915 select I2C select I2C_ALGOBIT select IRQ_WORK - # i915 depends on ACPI_VIDEO when ACPI is enabled - # but for select to work, need to select ACPI_VIDEO's dependencies, ick - select BACKLIGHT_CLASS_DEVICE if ACPI - select INPUT if ACPI - select X86_PLATFORM_DEVICES if ACPI - select ACPI_WMI if ACPI - select ACPI_VIDEO if ACPI - select ACPI_BUTTON if ACPI select SYNC_FILE select IOSF_MBI if X86 select CRC32 diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig index 1e6aaf95ff7c..a3768484cbf5 100644 --- a/drivers/gpu/drm/nouveau/Kconfig +++ b/drivers/gpu/drm/nouveau/Kconfig @@ -2,6 +2,7 @@ config DRM_NOUVEAU tristate "Nouveau (NVIDIA) cards" depends on DRM && PCI && MMU + depends on ACPI_VIDEO || !ACPI select IOMMU_API select FW_LOADER select DRM_DISPLAY_DP_HELPER @@ -15,16 +16,8 @@ config DRM_NOUVEAU select DRM_SCHED select I2C select I2C_ALGOBIT - select BACKLIGHT_CLASS_DEVICE if DRM_NOUVEAU_BACKLIGHT - select X86_PLATFORM_DEVICES if ACPI && X86 - select ACPI_WMI if ACPI && X86 - select MXM_WMI if ACPI && X86 select POWER_SUPPLY - # Similar to i915, we need to select ACPI_VIDEO and it's dependencies - select BACKLIGHT_CLASS_DEVICE if ACPI && X86 - select INPUT if ACPI && X86 select THERMAL if ACPI && X86 - select ACPI_VIDEO if ACPI && X86 select SND_HDA_COMPONENT if SND_HDA_CORE help Choose this option for
[PATCH v6 3/5] drm: Add support to get EDID from ACPI
Some manufacturers have intentionally put an EDID that differs from
the EDID on the internal panel on laptops. Drivers that prefer to
fetch this EDID can set a bit on the drm_connector to indicate that
the DRM EDID helpers should try to fetch it and it is preferred if
it's present.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/drm_edid.c | 109 +---
include/drm/drm_connector.h | 6 ++
include/drm/drm_edid.h | 1 +
4 files changed, 109 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 872edb47bb53..3db89e6af01d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -8,6 +8,7 @@
menuconfig DRM
tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI
support)"
depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA
+ depends on (ACPI_VIDEO || ACPI_VIDEO=n)
select DRM_PANEL_ORIENTATION_QUIRKS
select DRM_KMS_HELPER if DRM_FBDEV_EMULATION
select FB_CORE if DRM_FBDEV_EMULATION
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 923c4423151c..cdc30c6d05d5 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -28,6 +28,7 @@
* DEALINGS IN THE SOFTWARE.
*/
+#include
#include
#include
#include
@@ -2188,6 +2189,58 @@ drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned int
block, size_t len)
return ret == xfers ? 0 : -1;
}
+/**
+ * drm_do_probe_acpi_edid() - get EDID information via ACPI _DDC
+ * @data: struct drm_connector
+ * @buf: EDID data buffer to be filled
+ * @block: 128 byte EDID block to start fetching from
+ * @len: EDID data buffer length to fetch
+ *
+ * Try to fetch EDID information by calling acpi_video_get_edid() function.
+ *
+ * Return: 0 on success or error code on failure.
+ */
+static int
+drm_do_probe_acpi_edid(void *data, u8 *buf, unsigned int block, size_t len)
+{
+ struct drm_connector *connector = data;
+ struct drm_device *ddev = connector->dev;
+ struct acpi_device *acpidev = ACPI_COMPANION(ddev->dev);
+ unsigned char start = block * EDID_LENGTH;
+ void *edid;
+ int r;
+
+ if (!acpidev)
+ return -ENODEV;
+
+ switch (connector->connector_type) {
+ case DRM_MODE_CONNECTOR_LVDS:
+ case DRM_MODE_CONNECTOR_eDP:
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ /* fetch the entire edid from BIOS */
+ r = acpi_video_get_edid(acpidev, ACPI_VIDEO_DISPLAY_LCD, -1, );
+ if (r < 0) {
+ DRM_DEBUG_KMS("Failed to get EDID from ACPI: %d\n", r);
+ return r;
+ }
+ if (len > r || start > r || start + len > r) {
+ r = -EINVAL;
+ goto cleanup;
+ }
+
+ memcpy(buf, edid + start, len);
+ r = 0;
+
+cleanup:
+ kfree(edid);
+
+ return r;
+}
+
static void connector_bad_edid(struct drm_connector *connector,
const struct edid *edid, int num_blocks)
{
@@ -2621,7 +2674,8 @@ EXPORT_SYMBOL(drm_probe_ddc);
* @connector: connector we're probing
* @adapter: I2C adapter to use for DDC
*
- * Poke the given I2C channel to grab EDID data if possible. If found,
+ * If the connector allows it, try to fetch EDID data using ACPI. If not found
+ * poke the given I2C channel to grab EDID data if possible. If found,
* attach it to the connector.
*
* Return: Pointer to valid EDID or NULL if we couldn't find any.
@@ -2629,20 +2683,50 @@ EXPORT_SYMBOL(drm_probe_ddc);
struct edid *drm_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter)
{
- struct edid *edid;
+ struct edid *edid = NULL;
if (connector->force == DRM_FORCE_OFF)
return NULL;
- if (connector->force == DRM_FORCE_UNSPECIFIED &&
!drm_probe_ddc(adapter))
- return NULL;
+ if (connector->acpi_edid_allowed)
+ edid = _drm_do_get_edid(connector, drm_do_probe_acpi_edid,
connector, NULL);
+
+ if (!edid) {
+ if (connector->force == DRM_FORCE_UNSPECIFIED &&
!drm_probe_ddc(adapter))
+ return NULL;
+ edid = _drm_do_get_edid(connector, drm_do_probe_ddc_edid,
adapter, NULL);
+ }
- edid = _drm_do_get_edid(connector, drm_do_probe_ddc_edid, adapter,
NULL);
drm_connector_update_edid_property(connector, edid);
return edid;
}
EXPORT_SYMBOL(drm_get_edid);
+/**
+ * drm_edid_read_acpi - get EDID data, if available
+ * @connector: connector we're probing
+ *
+ * Use the BIOS to attempt to grab EDID data if possible.
+ *
+ * The returned pointer must be freed using drm_edid_free().
+ *
+ * Return: Pointer to valid EDID or NULL if we couldn't find any.
+ */
+const struct drm_edid *drm_edid_read_acpi(struct drm_connector *connector)
+{
+
[PATCH v6 0/5] Add support for getting EDID over ACPI to DRM
This series adds the ability to fetch the EDID through ACPI for laptop panels. Drivers need to opt into the behavior. In this series it's enabled by default for all eDP or LVDS panels with AMDGPU and certain panels for Nouveau. Mario Limonciello (5): drm: Stop using `select ACPI_VIDEO` in all drivers drm: Stop using `select BACKLIGHT_CLASS_DEVICE` drm: Add support to get EDID from ACPI drm/amd: Fetch the EDID from _DDC if available for eDP drm/nouveau: Use drm_edid_read_acpi() helper drivers/gpu/drm/Kconfig | 1 + drivers/gpu/drm/amd/amdgpu/Kconfig| 9 +- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 + .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 3 + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 8 ++ .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +- .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 + drivers/gpu/drm/bridge/Kconfig| 2 +- drivers/gpu/drm/drm_edid.c| 109 -- drivers/gpu/drm/fsl-dcu/Kconfig | 2 +- drivers/gpu/drm/gma500/Kconfig| 7 +- drivers/gpu/drm/gud/Kconfig | 2 +- drivers/gpu/drm/i915/Kconfig | 9 +- drivers/gpu/drm/nouveau/Kconfig | 9 +- drivers/gpu/drm/nouveau/nouveau_acpi.c| 27 - drivers/gpu/drm/nouveau/nouveau_acpi.h| 2 - drivers/gpu/drm/nouveau/nouveau_connector.c | 35 +++--- drivers/gpu/drm/radeon/Kconfig| 9 +- drivers/gpu/drm/renesas/shmobile/Kconfig | 2 +- drivers/gpu/drm/solomon/Kconfig | 2 +- drivers/gpu/drm/tilcdc/Kconfig| 2 +- drivers/gpu/drm/tiny/Kconfig | 14 +-- drivers/gpu/drm/xe/Kconfig| 8 +- drivers/platform/loongarch/Kconfig| 2 +- drivers/platform/x86/Kconfig | 4 +- drivers/staging/olpc_dcon/Kconfig | 2 +- drivers/usb/misc/Kconfig | 2 +- drivers/video/fbdev/core/Kconfig | 2 +- include/drm/drm_connector.h | 6 + include/drm/drm_edid.h| 1 + 30 files changed, 165 insertions(+), 123 deletions(-) -- 2.34.1
Re: [PATCH 3/5] drm: msm: add support for A750 GPU
On 12.02.2024 15:45, Neil Armstrong wrote:
> On 12/02/2024 11:46, Konrad Dybcio wrote:
>> On 12.02.2024 11:37, Neil Armstrong wrote:
>>> Add support for the A750 GPU found on the SM8650 platform
>>>
>>> Unlike the the very close A740 GPU on the SM8550 SoC, the A750 GPU
>>> doesn't have an HWCFG block but a separate register set.
>>>
>>> The missing registers are added in the a6xx.xml.h file that would
>>> require a subsequent sync and the non-existent hwcfg is handled
>>> in a6xx_set_hwcg().
>>
>> These should also be submitted to mesa to make sure the next header sync
>> doesn't wipe them
>
> Ack submitting them right now:
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27576
Thanks
>
>>
>> [...]
>>
>>> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
>>> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
>>> @@ -958,10 +958,11 @@ static void a6xx_set_hwcg(struct msm_gpu *gpu, bool
>>> state)
>>> struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
>>> struct a6xx_gmu *gmu = _gpu->gmu;
>>> const struct adreno_reglist *reg;
>>> + bool skip_programming = !(adreno_gpu->info->hwcg ||
>>> adreno_is_a7xx(adreno_gpu));
>>
>> is_a750?
>
> OK right, I was thinking of the next gpu which will probably also miss an
> hwcfg
>
>>
>>> unsigned int i;
>>> u32 val, clock_cntl_on, cgc_mode;
>>> - if (!adreno_gpu->info->hwcg)
>>> + if (skip_programming)
>>> return;
>>> if (adreno_is_a630(adreno_gpu))
>>> @@ -982,6 +983,25 @@ static void a6xx_set_hwcg(struct msm_gpu *gpu, bool
>>> state)
>>> state ? 0x : 0);
>>> }
>>> + if (!adreno_gpu->info->hwcg) {
>>
>> I don't think this block of code is reachable now, no?
>
> It is because we didn't skip when adreno_is_a7xx(adreno_gpu)
Ahh I misread the brackets within the assignment
>
>>
>> Maybe remove the skip_programming and if_a750 here?
> This would require:
>>> - if (!adreno_gpu->info->hwcg || )
>>> + if (!(adreno_gpu->info->hwcg || adreno_is_a750(adreno_gpu)))
>
> and:
>
>>> + if (adreno_is_a750(adreno_gpu)) {
>
> But if the next gpu also doesn't have an hwcfg, we will need to use
> the current design...
>
> I just tried with:
> ><===
> @@ -961,7 +961,7 @@ static void a6xx_set_hwcg(struct msm_gpu *gpu, bool state)
> unsigned int i;
> u32 val, clock_cntl_on, cgc_mode;
>
> - if (!adreno_gpu->info->hwcg)
> + if (!(adreno_gpu->info->hwcg || adreno_is_a750(adreno_gpu)))
> return;
>
> if (adreno_is_a630(adreno_gpu))
> @@ -982,6 +982,25 @@ static void a6xx_set_hwcg(struct msm_gpu *gpu, bool
> state)
> state ? 0x : 0);
> }
>
> + if (adreno_is_a750(adreno_gpu)) {
> + gpu_write(gpu, REG_A7XX_RBBM_CLOCK_CNTL_GLOBAL, 1);
> + gpu_write(gpu, REG_A7XX_RBBM_CGC_GLOBAL_LOAD_CMD, state ? 1 :
> 0);
> +
> + if (state) {
> + gpu_write(gpu, REG_A7XX_RBBM_CGC_P2S_TRIG_CMD, 1);
> +
> + if (gpu_poll_timeout(gpu,
> REG_A7XX_RBBM_CGC_P2S_STATUS, val,
> + val &
> A7XX_RBBM_CGC_P2S_STATUS_TXDONE, 1, 10)) {
> + dev_err(>pdev->dev, "RBBM_CGC_P2S_STATUS
> TXDONE Poll failed\n");
> + return;
> + }
> +
> + gpu_write(gpu, REG_A7XX_RBBM_CLOCK_CNTL_GLOBAL, 0);
> + }
> +
> + return;
> + }
> +
> val = gpu_read(gpu, REG_A6XX_RBBM_CLOCK_CNTL);
>
> /* Don't re-program the registers if they are already correct */
> ><===
>
> And it works fine, does it work it for you ?
Let's keep it as-is in the original submission, as I've mentioned, I had
misread the code
Konrad
>
>>
>>> + gpu_write(gpu, REG_A7XX_RBBM_CLOCK_CNTL_GLOBAL, 1);
>>> + gpu_write(gpu, REG_A7XX_RBBM_CGC_GLOBAL_LOAD_CMD, state ? 1 : 0);
>>> +
>>> + if (state) {
>>> + gpu_write(gpu, REG_A7XX_RBBM_CGC_P2S_TRIG_CMD, 1);
>>> +
>>> + if (gpu_poll_timeout(gpu, REG_A7XX_RBBM_CGC_P2S_STATUS, val,
>>> + val & BIT(0), 1, 10)) {
>>
>> We should define that bit name (the err suggests it's
>> REG_A7XX_RBBM_GCC_P2S_STATUS_TXDONE or so)
>>
>> [...]
>>
>>> +static inline int adreno_is_a750(struct adreno_gpu *gpu)
>>> +{
>>> + return gpu->info->chip_ids[0] == 0x43051401;
>>> +}
>>> +
>>> /* Placeholder to make future diffs smaller */
>>
>> Please also remove this comment now that it's invalid
>
> Ack
>
>>
>> Konrad
>
> Thanks,
> Neil
>
Re: [PATCH] Revert "drm/panel-edp: Add auo_b116xa3_mode"
Hi, On Tue, Feb 13, 2024 at 11:24 PM Hsin-Yi Wang wrote: > > This reverts commit 70e0d5550f5cec301ad116703b840a539fe985dc. > > The overridden mode fixes the panel glitching issue on mt8186 chromebook. > However, it causes the internal display not working on mt8173 chromebook. > Revert the overridden mode for now to let mt8173 have a functional display. > > Signed-off-by: Hsin-Yi Wang > --- > drivers/gpu/drm/panel/panel-edp.c | 19 ++- > 1 file changed, 2 insertions(+), 17 deletions(-) Given that the breakage for affected mt8173 Chromebooks is pretty bad (black screen), I'll plan to just wait an extra day for any screams and then I'll apply to drm-misc-fixes. Reviewed-by: Douglas Anderson
[PATCH v2 4/4] drm/msm/dpu: Add X1E80100 support
Add definitions for the display hardware used on the Qualcomm X1E80100
platform.
Co-developed-by: Abhinav Kumar
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Abel Vesa
---
.../drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h | 449 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 1 +
4 files changed, 453 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h
new file mode 100644
index ..9a9f7092c526
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h
@@ -0,0 +1,449 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2023, Linaro Limited
+ */
+
+#ifndef _DPU_9_2_X1E80100_H
+#define _DPU_9_2_X1E80100_H
+
+static const struct dpu_caps x1e80100_dpu_caps = {
+ .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .max_mixer_blendstages = 0xb,
+ .has_src_split = true,
+ .has_dim_layer = true,
+ .has_idle_pc = true,
+ .has_3d_merge = true,
+ .max_linewidth = 5120,
+ .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+};
+
+static const struct dpu_mdp_cfg x1e80100_mdp = {
+ .name = "top_0",
+ .base = 0, .len = 0x494,
+ .features = BIT(DPU_MDP_PERIPH_0_REMOVED),
+ .clk_ctrls = {
+ [DPU_CLK_CTRL_REG_DMA] = { .reg_off = 0x2bc, .bit_off = 20 },
+ },
+};
+
+/* FIXME: get rid of DPU_CTL_SPLIT_DISPLAY in favour of proper ACTIVE_CTL
support */
+static const struct dpu_ctl_cfg x1e80100_ctl[] = {
+ {
+ .name = "ctl_0", .id = CTL_0,
+ .base = 0x15000, .len = 0x290,
+ .features = CTL_SM8550_MASK | BIT(DPU_CTL_SPLIT_DISPLAY),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
+ }, {
+ .name = "ctl_1", .id = CTL_1,
+ .base = 0x16000, .len = 0x290,
+ .features = CTL_SM8550_MASK | BIT(DPU_CTL_SPLIT_DISPLAY),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 10),
+ }, {
+ .name = "ctl_2", .id = CTL_2,
+ .base = 0x17000, .len = 0x290,
+ .features = CTL_SM8550_MASK,
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 11),
+ }, {
+ .name = "ctl_3", .id = CTL_3,
+ .base = 0x18000, .len = 0x290,
+ .features = CTL_SM8550_MASK,
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 12),
+ }, {
+ .name = "ctl_4", .id = CTL_4,
+ .base = 0x19000, .len = 0x290,
+ .features = CTL_SM8550_MASK,
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 13),
+ }, {
+ .name = "ctl_5", .id = CTL_5,
+ .base = 0x1a000, .len = 0x290,
+ .features = CTL_SM8550_MASK,
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 23),
+ },
+};
+
+static const struct dpu_sspp_cfg x1e80100_sspp[] = {
+ {
+ .name = "sspp_0", .id = SSPP_VIG0,
+ .base = 0x4000, .len = 0x344,
+ .features = VIG_SDM845_MASK_SDMA,
+ .sblk = _vig_sblk_qseed3_3_3,
+ .xin_id = 0,
+ .type = SSPP_TYPE_VIG,
+ }, {
+ .name = "sspp_1", .id = SSPP_VIG1,
+ .base = 0x6000, .len = 0x344,
+ .features = VIG_SDM845_MASK_SDMA,
+ .sblk = _vig_sblk_qseed3_3_3,
+ .xin_id = 4,
+ .type = SSPP_TYPE_VIG,
+ }, {
+ .name = "sspp_2", .id = SSPP_VIG2,
+ .base = 0x8000, .len = 0x344,
+ .features = VIG_SDM845_MASK_SDMA,
+ .sblk = _vig_sblk_qseed3_3_3,
+ .xin_id = 8,
+ .type = SSPP_TYPE_VIG,
+ }, {
+ .name = "sspp_3", .id = SSPP_VIG3,
+ .base = 0xa000, .len = 0x344,
+ .features = VIG_SDM845_MASK_SDMA,
+ .sblk = _vig_sblk_qseed3_3_3,
+ .xin_id = 12,
+ .type = SSPP_TYPE_VIG,
+ }, {
+ .name = "sspp_8", .id = SSPP_DMA0,
+ .base = 0x24000, .len = 0x344,
+ .features = DMA_SDM845_MASK_SDMA,
+ .sblk = _dma_sblk,
+ .xin_id = 1,
+ .type = SSPP_TYPE_DMA,
+ }, {
+ .name = "sspp_9", .id = SSPP_DMA1,
+ .base = 0x26000, .len = 0x344,
+ .features = DMA_SDM845_MASK_SDMA,
+ .sblk = _dma_sblk,
+ .xin_id = 5,
+ .type = SSPP_TYPE_DMA,
+ }, {
+ .name = "sspp_10", .id = SSPP_DMA2,
+ .base = 0x28000, .len = 0x344,
+ .features = DMA_SDM845_MASK_SDMA,
+ .sblk = _dma_sblk,
+ .xin_id = 9,
+
[PATCH v2 0/4] drm/msm: Add display support for X1E80100
This patchset adds support for display for X1E80100. The support for embedded DisplayPort on this platform will not be enabled using the connetor type from driver match data, but through some 'is-edp' property via DT. This subsequent work will be part of a separate patchset. Signed-off-by: Abel Vesa --- Changes in v2: - Dropped the 4th patch: "drm/msm/dp: Try looking for link-frequencies into the port@0's endpoint first" - Fixed the qcom,x1e80100-mdss schema by including some missing headers in the example - Added TODO comment for reg_bus_bw - Switched to SDMA features mask - Added Krzysztof's R-b tag to mdss schema patch - Added Dmitry's R-b tag to the dpu patch - Link to v1: https://lore.kernel.org/r/20240129-x1e80100-display-v1-0-0d9eb8254...@linaro.org --- Abel Vesa (4): dt-bindings: display/msm: document MDSS on X1E80100 dt-bindings: display/msm: Document the DPU for X1E80100 drm/msm: mdss: Add X1E80100 support drm/msm/dpu: Add X1E80100 support .../bindings/display/msm/qcom,sm8650-dpu.yaml | 4 +- .../bindings/display/msm/qcom,x1e80100-mdss.yaml | 252 .../drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h | 449 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 1 + drivers/gpu/drm/msm/msm_mdss.c | 13 + 7 files changed, 721 insertions(+), 1 deletion(-) --- base-commit: 85a96a047f413da4b663919a4ced39a4715c6835 change-id: 20231201-x1e80100-display-a46324400baf Best regards, -- Abel Vesa
[PATCH v2 3/4] drm/msm: mdss: Add X1E80100 support
Add support for MDSS on X1E80100.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/msm_mdss.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index 35423d10aafa..6eda501e2a1a 100644
--- a/drivers/gpu/drm/msm/msm_mdss.c
+++ b/drivers/gpu/drm/msm/msm_mdss.c
@@ -636,6 +636,18 @@ static const struct msm_mdss_data sm8550_data = {
.macrotile_mode = 1,
.reg_bus_bw = 57000,
};
+
+static const struct msm_mdss_data x1e80100_data = {
+ .ubwc_enc_version = UBWC_4_0,
+ .ubwc_dec_version = UBWC_4_3,
+ .ubwc_swizzle = 6,
+ .ubwc_static = 1,
+ /* TODO: highest_bank_bit = 2 for LP_DDR4 */
+ .highest_bank_bit = 3,
+ .macrotile_mode = 1,
+ /* TODO: Add reg_bus_bw with real value */
+};
+
static const struct of_device_id mdss_dt_match[] = {
{ .compatible = "qcom,mdss" },
{ .compatible = "qcom,msm8998-mdss", .data = _data },
@@ -656,6 +668,7 @@ static const struct of_device_id mdss_dt_match[] = {
{ .compatible = "qcom,sm8450-mdss", .data = _data },
{ .compatible = "qcom,sm8550-mdss", .data = _data },
{ .compatible = "qcom,sm8650-mdss", .data = _data},
+ { .compatible = "qcom,x1e80100-mdss", .data = _data},
{}
};
MODULE_DEVICE_TABLE(of, mdss_dt_match);
--
2.34.1
[PATCH v2 1/4] dt-bindings: display/msm: document MDSS on X1E80100
Document the MDSS hardware found on the Qualcomm X1E80100 platform.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Abel Vesa
---
.../bindings/display/msm/qcom,x1e80100-mdss.yaml | 252 +
1 file changed, 252 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.yaml
new file mode 100644
index ..c3e38afab76e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.yaml
@@ -0,0 +1,252 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,x1e80100-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm X1E80100 Display MDSS
+
+maintainers:
+ - Abel Vesa
+
+description:
+ X1E80100 MSM Mobile Display Subsystem(MDSS), which encapsulates sub-blocks
like
+ DPU display controller, DP interfaces, etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+const: qcom,x1e80100-mdss
+
+ clocks:
+items:
+ - description: Display AHB
+ - description: Display hf AXI
+ - description: Display core
+
+ iommus:
+maxItems: 1
+
+ interconnects:
+maxItems: 3
+
+ interconnect-names:
+maxItems: 3
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+type: object
+properties:
+ compatible:
+const: qcom,x1e80100-dpu
+
+ "^displayport-controller@[0-9a-f]+$":
+type: object
+properties:
+ compatible:
+const: qcom,x1e80100-dp
+
+ "^phy@[0-9a-f]+$":
+type: object
+properties:
+ compatible:
+const: qcom,x1e80100-dp-phy
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+display-subsystem@ae0 {
+compatible = "qcom,x1e80100-mdss";
+reg = <0x0ae0 0x1000>;
+reg-names = "mdss";
+
+interconnects = <_noc MASTER_MDP 0 _noc SLAVE_LLCC 0>,
+<_virt MASTER_LLCC 0 _virt SLAVE_EBI1 0>,
+<_noc MASTER_APPSS_PROC 0 _noc
SLAVE_DISPLAY_CFG 0>;
+interconnect-names = "mdp0-mem", "mdp1-mem", "cpu-cfg";
+
+resets = <_core_bcr>;
+
+power-domains = <_gdsc>;
+
+clocks = < DISP_CC_MDSS_AHB_CLK>,
+ < GCC_DISP_HF_AXI_CLK>,
+ < DISP_CC_MDSS_MDP_CLK>;
+clock-names = "bus", "nrt_bus", "core";
+
+interrupts = ;
+interrupt-controller;
+#interrupt-cells = <1>;
+
+iommus = <_smmu 0x1c00 0x2>;
+
+#address-cells = <1>;
+#size-cells = <1>;
+ranges;
+
+display-controller@ae01000 {
+compatible = "qcom,x1e80100-dpu";
+reg = <0x0ae01000 0x8f000>,
+ <0x0aeb 0x2008>;
+reg-names = "mdp", "vbif";
+
+clocks = <_axi_clk>,
+ <_ahb_clk>,
+ <_mdp_lut_clk>,
+ <_mdp_clk>,
+ <_mdp_vsync_clk>;
+clock-names = "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+
+assigned-clocks = <_mdp_vsync_clk>;
+assigned-clock-rates = <1920>;
+
+operating-points-v2 = <_opp_table>;
+power-domains = < RPMHPD_MMCX>;
+
+interrupt-parent = <>;
+interrupts = <0>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+dpu_intf1_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+
+port@1 {
+reg = <1>;
+dpu_intf2_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+
+mdp_opp_table: opp-table {
+compatible = "operating-points-v2";
+
+opp-2 {
+opp-hz = /bits/ 64 <2>;
+required-opps = <_opp_low_svs>;
+};
+
+opp-32500 {
+opp-hz = /bits/ 64 <32500>;
+required-opps = <_opp_svs>;
+};
+
+opp-37500 {
+opp-hz = /bits/ 64 <37500>;
+required-opps = <_opp_svs_l1>;
+};
+
+opp-51400 {
+opp-hz = /bits/ 64 <51400>;
+required-opps = <_opp_nom>;
+};
+};
+};
+
+displayport-controller@ae9 {
+compatible = "qcom,x1e80100-dp";
+
[PATCH v2 2/4] dt-bindings: display/msm: Document the DPU for X1E80100
Document the DPU for Qualcomm X1E80100 platform in the SM8650 schema, as they are similar. Signed-off-by: Abel Vesa --- Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml index a01d15a03317..c4087cc5abbd 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml @@ -13,7 +13,9 @@ $ref: /schemas/display/msm/dpu-common.yaml# properties: compatible: -const: qcom,sm8650-dpu +enum: + - qcom,sm8650-dpu + - qcom,x1e80100-dpu reg: items: -- 2.34.1
[PATCH] drm/vmwgfx: Remove unused code
Remove unused structs, members, and file. Many of these are written but
never read.
Signed-off-by: Ian Forbes
---
drivers/gpu/drm/vmwgfx/ttm_object.c| 4 -
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 27 -
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 12 ---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h| 16 ---
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 3 -
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 110 -
drivers/gpu/drm/vmwgfx/vmwgfx_validation.c | 19 +---
drivers/gpu/drm/vmwgfx/vmwgfx_validation.h | 7 --
8 files changed, 1 insertion(+), 197 deletions(-)
delete mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
diff --git a/drivers/gpu/drm/vmwgfx/ttm_object.c
b/drivers/gpu/drm/vmwgfx/ttm_object.c
index 6806c05e57f6..3353e97687d1 100644
--- a/drivers/gpu/drm/vmwgfx/ttm_object.c
+++ b/drivers/gpu/drm/vmwgfx/ttm_object.c
@@ -87,14 +87,11 @@ struct ttm_object_file {
*
* @object_lock: lock that protects idr.
*
- * @object_count: Per device object count.
- *
* This is the per-device data structure needed for ttm object management.
*/
struct ttm_object_device {
spinlock_t object_lock;
- atomic_t object_count;
struct dma_buf_ops ops;
void (*dmabuf_release)(struct dma_buf *dma_buf);
struct idr idr;
@@ -431,7 +428,6 @@ ttm_object_device_init(const struct dma_buf_ops *ops)
return NULL;
spin_lock_init(>object_lock);
- atomic_set(>object_count, 0);
/*
* Our base is at VMWGFX_NUM_MOB + 1 because we want to create
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 12efecc17df6..01f41fbb9c3b 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -117,25 +117,8 @@ struct vmwgfx_hash_item {
unsigned long key;
};
-
-/**
- * struct vmw_validate_buffer - Carries validation info about buffers.
- *
- * @base: Validation info for TTM.
- * @hash: Hash entry for quick lookup of the TTM buffer object.
- *
- * This structure contains also driver private validation info
- * on top of the info needed by TTM.
- */
-struct vmw_validate_buffer {
- struct ttm_validate_buffer base;
- struct vmwgfx_hash_item hash;
- bool validate_as_mob;
-};
-
struct vmw_res_func;
-
/**
* struct vmw-resource - base class for hardware resources
*
@@ -445,15 +428,6 @@ struct vmw_sw_context{
struct vmw_legacy_display;
struct vmw_overlay;
-struct vmw_vga_topology_state {
- uint32_t width;
- uint32_t height;
- uint32_t primary;
- uint32_t pos_x;
- uint32_t pos_y;
-};
-
-
/*
* struct vmw_otable - Guest Memory OBject table metadata
*
@@ -501,7 +475,6 @@ struct vmw_private {
struct drm_device drm;
struct ttm_device bdev;
- struct drm_vma_offset_manager vma_manager;
u32 pci_id;
resource_size_t io_start;
resource_size_t vram_start;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index cd4925346ed4..09214f9339b2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -775,7 +775,6 @@ vmw_du_cursor_plane_atomic_update(struct drm_plane *plane,
hotspot_y = du->hotspot_y + new_state->hotspot_y;
du->cursor_surface = vps->surf;
- du->cursor_bo = vps->bo;
if (!vps->surf && !vps->bo) {
vmw_cursor_update_position(dev_priv, false, 0, 0);
@@ -858,15 +857,6 @@ int vmw_du_primary_plane_atomic_check(struct drm_plane
*plane,
DRM_PLANE_NO_SCALING,
DRM_PLANE_NO_SCALING,
false, true);
-
- if (!ret && new_fb) {
- struct drm_crtc *crtc = new_state->crtc;
- struct vmw_display_unit *du = vmw_crtc_to_du(crtc);
-
- vmw_connector_state_to_vcs(du->connector.state);
- }
-
-
return ret;
}
@@ -1361,7 +1351,6 @@ static int vmw_kms_new_framebuffer_surface(struct
vmw_private *dev_priv,
drm_helper_mode_fill_fb_struct(dev, >base.base, mode_cmd);
vfbs->surface = vmw_surface_reference(surface);
- vfbs->base.user_handle = mode_cmd->handles[0];
vfbs->is_bo_proxy = is_bo_proxy;
*out = >base;
@@ -1529,7 +1518,6 @@ static int vmw_kms_new_framebuffer_bo(struct vmw_private
*dev_priv,
drm_helper_mode_fill_fb_struct(dev, >base.base, mode_cmd);
vfbd->base.bo = true;
vfbd->buffer = vmw_bo_reference(bo);
- vfbd->base.user_handle = mode_cmd->handles[0];
*out = >base;
ret = drm_framebuffer_init(dev, >base.base,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
index a94947b588e8..4a2e3cac1c22 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
@@ -217,21
Re: [PATCH v6 152/164] drm/bridge: ti-sn65dsi86: Make use of pwmchip_parent() accessor
Hi, On Wed, Feb 14, 2024 at 1:34 AM Uwe Kleine-König wrote: > > struct pwm_chip::dev is about to change. To not have to touch this > driver in the same commit as struct pwm_chip::dev, use the accessor > function provided for exactly this purpose. > > Signed-off-by: Uwe Kleine-König > --- > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) I don't see any differences from v5, so not sure why you didn't carry forward my Ack [1] on this one. Maybe because of the questions I asked? Your answers from v5 seemed fine to me. In any case: Acked-by: Douglas Anderson [1] https://lore.kernel.org/r/CAD=FV=vqpcbftp86wewf+-o9_v5olsquu1dqb5emlzzesqg...@mail.gmail.com
Re: [PATCH v2] drm/msm/dpu: make "vblank timeout" more useful
On 2/14/2024 11:20 AM, Dmitry Baryshkov wrote:
On Wed, 14 Feb 2024 at 20:02, Abhinav Kumar wrote:
On 2/8/2024 6:50 AM, Dmitry Baryshkov wrote:
We have several reports of vblank timeout messages. However after some
debugging it was found that there might be different causes to that.
To allow us to identify the DPU block that gets stuck, include the
actual CTL_FLUSH value into the timeout message and trigger the devcore
snapshot capture.
Signed-off-by: Dmitry Baryshkov
---
Changes in v2:
- Added a call to msm_disp_snapshot_state() to trigger devcore dump
(Abhinav)
- Link to v1:
https://lore.kernel.org/r/20240106-fd-dpu-debug-timeout-v1-1-6d9762884...@linaro.org
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index d0f56c5c4cce..a8d6165b3c0a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -489,7 +489,8 @@ static int dpu_encoder_phys_vid_wait_for_commit_done(
(hw_ctl->ops.get_flush_register(hw_ctl) == 0),
msecs_to_jiffies(50));
if (ret <= 0) {
- DPU_ERROR("vblank timeout\n");
+ DPU_ERROR("vblank timeout: %x\n",
hw_ctl->ops.get_flush_register(hw_ctl));
+ msm_disp_snapshot_state(phys_enc->parent->dev);
There is no rate limiting in this piece of code unfortunately. So this
will flood the number of snapshots.
Well... Yes and no. The devcoredump will destroy other snapshots if
there is a pending one. So only the console will be flooded and only
in case when MSM_DISP_SNAPSHOT_DUMP_IN_CONSOLE is enabled.
Yes, true but at the same time this makes it hard to capture a good dump
as potentially every vblank you could timeout so this destroy/create
cycle wont end.
Short-term solution is you can go with a vblank_timeout_cnt and reset it
in the enable() like other similar error counters.
long-term solution is we need to centralize these error locations to one
single dpu_encoder_error_handler() with a single counter and the error
handler will print out the error code along with the snapshot instead of
the snapshot being called from all over the place.
return -ETIMEDOUT;
}
---
base-commit: 39676dfe52331dba909c617f213fdb21015c8d10
change-id: 20240106-fd-dpu-debug-timeout-e917f0bc8063
Best regards,
Re: [PATCH v3 13/19] drm/msm/dp: add VSC SDP support for YUV420 over DP
On 2/14/2024 11:39 AM, Dmitry Baryshkov wrote:
On Wed, 14 Feb 2024 at 20:04, Paloma Arellano wrote:
Add support to pack and send the VSC SDP packet for DP. This therefore
allows the transmision of format information to the sinks which is
needed for YUV420 support over DP.
Changes in v3:
- Create a new struct, msm_dp_sdp_with_parity, which holds the
packing information for VSC SDP
- Use drm_dp_vsc_sdp_pack() to pack the data into the new
msm_dp_sdp_with_parity struct instead of specifically packing
for YUV420 format
- Modify dp_catalog_panel_send_vsc_sdp() to send the VSC SDP
data using the new msm_dp_sdp_with_parity struct
Changes in v2:
- Rename GENERIC0_SDPSIZE macro to GENERIC0_SDPSIZE_VALID
- Remove dp_sdp from the dp_catalog struct since this data is
being allocated at the point used
- Create a new function in dp_utils to pack the VSC SDP data
into a buffer
- Create a new function that packs the SDP header bytes into a
buffer. This function is made generic so that it can be
utilized by dp_audio
header bytes into a buffer
- Create a new function in dp_utils that takes the packed buffer
and writes to the DP_GENERIC0_* registers
- Split the dp_catalog_panel_config_vsc_sdp() function into two
to disable/enable sending VSC SDP packets
- Check the DP HW version using the original useage of
dp_catalog_hw_revision() and correct the version checking
logic
- Rename dp_panel_setup_vsc_sdp() to
dp_panel_setup_vsc_sdp_yuv_420() to explicitly state that
currently VSC SDP is only being set up to support YUV420 modes
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 113
drivers/gpu/drm/msm/dp/dp_catalog.h | 7 ++
drivers/gpu/drm/msm/dp/dp_ctrl.c| 4 +
drivers/gpu/drm/msm/dp/dp_panel.c | 55 ++
drivers/gpu/drm/msm/dp/dp_reg.h | 3 +
drivers/gpu/drm/msm/dp/dp_utils.c | 48
drivers/gpu/drm/msm/dp/dp_utils.h | 18 +
7 files changed, 248 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 5d84c089e520a..61d5317efe683 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -901,6 +901,119 @@ int dp_catalog_panel_timing_cfg(struct dp_catalog
*dp_catalog)
return 0;
}
+static void dp_catalog_panel_send_vsc_sdp(struct dp_catalog *dp_catalog,
+ struct msm_dp_sdp_with_parity
*msm_dp_sdp)
+{
+ struct dp_catalog_private *catalog;
+ u32 val;
+
+ if (!dp_catalog) {
+ DRM_ERROR("invalid input\n");
+ return;
+ }
+
+ catalog = container_of(dp_catalog, struct dp_catalog_private,
dp_catalog);
+
+ val = ((msm_dp_sdp->vsc_sdp.sdp_header.HB0) << HEADER_BYTE_0_BIT |
+ (msm_dp_sdp->pb.PB0 << PARITY_BYTE_0_BIT) |
+ (msm_dp_sdp->vsc_sdp.sdp_header.HB1) << HEADER_BYTE_1_BIT |
+ (msm_dp_sdp->pb.PB1 << PARITY_BYTE_1_BIT));
+ dp_write_link(catalog, MMSS_DP_GENERIC0_0, val);
+
+ val = ((msm_dp_sdp->vsc_sdp.sdp_header.HB2) << HEADER_BYTE_2_BIT |
+ (msm_dp_sdp->pb.PB2 << PARITY_BYTE_2_BIT) |
+ (msm_dp_sdp->vsc_sdp.sdp_header.HB3) << HEADER_BYTE_3_BIT |
+ (msm_dp_sdp->pb.PB3 << PARITY_BYTE_3_BIT));
+ dp_write_link(catalog, MMSS_DP_GENERIC0_1, val);
I still think that this is not the way to do it. Could you please
extract the function that takes struct dp_sdp_header, calculates
padding and writes resulting data to the hardware? This way we can
reuse it later for all the dp_audio stuff.
hmmm ... dp_utils_pack_sdp_header() does that you are asking for right?
OR are you asking for another function like:
1) rename dp_utils_pack_sdp_header() to dp_utils_calc_sdp_parity()
2) dp_utils_pack_sdp() takes two u32 to pack the header and parity
together and we move the << HEADER_BYTE_xx | part to it
dp_catalog_panel_send_vsc_sdp() just uses these two u32 to write the
headers.
+
+ val = ((msm_dp_sdp->vsc_sdp.db[16]) | (msm_dp_sdp->vsc_sdp.db[17] << 8)
|
+ (msm_dp_sdp->vsc_sdp.db[18] << 16));
+ dp_write_link(catalog, MMSS_DP_GENERIC0_6, val);
Shouldn't we write full dp_sdp data, including all zeroes? Here you
assume that there is no other data in dp_sdp and also that nobody
wrote anything senseless to those registers.
As per documentation, it says db[0] to db[15] are reserved so I thought
its better not to touch/use them and start writing for 16 onwards.
1592 * VSC SDP Payload for Pixel Encoding/Colorimetry Format
1593 * db[0] - db[15]: Reserved
1594 * db[16]: Pixel Encoding and Colorimetry Formats
1595 * db[17]: Dynamic Range
Re: [PATCH v3 01/12] drm/atomic-helper: split not-scaling part of drm_atomic_helper_check_plane_state
On Wed, 14 Feb 2024 at 21:39, Ville Syrjälä wrote: > > On Wed, Feb 14, 2024 at 09:17:06PM +0200, Dmitry Baryshkov wrote: > > On Wed, 14 Feb 2024 at 20:47, Ville Syrjälä > > wrote: > > > > > > On Wed, Feb 14, 2024 at 08:37:02PM +0200, Ville Syrjälä wrote: > > > > On Thu, Sep 14, 2023 at 08:06:55AM +0300, Dmitry Baryshkov wrote: > > > > > The helper drm_atomic_helper_check_plane_state() runs several checks > > > > > on > > > > > plane src and dst rectangles, including the check whether required > > > > > scaling fits into the required margins. The msm driver would benefit > > > > > from having a function that does all these checks except the scaling > > > > > one. Split them into a new helper called > > > > > drm_atomic_helper_check_plane_noscale(). > > > > > > > > What's the point in eliminating a nop scaling check? > > > > > > Actually, what are you even doing in there? Are you saying that > > > the hardware has absolutely no limits on how much it can scale > > > in either direction? > > > > No, I'm just saying that the scaling ability depends on the rotation > > and other plane properties. So I had to separate the basic plane > > checks and the scaling check. > > Basic (noscale) plane check source and destination rectangles, etc. > > After that the driver identifies possible hardware pipe usage and > > after that it can perform a scaling check. > > Hmm. We have sport of similar situation in i915 where we pick a scaler > much later and so don't know the exact scaling limits at the time when > we do this check. But we opted to pass the lower/upper bounds of the > scaling limits instead. That will guarantee that at least completely > illegal values are rejected as early as possible, and so we don't have > to worry about running into them later on. Ack, I'll follow this approach then. -- With best wishes Dmitry
Re: [PATCH v3 15/19] drm/msm/dp: enable SDP and SDE periph flush update
On Wed, 14 Feb 2024 at 20:04, Paloma Arellano wrote:
>
> DP controller can be setup to operate in either SDP update flush mode or
> peripheral flush mode based on the DP controller hardware version.
>
> Starting in DP v1.2, the hardware documents require the use of
> peripheral flush mode for SDP packets such as PPS OR VSC SDP packets.
>
> In-line with this guidance, lets program the DP controller to use
> peripheral flush mode starting DP v1.2
>
> Changes in v3:
> - Clear up that the DP_MAINLINK_FLUSH_MODE_SDE_PERIPH_UPDATE
> macro is setting bits [24:23] to a value of 3
>
> Changes in v2:
> - Use the original dp_catalog_hw_revision() function to
> correctly check the DP HW version
>
> Signed-off-by: Paloma Arellano
> ---
> drivers/gpu/drm/msm/dp/dp_catalog.c | 17 +
> drivers/gpu/drm/msm/dp/dp_catalog.h | 1 +
> drivers/gpu/drm/msm/dp/dp_ctrl.c| 1 +
> drivers/gpu/drm/msm/dp/dp_reg.h | 5 +
> 4 files changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
> b/drivers/gpu/drm/msm/dp/dp_catalog.c
> index 61d5317efe683..823eeba7e71d3 100644
> --- a/drivers/gpu/drm/msm/dp/dp_catalog.c
> +++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
> @@ -440,6 +440,23 @@ void dp_catalog_ctrl_config_misc(struct dp_catalog
> *dp_catalog,
> dp_write_link(catalog, REG_DP_MISC1_MISC0, misc_val);
> }
>
> +void dp_catalog_setup_peripheral_flush(struct dp_catalog *dp_catalog)
> +{
> + u32 mainlink_ctrl, hw_revision;
> + struct dp_catalog_private *catalog = container_of(dp_catalog,
> + struct dp_catalog_private, dp_catalog);
> +
> + mainlink_ctrl = dp_read_link(catalog, REG_DP_MAINLINK_CTRL);
> +
> + hw_revision = dp_catalog_hw_revision(dp_catalog);
> + if (hw_revision >= DP_HW_VERSION_1_2)
> + mainlink_ctrl |= DP_MAINLINK_FLUSH_MODE_SDE_PERIPH_UPDATE;
> + else
> + mainlink_ctrl |= DP_MAINLINK_FLUSH_MODE_UPDATE_SDP;
> +
> + dp_write_link(catalog, REG_DP_MAINLINK_CTRL, mainlink_ctrl);
> +}
> +
> void dp_catalog_ctrl_config_msa(struct dp_catalog *dp_catalog,
> u32 rate, u32 stream_rate_khz,
> bool fixed_nvid, bool is_ycbcr_420)
> diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.h
> b/drivers/gpu/drm/msm/dp/dp_catalog.h
> index 4bf08c27a9bf3..eb05a37837beb 100644
> --- a/drivers/gpu/drm/msm/dp/dp_catalog.h
> +++ b/drivers/gpu/drm/msm/dp/dp_catalog.h
> @@ -98,6 +98,7 @@ void dp_catalog_ctrl_config_ctrl(struct dp_catalog
> *dp_catalog, u32 config);
> void dp_catalog_ctrl_lane_mapping(struct dp_catalog *dp_catalog);
> void dp_catalog_ctrl_mainlink_ctrl(struct dp_catalog *dp_catalog, bool
> enable);
> void dp_catalog_ctrl_psr_mainlink_enable(struct dp_catalog *dp_catalog, bool
> enable);
> +void dp_catalog_setup_peripheral_flush(struct dp_catalog *dp_catalog);
> void dp_catalog_ctrl_config_misc(struct dp_catalog *dp_catalog, u32 cc, u32
> tb);
> void dp_catalog_ctrl_config_msa(struct dp_catalog *dp_catalog, u32 rate,
> u32 stream_rate_khz, bool fixed_nvid, bool
> is_ycbcr_420);
> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> index beef86b1aaf81..f1e7b0a5ee5d1 100644
> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> @@ -170,6 +170,7 @@ static void dp_ctrl_configure_source_params(struct
> dp_ctrl_private *ctrl)
>
> dp_catalog_ctrl_lane_mapping(ctrl->catalog);
> dp_catalog_ctrl_mainlink_ctrl(ctrl->catalog, true);
> + dp_catalog_setup_peripheral_flush(ctrl->catalog);
>
> dp_ctrl_config_ctrl(ctrl);
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_reg.h b/drivers/gpu/drm/msm/dp/dp_reg.h
> index 2983756c125cd..d4fb8572cd1e4 100644
> --- a/drivers/gpu/drm/msm/dp/dp_reg.h
> +++ b/drivers/gpu/drm/msm/dp/dp_reg.h
> @@ -6,6 +6,9 @@
> #ifndef _DP_REG_H_
> #define _DP_REG_H_
>
> +#include
> +#include
> +
> /* DP_TX Registers */
> #define REG_DP_HW_VERSION (0x)
>
> @@ -102,6 +105,8 @@
> #define DP_MAINLINK_CTRL_ENABLE(0x0001)
> #define DP_MAINLINK_CTRL_RESET (0x0002)
> #define DP_MAINLINK_CTRL_SW_BYPASS_SCRAMBLER (0x0010)
> +#define DP_MAINLINK_FLUSH_MODE_UPDATE_SDP (0x0080)
This define covers data from the same bit field. Please use FIELD_PREP too.
> +#define DP_MAINLINK_FLUSH_MODE_SDE_PERIPH_UPDATE
> FIELD_PREP(GENMASK(24, 23), 3)
#define DP_foo_MASK GENMASK(24,23)
> #define DP_MAINLINK_FB_BOUNDARY_SEL(0x0200)
>
> #define REG_DP_STATE_CTRL (0x0004)
> --
> 2.39.2
>
--
With best wishes
Dmitry
Re: [PATCH v3 13/19] drm/msm/dp: add VSC SDP support for YUV420 over DP
On Wed, 14 Feb 2024 at 20:04, Paloma Arellano wrote:
>
> Add support to pack and send the VSC SDP packet for DP. This therefore
> allows the transmision of format information to the sinks which is
> needed for YUV420 support over DP.
>
> Changes in v3:
> - Create a new struct, msm_dp_sdp_with_parity, which holds the
> packing information for VSC SDP
> - Use drm_dp_vsc_sdp_pack() to pack the data into the new
> msm_dp_sdp_with_parity struct instead of specifically packing
> for YUV420 format
> - Modify dp_catalog_panel_send_vsc_sdp() to send the VSC SDP
> data using the new msm_dp_sdp_with_parity struct
>
> Changes in v2:
> - Rename GENERIC0_SDPSIZE macro to GENERIC0_SDPSIZE_VALID
> - Remove dp_sdp from the dp_catalog struct since this data is
> being allocated at the point used
> - Create a new function in dp_utils to pack the VSC SDP data
> into a buffer
> - Create a new function that packs the SDP header bytes into a
> buffer. This function is made generic so that it can be
> utilized by dp_audio
> header bytes into a buffer
> - Create a new function in dp_utils that takes the packed buffer
> and writes to the DP_GENERIC0_* registers
> - Split the dp_catalog_panel_config_vsc_sdp() function into two
> to disable/enable sending VSC SDP packets
> - Check the DP HW version using the original useage of
> dp_catalog_hw_revision() and correct the version checking
> logic
> - Rename dp_panel_setup_vsc_sdp() to
> dp_panel_setup_vsc_sdp_yuv_420() to explicitly state that
> currently VSC SDP is only being set up to support YUV420 modes
>
> Signed-off-by: Paloma Arellano
> ---
> drivers/gpu/drm/msm/dp/dp_catalog.c | 113
> drivers/gpu/drm/msm/dp/dp_catalog.h | 7 ++
> drivers/gpu/drm/msm/dp/dp_ctrl.c| 4 +
> drivers/gpu/drm/msm/dp/dp_panel.c | 55 ++
> drivers/gpu/drm/msm/dp/dp_reg.h | 3 +
> drivers/gpu/drm/msm/dp/dp_utils.c | 48
> drivers/gpu/drm/msm/dp/dp_utils.h | 18 +
> 7 files changed, 248 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
> b/drivers/gpu/drm/msm/dp/dp_catalog.c
> index 5d84c089e520a..61d5317efe683 100644
> --- a/drivers/gpu/drm/msm/dp/dp_catalog.c
> +++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
> @@ -901,6 +901,119 @@ int dp_catalog_panel_timing_cfg(struct dp_catalog
> *dp_catalog)
> return 0;
> }
>
> +static void dp_catalog_panel_send_vsc_sdp(struct dp_catalog *dp_catalog,
> + struct msm_dp_sdp_with_parity
> *msm_dp_sdp)
> +{
> + struct dp_catalog_private *catalog;
> + u32 val;
> +
> + if (!dp_catalog) {
> + DRM_ERROR("invalid input\n");
> + return;
> + }
> +
> + catalog = container_of(dp_catalog, struct dp_catalog_private,
> dp_catalog);
> +
> + val = ((msm_dp_sdp->vsc_sdp.sdp_header.HB0) << HEADER_BYTE_0_BIT |
> + (msm_dp_sdp->pb.PB0 << PARITY_BYTE_0_BIT) |
> + (msm_dp_sdp->vsc_sdp.sdp_header.HB1) << HEADER_BYTE_1_BIT |
> + (msm_dp_sdp->pb.PB1 << PARITY_BYTE_1_BIT));
> + dp_write_link(catalog, MMSS_DP_GENERIC0_0, val);
> +
> + val = ((msm_dp_sdp->vsc_sdp.sdp_header.HB2) << HEADER_BYTE_2_BIT |
> + (msm_dp_sdp->pb.PB2 << PARITY_BYTE_2_BIT) |
> + (msm_dp_sdp->vsc_sdp.sdp_header.HB3) << HEADER_BYTE_3_BIT |
> + (msm_dp_sdp->pb.PB3 << PARITY_BYTE_3_BIT));
> + dp_write_link(catalog, MMSS_DP_GENERIC0_1, val);
I still think that this is not the way to do it. Could you please
extract the function that takes struct dp_sdp_header, calculates
padding and writes resulting data to the hardware? This way we can
reuse it later for all the dp_audio stuff.
> +
> + val = ((msm_dp_sdp->vsc_sdp.db[16]) | (msm_dp_sdp->vsc_sdp.db[17] <<
> 8) |
> + (msm_dp_sdp->vsc_sdp.db[18] << 16));
> + dp_write_link(catalog, MMSS_DP_GENERIC0_6, val);
Shouldn't we write full dp_sdp data, including all zeroes? Here you
assume that there is no other data in dp_sdp and also that nobody
wrote anything senseless to those registers.
> +}
> +
> +static void dp_catalog_panel_update_sdp(struct dp_catalog *dp_catalog)
> +{
> + struct dp_catalog_private *catalog;
> + u32 hw_revision;
> +
> + catalog = container_of(dp_catalog, struct dp_catalog_private,
> dp_catalog);
> +
> + hw_revision = dp_catalog_hw_revision(dp_catalog);
> + if (hw_revision < DP_HW_VERSION_1_2 && hw_revision >=
> DP_HW_VERSION_1_0) {
> + dp_write_link(catalog, MMSS_DP_SDP_CFG3, 0x01);
> + dp_write_link(catalog, MMSS_DP_SDP_CFG3, 0x00);
> + }
> +}
> +
> +void dp_catalog_panel_enable_vsc_sdp(struct dp_catalog *dp_catalog,
> +
Re: [PATCH v3 01/12] drm/atomic-helper: split not-scaling part of drm_atomic_helper_check_plane_state
On Wed, Feb 14, 2024 at 09:17:06PM +0200, Dmitry Baryshkov wrote: > On Wed, 14 Feb 2024 at 20:47, Ville Syrjälä > wrote: > > > > On Wed, Feb 14, 2024 at 08:37:02PM +0200, Ville Syrjälä wrote: > > > On Thu, Sep 14, 2023 at 08:06:55AM +0300, Dmitry Baryshkov wrote: > > > > The helper drm_atomic_helper_check_plane_state() runs several checks on > > > > plane src and dst rectangles, including the check whether required > > > > scaling fits into the required margins. The msm driver would benefit > > > > from having a function that does all these checks except the scaling > > > > one. Split them into a new helper called > > > > drm_atomic_helper_check_plane_noscale(). > > > > > > What's the point in eliminating a nop scaling check? > > > > Actually, what are you even doing in there? Are you saying that > > the hardware has absolutely no limits on how much it can scale > > in either direction? > > No, I'm just saying that the scaling ability depends on the rotation > and other plane properties. So I had to separate the basic plane > checks and the scaling check. > Basic (noscale) plane check source and destination rectangles, etc. > After that the driver identifies possible hardware pipe usage and > after that it can perform a scaling check. Hmm. We have sport of similar situation in i915 where we pick a scaler much later and so don't know the exact scaling limits at the time when we do this check. But we opted to pass the lower/upper bounds of the scaling limits instead. That will guarantee that at least completely illegal values are rejected as early as possible, and so we don't have to worry about running into them later on. -- Ville Syrjälä Intel
[PATCH] drm/v3d: Enable V3D to use different PAGE_SIZE
Currently, the V3D driver uses PAGE_SHIFT over the assumption that PAGE_SHIFT = 12, as the PAGE_SIZE = 4KB. But, the RPi 5 is using PAGE_SIZE = 16KB, so the MMU PAGE_SHIFT is different than the system's PAGE_SHIFT. Enable V3D to be used in system's with any PAGE_SIZE by making sure that everything MMU-related uses the MMU page shift. Signed-off-by: Maíra Canal --- drivers/gpu/drm/v3d/v3d_bo.c | 12 ++-- drivers/gpu/drm/v3d/v3d_debugfs.c | 2 +- drivers/gpu/drm/v3d/v3d_drv.h | 2 ++ drivers/gpu/drm/v3d/v3d_irq.c | 2 +- drivers/gpu/drm/v3d/v3d_mmu.c | 2 -- 5 files changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/v3d/v3d_bo.c b/drivers/gpu/drm/v3d/v3d_bo.c index 1bdfac8beafd..a07ede668cc1 100644 --- a/drivers/gpu/drm/v3d/v3d_bo.c +++ b/drivers/gpu/drm/v3d/v3d_bo.c @@ -40,7 +40,7 @@ void v3d_free_object(struct drm_gem_object *obj) mutex_lock(>bo_lock); v3d->bo_stats.num_allocated--; - v3d->bo_stats.pages_allocated -= obj->size >> PAGE_SHIFT; + v3d->bo_stats.pages_allocated -= obj->size >> V3D_MMU_PAGE_SHIFT; mutex_unlock(>bo_lock); spin_lock(>mm_lock); @@ -109,8 +109,8 @@ v3d_bo_create_finish(struct drm_gem_object *obj) * lifetime of the BO. */ ret = drm_mm_insert_node_generic(>mm, >node, -obj->size >> PAGE_SHIFT, -GMP_GRANULARITY >> PAGE_SHIFT, 0, 0); +obj->size >> V3D_MMU_PAGE_SHIFT, +GMP_GRANULARITY >> V3D_MMU_PAGE_SHIFT, 0, 0); spin_unlock(>mm_lock); if (ret) return ret; @@ -118,7 +118,7 @@ v3d_bo_create_finish(struct drm_gem_object *obj) /* Track stats for /debug/dri/n/bo_stats. */ mutex_lock(>bo_lock); v3d->bo_stats.num_allocated++; - v3d->bo_stats.pages_allocated += obj->size >> PAGE_SHIFT; + v3d->bo_stats.pages_allocated += obj->size >> V3D_MMU_PAGE_SHIFT; mutex_unlock(>bo_lock); v3d_mmu_insert_ptes(bo); @@ -201,7 +201,7 @@ int v3d_create_bo_ioctl(struct drm_device *dev, void *data, if (IS_ERR(bo)) return PTR_ERR(bo); - args->offset = bo->node.start << PAGE_SHIFT; + args->offset = bo->node.start << V3D_MMU_PAGE_SHIFT; ret = drm_gem_handle_create(file_priv, >base.base, >handle); drm_gem_object_put(>base.base); @@ -246,7 +246,7 @@ int v3d_get_bo_offset_ioctl(struct drm_device *dev, void *data, } bo = to_v3d_bo(gem_obj); - args->offset = bo->node.start << PAGE_SHIFT; + args->offset = bo->node.start << V3D_MMU_PAGE_SHIFT; drm_gem_object_put(gem_obj); return 0; diff --git a/drivers/gpu/drm/v3d/v3d_debugfs.c b/drivers/gpu/drm/v3d/v3d_debugfs.c index dc3cf708d02e..19e3ee7ac897 100644 --- a/drivers/gpu/drm/v3d/v3d_debugfs.c +++ b/drivers/gpu/drm/v3d/v3d_debugfs.c @@ -219,7 +219,7 @@ static int v3d_debugfs_bo_stats(struct seq_file *m, void *unused) seq_printf(m, "allocated bos: %d\n", v3d->bo_stats.num_allocated); seq_printf(m, "allocated bo size (kb): %ld\n", - (long)v3d->bo_stats.pages_allocated << (PAGE_SHIFT - 10)); + (long)v3d->bo_stats.pages_allocated << (V3D_MMU_PAGE_SHIFT - 10)); mutex_unlock(>bo_lock); return 0; diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h index 3c7d58866570..1950c723dde1 100644 --- a/drivers/gpu/drm/v3d/v3d_drv.h +++ b/drivers/gpu/drm/v3d/v3d_drv.h @@ -19,6 +19,8 @@ struct reset_control; #define GMP_GRANULARITY (128 * 1024) +#define V3D_MMU_PAGE_SHIFT 12 + #define V3D_MAX_QUEUES (V3D_CPU + 1) static inline char *v3d_queue_to_string(enum v3d_queue queue) diff --git a/drivers/gpu/drm/v3d/v3d_irq.c b/drivers/gpu/drm/v3d/v3d_irq.c index afc76390a197..2e04f6cb661e 100644 --- a/drivers/gpu/drm/v3d/v3d_irq.c +++ b/drivers/gpu/drm/v3d/v3d_irq.c @@ -70,7 +70,7 @@ v3d_overflow_mem_work(struct work_struct *work) list_add_tail(>unref_head, >bin_job->render->unref_list); spin_unlock_irqrestore(>job_lock, irqflags); - V3D_CORE_WRITE(0, V3D_PTB_BPOA, bo->node.start << PAGE_SHIFT); + V3D_CORE_WRITE(0, V3D_PTB_BPOA, bo->node.start << V3D_MMU_PAGE_SHIFT); V3D_CORE_WRITE(0, V3D_PTB_BPOS, obj->size); out: diff --git a/drivers/gpu/drm/v3d/v3d_mmu.c b/drivers/gpu/drm/v3d/v3d_mmu.c index 5a453532901f..14f3af40d6f6 100644 --- a/drivers/gpu/drm/v3d/v3d_mmu.c +++ b/drivers/gpu/drm/v3d/v3d_mmu.c @@ -21,8 +21,6 @@ #include "v3d_drv.h" #include "v3d_regs.h" -#define V3D_MMU_PAGE_SHIFT 12 - /* Note: All PTEs for the 1MB superpage must be filled with the * superpage bit set. */ -- 2.43.0
Re: [PATCH v2] drm/msm/dpu: make "vblank timeout" more useful
On Wed, 14 Feb 2024 at 20:02, Abhinav Kumar wrote:
>
>
>
> On 2/8/2024 6:50 AM, Dmitry Baryshkov wrote:
> > We have several reports of vblank timeout messages. However after some
> > debugging it was found that there might be different causes to that.
> > To allow us to identify the DPU block that gets stuck, include the
> > actual CTL_FLUSH value into the timeout message and trigger the devcore
> > snapshot capture.
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > Changes in v2:
> > - Added a call to msm_disp_snapshot_state() to trigger devcore dump
> >(Abhinav)
> > - Link to v1:
> > https://lore.kernel.org/r/20240106-fd-dpu-debug-timeout-v1-1-6d9762884...@linaro.org
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> > index d0f56c5c4cce..a8d6165b3c0a 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> > @@ -489,7 +489,8 @@ static int dpu_encoder_phys_vid_wait_for_commit_done(
> > (hw_ctl->ops.get_flush_register(hw_ctl) == 0),
> > msecs_to_jiffies(50));
> > if (ret <= 0) {
> > - DPU_ERROR("vblank timeout\n");
> > + DPU_ERROR("vblank timeout: %x\n",
> > hw_ctl->ops.get_flush_register(hw_ctl));
> > + msm_disp_snapshot_state(phys_enc->parent->dev);
>
>
> There is no rate limiting in this piece of code unfortunately. So this
> will flood the number of snapshots.
Well... Yes and no. The devcoredump will destroy other snapshots if
there is a pending one. So only the console will be flooded and only
in case when MSM_DISP_SNAPSHOT_DUMP_IN_CONSOLE is enabled.
>
> Short-term solution is you can go with a vblank_timeout_cnt and reset it
> in the enable() like other similar error counters.
>
> long-term solution is we need to centralize these error locations to one
> single dpu_encoder_error_handler() with a single counter and the error
> handler will print out the error code along with the snapshot instead of
> the snapshot being called from all over the place.
>
>
>
> > return -ETIMEDOUT;
> > }
> >
> >
> > ---
> > base-commit: 39676dfe52331dba909c617f213fdb21015c8d10
> > change-id: 20240106-fd-dpu-debug-timeout-e917f0bc8063
> >
> > Best regards,
--
With best wishes
Dmitry
Re: [PATCH v3 02/12] drm/msm/dpu: add current resource allocation to dumped state
On Wed, 14 Feb 2024 at 20:41, Abhinav Kumar wrote:
>
>
>
> On 9/13/2023 10:06 PM, Dmitry Baryshkov wrote:
> > Provide atomic_print_state callback to the DPU's private object. This
> > way the debugfs/dri/0/state will also include RM's internal state.
> >
>
> I like this idea !
>
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 +++
> > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 ++
> > drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 48 +
> > drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 8 +
> > 4 files changed, 62 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > index ee84160592ce..172b64dc60e6 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > @@ -362,6 +362,7 @@ static void dpu_kms_global_destroy_state(struct
> > drm_private_obj *obj,
> > static const struct drm_private_state_funcs dpu_kms_global_state_funcs = {
> > .atomic_duplicate_state = dpu_kms_global_duplicate_state,
> > .atomic_destroy_state = dpu_kms_global_destroy_state,
> > + .atomic_print_state = dpu_rm_print_state,
> > };
> >
> > static int dpu_kms_global_obj_init(struct dpu_kms *dpu_kms)
> > @@ -375,6 +376,9 @@ static int dpu_kms_global_obj_init(struct dpu_kms
> > *dpu_kms)
> > drm_atomic_private_obj_init(dpu_kms->dev, _kms->global_state,
> > >base,
> > _kms_global_state_funcs);
> > +
> > + state->rm = _kms->rm;
> > +
> > return 0;
> > }
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> > index ed549f0f7c65..dd2be279b366 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> > @@ -130,6 +130,8 @@ struct vsync_info {
> > struct dpu_global_state {
> > struct drm_private_state base;
> >
> > + struct dpu_rm *rm;
> > +
> > uint32_t pingpong_to_enc_id[PINGPONG_MAX - PINGPONG_0];
> > uint32_t mixer_to_enc_id[LM_MAX - LM_0];
> > uint32_t ctl_to_enc_id[CTL_MAX - CTL_0];
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> > index f9215643c71a..5e3442fb8678 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> > @@ -652,3 +652,51 @@ int dpu_rm_get_assigned_resources(struct dpu_rm *rm,
> >
> > return num_blks;
> > }
> > +
> > +void dpu_rm_print_state(struct drm_printer *p,
> > + const struct drm_private_state *state)
> > +{
> > + const struct dpu_global_state *global_state =
> > to_dpu_global_state(state);
> > + const struct dpu_rm *rm = global_state->rm;
> > + int i;
> > +
> > + drm_puts(p, "pingpong:");
> > + for (i = 0; i < ARRAY_SIZE(global_state->pingpong_to_enc_id); i++)
> > + if (rm->pingpong_blks[i])
> > + drm_printf(p, " %d,",
> > global_state->pingpong_to_enc_id[i]);
> > + else
> > + drm_puts(p, " -,");
> > + drm_puts(p, "\n");
> > +
> > + drm_puts(p, "mixer:");
> > + for (i = 0; i < ARRAY_SIZE(global_state->mixer_to_enc_id); i++)
> > + if (rm->mixer_blks[i])
> > + drm_printf(p, " %d,",
> > global_state->mixer_to_enc_id[i]);
> > + else
> > + drm_puts(p, " -,");
> > + drm_puts(p, "\n");
> > +
> > + drm_puts(p, "ctl:");
> > + for (i = 0; i < ARRAY_SIZE(global_state->ctl_to_enc_id); i++)
> > + if (rm->ctl_blks[i])
> > + drm_printf(p, " %d,", global_state->ctl_to_enc_id[i]);
> > + else
> > + drm_puts(p, " -,");
> > + drm_puts(p, "\n");
> > +
> > + drm_puts(p, "dspp:");
> > + for (i = 0; i < ARRAY_SIZE(global_state->dspp_to_enc_id); i++)
> > + if (rm->dspp_blks[i])
> > + drm_printf(p, " %d,",
> > global_state->dspp_to_enc_id[i]);
> > + else
> > + drm_puts(p, " -,");
> > + drm_puts(p, "\n");
> > +
> > + drm_puts(p, "dsc:");
> > + for (i = 0; i < ARRAY_SIZE(global_state->dsc_to_enc_id); i++)
> > + if (rm->dsc_blks[i])
> > + drm_printf(p, " %d,", global_state->dsc_to_enc_id[i]);
> > + else
> > + drm_puts(p, " -,");
> > + drm_puts(p, "\n");
> > +}
>
> You also need to include cdm_to_enc_id now. But otherwise LGTM.
>
> If you have run this before, do you have a sample output to share?
No, I don't have a dump at hand. But I can post this patch separately,
including the CDM change.
>
>
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
> > index 2b551566cbf4..913baca81a42 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
Re: [PATCH v3 01/12] drm/atomic-helper: split not-scaling part of drm_atomic_helper_check_plane_state
On Wed, 14 Feb 2024 at 20:47, Ville Syrjälä
wrote:
>
> On Wed, Feb 14, 2024 at 08:37:02PM +0200, Ville Syrjälä wrote:
> > On Thu, Sep 14, 2023 at 08:06:55AM +0300, Dmitry Baryshkov wrote:
> > > The helper drm_atomic_helper_check_plane_state() runs several checks on
> > > plane src and dst rectangles, including the check whether required
> > > scaling fits into the required margins. The msm driver would benefit
> > > from having a function that does all these checks except the scaling
> > > one. Split them into a new helper called
> > > drm_atomic_helper_check_plane_noscale().
> >
> > What's the point in eliminating a nop scaling check?
>
> Actually, what are you even doing in there? Are you saying that
> the hardware has absolutely no limits on how much it can scale
> in either direction?
No, I'm just saying that the scaling ability depends on the rotation
and other plane properties. So I had to separate the basic plane
checks and the scaling check.
Basic (noscale) plane check source and destination rectangles, etc.
After that the driver identifies possible hardware pipe usage and
after that it can perform a scaling check.
>
> >
> > >
> > > Signed-off-by: Dmitry Baryshkov
> > > ---
> > > drivers/gpu/drm/drm_atomic_helper.c | 110 ++--
> > > include/drm/drm_atomic_helper.h | 7 ++
> > > 2 files changed, 96 insertions(+), 21 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 292e38eb6218..2d7dd66181c9 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -825,11 +825,9 @@ drm_atomic_helper_check_wb_encoder_state(struct
> > > drm_encoder *encoder,
> > > EXPORT_SYMBOL(drm_atomic_helper_check_wb_encoder_state);
> > >
> > > /**
> > > - * drm_atomic_helper_check_plane_state() - Check plane state for validity
> > > + * drm_atomic_helper_check_plane_noscale() - Check plane state for
> > > validity
> > > * @plane_state: plane state to check
> > > * @crtc_state: CRTC state to check
> > > - * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
> > > - * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
> > > * @can_position: is it legal to position the plane such that it
> > > *doesn't cover the entire CRTC? This will generally
> > > *only be false for primary planes.
> > > @@ -845,19 +843,16 @@
> > > EXPORT_SYMBOL(drm_atomic_helper_check_wb_encoder_state);
> > > * RETURNS:
> > > * Zero if update appears valid, error code on failure
> > > */
> > > -int drm_atomic_helper_check_plane_state(struct drm_plane_state
> > > *plane_state,
> > > - const struct drm_crtc_state
> > > *crtc_state,
> > > - int min_scale,
> > > - int max_scale,
> > > - bool can_position,
> > > - bool can_update_disabled)
> > > +int drm_atomic_helper_check_plane_noscale(struct drm_plane_state
> > > *plane_state,
> > > + const struct drm_crtc_state
> > > *crtc_state,
> > > + bool can_position,
> > > + bool can_update_disabled)
> > > {
> > > struct drm_framebuffer *fb = plane_state->fb;
> > > struct drm_rect *src = _state->src;
> > > struct drm_rect *dst = _state->dst;
> > > unsigned int rotation = plane_state->rotation;
> > > struct drm_rect clip = {};
> > > - int hscale, vscale;
> > >
> > > WARN_ON(plane_state->crtc && plane_state->crtc != crtc_state->crtc);
> > >
> > > @@ -883,17 +878,6 @@ int drm_atomic_helper_check_plane_state(struct
> > > drm_plane_state *plane_state,
> > >
> > > drm_rect_rotate(src, fb->width << 16, fb->height << 16, rotation);
> > >
> > > - /* Check scaling */
> > > - hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
> > > - vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
> > > - if (hscale < 0 || vscale < 0) {
> > > - drm_dbg_kms(plane_state->plane->dev,
> > > - "Invalid scaling of plane\n");
> > > - drm_rect_debug_print("src: ", _state->src, true);
> > > - drm_rect_debug_print("dst: ", _state->dst, false);
> > > - return -ERANGE;
> > > - }
> > > -
> > > if (crtc_state->enable)
> > > drm_mode_get_hv_timing(_state->mode, , );
> > >
> > > @@ -921,6 +905,90 @@ int drm_atomic_helper_check_plane_state(struct
> > > drm_plane_state *plane_state,
> > >
> > > return 0;
> > > }
> > > +EXPORT_SYMBOL(drm_atomic_helper_check_plane_noscale);
> > > +
> > > +/**
> > > + * drm_atomic_helper_check_plane_scale() - Check whether plane can be
> > > scaled
> > > + * @plane_state: plane state to check
> > > + * @min_scale: minimum @src:@dest scaling factor in 16.16
Re: [PATCH] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper
On Wed, 14 Feb 2024 at 20:08, Abhinav Kumar wrote: > > > > On 2/14/2024 10:02 AM, Ville Syrjälä wrote: > > On Wed, Feb 14, 2024 at 09:17:34AM -0800, Abhinav Kumar wrote: > >> > >> > >> On 2/14/2024 12:15 AM, Dmitry Baryshkov wrote: > >>> On Wed, 14 Feb 2024 at 01:45, Abhinav Kumar > >>> wrote: > > intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well. > Lets move this to drm_dp_helper to achieve this. > > Signed-off-by: Abhinav Kumar > >>> > >>> My preference would be to have packing functions in > >>> drivers/video/hdmi.c, as we already have > >>> hdmi_audio_infoframe_pack_for_dp() there. > >>> > >> > >> My preference is drm_dp_helper because it already has some VSC SDP stuff > >> and after discussion with Ville on IRC, I decided to post it this way. > >> > >> hdmi_audio_infoframe_pack_for_dp() is an exception from my PoV as the > >> hdmi audio infoframe fields were re-used and packed into a DP SDP > >> thereby re-using the existing struct hdmi_audio_infoframe . > >> > >> This is not like that. Here we pack from struct drm_dp_vsc_sdp to struct > >> dp_sdp both of which had prior usages already in this file. > >> > >> So it all adds up and makes sense to me to be in this file. > >> > >> I will let the other DRM core maintainers comment on this. > >> > >> Ville, Jani? > > > > Yeah, I'm not sure bloating the (poorly named) hdmi.c with all > > SDP stuff is a great idea. Since other related stuff already > > lives in the drm_dp_helper.c that seems reasonable to me at this > > time. And if we get a decent amount of this then probably all > > DP SDP stuff should be extracted into its own file. > > > > Yes, thanks. > > > There are of course a few overlaps here andthere (the audio SDP > > I guess, and the CTA infoframe SDP). But I'm not sure that actually > > needs any SDP specific stuff in hdmi.c, or could we just let hdmi.c > > deal with the actual CTA-861 stuff and then have the DP SDP code > > wrap that up in its own thing externally? Dunno, haven't really > > looked at the details. > > > > Thats a good way to look at it. this packing is from DP spec and not CTA > so makes more sense to be in this file. > > In that case, R-b? > > >> > --- > drivers/gpu/drm/display/drm_dp_helper.c | 78 + > drivers/gpu/drm/i915/display/intel_dp.c | 73 +-- > include/drm/display/drm_dp_helper.h | 3 + > 3 files changed, 84 insertions(+), 70 deletions(-) > > diff --git a/drivers/gpu/drm/display/drm_dp_helper.c > b/drivers/gpu/drm/display/drm_dp_helper.c > index b1ca3a1100da..066cfbbf7a91 100644 > --- a/drivers/gpu/drm/display/drm_dp_helper.c > +++ b/drivers/gpu/drm/display/drm_dp_helper.c > @@ -2916,6 +2916,84 @@ void drm_dp_vsc_sdp_log(const char *level, struct > device *dev, > } > EXPORT_SYMBOL(drm_dp_vsc_sdp_log); > > +/** > + * drm_dp_vsc_sdp_pack() - pack a given vsc sdp into generic dp_sdp > + * @vsc: vsc sdp initialized according to its purpose as defined in > + * table 2-118 - table 2-120 in DP 1.4a specification > + * @sdp: valid handle to the generic dp_sdp which will be packed > + * @size: valid size of the passed sdp handle > + * > + * Returns length of sdp on success and error code on failure > + */ > +ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc, > + struct dp_sdp *sdp, size_t size) > >>> > >>> I know that you are just moving the function. Maybe there can be > >>> patch#2, which drops the size argument? The struct dp_sdp already has > >>> a defined size. The i915 driver just passes sizeof(sdp), which is more > >>> or less useless. > >>> > >> > >> Yes this is a valid point, I also noticed this. I can post it on top of > >> this once we get an agreement and ack on this patch first. > >> >From my side, with the promise of the size fixup. Acked-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v3 03/12] drm/msm/dpu: take plane rotation into account for wide planes
On 9/13/2023 10:06 PM, Dmitry Baryshkov wrote:
Take into account the plane rotation and flipping when calculating src
positions for the wide plane parts.
This is not an issue yet, because rotation is only supported for the
UBWC planes and wide UBWC planes are rejected anyway because in parallel
multirect case only the half of the usual width is supported for tiled
formats. However it's better to fix this now rather than stumbling upon
it later.
Fixes: 80e8ae3b38ab ("drm/msm/dpu: add support for wide planes")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 27 ++-
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index c2aaaded07ed..67f9c2a62a17 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -827,16 +827,6 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
return -EINVAL;
}
- pipe_cfg->src_rect = new_plane_state->src;
-
- /* state->src is 16.16, src_rect is not */
- pipe_cfg->src_rect.x1 >>= 16;
- pipe_cfg->src_rect.x2 >>= 16;
- pipe_cfg->src_rect.y1 >>= 16;
- pipe_cfg->src_rect.y2 >>= 16;
-
- pipe_cfg->dst_rect = new_plane_state->dst;
-
Why were these lines moved down?
So this change is doing two things:
1) Using drm_rect_fp_to_int() instead of the hand-rolled right shifting
2) Considering rotation for wide plane cases
Do we need to break this up into 2?
fb_rect.x2 = new_plane_state->fb->width;
fb_rect.y2 = new_plane_state->fb->height;
@@ -852,6 +842,15 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
max_linewidth = pdpu->catalog->caps->max_linewidth;
+ /* state->src is 16.16, src_rect is not */
+ drm_rect_fp_to_int(_cfg->src_rect, _plane_state->src);
+
+ pipe_cfg->dst_rect = new_plane_state->dst;
+
+ drm_rect_rotate(_cfg->src_rect,
+ new_plane_state->fb->width, new_plane_state->fb->height,
+ new_plane_state->rotation);
+
if (drm_rect_width(_cfg->src_rect) > max_linewidth) {
/*
* In parallel multirect case only the half of the usual width
@@ -899,6 +898,14 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
r_pipe_cfg->dst_rect.x1 = pipe_cfg->dst_rect.x2;
}
+ drm_rect_rotate_inv(_cfg->src_rect,
+ new_plane_state->fb->width,
new_plane_state->fb->height,
+ new_plane_state->rotation);
+ if (r_pipe->sspp)
+ drm_rect_rotate_inv(_pipe_cfg->src_rect,
+ new_plane_state->fb->width,
new_plane_state->fb->height,
+ new_plane_state->rotation);
+
iiuc, so we do
1) rotate() on full plane
2) rotate_inv() on left half-plane
3) rotate_inv() on right half-plane
If so, looks right to me.
ret = dpu_plane_atomic_check_pipe(pdpu, pipe, pipe_cfg, fmt);
if (ret)
return ret;
Re: [PATCH v3 01/12] drm/atomic-helper: split not-scaling part of drm_atomic_helper_check_plane_state
On Wed, Feb 14, 2024 at 08:37:02PM +0200, Ville Syrjälä wrote:
> On Thu, Sep 14, 2023 at 08:06:55AM +0300, Dmitry Baryshkov wrote:
> > The helper drm_atomic_helper_check_plane_state() runs several checks on
> > plane src and dst rectangles, including the check whether required
> > scaling fits into the required margins. The msm driver would benefit
> > from having a function that does all these checks except the scaling
> > one. Split them into a new helper called
> > drm_atomic_helper_check_plane_noscale().
>
> What's the point in eliminating a nop scaling check?
Actually, what are you even doing in there? Are you saying that
the hardware has absolutely no limits on how much it can scale
in either direction?
>
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 110 ++--
> > include/drm/drm_atomic_helper.h | 7 ++
> > 2 files changed, 96 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 292e38eb6218..2d7dd66181c9 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -825,11 +825,9 @@ drm_atomic_helper_check_wb_encoder_state(struct
> > drm_encoder *encoder,
> > EXPORT_SYMBOL(drm_atomic_helper_check_wb_encoder_state);
> >
> > /**
> > - * drm_atomic_helper_check_plane_state() - Check plane state for validity
> > + * drm_atomic_helper_check_plane_noscale() - Check plane state for validity
> > * @plane_state: plane state to check
> > * @crtc_state: CRTC state to check
> > - * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
> > - * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
> > * @can_position: is it legal to position the plane such that it
> > *doesn't cover the entire CRTC? This will generally
> > *only be false for primary planes.
> > @@ -845,19 +843,16 @@
> > EXPORT_SYMBOL(drm_atomic_helper_check_wb_encoder_state);
> > * RETURNS:
> > * Zero if update appears valid, error code on failure
> > */
> > -int drm_atomic_helper_check_plane_state(struct drm_plane_state
> > *plane_state,
> > - const struct drm_crtc_state *crtc_state,
> > - int min_scale,
> > - int max_scale,
> > - bool can_position,
> > - bool can_update_disabled)
> > +int drm_atomic_helper_check_plane_noscale(struct drm_plane_state
> > *plane_state,
> > + const struct drm_crtc_state
> > *crtc_state,
> > + bool can_position,
> > + bool can_update_disabled)
> > {
> > struct drm_framebuffer *fb = plane_state->fb;
> > struct drm_rect *src = _state->src;
> > struct drm_rect *dst = _state->dst;
> > unsigned int rotation = plane_state->rotation;
> > struct drm_rect clip = {};
> > - int hscale, vscale;
> >
> > WARN_ON(plane_state->crtc && plane_state->crtc != crtc_state->crtc);
> >
> > @@ -883,17 +878,6 @@ int drm_atomic_helper_check_plane_state(struct
> > drm_plane_state *plane_state,
> >
> > drm_rect_rotate(src, fb->width << 16, fb->height << 16, rotation);
> >
> > - /* Check scaling */
> > - hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
> > - vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
> > - if (hscale < 0 || vscale < 0) {
> > - drm_dbg_kms(plane_state->plane->dev,
> > - "Invalid scaling of plane\n");
> > - drm_rect_debug_print("src: ", _state->src, true);
> > - drm_rect_debug_print("dst: ", _state->dst, false);
> > - return -ERANGE;
> > - }
> > -
> > if (crtc_state->enable)
> > drm_mode_get_hv_timing(_state->mode, , );
> >
> > @@ -921,6 +905,90 @@ int drm_atomic_helper_check_plane_state(struct
> > drm_plane_state *plane_state,
> >
> > return 0;
> > }
> > +EXPORT_SYMBOL(drm_atomic_helper_check_plane_noscale);
> > +
> > +/**
> > + * drm_atomic_helper_check_plane_scale() - Check whether plane can be
> > scaled
> > + * @plane_state: plane state to check
> > + * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
> > + * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
> > + *
> > + * Checks that a desired plane scale fits into the min_scale..max_scale
> > + * boundaries.
> > + * Drivers that provide their own plane handling rather than
> > helper-provided
> > + * implementations may still wish to call this function to avoid
> > duplication of
> > + * error checking code.
> > + *
> > + * RETURNS:
> > + * Zero if update appears valid, error code on failure
> > + */
> > +int drm_atomic_helper_check_plane_scale(struct drm_plane_state
> > *plane_state,
> > +
Re: [PATCH v2 4/6] drm/i915/mst: use the MST mode detected previously
On Wed, 14 Feb 2024, Ville Syrjälä wrote:
> On Tue, Feb 13, 2024 at 01:30:59PM +0200, Jani Nikula wrote:
>> Drop the duplicate read of DP_MSTM_CAP DPCD register, and the duplicate
>> logic for choosing MST mode, and store the chosen mode in struct
>> intel_dp. Rename intel_dp_configure_mst() to intel_dp_mst_configure()
>> while at it.
>>
>> Cc: Arun R Murthy
>> Cc: Ville Syrjälä
>> Signed-off-by: Jani Nikula
>> ---
>> .../drm/i915/display/intel_display_types.h| 1 +
>> drivers/gpu/drm/i915/display/intel_dp.c | 23 ---
>> 2 files changed, 11 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
>> b/drivers/gpu/drm/i915/display/intel_display_types.h
>> index 01eb6e4e6049..4a8440a3a812 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
>> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
>> @@ -1780,6 +1780,7 @@ struct intel_dp {
>>
>> bool is_mst;
>> int active_mst_links;
>> +enum drm_dp_mst_mode mst_detect;
>>
>> /* connector directly attached - won't be use for modeset in mst world
>> */
>> struct intel_connector *attached_connector;
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
>> b/drivers/gpu/drm/i915/display/intel_dp.c
>> index 007cb2a04e38..72e91322e310 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> @@ -4039,11 +4039,10 @@ intel_dp_mst_detect(struct intel_dp *intel_dp)
>> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>> struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
>> enum drm_dp_mst_mode sink_mst_mode;
>> -enum drm_dp_mst_mode mst_detect;
>>
>> sink_mst_mode = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd);
>>
>> -mst_detect = intel_dp_mst_mode_choose(intel_dp, sink_mst_mode);
>> +intel_dp->mst_detect = intel_dp_mst_mode_choose(intel_dp,
>> sink_mst_mode);
>>
>> drm_dbg_kms(>drm,
>> "[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam:
>> %s -> enable: %s\n",
>> @@ -4051,25 +4050,23 @@ intel_dp_mst_detect(struct intel_dp *intel_dp)
>> str_yes_no(intel_dp_mst_source_support(intel_dp)),
>> intel_dp_mst_mode_str(sink_mst_mode),
>> str_yes_no(i915->display.params.enable_dp_mst),
>> -intel_dp_mst_mode_str(mst_detect));
>> +intel_dp_mst_mode_str(intel_dp->mst_detect));
>>
>> -return mst_detect != DRM_DP_SST;
>> +return intel_dp->mst_detect != DRM_DP_SST;
>> }
>>
>> static void
>> -intel_dp_configure_mst(struct intel_dp *intel_dp)
>> +intel_dp_mst_configure(struct intel_dp *intel_dp)
>> {
>> -struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>> -bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd)
>> == DRM_DP_MST;
>> -
>> if (!intel_dp_mst_source_support(intel_dp))
>> return;
>
> I was wondering if we even need that, but it looks to be just a
> check to see if we actually initialized the mst_mgt or not.
> We should probably rename it or something... Or perhaps we could
> tweak the topology manager a bit so we wouldn't need to check...
Yeah, I figured we should address this in
follow-up. intel_dp_mst_suspend() and intel_dp_mst_resume() would
benefit too.
>
>>
>> -intel_dp->is_mst = sink_can_mst &&
>> -i915->display.params.enable_dp_mst;
>> +intel_dp->is_mst = intel_dp->mst_detect != DRM_DP_SST;
>> +
>> +drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr, intel_dp->is_mst);
>>
>> -drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
>> -intel_dp->is_mst);
>> +/* Avoid stale info on the next detect cycle. */
>> +intel_dp->mst_detect = DRM_DP_SST;
>
> Hmm. Not sure I like having ephemeral stuff like this in intel_dp,
> but I guess the alternative would be plumb it up from detect_dpcd()
> by hand, which might not be super pretty either. Oh well.
Trust me, I went back and forth with this, and this felt least ugly. The
main reason for resetting it back here was to ensure nobody tries to use
it for anything else, and to ensure it gets reset.
>
> Reviewed-by: Ville Syrjälä
Thanks!
>
>> }
>>
>> static bool
>> @@ -5739,7 +5736,7 @@ intel_dp_detect(struct drm_connector *connector,
>>
>> intel_dp_detect_dsc_caps(intel_dp, intel_connector);
>>
>> -intel_dp_configure_mst(intel_dp);
>> +intel_dp_mst_configure(intel_dp);
>>
>> /*
>> * TODO: Reset link params when switching to MST mode, until MST
>> --
>> 2.39.2
--
Jani Nikula, Intel
Re: [PATCH v3 02/12] drm/msm/dpu: add current resource allocation to dumped state
On 9/13/2023 10:06 PM, Dmitry Baryshkov wrote:
Provide atomic_print_state callback to the DPU's private object. This
way the debugfs/dri/0/state will also include RM's internal state.
I like this idea !
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 48 +
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 8 +
4 files changed, 62 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index ee84160592ce..172b64dc60e6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -362,6 +362,7 @@ static void dpu_kms_global_destroy_state(struct
drm_private_obj *obj,
static const struct drm_private_state_funcs dpu_kms_global_state_funcs = {
.atomic_duplicate_state = dpu_kms_global_duplicate_state,
.atomic_destroy_state = dpu_kms_global_destroy_state,
+ .atomic_print_state = dpu_rm_print_state,
};
static int dpu_kms_global_obj_init(struct dpu_kms *dpu_kms)
@@ -375,6 +376,9 @@ static int dpu_kms_global_obj_init(struct dpu_kms *dpu_kms)
drm_atomic_private_obj_init(dpu_kms->dev, _kms->global_state,
>base,
_kms_global_state_funcs);
+
+ state->rm = _kms->rm;
+
return 0;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index ed549f0f7c65..dd2be279b366 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -130,6 +130,8 @@ struct vsync_info {
struct dpu_global_state {
struct drm_private_state base;
+ struct dpu_rm *rm;
+
uint32_t pingpong_to_enc_id[PINGPONG_MAX - PINGPONG_0];
uint32_t mixer_to_enc_id[LM_MAX - LM_0];
uint32_t ctl_to_enc_id[CTL_MAX - CTL_0];
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index f9215643c71a..5e3442fb8678 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -652,3 +652,51 @@ int dpu_rm_get_assigned_resources(struct dpu_rm *rm,
return num_blks;
}
+
+void dpu_rm_print_state(struct drm_printer *p,
+ const struct drm_private_state *state)
+{
+ const struct dpu_global_state *global_state =
to_dpu_global_state(state);
+ const struct dpu_rm *rm = global_state->rm;
+ int i;
+
+ drm_puts(p, "pingpong:");
+ for (i = 0; i < ARRAY_SIZE(global_state->pingpong_to_enc_id); i++)
+ if (rm->pingpong_blks[i])
+ drm_printf(p, " %d,",
global_state->pingpong_to_enc_id[i]);
+ else
+ drm_puts(p, " -,");
+ drm_puts(p, "\n");
+
+ drm_puts(p, "mixer:");
+ for (i = 0; i < ARRAY_SIZE(global_state->mixer_to_enc_id); i++)
+ if (rm->mixer_blks[i])
+ drm_printf(p, " %d,", global_state->mixer_to_enc_id[i]);
+ else
+ drm_puts(p, " -,");
+ drm_puts(p, "\n");
+
+ drm_puts(p, "ctl:");
+ for (i = 0; i < ARRAY_SIZE(global_state->ctl_to_enc_id); i++)
+ if (rm->ctl_blks[i])
+ drm_printf(p, " %d,", global_state->ctl_to_enc_id[i]);
+ else
+ drm_puts(p, " -,");
+ drm_puts(p, "\n");
+
+ drm_puts(p, "dspp:");
+ for (i = 0; i < ARRAY_SIZE(global_state->dspp_to_enc_id); i++)
+ if (rm->dspp_blks[i])
+ drm_printf(p, " %d,", global_state->dspp_to_enc_id[i]);
+ else
+ drm_puts(p, " -,");
+ drm_puts(p, "\n");
+
+ drm_puts(p, "dsc:");
+ for (i = 0; i < ARRAY_SIZE(global_state->dsc_to_enc_id); i++)
+ if (rm->dsc_blks[i])
+ drm_printf(p, " %d,", global_state->dsc_to_enc_id[i]);
+ else
+ drm_puts(p, " -,");
+ drm_puts(p, "\n");
+}
You also need to include cdm_to_enc_id now. But otherwise LGTM.
If you have run this before, do you have a sample output to share?
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
index 2b551566cbf4..913baca81a42 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
@@ -92,6 +92,14 @@ int dpu_rm_get_assigned_resources(struct dpu_rm *rm,
struct dpu_global_state *global_state, uint32_t enc_id,
enum dpu_hw_blk_type type, struct dpu_hw_blk **blks, int blks_size);
+/**
+ * dpu_rm_print_state - output the RM private state
+ * @p: DRM printer
+ * @state: private object state
+ */
+void dpu_rm_print_state(struct drm_printer *p,
+ const struct drm_private_state *state);
+
/**
*
Re: [PATCH v3 01/12] drm/atomic-helper: split not-scaling part of drm_atomic_helper_check_plane_state
On Thu, Sep 14, 2023 at 08:06:55AM +0300, Dmitry Baryshkov wrote:
> The helper drm_atomic_helper_check_plane_state() runs several checks on
> plane src and dst rectangles, including the check whether required
> scaling fits into the required margins. The msm driver would benefit
> from having a function that does all these checks except the scaling
> one. Split them into a new helper called
> drm_atomic_helper_check_plane_noscale().
What's the point in eliminating a nop scaling check?
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 110 ++--
> include/drm/drm_atomic_helper.h | 7 ++
> 2 files changed, 96 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 292e38eb6218..2d7dd66181c9 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -825,11 +825,9 @@ drm_atomic_helper_check_wb_encoder_state(struct
> drm_encoder *encoder,
> EXPORT_SYMBOL(drm_atomic_helper_check_wb_encoder_state);
>
> /**
> - * drm_atomic_helper_check_plane_state() - Check plane state for validity
> + * drm_atomic_helper_check_plane_noscale() - Check plane state for validity
> * @plane_state: plane state to check
> * @crtc_state: CRTC state to check
> - * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
> - * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
> * @can_position: is it legal to position the plane such that it
> *doesn't cover the entire CRTC? This will generally
> *only be false for primary planes.
> @@ -845,19 +843,16 @@ EXPORT_SYMBOL(drm_atomic_helper_check_wb_encoder_state);
> * RETURNS:
> * Zero if update appears valid, error code on failure
> */
> -int drm_atomic_helper_check_plane_state(struct drm_plane_state *plane_state,
> - const struct drm_crtc_state *crtc_state,
> - int min_scale,
> - int max_scale,
> - bool can_position,
> - bool can_update_disabled)
> +int drm_atomic_helper_check_plane_noscale(struct drm_plane_state
> *plane_state,
> + const struct drm_crtc_state
> *crtc_state,
> + bool can_position,
> + bool can_update_disabled)
> {
> struct drm_framebuffer *fb = plane_state->fb;
> struct drm_rect *src = _state->src;
> struct drm_rect *dst = _state->dst;
> unsigned int rotation = plane_state->rotation;
> struct drm_rect clip = {};
> - int hscale, vscale;
>
> WARN_ON(plane_state->crtc && plane_state->crtc != crtc_state->crtc);
>
> @@ -883,17 +878,6 @@ int drm_atomic_helper_check_plane_state(struct
> drm_plane_state *plane_state,
>
> drm_rect_rotate(src, fb->width << 16, fb->height << 16, rotation);
>
> - /* Check scaling */
> - hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
> - vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
> - if (hscale < 0 || vscale < 0) {
> - drm_dbg_kms(plane_state->plane->dev,
> - "Invalid scaling of plane\n");
> - drm_rect_debug_print("src: ", _state->src, true);
> - drm_rect_debug_print("dst: ", _state->dst, false);
> - return -ERANGE;
> - }
> -
> if (crtc_state->enable)
> drm_mode_get_hv_timing(_state->mode, , );
>
> @@ -921,6 +905,90 @@ int drm_atomic_helper_check_plane_state(struct
> drm_plane_state *plane_state,
>
> return 0;
> }
> +EXPORT_SYMBOL(drm_atomic_helper_check_plane_noscale);
> +
> +/**
> + * drm_atomic_helper_check_plane_scale() - Check whether plane can be scaled
> + * @plane_state: plane state to check
> + * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
> + * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
> + *
> + * Checks that a desired plane scale fits into the min_scale..max_scale
> + * boundaries.
> + * Drivers that provide their own plane handling rather than helper-provided
> + * implementations may still wish to call this function to avoid duplication
> of
> + * error checking code.
> + *
> + * RETURNS:
> + * Zero if update appears valid, error code on failure
> + */
> +int drm_atomic_helper_check_plane_scale(struct drm_plane_state *plane_state,
> + int min_scale,
> + int max_scale)
> +{
> + struct drm_framebuffer *fb = plane_state->fb;
> + struct drm_rect src;
> + struct drm_rect dst;
> + int hscale, vscale;
> +
> + if (!plane_state->visible)
> + return 0;
> +
> + src = drm_plane_state_src(plane_state);
> + dst =
Re: [PATCH v2 5/6] drm/i915/mst: add intel_dp_mst_disconnect()
On Tue, Feb 13, 2024 at 01:31:00PM +0200, Jani Nikula wrote:
> Abstract the MST mode disconnect to a separate function.
>
> Cc: Arun R Murthy
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 24 +++-
> 1 file changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 72e91322e310..7f97d5512a3e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4069,6 +4069,20 @@ intel_dp_mst_configure(struct intel_dp *intel_dp)
> intel_dp->mst_detect = DRM_DP_SST;
> }
>
> +static void
> +intel_dp_mst_disconnect(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> +
> + if (!intel_dp->is_mst)
> + return;
> +
> + drm_dbg_kms(>drm, "MST device may have disappeared %d vs %d\n",
> + intel_dp->is_mst, intel_dp->mst_mgr.mst_state);
> + intel_dp->is_mst = false;
> + drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr, intel_dp->is_mst);
> +}
> +
> static bool
> intel_dp_get_sink_irq_esi(struct intel_dp *intel_dp, u8 *esi)
> {
> @@ -5721,15 +5735,7 @@ intel_dp_detect(struct drm_connector *connector,
> memset(intel_connector->dp.dsc_dpcd, 0,
> sizeof(intel_connector->dp.dsc_dpcd));
> intel_dp->psr.sink_panel_replay_support = false;
>
> - if (intel_dp->is_mst) {
> - drm_dbg_kms(_priv->drm,
> - "MST device may have disappeared %d vs
> %d\n",
> - intel_dp->is_mst,
> - intel_dp->mst_mgr.mst_state);
> - intel_dp->is_mst = false;
> - drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
> - intel_dp->is_mst);
> - }
> + intel_dp_mst_disconnect(intel_dp);
>
> goto out;
> }
> --
> 2.39.2
--
Ville Syrjälä
Intel
Re: [PATCH v2 4/6] drm/i915/mst: use the MST mode detected previously
On Tue, Feb 13, 2024 at 01:30:59PM +0200, Jani Nikula wrote:
> Drop the duplicate read of DP_MSTM_CAP DPCD register, and the duplicate
> logic for choosing MST mode, and store the chosen mode in struct
> intel_dp. Rename intel_dp_configure_mst() to intel_dp_mst_configure()
> while at it.
>
> Cc: Arun R Murthy
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> .../drm/i915/display/intel_display_types.h| 1 +
> drivers/gpu/drm/i915/display/intel_dp.c | 23 ---
> 2 files changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 01eb6e4e6049..4a8440a3a812 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1780,6 +1780,7 @@ struct intel_dp {
>
> bool is_mst;
> int active_mst_links;
> + enum drm_dp_mst_mode mst_detect;
>
> /* connector directly attached - won't be use for modeset in mst world
> */
> struct intel_connector *attached_connector;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 007cb2a04e38..72e91322e310 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4039,11 +4039,10 @@ intel_dp_mst_detect(struct intel_dp *intel_dp)
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
> enum drm_dp_mst_mode sink_mst_mode;
> - enum drm_dp_mst_mode mst_detect;
>
> sink_mst_mode = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd);
>
> - mst_detect = intel_dp_mst_mode_choose(intel_dp, sink_mst_mode);
> + intel_dp->mst_detect = intel_dp_mst_mode_choose(intel_dp,
> sink_mst_mode);
>
> drm_dbg_kms(>drm,
> "[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam:
> %s -> enable: %s\n",
> @@ -4051,25 +4050,23 @@ intel_dp_mst_detect(struct intel_dp *intel_dp)
> str_yes_no(intel_dp_mst_source_support(intel_dp)),
> intel_dp_mst_mode_str(sink_mst_mode),
> str_yes_no(i915->display.params.enable_dp_mst),
> - intel_dp_mst_mode_str(mst_detect));
> + intel_dp_mst_mode_str(intel_dp->mst_detect));
>
> - return mst_detect != DRM_DP_SST;
> + return intel_dp->mst_detect != DRM_DP_SST;
> }
>
> static void
> -intel_dp_configure_mst(struct intel_dp *intel_dp)
> +intel_dp_mst_configure(struct intel_dp *intel_dp)
> {
> - struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> - bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd)
> == DRM_DP_MST;
> -
> if (!intel_dp_mst_source_support(intel_dp))
> return;
I was wondering if we even need that, but it looks to be just a
check to see if we actually initialized the mst_mgt or not.
We should probably rename it or something... Or perhaps we could
tweak the topology manager a bit so we wouldn't need to check...
>
> - intel_dp->is_mst = sink_can_mst &&
> - i915->display.params.enable_dp_mst;
> + intel_dp->is_mst = intel_dp->mst_detect != DRM_DP_SST;
> +
> + drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr, intel_dp->is_mst);
>
> - drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
> - intel_dp->is_mst);
> + /* Avoid stale info on the next detect cycle. */
> + intel_dp->mst_detect = DRM_DP_SST;
Hmm. Not sure I like having ephemeral stuff like this in intel_dp,
but I guess the alternative would be plumb it up from detect_dpcd()
by hand, which might not be super pretty either. Oh well.
Reviewed-by: Ville Syrjälä
> }
>
> static bool
> @@ -5739,7 +5736,7 @@ intel_dp_detect(struct drm_connector *connector,
>
> intel_dp_detect_dsc_caps(intel_dp, intel_connector);
>
> - intel_dp_configure_mst(intel_dp);
> + intel_dp_mst_configure(intel_dp);
>
> /*
>* TODO: Reset link params when switching to MST mode, until MST
> --
> 2.39.2
--
Ville Syrjälä
Intel
Re: [PATCH v3 01/12] drm/atomic-helper: split not-scaling part of drm_atomic_helper_check_plane_state
On 9/13/2023 10:06 PM, Dmitry Baryshkov wrote:
The helper drm_atomic_helper_check_plane_state() runs several checks on
plane src and dst rectangles, including the check whether required
scaling fits into the required margins. The msm driver would benefit
from having a function that does all these checks except the scaling
one. Split them into a new helper called
drm_atomic_helper_check_plane_noscale().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_atomic_helper.c | 110 ++--
include/drm/drm_atomic_helper.h | 7 ++
2 files changed, 96 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 292e38eb6218..2d7dd66181c9 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -825,11 +825,9 @@ drm_atomic_helper_check_wb_encoder_state(struct
drm_encoder *encoder,
EXPORT_SYMBOL(drm_atomic_helper_check_wb_encoder_state);
/**
- * drm_atomic_helper_check_plane_state() - Check plane state for validity
+ * drm_atomic_helper_check_plane_noscale() - Check plane state for validity
* @plane_state: plane state to check
* @crtc_state: CRTC state to check
- * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
- * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
* @can_position: is it legal to position the plane such that it
*doesn't cover the entire CRTC? This will generally
*only be false for primary planes.
@@ -845,19 +843,16 @@ EXPORT_SYMBOL(drm_atomic_helper_check_wb_encoder_state);
* RETURNS:
* Zero if update appears valid, error code on failure
*/
-int drm_atomic_helper_check_plane_state(struct drm_plane_state *plane_state,
- const struct drm_crtc_state *crtc_state,
- int min_scale,
- int max_scale,
- bool can_position,
- bool can_update_disabled)
+int drm_atomic_helper_check_plane_noscale(struct drm_plane_state *plane_state,
+ const struct drm_crtc_state
*crtc_state,
+ bool can_position,
+ bool can_update_disabled)
{
struct drm_framebuffer *fb = plane_state->fb;
struct drm_rect *src = _state->src;
struct drm_rect *dst = _state->dst;
unsigned int rotation = plane_state->rotation;
struct drm_rect clip = {};
- int hscale, vscale;
WARN_ON(plane_state->crtc && plane_state->crtc != crtc_state->crtc);
@@ -883,17 +878,6 @@ int drm_atomic_helper_check_plane_state(struct drm_plane_state *plane_state,
drm_rect_rotate(src, fb->width << 16, fb->height << 16, rotation);
Do we need to do the rotation even for noscale before validation?
- /* Check scaling */
- hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
- vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
- if (hscale < 0 || vscale < 0) {
- drm_dbg_kms(plane_state->plane->dev,
- "Invalid scaling of plane\n");
- drm_rect_debug_print("src: ", _state->src, true);
- drm_rect_debug_print("dst: ", _state->dst, false);
- return -ERANGE;
- }
-
if (crtc_state->enable)
drm_mode_get_hv_timing(_state->mode, , );
@@ -921,6 +905,90 @@ int drm_atomic_helper_check_plane_state(struct drm_plane_state *plane_state,
return 0;
}
+EXPORT_SYMBOL(drm_atomic_helper_check_plane_noscale);
+
+/**
+ * drm_atomic_helper_check_plane_scale() - Check whether plane can be scaled
+ * @plane_state: plane state to check
+ * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
+ * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
+ *
+ * Checks that a desired plane scale fits into the min_scale..max_scale
+ * boundaries.
+ * Drivers that provide their own plane handling rather than helper-provided
+ * implementations may still wish to call this function to avoid duplication of
+ * error checking code.
+ *
+ * RETURNS:
+ * Zero if update appears valid, error code on failure
+ */
+int drm_atomic_helper_check_plane_scale(struct drm_plane_state *plane_state,
+ int min_scale,
+ int max_scale)
+{
+ struct drm_framebuffer *fb = plane_state->fb;
+ struct drm_rect src;
+ struct drm_rect dst;
+ int hscale, vscale;
+
+ if (!plane_state->visible)
+ return 0;
+
+ src = drm_plane_state_src(plane_state);
+ dst = drm_plane_state_dest(plane_state);
+
+ drm_rect_rotate(, fb->width << 16, fb->height << 16,
plane_state->rotation);
+
Does this need to be accompanied by
Re: [PATCH v2 3/6] drm/i915/mst: abstract choosing the MST mode to use
On Tue, Feb 13, 2024 at 01:30:58PM +0200, Jani Nikula wrote:
> Clarify the conditions for choosing the MST mode to use by adding a new
> function intel_dp_mst_mode_choose(). This also prepares for being able
> to extend the MST modes to single-stream sideband messaging.
>
> Cc: Arun R Murthy
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 25 +++--
> 1 file changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 944f566525dd..007cb2a04e38 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4015,6 +4015,24 @@ static const char *intel_dp_mst_mode_str(enum
> drm_dp_mst_mode mst_mode)
> return str_yes_no(mst_mode == DRM_DP_MST);
> }
>
> +static enum drm_dp_mst_mode
> +intel_dp_mst_mode_choose(struct intel_dp *intel_dp,
> + enum drm_dp_mst_mode sink_mst_mode)
> +{
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> +
> + if (!i915->display.params.enable_dp_mst)
> + return DRM_DP_SST;
> +
> + if (!intel_dp_mst_source_support(intel_dp))
> + return DRM_DP_SST;
> +
> + if (sink_mst_mode == DRM_DP_SST_SIDEBAND_MSG)
> + return DRM_DP_SST;
> +
> + return sink_mst_mode;
> +}
> +
> static bool
> intel_dp_mst_detect(struct intel_dp *intel_dp)
> {
> @@ -4025,12 +4043,7 @@ intel_dp_mst_detect(struct intel_dp *intel_dp)
>
> sink_mst_mode = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd);
>
> - if (i915->display.params.enable_dp_mst &&
> - intel_dp_mst_source_support(intel_dp) &&
> - sink_mst_mode == DRM_DP_MST)
> - mst_detect = DRM_DP_MST;
> - else
> - mst_detect = DRM_DP_SST;
> + mst_detect = intel_dp_mst_mode_choose(intel_dp, sink_mst_mode);
>
> drm_dbg_kms(>drm,
> "[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam:
> %s -> enable: %s\n",
> --
> 2.39.2
--
Ville Syrjälä
Intel
Re: [PATCH v2 2/6] drm/i915/mst: improve debug logging of DP MST mode detect
On Tue, Feb 13, 2024 at 01:30:57PM +0200, Jani Nikula wrote:
> Rename intel_dp_can_mst() to intel_dp_mst_detect(), and move all DP MST
> detect debug logging there. Debug log the sink's MST capability,
> including single-stream sideband messaging support, and the decision
> whether to enable MST mode or not. Do this regardless of whether we're
> actually enabling MST or not.
>
> Cc: Arun R Murthy
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 45 +
> 1 file changed, 31 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index a1c304f451bd..944f566525dd 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4007,31 +4007,48 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> intel_dp->downstream_ports) == 0;
> }
>
> +static const char *intel_dp_mst_mode_str(enum drm_dp_mst_mode mst_mode)
> +{
> + if (mst_mode == DRM_DP_SST_SIDEBAND_MSG)
> + return "single-stream sideband messaging";
> + else
> + return str_yes_no(mst_mode == DRM_DP_MST);
I wonder if this should also just say "sst"/"mst"/"sst sideband" etc.
Shrug.
Reviewed-by: Ville Syrjälä
> +}
> +
> static bool
> -intel_dp_can_mst(struct intel_dp *intel_dp)
> +intel_dp_mst_detect(struct intel_dp *intel_dp)
> {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
> + enum drm_dp_mst_mode sink_mst_mode;
> + enum drm_dp_mst_mode mst_detect;
> +
> + sink_mst_mode = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd);
> +
> + if (i915->display.params.enable_dp_mst &&
> + intel_dp_mst_source_support(intel_dp) &&
> + sink_mst_mode == DRM_DP_MST)
> + mst_detect = DRM_DP_MST;
> + else
> + mst_detect = DRM_DP_SST;
>
> - return i915->display.params.enable_dp_mst &&
> - intel_dp_mst_source_support(intel_dp) &&
> - drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd) ==
> DRM_DP_MST;
> + drm_dbg_kms(>drm,
> + "[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam:
> %s -> enable: %s\n",
> + encoder->base.base.id, encoder->base.name,
> + str_yes_no(intel_dp_mst_source_support(intel_dp)),
> + intel_dp_mst_mode_str(sink_mst_mode),
> + str_yes_no(i915->display.params.enable_dp_mst),
> + intel_dp_mst_mode_str(mst_detect));
> +
> + return mst_detect != DRM_DP_SST;
> }
>
> static void
> intel_dp_configure_mst(struct intel_dp *intel_dp)
> {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> - struct intel_encoder *encoder =
> - _to_dig_port(intel_dp)->base;
> bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd)
> == DRM_DP_MST;
>
> - drm_dbg_kms(>drm,
> - "[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam:
> %s\n",
> - encoder->base.base.id, encoder->base.name,
> - str_yes_no(intel_dp_mst_source_support(intel_dp)),
> - str_yes_no(sink_can_mst),
> - str_yes_no(i915->display.params.enable_dp_mst));
> -
> if (!intel_dp_mst_source_support(intel_dp))
> return;
>
> @@ -5390,7 +5407,7 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
> connector_status_connected : connector_status_disconnected;
> }
>
> - if (intel_dp_can_mst(intel_dp))
> + if (intel_dp_mst_detect(intel_dp))
> return connector_status_connected;
>
> /* If no HPD, poke DDC gently */
> --
> 2.39.2
--
Ville Syrjälä
Intel
Re: [PATCH v2 1/6] drm/mst: read sideband messaging cap
On Tue, Feb 13, 2024 at 01:30:56PM +0200, Jani Nikula wrote:
> Amend drm_dp_read_mst_cap() to return an enum, indicating "SST", "SST
> with sideband messaging", or "MST". Modify all call sites to take the
> new return value into account.
>
> v2:
> - Rename enumerators (Ville)
>
> Cc: Arun R Murthy
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/display/drm_dp_mst_topology.c | 20 ++--
> drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
> drivers/gpu/drm/nouveau/nouveau_dp.c | 2 +-
> include/drm/display/drm_dp_mst_helper.h | 23 ++-
> 4 files changed, 38 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 03d528209426..c193be3577f7 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -3608,24 +3608,30 @@ fixed20_12 drm_dp_get_vc_payload_bw(const struct
> drm_dp_mst_topology_mgr *mgr,
> EXPORT_SYMBOL(drm_dp_get_vc_payload_bw);
>
> /**
> - * drm_dp_read_mst_cap() - check whether or not a sink supports MST
> + * drm_dp_read_mst_cap() - Read the sink's MST mode capability
> * @aux: The DP AUX channel to use
> * @dpcd: A cached copy of the DPCD capabilities for this sink
> *
> - * Returns: %True if the sink supports MST, %false otherwise
> + * Returns: enum drm_dp_mst_mode to indicate MST mode capability
> */
> -bool drm_dp_read_mst_cap(struct drm_dp_aux *aux,
> - const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> +enum drm_dp_mst_mode drm_dp_read_mst_cap(struct drm_dp_aux *aux,
> + const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> {
> u8 mstm_cap;
>
> if (dpcd[DP_DPCD_REV] < DP_DPCD_REV_12)
> - return false;
> + return DRM_DP_SST;
>
> if (drm_dp_dpcd_readb(aux, DP_MSTM_CAP, _cap) != 1)
> - return false;
> + return DRM_DP_SST;
> +
> + if (mstm_cap & DP_MST_CAP)
> + return DRM_DP_MST;
> +
> + if (mstm_cap & DP_SINGLE_STREAM_SIDEBAND_MSG)
> + return DRM_DP_SST_SIDEBAND_MSG;
>
> - return mstm_cap & DP_MST_CAP;
> + return DRM_DP_SST;
> }
> EXPORT_SYMBOL(drm_dp_read_mst_cap);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 5045c34a16be..a1c304f451bd 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4014,7 +4014,7 @@ intel_dp_can_mst(struct intel_dp *intel_dp)
>
> return i915->display.params.enable_dp_mst &&
> intel_dp_mst_source_support(intel_dp) &&
> - drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd);
> + drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd) ==
> DRM_DP_MST;
> }
>
> static void
> @@ -4023,7 +4023,7 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> struct intel_encoder *encoder =
> _to_dig_port(intel_dp)->base;
> - bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd);
> + bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd)
> == DRM_DP_MST;
>
> drm_dbg_kms(>drm,
> "[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam:
> %s\n",
> diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
> b/drivers/gpu/drm/nouveau/nouveau_dp.c
> index 7de7707ec6a8..fb06ee17d9e5 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_dp.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
> @@ -181,7 +181,7 @@ nouveau_dp_probe_dpcd(struct nouveau_connector
> *nv_connector,
> if (nouveau_mst) {
> mstm = outp->dp.mstm;
> if (mstm)
> - mstm->can_mst = drm_dp_read_mst_cap(aux, dpcd);
> + mstm->can_mst = drm_dp_read_mst_cap(aux, dpcd) ==
> DRM_DP_MST;
> }
>
> if (nouveau_dp_has_sink_count(connector, outp)) {
> diff --git a/include/drm/display/drm_dp_mst_helper.h
> b/include/drm/display/drm_dp_mst_helper.h
> index 9b19d8bd520a..3c9e128c444a 100644
> --- a/include/drm/display/drm_dp_mst_helper.h
> +++ b/include/drm/display/drm_dp_mst_helper.h
> @@ -818,7 +818,28 @@ int drm_dp_mst_topology_mgr_init(struct
> drm_dp_mst_topology_mgr *mgr,
>
> void drm_dp_mst_topology_mgr_destroy(struct drm_dp_mst_topology_mgr *mgr);
>
> -bool drm_dp_read_mst_cap(struct drm_dp_aux *aux, const u8
> dpcd[DP_RECEIVER_CAP_SIZE]);
> +/**
> + * enum drm_dp_mst_mode - sink's MST mode capability
> + */
> +enum drm_dp_mst_mode {
> + /**
> + * @DRM_DP_SST: The sink does not support MST nor single stream sideband
> + * messaging.
> + */
> + DRM_DP_SST,
> + /**
> + * @DRM_DP_MST: Sink supports MST, more than one stream and single
> + * stream sideband messaging.
> + */
> + DRM_DP_MST,
> +
Re: [PATCH] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper
On 2/14/2024 10:02 AM, Ville Syrjälä wrote:
On Wed, Feb 14, 2024 at 09:17:34AM -0800, Abhinav Kumar wrote:
On 2/14/2024 12:15 AM, Dmitry Baryshkov wrote:
On Wed, 14 Feb 2024 at 01:45, Abhinav Kumar wrote:
intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well.
Lets move this to drm_dp_helper to achieve this.
Signed-off-by: Abhinav Kumar
My preference would be to have packing functions in
drivers/video/hdmi.c, as we already have
hdmi_audio_infoframe_pack_for_dp() there.
My preference is drm_dp_helper because it already has some VSC SDP stuff
and after discussion with Ville on IRC, I decided to post it this way.
hdmi_audio_infoframe_pack_for_dp() is an exception from my PoV as the
hdmi audio infoframe fields were re-used and packed into a DP SDP
thereby re-using the existing struct hdmi_audio_infoframe .
This is not like that. Here we pack from struct drm_dp_vsc_sdp to struct
dp_sdp both of which had prior usages already in this file.
So it all adds up and makes sense to me to be in this file.
I will let the other DRM core maintainers comment on this.
Ville, Jani?
Yeah, I'm not sure bloating the (poorly named) hdmi.c with all
SDP stuff is a great idea. Since other related stuff already
lives in the drm_dp_helper.c that seems reasonable to me at this
time. And if we get a decent amount of this then probably all
DP SDP stuff should be extracted into its own file.
Yes, thanks.
There are of course a few overlaps here andthere (the audio SDP
I guess, and the CTA infoframe SDP). But I'm not sure that actually
needs any SDP specific stuff in hdmi.c, or could we just let hdmi.c
deal with the actual CTA-861 stuff and then have the DP SDP code
wrap that up in its own thing externally? Dunno, haven't really
looked at the details.
Thats a good way to look at it. this packing is from DP spec and not CTA
so makes more sense to be in this file.
In that case, R-b?
---
drivers/gpu/drm/display/drm_dp_helper.c | 78 +
drivers/gpu/drm/i915/display/intel_dp.c | 73 +--
include/drm/display/drm_dp_helper.h | 3 +
3 files changed, 84 insertions(+), 70 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index b1ca3a1100da..066cfbbf7a91 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2916,6 +2916,84 @@ void drm_dp_vsc_sdp_log(const char *level, struct device
*dev,
}
EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
+/**
+ * drm_dp_vsc_sdp_pack() - pack a given vsc sdp into generic dp_sdp
+ * @vsc: vsc sdp initialized according to its purpose as defined in
+ * table 2-118 - table 2-120 in DP 1.4a specification
+ * @sdp: valid handle to the generic dp_sdp which will be packed
+ * @size: valid size of the passed sdp handle
+ *
+ * Returns length of sdp on success and error code on failure
+ */
+ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
+ struct dp_sdp *sdp, size_t size)
I know that you are just moving the function. Maybe there can be
patch#2, which drops the size argument? The struct dp_sdp already has
a defined size. The i915 driver just passes sizeof(sdp), which is more
or less useless.
Yes this is a valid point, I also noticed this. I can post it on top of
this once we get an agreement and ack on this patch first.
+{
+ size_t length = sizeof(struct dp_sdp);
+
+ if (size < length)
+ return -ENOSPC;
+
+ memset(sdp, 0, size);
+
+ /*
+* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
+* VSC SDP Header Bytes
+*/
+ sdp->sdp_header.HB0 = 0; /* Secondary-Data Packet ID = 0 */
+ sdp->sdp_header.HB1 = vsc->sdp_type; /* Secondary-data Packet Type */
+ sdp->sdp_header.HB2 = vsc->revision; /* Revision Number */
+ sdp->sdp_header.HB3 = vsc->length; /* Number of Valid Data Bytes */
+
+ if (vsc->revision == 0x6) {
+ sdp->db[0] = 1;
+ sdp->db[3] = 1;
+ }
+
+ /*
+* Revision 0x5 and revision 0x7 supports Pixel Encoding/Colorimetry
+* Format as per DP 1.4a spec and DP 2.0 respectively.
+*/
+ if (!(vsc->revision == 0x5 || vsc->revision == 0x7))
+ goto out;
+
+ /* VSC SDP Payload for DB16 through DB18 */
+ /* Pixel Encoding and Colorimetry Formats */
+ sdp->db[16] = (vsc->pixelformat & 0xf) << 4; /* DB16[7:4] */
+ sdp->db[16] |= vsc->colorimetry & 0xf; /* DB16[3:0] */
+
+ switch (vsc->bpc) {
+ case 6:
+ /* 6bpc: 0x0 */
+ break;
+ case 8:
+ sdp->db[17] = 0x1; /* DB17[3:0] */
+ break;
+ case 10:
+ sdp->db[17] = 0x2;
+ break;
+ case 12:
+ sdp->db[17] = 0x3;
+ break;
+ case 16:
+ sdp->db[17] = 0x4;
+
[PATCH v3 16/19] drm/msm/dpu: modify encoder programming for CDM over DP
Adjust the encoder format programming in the case of video mode for DP
to accommodate CDM related changes.
Changes in v2:
- Move timing engine programming to a separate patch from this
one
- Move update_pending_flush_periph() invocation completely to
this patch
- Change the logic of dpu_encoder_get_drm_fmt() so that it only
calls drm_mode_is_420_only() instead of doing additional
unnecessary checks
- Create new functions msm_dp_needs_periph_flush() and it's
supporting function dpu_encoder_needs_periph_flush() to check
if the mode is YUV420 and VSC SDP is enabled before doing a
peripheral flush
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 35 +++
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 13 +++
.../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 19 ++
drivers/gpu/drm/msm/dp/dp_display.c | 18 ++
drivers/gpu/drm/msm/msm_drv.h | 17 -
5 files changed, 101 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 7e7796561009a..6280c6be6dca9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -222,6 +222,41 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
};
+u32 dpu_encoder_get_drm_fmt(struct dpu_encoder_phys *phys_enc)
+{
+ struct drm_encoder *drm_enc;
+ struct dpu_encoder_virt *dpu_enc;
+ struct drm_display_info *info;
+ struct drm_display_mode *mode;
+
+ drm_enc = phys_enc->parent;
+ dpu_enc = to_dpu_encoder_virt(drm_enc);
+ info = _enc->connector->display_info;
+ mode = _enc->cached_mode;
+
+ if (drm_mode_is_420_only(info, mode))
+ return DRM_FORMAT_YUV420;
+
+ return DRM_FORMAT_RGB888;
+}
+
+bool dpu_encoder_needs_periph_flush(struct dpu_encoder_phys *phys_enc)
+{
+ struct drm_encoder *drm_enc;
+ struct dpu_encoder_virt *dpu_enc;
+ struct msm_display_info *disp_info;
+ struct msm_drm_private *priv;
+ struct drm_display_mode *mode;
+
+ drm_enc = phys_enc->parent;
+ dpu_enc = to_dpu_encoder_virt(drm_enc);
+ disp_info = _enc->disp_info;
+ priv = drm_enc->dev->dev_private;
+ mode = _enc->cached_mode;
+
+ return phys_enc->hw_intf->cap->type == INTF_DP && phys_enc->hw_cdm &&
+
msm_dp_needs_periph_flush(priv->dp[disp_info->h_tile_instance[0]], mode);
+}
bool dpu_encoder_is_widebus_enabled(const struct drm_encoder *drm_enc)
{
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index f43d57d9c74e1..211a3d90eb690 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -341,6 +341,19 @@ static inline enum dpu_3d_blend_mode
dpu_encoder_helper_get_3d_blend_mode(
*/
unsigned int dpu_encoder_helper_get_dsc(struct dpu_encoder_phys *phys_enc);
+/**
+ * dpu_encoder_get_drm_fmt - return DRM fourcc format
+ * @phys_enc: Pointer to physical encoder structure
+ */
+u32 dpu_encoder_get_drm_fmt(struct dpu_encoder_phys *phys_enc);
+
+/**
+ * dpu_encoder_needs_periph_flush - return true if physical encoder requires
+ * peripheral flush
+ * @phys_enc: Pointer to physical encoder structure
+ */
+bool dpu_encoder_needs_periph_flush(struct dpu_encoder_phys *phys_enc);
+
/**
* dpu_encoder_helper_split_config - split display configuration helper
function
* This helper function may be used by physical encoders to configure
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index f02411b062c4c..e29bc4bd39208 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -415,8 +415,15 @@ static int dpu_encoder_phys_vid_control_vblank_irq(
static void dpu_encoder_phys_vid_enable(struct dpu_encoder_phys *phys_enc)
{
struct dpu_hw_ctl *ctl;
+ struct dpu_hw_cdm *hw_cdm;
+ const struct dpu_format *fmt = NULL;
+ u32 fmt_fourcc = DRM_FORMAT_RGB888;
ctl = phys_enc->hw_ctl;
+ hw_cdm = phys_enc->hw_cdm;
+ if (hw_cdm)
+ fmt_fourcc = dpu_encoder_get_drm_fmt(phys_enc);
+ fmt = dpu_get_dpu_format(fmt_fourcc);
DPU_DEBUG_VIDENC(phys_enc, "\n");
@@ -425,6 +432,8 @@ static void dpu_encoder_phys_vid_enable(struct
dpu_encoder_phys *phys_enc)
dpu_encoder_helper_split_config(phys_enc, phys_enc->hw_intf->idx);
+ dpu_encoder_helper_phys_setup_cdm(phys_enc, fmt, CDM_CDWN_OUTPUT_HDMI);
+
dpu_encoder_phys_vid_setup_timing_engine(phys_enc);
/*
@@ -440,6 +449,16 @@ static void
[PATCH v3 19/19] drm/msm/dp: allow YUV420 mode for DP connector when CDM available
All the components of YUV420 over DP are added. Therefore, let's mark the
connector property as true for DP connector when the DP type is not eDP
and when there is a CDM block available.
Changes in v3:
- Move setting the connector's ycbcr_420_allowed parameter so
that it is not dependent on if the dp_display is not eDP
Changes in v2:
- Check for if dp_catalog has a CDM block available instead of
checking if VSC SDP is allowed when setting the dp connector's
ycbcr_420_allowed parameter
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 +++-
drivers/gpu/drm/msm/dp/dp_display.c | 4 ++--
drivers/gpu/drm/msm/dp/dp_drm.c | 6 +-
drivers/gpu/drm/msm/dp/dp_drm.h | 3 ++-
drivers/gpu/drm/msm/msm_drv.h | 5 +++--
5 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 723cc1d821431..8d326fb36550a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -565,6 +565,7 @@ static int _dpu_kms_initialize_displayport(struct
drm_device *dev,
{
struct drm_encoder *encoder = NULL;
struct msm_display_info info;
+ bool yuv_supported;
int rc;
int i;
@@ -583,7 +584,8 @@ static int _dpu_kms_initialize_displayport(struct
drm_device *dev,
return PTR_ERR(encoder);
}
- rc = msm_dp_modeset_init(priv->dp[i], dev, encoder);
+ yuv_supported = !!dpu_kms->catalog->cdm;
+ rc = msm_dp_modeset_init(priv->dp[i], dev, encoder,
yuv_supported);
if (rc) {
DPU_ERROR("modeset_init failed for DP, rc = %d\n", rc);
return rc;
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index ebcc76ef1d590..9b9f5f2921903 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1471,7 +1471,7 @@ static int dp_display_get_next_bridge(struct msm_dp *dp)
}
int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device *dev,
- struct drm_encoder *encoder)
+ struct drm_encoder *encoder, bool yuv_supported)
{
struct dp_display_private *dp_priv;
int ret;
@@ -1487,7 +1487,7 @@ int msm_dp_modeset_init(struct msm_dp *dp_display, struct
drm_device *dev,
return ret;
}
- dp_display->connector = dp_drm_connector_init(dp_display, encoder);
+ dp_display->connector = dp_drm_connector_init(dp_display, encoder,
yuv_supported);
if (IS_ERR(dp_display->connector)) {
ret = PTR_ERR(dp_display->connector);
DRM_DEV_ERROR(dev->dev,
diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c b/drivers/gpu/drm/msm/dp/dp_drm.c
index 46e6889037e88..a819a4ff76a9f 100644
--- a/drivers/gpu/drm/msm/dp/dp_drm.c
+++ b/drivers/gpu/drm/msm/dp/dp_drm.c
@@ -353,7 +353,8 @@ int dp_bridge_init(struct msm_dp *dp_display, struct
drm_device *dev,
}
/* connector initialization */
-struct drm_connector *dp_drm_connector_init(struct msm_dp *dp_display, struct
drm_encoder *encoder)
+struct drm_connector *dp_drm_connector_init(struct msm_dp *dp_display, struct
drm_encoder *encoder,
+ bool yuv_supported)
{
struct drm_connector *connector = NULL;
@@ -364,6 +365,9 @@ struct drm_connector *dp_drm_connector_init(struct msm_dp
*dp_display, struct dr
if (!dp_display->is_edp)
drm_connector_attach_dp_subconnector_property(connector);
+ if (yuv_supported)
+ connector->ycbcr_420_allowed = true;
+
drm_connector_attach_encoder(connector, encoder);
return connector;
diff --git a/drivers/gpu/drm/msm/dp/dp_drm.h b/drivers/gpu/drm/msm/dp/dp_drm.h
index b3d684db2383b..45e57ac25a4d9 100644
--- a/drivers/gpu/drm/msm/dp/dp_drm.h
+++ b/drivers/gpu/drm/msm/dp/dp_drm.h
@@ -19,7 +19,8 @@ struct msm_dp_bridge {
#define to_dp_bridge(x) container_of((x), struct msm_dp_bridge, bridge)
-struct drm_connector *dp_drm_connector_init(struct msm_dp *dp_display, struct
drm_encoder *encoder);
+struct drm_connector *dp_drm_connector_init(struct msm_dp *dp_display, struct
drm_encoder *encoder,
+ bool yuv_supported);
int dp_bridge_init(struct msm_dp *dp_display, struct drm_device *dev,
struct drm_encoder *encoder);
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index b876ebd48effe..37335777f5c09 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -385,7 +385,7 @@ static inline struct drm_dsc_config
*msm_dsi_get_dsc_config(struct msm_dsi *msm_
int __init msm_dp_register(void);
void __exit msm_dp_unregister(void);
int msm_dp_modeset_init(struct
[PATCH v3 15/19] drm/msm/dp: enable SDP and SDE periph flush update
DP controller can be setup to operate in either SDP update flush mode or
peripheral flush mode based on the DP controller hardware version.
Starting in DP v1.2, the hardware documents require the use of
peripheral flush mode for SDP packets such as PPS OR VSC SDP packets.
In-line with this guidance, lets program the DP controller to use
peripheral flush mode starting DP v1.2
Changes in v3:
- Clear up that the DP_MAINLINK_FLUSH_MODE_SDE_PERIPH_UPDATE
macro is setting bits [24:23] to a value of 3
Changes in v2:
- Use the original dp_catalog_hw_revision() function to
correctly check the DP HW version
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 17 +
drivers/gpu/drm/msm/dp/dp_catalog.h | 1 +
drivers/gpu/drm/msm/dp/dp_ctrl.c| 1 +
drivers/gpu/drm/msm/dp/dp_reg.h | 5 +
4 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 61d5317efe683..823eeba7e71d3 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -440,6 +440,23 @@ void dp_catalog_ctrl_config_misc(struct dp_catalog
*dp_catalog,
dp_write_link(catalog, REG_DP_MISC1_MISC0, misc_val);
}
+void dp_catalog_setup_peripheral_flush(struct dp_catalog *dp_catalog)
+{
+ u32 mainlink_ctrl, hw_revision;
+ struct dp_catalog_private *catalog = container_of(dp_catalog,
+ struct dp_catalog_private, dp_catalog);
+
+ mainlink_ctrl = dp_read_link(catalog, REG_DP_MAINLINK_CTRL);
+
+ hw_revision = dp_catalog_hw_revision(dp_catalog);
+ if (hw_revision >= DP_HW_VERSION_1_2)
+ mainlink_ctrl |= DP_MAINLINK_FLUSH_MODE_SDE_PERIPH_UPDATE;
+ else
+ mainlink_ctrl |= DP_MAINLINK_FLUSH_MODE_UPDATE_SDP;
+
+ dp_write_link(catalog, REG_DP_MAINLINK_CTRL, mainlink_ctrl);
+}
+
void dp_catalog_ctrl_config_msa(struct dp_catalog *dp_catalog,
u32 rate, u32 stream_rate_khz,
bool fixed_nvid, bool is_ycbcr_420)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.h
b/drivers/gpu/drm/msm/dp/dp_catalog.h
index 4bf08c27a9bf3..eb05a37837beb 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.h
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.h
@@ -98,6 +98,7 @@ void dp_catalog_ctrl_config_ctrl(struct dp_catalog
*dp_catalog, u32 config);
void dp_catalog_ctrl_lane_mapping(struct dp_catalog *dp_catalog);
void dp_catalog_ctrl_mainlink_ctrl(struct dp_catalog *dp_catalog, bool enable);
void dp_catalog_ctrl_psr_mainlink_enable(struct dp_catalog *dp_catalog, bool
enable);
+void dp_catalog_setup_peripheral_flush(struct dp_catalog *dp_catalog);
void dp_catalog_ctrl_config_misc(struct dp_catalog *dp_catalog, u32 cc, u32
tb);
void dp_catalog_ctrl_config_msa(struct dp_catalog *dp_catalog, u32 rate,
u32 stream_rate_khz, bool fixed_nvid, bool
is_ycbcr_420);
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index beef86b1aaf81..f1e7b0a5ee5d1 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -170,6 +170,7 @@ static void dp_ctrl_configure_source_params(struct
dp_ctrl_private *ctrl)
dp_catalog_ctrl_lane_mapping(ctrl->catalog);
dp_catalog_ctrl_mainlink_ctrl(ctrl->catalog, true);
+ dp_catalog_setup_peripheral_flush(ctrl->catalog);
dp_ctrl_config_ctrl(ctrl);
diff --git a/drivers/gpu/drm/msm/dp/dp_reg.h b/drivers/gpu/drm/msm/dp/dp_reg.h
index 2983756c125cd..d4fb8572cd1e4 100644
--- a/drivers/gpu/drm/msm/dp/dp_reg.h
+++ b/drivers/gpu/drm/msm/dp/dp_reg.h
@@ -6,6 +6,9 @@
#ifndef _DP_REG_H_
#define _DP_REG_H_
+#include
+#include
+
/* DP_TX Registers */
#define REG_DP_HW_VERSION (0x)
@@ -102,6 +105,8 @@
#define DP_MAINLINK_CTRL_ENABLE(0x0001)
#define DP_MAINLINK_CTRL_RESET (0x0002)
#define DP_MAINLINK_CTRL_SW_BYPASS_SCRAMBLER (0x0010)
+#define DP_MAINLINK_FLUSH_MODE_UPDATE_SDP (0x0080)
+#define DP_MAINLINK_FLUSH_MODE_SDE_PERIPH_UPDATE FIELD_PREP(GENMASK(24,
23), 3)
#define DP_MAINLINK_FB_BOUNDARY_SEL(0x0200)
#define REG_DP_STATE_CTRL (0x0004)
--
2.39.2
[PATCH v3 18/19] drm/msm/dpu: reserve CDM blocks for DP if mode is YUV420
Reserve CDM blocks for DP if the mode format is YUV420. Currently this
reservation only works for writeback and DP if the format is YUV420. But
this can be easily extented to other YUV formats for DP.
Changes in v2:
- Minor code simplification
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 22 +
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 6280c6be6dca9..ec53e5f4a696d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -639,6 +639,7 @@ static int dpu_encoder_virt_atomic_check(
struct dpu_kms *dpu_kms;
struct drm_display_mode *adj_mode;
struct msm_display_topology topology;
+ struct msm_display_info *disp_info;
struct dpu_global_state *global_state;
struct drm_framebuffer *fb;
struct drm_dsc_config *dsc;
@@ -655,6 +656,7 @@ static int dpu_encoder_virt_atomic_check(
DPU_DEBUG_ENC(dpu_enc, "\n");
priv = drm_enc->dev->dev_private;
+ disp_info = _enc->disp_info;
dpu_kms = to_dpu_kms(priv->kms);
adj_mode = _state->adjusted_mode;
global_state = dpu_kms_get_global_state(crtc_state->state);
@@ -682,21 +684,24 @@ static int dpu_encoder_virt_atomic_check(
topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode,
crtc_state, dsc);
/*
-* Use CDM only for writeback at the moment as other interfaces cannot
handle it.
-* if writeback itself cannot handle cdm for some reason it will fail
in its atomic_check()
+* Use CDM only for writeback or DP at the moment as other interfaces
cannot handle it.
+* If writeback itself cannot handle cdm for some reason it will fail
in its atomic_check()
* earlier.
*/
- if (dpu_enc->disp_info.intf_type == INTF_WB &&
conn_state->writeback_job) {
+ if (disp_info->intf_type == INTF_WB && conn_state->writeback_job) {
fb = conn_state->writeback_job->fb;
if (fb &&
DPU_FORMAT_IS_YUV(to_dpu_format(msm_framebuffer_format(fb
topology.needs_cdm = true;
- if (topology.needs_cdm && !dpu_enc->cur_master->hw_cdm)
- crtc_state->mode_changed = true;
- else if (!topology.needs_cdm && dpu_enc->cur_master->hw_cdm)
- crtc_state->mode_changed = true;
+ } else if (disp_info->intf_type == INTF_DP) {
+ if
(msm_dp_is_yuv_420_enabled(priv->dp[disp_info->h_tile_instance[0]], adj_mode))
+ topology.needs_cdm = true;
}
+ if (topology.needs_cdm && !dpu_enc->cur_master->hw_cdm)
+ crtc_state->mode_changed = true;
+ else if (!topology.needs_cdm && dpu_enc->cur_master->hw_cdm)
+ crtc_state->mode_changed = true;
/*
* Release and Allocate resources on every modeset
* Dont allocate when active is false.
@@ -1137,7 +1142,8 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
dpu_enc->dsc_mask = dsc_mask;
- if (dpu_enc->disp_info.intf_type == INTF_WB &&
conn_state->writeback_job) {
+ if ((dpu_enc->disp_info.intf_type == INTF_WB &&
conn_state->writeback_job) ||
+ dpu_enc->disp_info.intf_type == INTF_DP) {
struct dpu_hw_blk *hw_cdm = NULL;
dpu_rm_get_assigned_resources(_kms->rm, global_state,
--
2.39.2
[PATCH v3 17/19] drm/msm/dpu: modify timing engine programming for YUV420 over DP
Adjust the encoder timing engine setup programming in the case of video
mode for YUV420 over DP to accommodate CDM.
Changes in v3:
- Move drm_display_mode's hskew division to another patch
- Minor cleanup
Changes in v2:
- Move timing engine programming to this patch
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index e29bc4bd39208..04df501d23bfa 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -236,7 +236,7 @@ static void dpu_encoder_phys_vid_setup_timing_engine(
struct drm_display_mode mode;
struct dpu_hw_intf_timing_params timing_params = { 0 };
const struct dpu_format *fmt = NULL;
- u32 fmt_fourcc = DRM_FORMAT_RGB888;
+ u32 fmt_fourcc;
unsigned long lock_flags;
struct dpu_hw_intf_cfg intf_cfg = { 0 };
@@ -255,7 +255,9 @@ static void dpu_encoder_phys_vid_setup_timing_engine(
DPU_DEBUG_VIDENC(phys_enc, "enabling mode:\n");
drm_mode_debug_printmodeline();
- if (phys_enc->split_role != ENC_ROLE_SOLO) {
+ fmt_fourcc = dpu_encoder_get_drm_fmt(phys_enc);
+
+ if (phys_enc->split_role != ENC_ROLE_SOLO || fmt_fourcc ==
DRM_FORMAT_YUV420) {
mode.hdisplay >>= 1;
mode.htotal >>= 1;
mode.hsync_start >>= 1;
@@ -275,6 +277,8 @@ static void dpu_encoder_phys_vid_setup_timing_engine(
fmt = dpu_get_dpu_format(fmt_fourcc);
DPU_DEBUG_VIDENC(phys_enc, "fmt_fourcc 0x%X\n", fmt_fourcc);
+ if (phys_enc->hw_cdm)
+ intf_cfg.cdm = phys_enc->hw_cdm->idx;
intf_cfg.intf = phys_enc->hw_intf->idx;
intf_cfg.intf_mode_sel = DPU_CTL_MODE_SEL_VID;
intf_cfg.stream_sel = 0; /* Don't care value for video mode */
--
2.39.2
[PATCH v3 10/19] drm/msm/dp: program config ctrl for YUV420 over DP
Change relevant DP controller related programming for YUV420 cases. Program the configuration control register to indicate YUV420. Changes in v2: - Create a new patch only for configuration control programming Signed-off-by: Paloma Arellano Reviewed-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/dp/dp_ctrl.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c index 77a8d9366ed7b..da8f0d9f98718 100644 --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c @@ -128,6 +128,9 @@ static void dp_ctrl_config_ctrl(struct dp_ctrl_private *ctrl) /* Default-> LSCLK DIV: 1/4 LCLK */ config |= (2 << DP_CONFIGURATION_CTRL_LSCLK_DIV_SHIFT); + if (ctrl->panel->dp_mode.out_fmt_is_yuv_420) + config |= DP_CONFIGURATION_CTRL_RGB_YUV; /* YUV420 */ + /* Scrambler reset enable */ if (drm_dp_alternate_scrambler_reset_cap(dpcd)) config |= DP_CONFIGURATION_CTRL_ASSR; -- 2.39.2
[PATCH v3 14/19] drm/msm/dpu: add support of new peripheral flush mechanism
From: Kuogee Hsieh
Introduce a peripheral flushing mechanism to decouple peripheral
metadata flushing from timing engine related flush.
Changes in v2:
- Fixed some misalignment issues
Signed-off-by: Kuogee Hsieh
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 17 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 10 ++
2 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index e76565c3e6a43..a06f69d0b257d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -39,6 +39,7 @@
#define CTL_WB_FLUSH 0x108
#define CTL_INTF_FLUSH0x110
#define CTL_CDM_FLUSH0x114
+#define CTL_PERIPH_FLUSH 0x128
#define CTL_INTF_MASTER 0x134
#define CTL_DSPP_n_FLUSH(n) ((0x13C) + ((n) * 4))
@@ -49,6 +50,7 @@
#define MERGE_3D_IDX 23
#define DSC_IDX22
#define CDM_IDX 26
+#define PERIPH_IDX 30
#define INTF_IDX 31
#define WB_IDX 16
#define DSPP_IDX 29 /* From DPU hw rev 7.x.x */
@@ -151,6 +153,10 @@ static inline void dpu_hw_ctl_trigger_flush_v1(struct
dpu_hw_ctl *ctx)
ctx->pending_dspp_flush_mask[dspp - DSPP_0]);
}
+ if (ctx->pending_flush_mask & BIT(PERIPH_IDX))
+ DPU_REG_WRITE(>hw, CTL_PERIPH_FLUSH,
+ ctx->pending_periph_flush_mask);
+
if (ctx->pending_flush_mask & BIT(DSC_IDX))
DPU_REG_WRITE(>hw, CTL_DSC_FLUSH,
ctx->pending_dsc_flush_mask);
@@ -311,6 +317,13 @@ static void dpu_hw_ctl_update_pending_flush_intf_v1(struct
dpu_hw_ctl *ctx,
ctx->pending_flush_mask |= BIT(INTF_IDX);
}
+static void dpu_hw_ctl_update_pending_flush_periph_v1(struct dpu_hw_ctl *ctx,
+ enum dpu_intf intf)
+{
+ ctx->pending_periph_flush_mask |= BIT(intf - INTF_0);
+ ctx->pending_flush_mask |= BIT(PERIPH_IDX);
+}
+
static void dpu_hw_ctl_update_pending_flush_merge_3d_v1(struct dpu_hw_ctl *ctx,
enum dpu_merge_3d merge_3d)
{
@@ -680,6 +693,10 @@ static void _setup_ctl_ops(struct dpu_hw_ctl_ops *ops,
ops->reset_intf_cfg = dpu_hw_ctl_reset_intf_cfg_v1;
ops->update_pending_flush_intf =
dpu_hw_ctl_update_pending_flush_intf_v1;
+
+ ops->update_pending_flush_periph =
+ dpu_hw_ctl_update_pending_flush_periph_v1;
+
ops->update_pending_flush_merge_3d =
dpu_hw_ctl_update_pending_flush_merge_3d_v1;
ops->update_pending_flush_wb =
dpu_hw_ctl_update_pending_flush_wb_v1;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
index ff85b5ee0acf8..ef56280bea932 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
@@ -122,6 +122,15 @@ struct dpu_hw_ctl_ops {
void (*update_pending_flush_intf)(struct dpu_hw_ctl *ctx,
enum dpu_intf blk);
+ /**
+* OR in the given flushbits to the cached pending_(periph_)flush_mask
+* No effect on hardware
+* @ctx : ctl path ctx pointer
+* @blk : interface block index
+*/
+ void (*update_pending_flush_periph)(struct dpu_hw_ctl *ctx,
+ enum dpu_intf blk);
+
/**
* OR in the given flushbits to the cached pending_(merge_3d_)flush_mask
* No effect on hardware
@@ -264,6 +273,7 @@ struct dpu_hw_ctl {
u32 pending_flush_mask;
u32 pending_intf_flush_mask;
u32 pending_wb_flush_mask;
+ u32 pending_periph_flush_mask;
u32 pending_merge_3d_flush_mask;
u32 pending_dspp_flush_mask[DSPP_MAX - DSPP_0];
u32 pending_dsc_flush_mask;
--
2.39.2
[PATCH v3 08/19] drm/msm/dp: check if VSC SDP is supported in DP programming
In the DP driver, check if VSC SDP is supported and propagate this value
to dp_panel. In dp_display's dp_mode, the out_fmt_is_yuv_420 parameter
must also utilize this value since YUV420 is only allowed when VSC SDP
is supported.
Changes in v2:
- Move DP programming when VSC SDP is supported to this patch
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 5 -
drivers/gpu/drm/msm/dp/dp_panel.c | 1 +
drivers/gpu/drm/msm/dp/dp_panel.h | 1 +
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index ddac55f45a722..6323dc08d5eb8 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1595,8 +1595,10 @@ void dp_bridge_mode_set(struct drm_bridge *drm_bridge,
struct msm_dp_bridge *dp_bridge = to_dp_bridge(drm_bridge);
struct msm_dp *dp = dp_bridge->dp_display;
struct dp_display_private *dp_display;
+ struct dp_panel *dp_panel;
dp_display = container_of(dp, struct dp_display_private, dp_display);
+ dp_panel = dp_display->panel;
memset(_display->dp_mode, 0x0, sizeof(struct dp_display_mode));
@@ -1617,7 +1619,8 @@ void dp_bridge_mode_set(struct drm_bridge *drm_bridge,
!!(dp_display->dp_mode.drm_mode.flags & DRM_MODE_FLAG_NHSYNC);
dp_display->dp_mode.out_fmt_is_yuv_420 =
- drm_mode_is_420_only(>connector->display_info,
adjusted_mode);
+ drm_mode_is_420_only(>connector->display_info,
adjusted_mode) &&
+ dp_panel->vsc_sdp_supported;
/* populate wide_bus_support to different layers */
dp_display->ctrl->wide_bus_en =
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c
b/drivers/gpu/drm/msm/dp/dp_panel.c
index 127f6af995cd1..db1942794f1a4 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.c
+++ b/drivers/gpu/drm/msm/dp/dp_panel.c
@@ -53,6 +53,7 @@ static int dp_panel_read_dpcd(struct dp_panel *dp_panel)
if (rc)
return rc;
+ dp_panel->vsc_sdp_supported = drm_dp_vsc_sdp_supported(panel->aux,
dpcd);
link_info = _panel->link_info;
link_info->revision = dpcd[DP_DPCD_REV];
major = (link_info->revision >> 4) & 0x0f;
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.h
b/drivers/gpu/drm/msm/dp/dp_panel.h
index 6ec68be9f2366..e843f5062d1f6 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.h
+++ b/drivers/gpu/drm/msm/dp/dp_panel.h
@@ -46,6 +46,7 @@ struct dp_panel {
struct dp_display_mode dp_mode;
struct dp_panel_psr psr_cap;
bool video_test;
+ bool vsc_sdp_supported;
u32 vic;
u32 max_dp_lanes;
--
2.39.2
[PATCH v3 01/19] drm/msm/dpu: allow certain formats for CDM for DP
CDM block supports formats other than H1V2 for DP. Since we are now
adding support for CDM over DP, relax the checks to allow all other
formats for DP other than H1V2.
Changes in v2:
- Add fixes tag
- Move patch to top of series
Fixes: 0afac0ba6024 ("drm/msm/dpu: add dpu_hw_cdm abstraction for CDM block")
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c
index e9cdc7934a499..9016b3ade6bc3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c
@@ -186,7 +186,7 @@ static int dpu_hw_cdm_enable(struct dpu_hw_cdm *ctx, struct
dpu_hw_cdm_cfg *cdm)
dpu_hw_cdm_setup_cdwn(ctx, cdm);
if (cdm->output_type == CDM_CDWN_OUTPUT_HDMI) {
- if (fmt->chroma_sample != DPU_CHROMA_H1V2)
+ if (fmt->chroma_sample == DPU_CHROMA_H1V2)
return -EINVAL; /*unsupported format */
opmode = CDM_HDMI_PACK_OP_MODE_EN;
opmode |= (fmt->chroma_sample << 1);
--
2.39.2
[PATCH v3 11/19] drm/msm/dp: change clock related programming for YUV420 over DP
Change all relevant DP controller related programming for YUV420 cases.
Namely, change the pixel clock math to consider YUV420 and modify the
MVID programming to consider YUV420.
Changes in v2:
- Move configuration control programming to a different commit
- Slight code simplification
- Add VSC SDP check when doing mode_pclk_khz division in
dp_bridge_mode_valid
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 5 -
drivers/gpu/drm/msm/dp/dp_catalog.h | 2 +-
drivers/gpu/drm/msm/dp/dp_ctrl.c| 9 ++---
drivers/gpu/drm/msm/dp/dp_display.c | 4
4 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 5142aeb705a44..5d84c089e520a 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -442,7 +442,7 @@ void dp_catalog_ctrl_config_misc(struct dp_catalog
*dp_catalog,
void dp_catalog_ctrl_config_msa(struct dp_catalog *dp_catalog,
u32 rate, u32 stream_rate_khz,
- bool fixed_nvid)
+ bool fixed_nvid, bool is_ycbcr_420)
{
u32 pixel_m, pixel_n;
u32 mvid, nvid, pixel_div = 0, dispcc_input_rate;
@@ -485,6 +485,9 @@ void dp_catalog_ctrl_config_msa(struct dp_catalog
*dp_catalog,
nvid = temp;
}
+ if (is_ycbcr_420)
+ mvid /= 2;
+
if (link_rate_hbr2 == rate)
nvid *= 2;
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.h
b/drivers/gpu/drm/msm/dp/dp_catalog.h
index 38786e855b51a..6cb5e2a243de2 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.h
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.h
@@ -96,7 +96,7 @@ void dp_catalog_ctrl_mainlink_ctrl(struct dp_catalog
*dp_catalog, bool enable);
void dp_catalog_ctrl_psr_mainlink_enable(struct dp_catalog *dp_catalog, bool
enable);
void dp_catalog_ctrl_config_misc(struct dp_catalog *dp_catalog, u32 cc, u32
tb);
void dp_catalog_ctrl_config_msa(struct dp_catalog *dp_catalog, u32 rate,
- u32 stream_rate_khz, bool fixed_nvid);
+ u32 stream_rate_khz, bool fixed_nvid, bool
is_ycbcr_420);
int dp_catalog_ctrl_set_pattern_state_bit(struct dp_catalog *dp_catalog, u32
pattern);
u32 dp_catalog_hw_revision(const struct dp_catalog *dp_catalog);
void dp_catalog_ctrl_reset(struct dp_catalog *dp_catalog);
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index da8f0d9f98718..209cf2a35642f 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -960,7 +960,7 @@ static void dp_ctrl_calc_tu_parameters(struct
dp_ctrl_private *ctrl,
in.hporch = drm_mode->htotal - drm_mode->hdisplay;
in.nlanes = ctrl->link->link_params.num_lanes;
in.bpp = ctrl->panel->dp_mode.bpp;
- in.pixel_enc = 444;
+ in.pixel_enc = ctrl->panel->dp_mode.out_fmt_is_yuv_420 ? 420 : 444;
in.dsc_en = 0;
in.async_en = 0;
in.fec_en = 0;
@@ -1766,6 +1766,8 @@ int dp_ctrl_on_link(struct dp_ctrl *dp_ctrl)
ctrl->link->link_params.rate = rate;
ctrl->link->link_params.num_lanes =
ctrl->panel->link_info.num_lanes;
+ if (ctrl->panel->dp_mode.out_fmt_is_yuv_420)
+ pixel_rate >>= 1;
}
drm_dbg_dp(ctrl->drm_dev, "rate=%d, num_lanes=%d, pixel_rate=%lu\n",
@@ -1881,7 +1883,7 @@ int dp_ctrl_on_stream(struct dp_ctrl *dp_ctrl, bool
force_link_train)
pixel_rate = pixel_rate_orig = ctrl->panel->dp_mode.drm_mode.clock;
- if (dp_ctrl->wide_bus_en)
+ if (dp_ctrl->wide_bus_en || ctrl->panel->dp_mode.out_fmt_is_yuv_420)
pixel_rate >>= 1;
drm_dbg_dp(ctrl->drm_dev, "rate=%d, num_lanes=%d, pixel_rate=%lu\n",
@@ -1920,7 +1922,8 @@ int dp_ctrl_on_stream(struct dp_ctrl *dp_ctrl, bool
force_link_train)
dp_catalog_ctrl_config_msa(ctrl->catalog,
ctrl->link->link_params.rate,
- pixel_rate_orig, dp_ctrl_use_fixed_nvid(ctrl));
+ pixel_rate_orig, dp_ctrl_use_fixed_nvid(ctrl),
+ ctrl->panel->dp_mode.out_fmt_is_yuv_420);
dp_ctrl_setup_tr_unit(ctrl);
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 6323dc08d5eb8..4b04388719363 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -933,6 +933,10 @@ enum drm_mode_status dp_bridge_mode_valid(struct
drm_bridge *bridge,
dp_display = container_of(dp, struct dp_display_private, dp_display);
link_info = _display->panel->link_info;
+ if (drm_mode_is_420_only(>connector->display_info, mode) &&
+ dp_display->panel->vsc_sdp_supported)
+ mode_pclk_khz /= 2;
+
[PATCH v3 09/19] drm/msm/dpu: move widebus logic to its own API
Widebus enablement is decided by the interfaces based on their specific
checks and that already happens with DSI/DP specific helpers. Let's
invoke these helpers from dpu_encoder_is_widebus_enabled() to make it
cleaner overall.
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 29 -
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 4 +++
2 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 3c55d6290b708..7e7796561009a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -225,9 +225,21 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
bool dpu_encoder_is_widebus_enabled(const struct drm_encoder *drm_enc)
{
- const struct dpu_encoder_virt *dpu_enc = to_dpu_encoder_virt(drm_enc);
+ const struct dpu_encoder_virt *dpu_enc;
+ struct msm_drm_private *priv = drm_enc->dev->dev_private;
+ const struct msm_display_info *disp_info;
+ int index;
+
+ dpu_enc = to_dpu_encoder_virt(drm_enc);
+ disp_info = _enc->disp_info;
+ index = disp_info->h_tile_instance[0];
+
+ if (disp_info->intf_type == INTF_DP)
+ return msm_dp_wide_bus_available(priv->dp[index]);
+ else if (disp_info->intf_type == INTF_DSI)
+ return msm_dsi_wide_bus_enabled(priv->dsi[index]);
- return dpu_enc->wide_bus_en;
+ return false;
}
bool dpu_encoder_is_dsc_enabled(const struct drm_encoder *drm_enc)
@@ -1199,26 +1211,17 @@ static void dpu_encoder_virt_atomic_enable(struct
drm_encoder *drm_enc,
struct dpu_encoder_virt *dpu_enc = NULL;
int ret = 0;
struct drm_display_mode *cur_mode = NULL;
- struct msm_drm_private *priv = drm_enc->dev->dev_private;
- struct msm_display_info *disp_info;
- int index;
dpu_enc = to_dpu_encoder_virt(drm_enc);
- disp_info = _enc->disp_info;
- index = disp_info->h_tile_instance[0];
-
dpu_enc->dsc = dpu_encoder_get_dsc_config(drm_enc);
atomic_set(_enc->frame_done_timeout_cnt, 0);
- if (disp_info->intf_type == INTF_DP)
- dpu_enc->wide_bus_en =
msm_dp_wide_bus_available(priv->dp[index]);
- else if (disp_info->intf_type == INTF_DSI)
- dpu_enc->wide_bus_en =
msm_dsi_wide_bus_enabled(priv->dsi[index]);
-
mutex_lock(_enc->enc_lock);
cur_mode = _enc->base.crtc->state->adjusted_mode;
+ dpu_enc->wide_bus_en = dpu_encoder_is_widebus_enabled(drm_enc);
+
trace_dpu_enc_enable(DRMID(drm_enc), cur_mode->hdisplay,
cur_mode->vdisplay);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index fe6b1d312a742..67aef59c1f99c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -156,6 +156,10 @@ int dpu_encoder_get_linecount(struct drm_encoder *drm_enc);
*/
int dpu_encoder_get_vsync_count(struct drm_encoder *drm_enc);
+/**
+ * dpu_encoder_is_widebus_enabled - return bool value if widebus is enabled
+ * @drm_enc:Pointer to previously created drm encoder structure
+ */
bool dpu_encoder_is_widebus_enabled(const struct drm_encoder *drm_enc);
/**
--
2.39.2
[PATCH v3 04/19] drm/msm/dpu: allow dpu_encoder_helper_phys_setup_cdm to work for DP
Generalize dpu_encoder_helper_phys_setup_cdm to be compatible with DP.
Changes in v2:
- Minor formatting changes
- Move the modification of the dimensions for CDM setup to a new
patch
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 4 +--
.../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 27 ++-
2 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index 993f263433314..204d7cc3c1de8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -154,6 +154,7 @@ enum dpu_intr_idx {
* @hw_wb: Hardware interface to the wb registers
* @hw_cdm:Hardware interface to the CDM registers
* @dpu_kms: Pointer to the dpu_kms top level
+ * @cdm_cfg: CDM block config needed to store WB/DP block's CDM
configuration
* @cached_mode: DRM mode cached at mode_set time, acted on in enable
* @vblank_ctl_lock: Vblank ctl mutex lock to protect vblank_refcount
* @enabled: Whether the encoder has enabled and running a mode
@@ -184,6 +185,7 @@ struct dpu_encoder_phys {
struct dpu_hw_wb *hw_wb;
struct dpu_hw_cdm *hw_cdm;
struct dpu_kms *dpu_kms;
+ struct dpu_hw_cdm_cfg cdm_cfg;
struct drm_display_mode cached_mode;
struct mutex vblank_ctl_lock;
enum dpu_enc_split_role split_role;
@@ -213,7 +215,6 @@ static inline int dpu_encoder_phys_inc_pending(struct
dpu_encoder_phys *phys)
* @wbirq_refcount: Reference count of writeback interrupt
* @wb_done_timeout_cnt: number of wb done irq timeout errors
* @wb_cfg: writeback block config to store fb related details
- * @cdm_cfg: cdm block config needed to store writeback block's CDM
configuration
* @wb_conn: backpointer to writeback connector
* @wb_job: backpointer to current writeback job
* @dest: dpu buffer layout for current writeback output buffer
@@ -223,7 +224,6 @@ struct dpu_encoder_phys_wb {
atomic_t wbirq_refcount;
int wb_done_timeout_cnt;
struct dpu_hw_wb_cfg wb_cfg;
- struct dpu_hw_cdm_cfg cdm_cfg;
struct drm_writeback_connector *wb_conn;
struct drm_writeback_job *wb_job;
struct dpu_hw_fmt_layout dest;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
index ec9e053d3947d..072fc6950e496 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
@@ -269,28 +269,21 @@ static void dpu_encoder_phys_wb_setup_ctl(struct
dpu_encoder_phys *phys_enc)
* This API does not handle
DPU_CHROMA_H1V2.
* @phys_enc:Pointer to physical encoder
*/
-static void dpu_encoder_helper_phys_setup_cdm(struct dpu_encoder_phys
*phys_enc)
+static void dpu_encoder_helper_phys_setup_cdm(struct dpu_encoder_phys
*phys_enc,
+ const struct dpu_format *dpu_fmt,
+ u32 output_type)
{
struct dpu_hw_cdm *hw_cdm;
struct dpu_hw_cdm_cfg *cdm_cfg;
struct dpu_hw_pingpong *hw_pp;
- struct dpu_encoder_phys_wb *wb_enc;
- const struct msm_format *format;
- const struct dpu_format *dpu_fmt;
- struct drm_writeback_job *wb_job;
int ret;
if (!phys_enc)
return;
- wb_enc = to_dpu_encoder_phys_wb(phys_enc);
- cdm_cfg = _enc->cdm_cfg;
+ cdm_cfg = _enc->cdm_cfg;
hw_pp = phys_enc->hw_pp;
hw_cdm = phys_enc->hw_cdm;
- wb_job = wb_enc->wb_job;
-
- format = msm_framebuffer_format(wb_enc->wb_job->fb);
- dpu_fmt = dpu_get_dpu_format_ext(format->pixel_format,
wb_job->fb->modifier);
if (!hw_cdm)
return;
@@ -309,7 +302,7 @@ static void dpu_encoder_helper_phys_setup_cdm(struct
dpu_encoder_phys *phys_enc)
cdm_cfg->output_width = phys_enc->cached_mode.hdisplay;
cdm_cfg->output_height = phys_enc->cached_mode.vdisplay;
cdm_cfg->output_fmt = dpu_fmt;
- cdm_cfg->output_type = CDM_CDWN_OUTPUT_WB;
+ cdm_cfg->output_type = output_type;
cdm_cfg->output_bit_depth = DPU_FORMAT_IS_DX(dpu_fmt) ?
CDM_CDWN_OUTPUT_10BIT : CDM_CDWN_OUTPUT_8BIT;
cdm_cfg->csc_cfg = _csc10_rgb2yuv_601l;
@@ -462,6 +455,14 @@ static void dpu_encoder_phys_wb_setup(
struct dpu_hw_wb *hw_wb = phys_enc->hw_wb;
struct drm_display_mode mode = phys_enc->cached_mode;
struct drm_framebuffer *fb = NULL;
+ struct dpu_encoder_phys_wb *wb_enc = to_dpu_encoder_phys_wb(phys_enc);
+ struct drm_writeback_job *wb_job;
+ const struct msm_format *format;
+ const struct dpu_format *dpu_fmt;
+
+
[PATCH v3 05/19] drm/msm/dpu: move dpu_encoder_helper_phys_setup_cdm to dpu_encoder
Move dpu_encoder_helper_phys_setup_cdm to dpu_encoder in preparation for
implementing YUV420 over DP, which requires CDM compatibility.
Changes in v2:
- Slightly change the wording of the commit text to make clear
that YUV over DP requires CDM
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 78 +
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 9 ++
.../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 83 ---
3 files changed, 87 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 467f874979d5c..3c55d6290b708 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2121,6 +2121,84 @@ void dpu_encoder_helper_phys_cleanup(struct
dpu_encoder_phys *phys_enc)
ctl->ops.clear_pending_flush(ctl);
}
+void dpu_encoder_helper_phys_setup_cdm(struct dpu_encoder_phys *phys_enc,
+ const struct dpu_format *dpu_fmt,
+ u32 output_type)
+{
+ struct dpu_hw_cdm *hw_cdm;
+ struct dpu_hw_cdm_cfg *cdm_cfg;
+ struct dpu_hw_pingpong *hw_pp;
+ int ret;
+
+ if (!phys_enc)
+ return;
+
+ cdm_cfg = _enc->cdm_cfg;
+ hw_pp = phys_enc->hw_pp;
+ hw_cdm = phys_enc->hw_cdm;
+
+ if (!hw_cdm)
+ return;
+
+ if (!DPU_FORMAT_IS_YUV(dpu_fmt)) {
+ DPU_DEBUG("[enc:%d] cdm_disable fmt:%x\n",
DRMID(phys_enc->parent),
+ dpu_fmt->base.pixel_format);
+ if (hw_cdm->ops.bind_pingpong_blk)
+ hw_cdm->ops.bind_pingpong_blk(hw_cdm, PINGPONG_NONE);
+
+ return;
+ }
+
+ memset(cdm_cfg, 0, sizeof(struct dpu_hw_cdm_cfg));
+
+ cdm_cfg->output_width = phys_enc->cached_mode.hdisplay;
+ cdm_cfg->output_height = phys_enc->cached_mode.vdisplay;
+ cdm_cfg->output_fmt = dpu_fmt;
+ cdm_cfg->output_type = output_type;
+ cdm_cfg->output_bit_depth = DPU_FORMAT_IS_DX(dpu_fmt) ?
+ CDM_CDWN_OUTPUT_10BIT : CDM_CDWN_OUTPUT_8BIT;
+ cdm_cfg->csc_cfg = _csc10_rgb2yuv_601l;
+
+ /* enable 10 bit logic */
+ switch (cdm_cfg->output_fmt->chroma_sample) {
+ case DPU_CHROMA_RGB:
+ cdm_cfg->h_cdwn_type = CDM_CDWN_DISABLE;
+ cdm_cfg->v_cdwn_type = CDM_CDWN_DISABLE;
+ break;
+ case DPU_CHROMA_H2V1:
+ cdm_cfg->h_cdwn_type = CDM_CDWN_COSITE;
+ cdm_cfg->v_cdwn_type = CDM_CDWN_DISABLE;
+ break;
+ case DPU_CHROMA_420:
+ cdm_cfg->h_cdwn_type = CDM_CDWN_COSITE;
+ cdm_cfg->v_cdwn_type = CDM_CDWN_OFFSITE;
+ break;
+ case DPU_CHROMA_H1V2:
+ default:
+ DPU_ERROR("[enc:%d] unsupported chroma sampling type\n",
+ DRMID(phys_enc->parent));
+ cdm_cfg->h_cdwn_type = CDM_CDWN_DISABLE;
+ cdm_cfg->v_cdwn_type = CDM_CDWN_DISABLE;
+ break;
+ }
+
+ DPU_DEBUG("[enc:%d] cdm_enable:%d,%d,%X,%d,%d,%d,%d]\n",
+ DRMID(phys_enc->parent), cdm_cfg->output_width,
+ cdm_cfg->output_height,
cdm_cfg->output_fmt->base.pixel_format,
+ cdm_cfg->output_type, cdm_cfg->output_bit_depth,
+ cdm_cfg->h_cdwn_type, cdm_cfg->v_cdwn_type);
+
+ if (hw_cdm->ops.enable) {
+ cdm_cfg->pp_id = hw_pp->idx;
+ ret = hw_cdm->ops.enable(hw_cdm, cdm_cfg);
+ if (ret < 0) {
+ DPU_ERROR("[enc:%d] failed to enable CDM; ret:%d\n",
+ DRMID(phys_enc->parent), ret);
+ return;
+ }
+ }
+}
+
#ifdef CONFIG_DEBUG_FS
static int _dpu_encoder_status_show(struct seq_file *s, void *data)
{
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index 204d7cc3c1de8..f43d57d9c74e1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -381,6 +381,15 @@ int dpu_encoder_helper_wait_for_irq(struct
dpu_encoder_phys *phys_enc,
*/
void dpu_encoder_helper_phys_cleanup(struct dpu_encoder_phys *phys_enc);
+/**
+ * dpu_encoder_helper_phys_setup_cdm - setup chroma down sampling block
+ * @phys_enc: Pointer to physical encoder
+ * @output_type: HDMI/WB
+ */
+void dpu_encoder_helper_phys_setup_cdm(struct dpu_encoder_phys *phys_enc,
+ const struct dpu_format *dpu_fmt,
+ u32 output_type);
+
/**
* dpu_encoder_vblank_callback - Notify virtual encoder of vblank IRQ reception
* @drm_enc:Pointer to drm encoder structure
diff --git
[PATCH v3 13/19] drm/msm/dp: add VSC SDP support for YUV420 over DP
Add support to pack and send the VSC SDP packet for DP. This therefore
allows the transmision of format information to the sinks which is
needed for YUV420 support over DP.
Changes in v3:
- Create a new struct, msm_dp_sdp_with_parity, which holds the
packing information for VSC SDP
- Use drm_dp_vsc_sdp_pack() to pack the data into the new
msm_dp_sdp_with_parity struct instead of specifically packing
for YUV420 format
- Modify dp_catalog_panel_send_vsc_sdp() to send the VSC SDP
data using the new msm_dp_sdp_with_parity struct
Changes in v2:
- Rename GENERIC0_SDPSIZE macro to GENERIC0_SDPSIZE_VALID
- Remove dp_sdp from the dp_catalog struct since this data is
being allocated at the point used
- Create a new function in dp_utils to pack the VSC SDP data
into a buffer
- Create a new function that packs the SDP header bytes into a
buffer. This function is made generic so that it can be
utilized by dp_audio
header bytes into a buffer
- Create a new function in dp_utils that takes the packed buffer
and writes to the DP_GENERIC0_* registers
- Split the dp_catalog_panel_config_vsc_sdp() function into two
to disable/enable sending VSC SDP packets
- Check the DP HW version using the original useage of
dp_catalog_hw_revision() and correct the version checking
logic
- Rename dp_panel_setup_vsc_sdp() to
dp_panel_setup_vsc_sdp_yuv_420() to explicitly state that
currently VSC SDP is only being set up to support YUV420 modes
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 113
drivers/gpu/drm/msm/dp/dp_catalog.h | 7 ++
drivers/gpu/drm/msm/dp/dp_ctrl.c| 4 +
drivers/gpu/drm/msm/dp/dp_panel.c | 55 ++
drivers/gpu/drm/msm/dp/dp_reg.h | 3 +
drivers/gpu/drm/msm/dp/dp_utils.c | 48
drivers/gpu/drm/msm/dp/dp_utils.h | 18 +
7 files changed, 248 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 5d84c089e520a..61d5317efe683 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -901,6 +901,119 @@ int dp_catalog_panel_timing_cfg(struct dp_catalog
*dp_catalog)
return 0;
}
+static void dp_catalog_panel_send_vsc_sdp(struct dp_catalog *dp_catalog,
+ struct msm_dp_sdp_with_parity
*msm_dp_sdp)
+{
+ struct dp_catalog_private *catalog;
+ u32 val;
+
+ if (!dp_catalog) {
+ DRM_ERROR("invalid input\n");
+ return;
+ }
+
+ catalog = container_of(dp_catalog, struct dp_catalog_private,
dp_catalog);
+
+ val = ((msm_dp_sdp->vsc_sdp.sdp_header.HB0) << HEADER_BYTE_0_BIT |
+ (msm_dp_sdp->pb.PB0 << PARITY_BYTE_0_BIT) |
+ (msm_dp_sdp->vsc_sdp.sdp_header.HB1) << HEADER_BYTE_1_BIT |
+ (msm_dp_sdp->pb.PB1 << PARITY_BYTE_1_BIT));
+ dp_write_link(catalog, MMSS_DP_GENERIC0_0, val);
+
+ val = ((msm_dp_sdp->vsc_sdp.sdp_header.HB2) << HEADER_BYTE_2_BIT |
+ (msm_dp_sdp->pb.PB2 << PARITY_BYTE_2_BIT) |
+ (msm_dp_sdp->vsc_sdp.sdp_header.HB3) << HEADER_BYTE_3_BIT |
+ (msm_dp_sdp->pb.PB3 << PARITY_BYTE_3_BIT));
+ dp_write_link(catalog, MMSS_DP_GENERIC0_1, val);
+
+ val = ((msm_dp_sdp->vsc_sdp.db[16]) | (msm_dp_sdp->vsc_sdp.db[17] << 8)
|
+ (msm_dp_sdp->vsc_sdp.db[18] << 16));
+ dp_write_link(catalog, MMSS_DP_GENERIC0_6, val);
+}
+
+static void dp_catalog_panel_update_sdp(struct dp_catalog *dp_catalog)
+{
+ struct dp_catalog_private *catalog;
+ u32 hw_revision;
+
+ catalog = container_of(dp_catalog, struct dp_catalog_private,
dp_catalog);
+
+ hw_revision = dp_catalog_hw_revision(dp_catalog);
+ if (hw_revision < DP_HW_VERSION_1_2 && hw_revision >=
DP_HW_VERSION_1_0) {
+ dp_write_link(catalog, MMSS_DP_SDP_CFG3, 0x01);
+ dp_write_link(catalog, MMSS_DP_SDP_CFG3, 0x00);
+ }
+}
+
+void dp_catalog_panel_enable_vsc_sdp(struct dp_catalog *dp_catalog,
+struct msm_dp_sdp_with_parity *msm_dp_sdp)
+{
+ struct dp_catalog_private *catalog;
+ u32 cfg, cfg2, misc;
+
+ if (!dp_catalog) {
+ DRM_ERROR("invalid input\n");
+ return;
+ }
+
+ catalog = container_of(dp_catalog, struct dp_catalog_private,
dp_catalog);
+
+ cfg = dp_read_link(catalog, MMSS_DP_SDP_CFG);
+ cfg2 = dp_read_link(catalog, MMSS_DP_SDP_CFG2);
+ misc = dp_read_link(catalog, REG_DP_MISC1_MISC0);
+
+ cfg |= GEN0_SDP_EN;
+ dp_write_link(catalog, MMSS_DP_SDP_CFG, cfg);
+
+ cfg2 |= GENERIC0_SDPSIZE_VALID;
+ dp_write_link(catalog, MMSS_DP_SDP_CFG2,
[PATCH v3 00/19] Add support for CDM over DP
The Chroma Down Sampling (CDM) block is a hardware component in the DPU pipeline that includes a CSC block capable of converting RGB input from the DPU to YUV data. This block can be used with either HDMI, DP, or writeback interfaces. This series adds support for the CDM block to be used with DP in YUV420 mode format. This series allows selection of the YUV420 format for monitors which support certain resolutions only in YUV420 thus unblocking the validation of many other resolutions which were previously filtered out if the connector did not support YUV420. This was validated using a DP connected monitor requiring the use of YUV420 format. This series is dependent on [1], [2], and [3]: [1] https://patchwork.freedesktop.org/series/118831/ [2] https://patchwork.freedesktop.org/series/129395/ [3] https://patchwork.freedesktop.org/series/129864/ Changes in v3: - Change ordering of the header byte macros in dp_utils.h - Create a new struct, msm_dp_sdp_with_parity - Utilize drm_dp_vsc_sdp_pack() from a new added dependency of series [3] to pack the VSC SDP data into the new msm_dp_sdp_with_parity struct instead of packing only for YUV420 - Modify dp_catalog_panel_send_vsc_sdp() so that it sends the VSC SDP data using the new msm_dp_sdp_with_parity struct - Clear up that the DP_MAINLINK_FLUSH_MODE_SDE_PERIPH_UPDATE macro is setting multiple bits and not just one - Move the connector's ycbcr_420_allowed parameter so it is no longer dependent on if the dp_display is not eDP Changes in v2: - Minor formatting changes throughout - Move 'fixes' patch to the top - Move VSC SDP support check API from dp_panel.c to drm_dp_helper.c - Create a separate patch for modifying the dimensions for CDM setup to be non-WB specific - Remove a patch that modified the INTF_CONFIG2 register in favor of having this series be dependent on [2] - Separate configuration ctrl programming from clock related programming into two patches - Add a VSC SDP check in dp_bridge_mode_valid() - Move parity calculation functions to new files dp_utils.c and dp_utils.h - Remove dp_catalog_hw_revision() changes and utilize the original version of the function when checking the DP hardware version - Create separate packing and programming functions for the VSC SDP - Make the packing header bytes function generic so it can be used with dp_audio.c - Create two separate enable/disable VSC SDP functions instead of having one with the ability to do both - Move timing engine programming to a separate patch from original encoder programming patch - Move update_pending_flush_periph() code to be in the same patch as the encoder programming - Create new API's to check if the dpu encoder needs a peripheral flush - Allow YUV420 modes for the DP connector when there's a CDM block available instead of checking if VSC SDP is supported Kuogee Hsieh (1): drm/msm/dpu: add support of new peripheral flush mechanism Paloma Arellano (18): drm/msm/dpu: allow certain formats for CDM for DP drm/msm/dpu: add division of drm_display_mode's hskew parameter drm/msm/dpu: pass mode dimensions instead of fb size in CDM setup drm/msm/dpu: allow dpu_encoder_helper_phys_setup_cdm to work for DP drm/msm/dpu: move dpu_encoder_helper_phys_setup_cdm to dpu_encoder drm/msm/dp: rename wide_bus_en to wide_bus_supported drm/msm/dp: store mode YUV420 information to be used by rest of DP drm/msm/dp: check if VSC SDP is supported in DP programming drm/msm/dpu: move widebus logic to its own API drm/msm/dp: program config ctrl for YUV420 over DP drm/msm/dp: change clock related programming for YUV420 over DP drm/msm/dp: move parity calculation to dp_utils drm/msm/dp: add VSC SDP support for YUV420 over DP drm/msm/dp: enable SDP and SDE periph flush update drm/msm/dpu: modify encoder programming for CDM over DP drm/msm/dpu: modify timing engine programming for YUV420 over DP drm/msm/dpu: reserve CDM blocks for DP if mode is YUV420 drm/msm/dp: allow YUV420 mode for DP connector when CDM available drivers/gpu/drm/msm/Makefile | 3 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 164 +++--- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 4 + .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 26 ++- .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 33 +++- .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 100 +-- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c| 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c| 17 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h| 10 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 +- drivers/gpu/drm/msm/dp/dp_audio.c | 101
[PATCH v3 02/19] drm/msm/dpu: add division of drm_display_mode's hskew parameter
Setting up the timing engine when the physical encoder has a split role
neglects dividing the drm_display_mode's hskew parameter. Let's fix this
since this must also be done in preparation for implementing YUV420 over
DP.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index f562beb6f7971..f02411b062c4c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -260,12 +260,14 @@ static void dpu_encoder_phys_vid_setup_timing_engine(
mode.htotal >>= 1;
mode.hsync_start >>= 1;
mode.hsync_end >>= 1;
+ mode.hskew >>= 1;
DPU_DEBUG_VIDENC(phys_enc,
- "split_role %d, halve horizontal %d %d %d %d\n",
+ "split_role %d, halve horizontal %d %d %d %d %d\n",
phys_enc->split_role,
mode.hdisplay, mode.htotal,
- mode.hsync_start, mode.hsync_end);
+ mode.hsync_start, mode.hsync_end,
+ mode.hskew);
}
drm_mode_to_intf_timing_params(phys_enc, , _params);
--
2.39.2
[PATCH v3 12/19] drm/msm/dp: move parity calculation to dp_utils
Parity calculation is necessary for VSC SDP implementation. Therefore
create new files dp_utils.c and dp_utils.h and move the parity
calculating functions here. This ensures that they are usable by SDP
programming in both dp_catalog.c and dp_audio.c
Changes in v3:
- Change ordering of the header byte macros
Changes in v2:
- Create new files dp_utils.c and dp_utils.h
- Move the parity calculation to these new files instead of
having them in dp_catalog.c and dp_catalog.h
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Makefile | 3 +-
drivers/gpu/drm/msm/dp/dp_audio.c | 101 +-
drivers/gpu/drm/msm/dp/dp_utils.c | 73 +
drivers/gpu/drm/msm/dp/dp_utils.h | 22 +++
4 files changed, 112 insertions(+), 87 deletions(-)
create mode 100644 drivers/gpu/drm/msm/dp/dp_utils.c
create mode 100644 drivers/gpu/drm/msm/dp/dp_utils.h
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index b1173128b5b97..998b155e4a979 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -129,7 +129,8 @@ msm-$(CONFIG_DRM_MSM_DP)+= dp/dp_aux.o \
dp/dp_panel.o \
dp/dp_parser.o \
dp/dp_power.o \
- dp/dp_audio.o
+ dp/dp_audio.o \
+ dp/dp_utils.o
msm-$(CONFIG_DRM_FBDEV_EMULATION) += msm_fbdev.o
diff --git a/drivers/gpu/drm/msm/dp/dp_audio.c
b/drivers/gpu/drm/msm/dp/dp_audio.c
index 4a2e479723a85..7634e4b742084 100644
--- a/drivers/gpu/drm/msm/dp/dp_audio.c
+++ b/drivers/gpu/drm/msm/dp/dp_audio.c
@@ -15,13 +15,7 @@
#include "dp_audio.h"
#include "dp_panel.h"
#include "dp_display.h"
-
-#define HEADER_BYTE_2_BIT 0
-#define PARITY_BYTE_2_BIT 8
-#define HEADER_BYTE_1_BIT 16
-#define PARITY_BYTE_1_BIT 24
-#define HEADER_BYTE_3_BIT 16
-#define PARITY_BYTE_3_BIT 24
+#include "dp_utils.h"
struct dp_audio_private {
struct platform_device *audio_pdev;
@@ -36,71 +30,6 @@ struct dp_audio_private {
struct dp_audio dp_audio;
};
-static u8 dp_audio_get_g0_value(u8 data)
-{
- u8 c[4];
- u8 g[4];
- u8 ret_data = 0;
- u8 i;
-
- for (i = 0; i < 4; i++)
- c[i] = (data >> i) & 0x01;
-
- g[0] = c[3];
- g[1] = c[0] ^ c[3];
- g[2] = c[1];
- g[3] = c[2];
-
- for (i = 0; i < 4; i++)
- ret_data = ((g[i] & 0x01) << i) | ret_data;
-
- return ret_data;
-}
-
-static u8 dp_audio_get_g1_value(u8 data)
-{
- u8 c[4];
- u8 g[4];
- u8 ret_data = 0;
- u8 i;
-
- for (i = 0; i < 4; i++)
- c[i] = (data >> i) & 0x01;
-
- g[0] = c[0] ^ c[3];
- g[1] = c[0] ^ c[1] ^ c[3];
- g[2] = c[1] ^ c[2];
- g[3] = c[2] ^ c[3];
-
- for (i = 0; i < 4; i++)
- ret_data = ((g[i] & 0x01) << i) | ret_data;
-
- return ret_data;
-}
-
-static u8 dp_audio_calculate_parity(u32 data)
-{
- u8 x0 = 0;
- u8 x1 = 0;
- u8 ci = 0;
- u8 iData = 0;
- u8 i = 0;
- u8 parity_byte;
- u8 num_byte = (data & 0xFF00) > 0 ? 8 : 2;
-
- for (i = 0; i < num_byte; i++) {
- iData = (data >> i*4) & 0xF;
-
- ci = iData ^ x1;
- x1 = x0 ^ dp_audio_get_g1_value(ci);
- x0 = dp_audio_get_g0_value(ci);
- }
-
- parity_byte = x1 | (x0 << 4);
-
- return parity_byte;
-}
-
static u32 dp_audio_get_header(struct dp_catalog *catalog,
enum dp_catalog_audio_sdp_type sdp,
enum dp_catalog_audio_header_type header)
@@ -134,7 +63,7 @@ static void dp_audio_stream_sdp(struct dp_audio_private
*audio)
DP_AUDIO_SDP_STREAM, DP_AUDIO_SDP_HEADER_1);
new_value = 0x02;
- parity_byte = dp_audio_calculate_parity(new_value);
+ parity_byte = dp_utils_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_1_BIT)
| (parity_byte << PARITY_BYTE_1_BIT));
drm_dbg_dp(audio->drm_dev,
@@ -147,7 +76,7 @@ static void dp_audio_stream_sdp(struct dp_audio_private
*audio)
value = dp_audio_get_header(catalog,
DP_AUDIO_SDP_STREAM, DP_AUDIO_SDP_HEADER_2);
new_value = value;
- parity_byte = dp_audio_calculate_parity(new_value);
+ parity_byte = dp_utils_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_2_BIT)
| (parity_byte << PARITY_BYTE_2_BIT));
drm_dbg_dp(audio->drm_dev,
@@ -162,7 +91,7 @@ static void dp_audio_stream_sdp(struct dp_audio_private
*audio)
DP_AUDIO_SDP_STREAM, DP_AUDIO_SDP_HEADER_3);
new_value = audio->channels - 1;
- parity_byte = dp_audio_calculate_parity(new_value);
+ parity_byte = dp_utils_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_3_BIT)
|
[PATCH v3 06/19] drm/msm/dp: rename wide_bus_en to wide_bus_supported
Rename wide_bus_en to wide_bus_supported in dp_display_private to
correctly establish that the parameter is referencing if wide bus is
supported instead of enabled.
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 42 ++---
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index d37d599aec273..9df2a8b21021e 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -113,7 +113,7 @@ struct dp_display_private {
struct dp_event event_list[DP_EVENT_Q_MAX];
spinlock_t event_lock;
- bool wide_bus_en;
+ bool wide_bus_supported;
struct dp_audio *audio;
};
@@ -122,7 +122,7 @@ struct msm_dp_desc {
phys_addr_t io_start;
unsigned int id;
unsigned int connector_type;
- bool wide_bus_en;
+ bool wide_bus_supported;
};
static const struct msm_dp_desc sc7180_dp_descs[] = {
@@ -131,8 +131,8 @@ static const struct msm_dp_desc sc7180_dp_descs[] = {
};
static const struct msm_dp_desc sc7280_dp_descs[] = {
- { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
- { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_1, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
+ { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
+ { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_1, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_supported = true },
{}
};
@@ -144,22 +144,22 @@ static const struct msm_dp_desc sc8180x_dp_descs[] = {
};
static const struct msm_dp_desc sc8280xp_dp_descs[] = {
- { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
- { .io_start = 0x0ae98000, .id = MSM_DP_CONTROLLER_1, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
- { .io_start = 0x0ae9a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
- { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
- { .io_start = 0x2209, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
- { .io_start = 0x22098000, .id = MSM_DP_CONTROLLER_1, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
- { .io_start = 0x2209a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
- { .io_start = 0x220a, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
+ { .io_start = 0x0ae98000, .id = MSM_DP_CONTROLLER_1, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
+ { .io_start = 0x0ae9a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
+ { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
+ { .io_start = 0x2209, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
+ { .io_start = 0x22098000, .id = MSM_DP_CONTROLLER_1, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
+ { .io_start = 0x2209a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
+ { .io_start = 0x220a, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
{}
};
static const struct msm_dp_desc sc8280xp_edp_descs[] = {
- { .io_start = 0x0ae9a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
- { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
- { .io_start = 0x2209a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
- { .io_start = 0x220a, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
+ { .io_start = 0x0ae9a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_supported = true },
+ { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_supported = true },
+ { .io_start = 0x2209a000, .id =
[PATCH v3 03/19] drm/msm/dpu: pass mode dimensions instead of fb size in CDM setup
Modify the output width and height parameters of hw_cdm to utilize the physical encoder's data instead of obtaining the information from the framebuffer. CDM is to be set up to utilize the actual output data since at CDM setup, there is no difference between the two sources. Changes in v2: - Move the modification of the dimensions for CDM setup to this new patch Signed-off-by: Paloma Arellano Reviewed-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c index 4cd2d9e3131a4..ec9e053d3947d 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c @@ -306,8 +306,8 @@ static void dpu_encoder_helper_phys_setup_cdm(struct dpu_encoder_phys *phys_enc) memset(cdm_cfg, 0, sizeof(struct dpu_hw_cdm_cfg)); - cdm_cfg->output_width = wb_job->fb->width; - cdm_cfg->output_height = wb_job->fb->height; + cdm_cfg->output_width = phys_enc->cached_mode.hdisplay; + cdm_cfg->output_height = phys_enc->cached_mode.vdisplay; cdm_cfg->output_fmt = dpu_fmt; cdm_cfg->output_type = CDM_CDWN_OUTPUT_WB; cdm_cfg->output_bit_depth = DPU_FORMAT_IS_DX(dpu_fmt) ? -- 2.39.2
[PATCH v3 07/19] drm/msm/dp: store mode YUV420 information to be used by rest of DP
Wide bus is not supported when the mode is YUV420 in DP. In preparation
for changing the DPU programming to reflect this, the value and
assignment location of wide_bus_en for the DP submodules must be
changed. Move it from boot time in dp_init_sub_modules() to run time in
dp_display_mode_set.
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 17 +
drivers/gpu/drm/msm/dp/dp_panel.h | 1 +
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 9df2a8b21021e..ddac55f45a722 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -784,10 +784,6 @@ static int dp_init_sub_modules(struct dp_display_private
*dp)
goto error_ctrl;
}
- /* populate wide_bus_supported to different layers */
- dp->ctrl->wide_bus_en = dp->wide_bus_supported;
- dp->catalog->wide_bus_en = dp->wide_bus_supported;
-
return rc;
error_ctrl:
@@ -808,6 +804,7 @@ static int dp_display_set_mode(struct msm_dp *dp_display,
drm_mode_copy(>panel->dp_mode.drm_mode, >drm_mode);
dp->panel->dp_mode.bpp = mode->bpp;
dp->panel->dp_mode.capabilities = mode->capabilities;
+ dp->panel->dp_mode.out_fmt_is_yuv_420 = mode->out_fmt_is_yuv_420;
dp_panel_init_panel_info(dp->panel);
return 0;
}
@@ -1402,6 +1399,9 @@ bool msm_dp_wide_bus_available(const struct msm_dp
*dp_display)
dp = container_of(dp_display, struct dp_display_private, dp_display);
+ if (dp->dp_mode.out_fmt_is_yuv_420)
+ return false;
+
return dp->wide_bus_supported;
}
@@ -1615,6 +1615,15 @@ void dp_bridge_mode_set(struct drm_bridge *drm_bridge,
dp_display->dp_mode.h_active_low =
!!(dp_display->dp_mode.drm_mode.flags & DRM_MODE_FLAG_NHSYNC);
+
+ dp_display->dp_mode.out_fmt_is_yuv_420 =
+ drm_mode_is_420_only(>connector->display_info,
adjusted_mode);
+
+ /* populate wide_bus_support to different layers */
+ dp_display->ctrl->wide_bus_en =
+ dp_display->dp_mode.out_fmt_is_yuv_420 ? false :
dp_display->wide_bus_supported;
+ dp_display->catalog->wide_bus_en =
+ dp_display->dp_mode.out_fmt_is_yuv_420 ? false :
dp_display->wide_bus_supported;
}
void dp_bridge_hpd_enable(struct drm_bridge *bridge)
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.h
b/drivers/gpu/drm/msm/dp/dp_panel.h
index a0dfc579c5f9f..6ec68be9f2366 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.h
+++ b/drivers/gpu/drm/msm/dp/dp_panel.h
@@ -19,6 +19,7 @@ struct dp_display_mode {
u32 bpp;
u32 h_active_low;
u32 v_active_low;
+ bool out_fmt_is_yuv_420;
};
struct dp_panel_in {
--
2.39.2
Re: [PATCH] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper
On Wed, Feb 14, 2024 at 09:17:34AM -0800, Abhinav Kumar wrote:
>
>
> On 2/14/2024 12:15 AM, Dmitry Baryshkov wrote:
> > On Wed, 14 Feb 2024 at 01:45, Abhinav Kumar
> > wrote:
> >>
> >> intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well.
> >> Lets move this to drm_dp_helper to achieve this.
> >>
> >> Signed-off-by: Abhinav Kumar
> >
> > My preference would be to have packing functions in
> > drivers/video/hdmi.c, as we already have
> > hdmi_audio_infoframe_pack_for_dp() there.
> >
>
> My preference is drm_dp_helper because it already has some VSC SDP stuff
> and after discussion with Ville on IRC, I decided to post it this way.
>
> hdmi_audio_infoframe_pack_for_dp() is an exception from my PoV as the
> hdmi audio infoframe fields were re-used and packed into a DP SDP
> thereby re-using the existing struct hdmi_audio_infoframe .
>
> This is not like that. Here we pack from struct drm_dp_vsc_sdp to struct
> dp_sdp both of which had prior usages already in this file.
>
> So it all adds up and makes sense to me to be in this file.
>
> I will let the other DRM core maintainers comment on this.
>
> Ville, Jani?
Yeah, I'm not sure bloating the (poorly named) hdmi.c with all
SDP stuff is a great idea. Since other related stuff already
lives in the drm_dp_helper.c that seems reasonable to me at this
time. And if we get a decent amount of this then probably all
DP SDP stuff should be extracted into its own file.
There are of course a few overlaps here andthere (the audio SDP
I guess, and the CTA infoframe SDP). But I'm not sure that actually
needs any SDP specific stuff in hdmi.c, or could we just let hdmi.c
deal with the actual CTA-861 stuff and then have the DP SDP code
wrap that up in its own thing externally? Dunno, haven't really
looked at the details.
>
> >> ---
> >> drivers/gpu/drm/display/drm_dp_helper.c | 78 +
> >> drivers/gpu/drm/i915/display/intel_dp.c | 73 +--
> >> include/drm/display/drm_dp_helper.h | 3 +
> >> 3 files changed, 84 insertions(+), 70 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> >> b/drivers/gpu/drm/display/drm_dp_helper.c
> >> index b1ca3a1100da..066cfbbf7a91 100644
> >> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> >> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> >> @@ -2916,6 +2916,84 @@ void drm_dp_vsc_sdp_log(const char *level, struct
> >> device *dev,
> >> }
> >> EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
> >>
> >> +/**
> >> + * drm_dp_vsc_sdp_pack() - pack a given vsc sdp into generic dp_sdp
> >> + * @vsc: vsc sdp initialized according to its purpose as defined in
> >> + * table 2-118 - table 2-120 in DP 1.4a specification
> >> + * @sdp: valid handle to the generic dp_sdp which will be packed
> >> + * @size: valid size of the passed sdp handle
> >> + *
> >> + * Returns length of sdp on success and error code on failure
> >> + */
> >> +ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
> >> + struct dp_sdp *sdp, size_t size)
> >
> > I know that you are just moving the function. Maybe there can be
> > patch#2, which drops the size argument? The struct dp_sdp already has
> > a defined size. The i915 driver just passes sizeof(sdp), which is more
> > or less useless.
> >
>
> Yes this is a valid point, I also noticed this. I can post it on top of
> this once we get an agreement and ack on this patch first.
>
> >> +{
> >> + size_t length = sizeof(struct dp_sdp);
> >> +
> >> + if (size < length)
> >> + return -ENOSPC;
> >> +
> >> + memset(sdp, 0, size);
> >> +
> >> + /*
> >> +* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
> >> +* VSC SDP Header Bytes
> >> +*/
> >> + sdp->sdp_header.HB0 = 0; /* Secondary-Data Packet ID = 0 */
> >> + sdp->sdp_header.HB1 = vsc->sdp_type; /* Secondary-data Packet Type
> >> */
> >> + sdp->sdp_header.HB2 = vsc->revision; /* Revision Number */
> >> + sdp->sdp_header.HB3 = vsc->length; /* Number of Valid Data Bytes */
> >> +
> >> + if (vsc->revision == 0x6) {
> >> + sdp->db[0] = 1;
> >> + sdp->db[3] = 1;
> >> + }
> >> +
> >> + /*
> >> +* Revision 0x5 and revision 0x7 supports Pixel
> >> Encoding/Colorimetry
> >> +* Format as per DP 1.4a spec and DP 2.0 respectively.
> >> +*/
> >> + if (!(vsc->revision == 0x5 || vsc->revision == 0x7))
> >> + goto out;
> >> +
> >> + /* VSC SDP Payload for DB16 through DB18 */
> >> + /* Pixel Encoding and Colorimetry Formats */
> >> + sdp->db[16] = (vsc->pixelformat & 0xf) << 4; /* DB16[7:4] */
> >> + sdp->db[16] |= vsc->colorimetry & 0xf; /* DB16[3:0] */
> >> +
> >> + switch (vsc->bpc) {
> >> + case 6:
> >> + /* 6bpc: 0x0 */
> >> + break;
> >> + case 8:
> >> + sdp->db[17] = 0x1; /*
Re: [PATCH v2] drm/msm/dpu: make "vblank timeout" more useful
On 2/8/2024 6:50 AM, Dmitry Baryshkov wrote:
We have several reports of vblank timeout messages. However after some
debugging it was found that there might be different causes to that.
To allow us to identify the DPU block that gets stuck, include the
actual CTL_FLUSH value into the timeout message and trigger the devcore
snapshot capture.
Signed-off-by: Dmitry Baryshkov
---
Changes in v2:
- Added a call to msm_disp_snapshot_state() to trigger devcore dump
(Abhinav)
- Link to v1:
https://lore.kernel.org/r/20240106-fd-dpu-debug-timeout-v1-1-6d9762884...@linaro.org
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index d0f56c5c4cce..a8d6165b3c0a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -489,7 +489,8 @@ static int dpu_encoder_phys_vid_wait_for_commit_done(
(hw_ctl->ops.get_flush_register(hw_ctl) == 0),
msecs_to_jiffies(50));
if (ret <= 0) {
- DPU_ERROR("vblank timeout\n");
+ DPU_ERROR("vblank timeout: %x\n",
hw_ctl->ops.get_flush_register(hw_ctl));
+ msm_disp_snapshot_state(phys_enc->parent->dev);
There is no rate limiting in this piece of code unfortunately. So this
will flood the number of snapshots.
Short-term solution is you can go with a vblank_timeout_cnt and reset it
in the enable() like other similar error counters.
long-term solution is we need to centralize these error locations to one
single dpu_encoder_error_handler() with a single counter and the error
handler will print out the error code along with the snapshot instead of
the snapshot being called from all over the place.
return -ETIMEDOUT;
}
---
base-commit: 39676dfe52331dba909c617f213fdb21015c8d10
change-id: 20240106-fd-dpu-debug-timeout-e917f0bc8063
Best regards,
Re: [PATCH v4 09/14] drm/panthor: Add the heap logical block
On Mon, 12 Feb 2024 11:40:55 + Steven Price wrote: > On 22/01/2024 16:30, Boris Brezillon wrote: > > Tiler heap growing requires some kernel driver involvement: when the > > tiler runs out of heap memory, it will raise an exception which is > > either directly handled by the firmware if some free heap chunks are > > available in the heap context, or passed back to the kernel otherwise. > > The heap helpers will be used by the scheduler logic to allocate more > > heap chunks to a heap context, when such a situation happens. > > > > Heap context creation is explicitly requested by userspace (using > > the TILER_HEAP_CREATE ioctl), and the returned context is attached to a > > queue through some command stream instruction. > > > > All the kernel does is keep the list of heap chunks allocated to a > > context, so they can be freed when TILER_HEAP_DESTROY is called, or > > extended when the FW requests a new chunk. > > > > v4: > > - Rework locking to allow concurrent calls to panthor_heap_grow() > > - Add a helper to return a heap chunk if we couldn't pass it to the > > FW because the group was scheduled out > > > > v3: > > - Add a FIXME for the heap OOM deadlock > > - Use the panthor_kernel_bo abstraction for the heap context and heap > > chunks > > - Drop the panthor_heap_gpu_ctx struct as it is opaque to the driver > > - Ensure that the heap context is aligned to the GPU cache line size > > - Minor code tidy ups > > > > Co-developed-by: Steven Price > > Signed-off-by: Steven Price > > Signed-off-by: Boris Brezillon > > It looks fine, but there's a confusing FIXME comment: > > > + /* FIXME: panthor_alloc_heap_chunk() triggers a kernel BO creation, > > which > > +* relies on blocking allocations (both for the BO itself, and backing > > +* memory), which might cause a deadlock because we're called from a > > context > > +* where we hold the panthor scheduler lock, thus preventing job > > cleanups > > +* that could free up some memory. The jobs themselves will timeout, but > > +* we'll still be blocked there. The only solution here is to implement > > +* something similar to shmem_sg_alloc_table() in i915, so we can do > > +* non-blocking allocations, and just kill the job when we run > > out-of-memory > > +* for the tiler context. > > +*/ > > Whereas at the call site (group_process_tiler_oom()) there's the comment: > > > /* We do the allocation without holding the scheduler lock to > > avoid > > * blocking the scheduling. > > */ > > AFAICT that FIXME comment can just be deleted now. Assuming you agree > then with that change: The FIXME is no longer accurate indeed, but I'd like to keep a FIXME here to reflect the fact the solution we have is not the one we want, as it prevents the GPU from immediately falling back to the user provided OOM exception handler, or killing the job if there's no way it can reclaim tiler memory. How about: FIXME: panthor_alloc_heap_chunk() triggers a kernel BO creation, which goes through the blocking allocation path. Ultimately, we want a non-blocking allocation, so we can immediately report to the FW when the system is running out of memory. In that case, the FW can call a user-provided exception handler, which might try to free some tiler memory by issuing an intermediate fragment job. If the exception handler can't do anything, it will flag the queue as faulty so the job that triggered this tiler chunk allocation and all further jobs in this queue fail immediately instead of having to wait for the job timeout. > > Reviewed-by: Steven Price
Re: [PATCH] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper
On 2/14/2024 12:15 AM, Dmitry Baryshkov wrote:
On Wed, 14 Feb 2024 at 01:45, Abhinav Kumar wrote:
intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well.
Lets move this to drm_dp_helper to achieve this.
Signed-off-by: Abhinav Kumar
My preference would be to have packing functions in
drivers/video/hdmi.c, as we already have
hdmi_audio_infoframe_pack_for_dp() there.
My preference is drm_dp_helper because it already has some VSC SDP stuff
and after discussion with Ville on IRC, I decided to post it this way.
hdmi_audio_infoframe_pack_for_dp() is an exception from my PoV as the
hdmi audio infoframe fields were re-used and packed into a DP SDP
thereby re-using the existing struct hdmi_audio_infoframe .
This is not like that. Here we pack from struct drm_dp_vsc_sdp to struct
dp_sdp both of which had prior usages already in this file.
So it all adds up and makes sense to me to be in this file.
I will let the other DRM core maintainers comment on this.
Ville, Jani?
---
drivers/gpu/drm/display/drm_dp_helper.c | 78 +
drivers/gpu/drm/i915/display/intel_dp.c | 73 +--
include/drm/display/drm_dp_helper.h | 3 +
3 files changed, 84 insertions(+), 70 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index b1ca3a1100da..066cfbbf7a91 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2916,6 +2916,84 @@ void drm_dp_vsc_sdp_log(const char *level, struct device
*dev,
}
EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
+/**
+ * drm_dp_vsc_sdp_pack() - pack a given vsc sdp into generic dp_sdp
+ * @vsc: vsc sdp initialized according to its purpose as defined in
+ * table 2-118 - table 2-120 in DP 1.4a specification
+ * @sdp: valid handle to the generic dp_sdp which will be packed
+ * @size: valid size of the passed sdp handle
+ *
+ * Returns length of sdp on success and error code on failure
+ */
+ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
+ struct dp_sdp *sdp, size_t size)
I know that you are just moving the function. Maybe there can be
patch#2, which drops the size argument? The struct dp_sdp already has
a defined size. The i915 driver just passes sizeof(sdp), which is more
or less useless.
Yes this is a valid point, I also noticed this. I can post it on top of
this once we get an agreement and ack on this patch first.
+{
+ size_t length = sizeof(struct dp_sdp);
+
+ if (size < length)
+ return -ENOSPC;
+
+ memset(sdp, 0, size);
+
+ /*
+* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
+* VSC SDP Header Bytes
+*/
+ sdp->sdp_header.HB0 = 0; /* Secondary-Data Packet ID = 0 */
+ sdp->sdp_header.HB1 = vsc->sdp_type; /* Secondary-data Packet Type */
+ sdp->sdp_header.HB2 = vsc->revision; /* Revision Number */
+ sdp->sdp_header.HB3 = vsc->length; /* Number of Valid Data Bytes */
+
+ if (vsc->revision == 0x6) {
+ sdp->db[0] = 1;
+ sdp->db[3] = 1;
+ }
+
+ /*
+* Revision 0x5 and revision 0x7 supports Pixel Encoding/Colorimetry
+* Format as per DP 1.4a spec and DP 2.0 respectively.
+*/
+ if (!(vsc->revision == 0x5 || vsc->revision == 0x7))
+ goto out;
+
+ /* VSC SDP Payload for DB16 through DB18 */
+ /* Pixel Encoding and Colorimetry Formats */
+ sdp->db[16] = (vsc->pixelformat & 0xf) << 4; /* DB16[7:4] */
+ sdp->db[16] |= vsc->colorimetry & 0xf; /* DB16[3:0] */
+
+ switch (vsc->bpc) {
+ case 6:
+ /* 6bpc: 0x0 */
+ break;
+ case 8:
+ sdp->db[17] = 0x1; /* DB17[3:0] */
+ break;
+ case 10:
+ sdp->db[17] = 0x2;
+ break;
+ case 12:
+ sdp->db[17] = 0x3;
+ break;
+ case 16:
+ sdp->db[17] = 0x4;
+ break;
+ default:
+ WARN(1, "Missing case %d\n", vsc->bpc);
+ return -EINVAL;
+ }
+
+ /* Dynamic Range and Component Bit Depth */
+ if (vsc->dynamic_range == DP_DYNAMIC_RANGE_CTA)
+ sdp->db[17] |= 0x80; /* DB17[7] */
+
+ /* Content Type */
+ sdp->db[18] = vsc->content_type & 0x7;
+
+out:
+ return length;
+}
+EXPORT_SYMBOL(drm_dp_vsc_sdp_pack);
+
/**
* drm_dp_get_pcon_max_frl_bw() - maximum frl supported by PCON
* @dpcd: DisplayPort configuration data
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index f5ef95da5534..e94db51aeeb7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4110,73 +4110,6 @@ intel_dp_needs_vsc_sdp(const struct intel_crtc_state
*crtc_state,
return false;
}
-static ssize_t
Re: [PATCH v2 1/6] tracing, dma-buf: add a trace_dma_fence_sync_to event
Le 14/02/2024 à 16:10, Steven Rostedt a écrit : On Wed, 14 Feb 2024 13:00:16 +0100 Christian König wrote: +DEFINE_EVENT(dma_fence_from, dma_fence_sync_to, For a single event you should probably use TRACE_EVENT() instead of declaring a class. A class is only used if you have multiple events with the same parameters. FYI, TRACE_EVENT() is actually defined as: #define TRACE_EVENT(name, proto, args, tstruct, assign, print) \ DECLARE_EVENT_CLASS(name, \ PARAMS(proto),\ PARAMS(args), \ PARAMS(tstruct), \ PARAMS(assign), \ PARAMS(print)); \ DEFINE_EVENT(name, name, PARAMS(proto), PARAMS(args)); So basically, you could really just declare one TRACE_EVENT() and add DEFINE_EVENT()s on top of it ;) I never recommended that because I thought it would be confusing. Thanks Steve and Christian for your feedback. I'm integrating your suggestions in my branch and will re-send the series after more testing. Pierre-Eric -- Steve
Re: [PATCH v4 10/14] drm/panthor: Add the scheduler logical block
On 22/01/2024 16:30, Boris Brezillon wrote:
> This is the piece of software interacting with the FW scheduler, and
> taking care of some scheduling aspects when the FW comes short of slots
> scheduling slots. Indeed, the FW only expose a few slots, and the kernel
> has to give all submission contexts, a chance to execute their jobs.
>
> The kernel-side scheduler is timeslice-based, with a round-robin queue
> per priority level.
>
> Job submission is handled with a 1:1 drm_sched_entity:drm_gpu_scheduler,
> allowing us to delegate the dependency tracking to the core.
>
> All the gory details should be documented inline.
>
> v4:
> - Check drmm_mutex_init() return code
> - s/drm_gem_vmap_unlocked/drm_gem_vunmap_unlocked/ in
> panthor_queue_put_syncwait_obj()
> - Drop unneeded WARN_ON() in cs_slot_sync_queue_state_locked()
> - Use atomic_xchg() instead of atomic_fetch_and(0)
> - Fix typos
> - Let panthor_kernel_bo_destroy() check for IS_ERR_OR_NULL() BOs
> - Defer TILER_OOM event handling to a separate workqueue to prevent
> deadlocks when the heap chunk allocation is blocked on mem-reclaim.
> This is just a temporary solution, until we add support for
> non-blocking/failable allocations
> - Pass the scheduler workqueue to drm_sched instead of instantiating
> a separate one (no longer needed now that heap chunk allocation
> happens on a dedicated wq)
> - Set WQ_MEM_RECLAIM on the scheduler workqueue, so we can handle
> job timeouts when the system is under mem pressure, and hopefully
> free up some memory retained by these jobs
>
> v3:
> - Rework the FW event handling logic to avoid races
> - Make sure MMU faults kill the group immediately
> - Use the panthor_kernel_bo abstraction for group/queue buffers
> - Make in_progress an atomic_t, so we can check it without the reset lock
> held
> - Don't limit the number of groups per context to the FW scheduler
> capacity. Fix the limit to 128 for now.
> - Add a panthor_job_vm() helper
> - Account for panthor_vm changes
> - Add our job fence as DMA_RESV_USAGE_WRITE to all external objects
> (was previously DMA_RESV_USAGE_BOOKKEEP). I don't get why, given
> we're supposed to be fully-explicit, but other drivers do that, so
> there must be a good reason
> - Account for drm_sched changes
> - Provide a panthor_queue_put_syncwait_obj()
> - Unconditionally return groups to their idle list in
> panthor_sched_suspend()
> - Condition of sched_queue_{,delayed_}work fixed to be only when a reset
> isn't pending or in progress.
> - Several typos in comments fixed.
>
> Co-developed-by: Steven Price
> Signed-off-by: Steven Price
> Signed-off-by: Boris Brezillon
Looks good, a few minor NITs below, but otherwise.
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panthor/panthor_sched.c | 3500 +++
> drivers/gpu/drm/panthor/panthor_sched.h | 48 +
> 2 files changed, 3548 insertions(+)
> create mode 100644 drivers/gpu/drm/panthor/panthor_sched.c
> create mode 100644 drivers/gpu/drm/panthor/panthor_sched.h
>
> diff --git a/drivers/gpu/drm/panthor/panthor_sched.c
> b/drivers/gpu/drm/panthor/panthor_sched.c
> new file mode 100644
> index ..b57f4a5f5176
> --- /dev/null
> +++ b/drivers/gpu/drm/panthor/panthor_sched.c
> @@ -0,0 +1,3500 @@
> +// SPDX-License-Identifier: GPL-2.0 or MIT
> +/* Copyright 2023 Collabora ltd. */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "panthor_sched.h"
> +#include "panthor_devfreq.h"
> +#include "panthor_device.h"
> +#include "panthor_gem.h"
> +#include "panthor_heap.h"
> +#include "panthor_regs.h"
> +#include "panthor_gpu.h"
> +#include "panthor_fw.h"
> +#include "panthor_mmu.h"
> +
> +/**
> + * DOC: Scheduler
> + *
> + * Mali CSF hardware adopts a firmware-assisted scheduling model, where
> + * the firmware takes care of scheduling aspects, to some extend.
NIT: s/extend/extent/
> + *
> + * The scheduling happens at the scheduling group level, each group
> + * contains 1 to N queues (N is FW/hardware dependent, and exposed
> + * through the firmware interface). Each queue is assigned a command
> + * stream ring buffer, which serves as a way to get jobs submitted to
> + * the GPU, among other things.
> + *
> + * The firmware can schedule a maximum of M groups (M is FW/hardware
> + * dependent, and exposed through the firmware interface). Passed
> + * this maximum number of groups, the kernel must take care of
> + * rotating the groups passed to the firmware so every group gets
> + * a chance to have his queues scheduled for execution.
> + *
> + * The current implementation only supports with kernel-mode queues.
> + * In other terms, userspace doesn't have access to the ring-buffer.
> + * Instead, userspace passes indirect command stream buffers that are
>
Re: [PATCH v2 5/6] drm/amdgpu: add a amdgpu_cs_ioctl2 event
Le 14/02/2024 à 13:09, Christian König a écrit :
Am 13.02.24 um 16:50 schrieb Pierre-Eric Pelloux-Prayer:
amdgpu_cs_ioctl already exists but serves a different
purpose.
amdgpu_cs_ioctl2 marks the beginning of the kernel processing of
the ioctl which is useful for tools to map which events belong to
the same submission (without this, the first event would be the
amdgpu_bo_set_list ones).
That's not necessary a good justification for the naming. What exactly was the
original trace_amdgpu_cs_ioctl() doing?
trace_amdgpu_cs_ioctl is used right before drm_sched_entity_push_job is called
so in a sense it's a duplicate
of trace_drm_sched_job.
That being said, it's used by gpuvis so I chose to not modify it.
As for the new event: initially I named it "amdgpu_cs_parser_init", but since
the intent is to mark the
beginning of the amdgpu_cs_submit I've renamed it.
Any suggestion for a better name?
Thanks,
Pierre-Eric
Regards,
Christian.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 12
2 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 6830892383c3..29e43a66d0d6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1402,6 +1402,8 @@ int amdgpu_cs_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
return r;
}
+ trace_amdgpu_cs_ioctl2(data);
+
r = amdgpu_cs_pass1(, data);
if (r)
goto error_fini;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index e8ea1cfe7027..24e95560ede5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -189,6 +189,18 @@ TRACE_EVENT(amdgpu_cs_ioctl,
__entry->seqno, __get_str(ring), __entry->num_ibs)
);
+TRACE_EVENT(amdgpu_cs_ioctl2,
+ TP_PROTO(union drm_amdgpu_cs *cs),
+ TP_ARGS(cs),
+ TP_STRUCT__entry(
+ __field(uint32_t, ctx_id)
+ ),
+ TP_fast_assign(
+ __entry->ctx_id = cs->in.ctx_id;
+ ),
+ TP_printk("context=%u", __entry->ctx_id)
+);
+
TRACE_EVENT(amdgpu_sched_run_job,
TP_PROTO(struct amdgpu_job *job),
TP_ARGS(job),
Re: [PATCH v2 5/6] drm/amdgpu: add a amdgpu_cs_ioctl2 event
Am 14.02.24 um 17:38 schrieb Pierre-Eric Pelloux-Prayer:
Le 14/02/2024 à 13:09, Christian König a écrit :
Am 13.02.24 um 16:50 schrieb Pierre-Eric Pelloux-Prayer:
amdgpu_cs_ioctl already exists but serves a different
purpose.
amdgpu_cs_ioctl2 marks the beginning of the kernel processing of
the ioctl which is useful for tools to map which events belong to
the same submission (without this, the first event would be the
amdgpu_bo_set_list ones).
That's not necessary a good justification for the naming. What
exactly was the original trace_amdgpu_cs_ioctl() doing?
trace_amdgpu_cs_ioctl is used right before drm_sched_entity_push_job
is called so in a sense it's a duplicate
of trace_drm_sched_job.
Ah, yes I remember that I wanted to remove that one as well and got
pushback.
That being said, it's used by gpuvis so I chose to not modify it.
As for the new event: initially I named it "amdgpu_cs_parser_init",
but since the intent is to mark the
beginning of the amdgpu_cs_submit I've renamed it.
Any suggestion for a better name?
How about amdgpu_cs_start ?
Regards,
Christian.
Thanks,
Pierre-Eric
Regards,
Christian.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 12
2 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 6830892383c3..29e43a66d0d6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1402,6 +1402,8 @@ int amdgpu_cs_ioctl(struct drm_device *dev,
void *data, struct drm_file *filp)
return r;
}
+ trace_amdgpu_cs_ioctl2(data);
+
r = amdgpu_cs_pass1(, data);
if (r)
goto error_fini;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index e8ea1cfe7027..24e95560ede5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -189,6 +189,18 @@ TRACE_EVENT(amdgpu_cs_ioctl,
__entry->seqno, __get_str(ring), __entry->num_ibs)
);
+TRACE_EVENT(amdgpu_cs_ioctl2,
+ TP_PROTO(union drm_amdgpu_cs *cs),
+ TP_ARGS(cs),
+ TP_STRUCT__entry(
+ __field(uint32_t, ctx_id)
+ ),
+ TP_fast_assign(
+ __entry->ctx_id = cs->in.ctx_id;
+ ),
+ TP_printk("context=%u", __entry->ctx_id)
+);
+
TRACE_EVENT(amdgpu_sched_run_job,
TP_PROTO(struct amdgpu_job *job),
TP_ARGS(job),
Re: [PATCH v2 2/8] staging/fbtft: Include
Am 13.02.24 um 09:42 schrieb Thomas Zimmermann: Resolved the proxy include via , which does not require the backlight header. Signed-off-by: Thomas Zimmermann Acked by Jani via IRC Acked-by: Jani Nikula --- drivers/staging/fbtft/fb_ssd1351.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/staging/fbtft/fb_ssd1351.c b/drivers/staging/fbtft/fb_ssd1351.c index b8d55aa8c5c75..72172e870007e 100644 --- a/drivers/staging/fbtft/fb_ssd1351.c +++ b/drivers/staging/fbtft/fb_ssd1351.c @@ -1,4 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 + +#include #include #include #include -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
Re: [RFC PATCH 2/3] drm/tidss: Add support for display sharing
Hi Maxime, Thanks for the quick reply. On 13/02/24 19:34, Maxime Ripard wrote: > Hi Devarsh, > > On Thu, Feb 08, 2024 at 06:26:17PM +0530, Devarsh Thakkar wrote: >> Hi Maxime, >> >> Thanks a lot for checking on this. >> >> On 26/01/24 17:45, Maxime Ripard wrote: >>> Hi, >>> >>> Thanks a lot for working on that. >>> >>> On Tue, Jan 16, 2024 at 07:11:41PM +0530, Devarsh Thakkar wrote: Display subsystem present in TI Keystone family of devices supports sharing of display between multiple hosts as it provides separate register space (common* region) for each host to programming display controller and also a unique interrupt line for each host. This adds support for display sharing, by allowing partitioning of resources either at video port level or at video plane level as described below : 1) Linux can own (i.e have write access) completely one or more of video ports along with corresponding resources (viz. overlay managers, video planes) used by Linux in context of those video ports. Even if Linux is owning these video ports it can still share this video port with a remote core which can own one or more video planes associated with this video port. 2) Linux owns one or more of the video planes with video port (along with corresponding overlay manager) associated with these planes being owned and controlled by a remote core. Linux still has read-only access to the associated video port and overlay managers so that it can parse the settings made by remote core. >>> >>> So, just to make sure we're on the same page. 1) means Linux drives the >>> whole display engine, but can lend planes to the R5? How does that work, >>> is Linux aware of the workload being there (plane size, format, etc) ? >>> >> >> Well, there is no dynamic procedure being followed for lending. The >> partitioning scheme is decided and known before hand, and the remote >> core firmware updated and compiled accordingly, and similarly the >> device-tree overlay for Linux is also updated with partitioning >> information before bootup. >> >> What would happen here is that Linux will know before-hand this >> partitioning information via device-tree properties and won't enumerate >> the plane owned by RTOS, but it will enumerate the rest of the display >> components and initialize the DSS, after which user can load the DSS >> firmware on remote core and this firmware will only have control of >> plane as it was compiled with that configuration. > > Right. If the RTOS is in control of a single plane, how it is expected > to deal with Linux shutting the CRTC down, or enforcing a configuration > that isn't compatible with what the RTOS expects (like a plane with a > higher zpos masking its plane), what is the mechanism to reconcile it? > Just for the note, for this "RTOS control single plane" mode, we don't have a firmware available to test (right now we are only supporting example for "RTOS controlling the display mode" as shared here [1]) and hence this is not validated but the idea was to keep dt-bindings generic enough to support them in future and that's why I referred to it here. Coming back to your questions, with the current scheme the Linux (tidss) would be expected to make sure the CRTC being shared with RTOS is never shutdown and the RTOS plane should never gets masked. I think the IPC based scheme would have been mainly needed for the case where you have a single entity controlling the display for e.g you have a single display controller register space and a single IRQ but you have multiple planes and say you want to divide these planes to different host processors. In that case you want a single entity to act as a main entity and be in control of DSS and rest of the processors communicate with the "main entity" to request display resources and plane updates and main entity also programs dss on their behalf. But unlike above, TI DSS7 is designed to support static partitioning of display resources among multiple hosts, where each host can program the display hardware independently using separate register space and having a separate irq and without requirement of any communication between the hosts. Now as this feature is unique to TI DSS7 we want to support this feature in tidss driver. The DSS resource partitioning feature is described in detail here [2] >>> And 2) would mean that the display engine is under the R5 control and >>> Linux only gets to fill the plane and let the firmware know of what it >>> wants? >>> >> >> Here too the partitioning information is pre-decided and remote core >> firmware and device-tree overlay for Linux updated accordingly. But in >> this case as remote core firmware owns the display (minus the plane >> owned by Linux) it is started and initialized during the bootloader >> phase itself where it initializes the DSS and starts rendering using the >> plane owned by it and Linux just latches to the
Re: [RFC PATCH net-next v5 07/14] page_pool: devmem support
On 2/13/24 21:11, Mina Almasry wrote: On Tue, Feb 13, 2024 at 5:28 AM Pavel Begunkov wrote: ... A bit of a churn with the padding and nesting net_iov but looks sturdier. No duplication, and you can just check positions of the structure instead of per-field NET_IOV_ASSERT_OFFSET, which you have to not forget to update e.g. when adding a new field. Also, Yes, this is nicer. If possible I'll punt it to a minor cleanup as a follow up change. Logistically I think if this series need-not touch code outside of net/, that's better. Outside of net it should only be a small change in struct page layout, but otherwise with struct_group_tagged things like page->pp_magic would still work. Anyway, I'm not insisting. with the change __netmem_clear_lsb can return a pointer to that structure, casting struct net_iov when it's a page is a bit iffy. And the next question would be whether it'd be a good idea to encode iov vs page not by setting a bit but via one of the fields in the structure, maybe pp_magic. I will push back against this, for 2 reasons: 1. I think pp_magic's first 2 bits (and maybe more) are used by mm code and thus I think extending usage of pp_magic in this series is a bit iffy and I would like to avoid it. I just don't want to touch the semantics of struct page if I don't have to. 2. I think this will be a measurable perf regression. Currently we can tell if a pointer is a page or net_iov without dereferencing the pointer and dirtying the cache-line. This will cause us to possibly dereference the pointer in areas where we don't need to. I think I had an earlier version of this code that required a dereference to tell if a page was devmem and Eric pointed to me it was a perf regression. fair enough I also don't see any upside of using pp_magic, other than making the code slightly more readable, maybe. With that said I'm a bit concerned about the net_iov size. If each represents 4096 bytes and you're registering 10MB, then you need 30 pages worth of memory just for the iov array. Makes kvmalloc a must even for relatively small sizes. This I think is an age-old challenge with pages. 1.6% of the machine's memory is 'wasted' on every machine because a struct page needs to be allocated for each PAGE_SIZE region. We're running into the same issue here where if we want to refer to PAGE_SIZE regions of memory we need to allocate some reference to it. Note that net_iov can be relatively easily extended to support N order pages. Also note that in the devmem TCP use case it's not really an issue; the minor increase in mem utilization is more than offset by the saving in memory bw as compared to using host memory as a bounce buffer. It's not about memory consumption per se but rather the need to vmalloc everything because of size. All in all I vote this is something that can be tuned or improved in the future if someone finds the extra memory usage a hurdle to using devmem TCP or this net_iov infra. That's exactly what I was saying about overlaying it with struct page, where the increase in size came from, but I agree it's not critical And the final bit, I don't believe the overlay is necessary in this series. Optimisations are great, but this one is a bit more on the controversial side. Unless I missed something and it does make things easier, it might make sense to do it separately later. I completely agree, the overlay is not necessary. I implemented the overlay in response to Yunsheng's strong requests for more 'unified' processing between page and devmem. This is the most unification I can do IMO without violating the requirements from Jason. I'm prepared to remove the overlay if it turns out controversial, but so far I haven't seen any complaints. Jason, please do take a look if you have not already. Just to be clear, I have no objections to the change but noting that IMHO it can be removed for now if it'd be dragging down the set. -- Pavel Begunkov
Re: [PATCH v2 1/6] tracing, dma-buf: add a trace_dma_fence_sync_to event
On Wed, 14 Feb 2024 13:00:16 +0100 Christian König wrote: > > +DEFINE_EVENT(dma_fence_from, dma_fence_sync_to, > > For a single event you should probably use TRACE_EVENT() instead of > declaring a class. A class is only used if you have multiple events with > the same parameters. FYI, TRACE_EVENT() is actually defined as: #define TRACE_EVENT(name, proto, args, tstruct, assign, print) \ DECLARE_EVENT_CLASS(name, \ PARAMS(proto),\ PARAMS(args), \ PARAMS(tstruct), \ PARAMS(assign), \ PARAMS(print)); \ DEFINE_EVENT(name, name, PARAMS(proto), PARAMS(args)); So basically, you could really just declare one TRACE_EVENT() and add DEFINE_EVENT()s on top of it ;) I never recommended that because I thought it would be confusing. -- Steve
Re: [PATCH v2 16/19] drm/msm/dpu: modify encoder programming for CDM over DP
On Wed, 14 Feb 2024 at 00:11, Abhinav Kumar wrote:
>
>
>
> On 2/13/2024 1:16 PM, Dmitry Baryshkov wrote:
> > On Tue, 13 Feb 2024 at 23:10, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 2/13/2024 11:31 AM, Dmitry Baryshkov wrote:
> >>> On Tue, 13 Feb 2024 at 20:46, Abhinav Kumar
> >>> wrote:
>
>
>
> On 2/13/2024 10:23 AM, Dmitry Baryshkov wrote:
> > On Tue, 13 Feb 2024 at 19:32, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 2/13/2024 3:18 AM, Dmitry Baryshkov wrote:
> >>> On Sat, 10 Feb 2024 at 03:53, Paloma Arellano
> >>> wrote:
>
> Adjust the encoder format programming in the case of video mode for
> DP
> to accommodate CDM related changes.
>
> Changes in v2:
> - Move timing engine programming to a separate patch
> from this
> one
> - Move update_pending_flush_periph() invocation
> completely to
> this patch
> - Change the logic of dpu_encoder_get_drm_fmt() so that
> it only
> calls drm_mode_is_420_only() instead of doing
> additional
> unnecessary checks
> - Create new functions msm_dp_needs_periph_flush() and
> it's
> supporting function dpu_encoder_needs_periph_flush()
> to check
> if the mode is YUV420 and VSC SDP is enabled before
> doing a
> peripheral flush
>
> Signed-off-by: Paloma Arellano
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 35
> +++
> .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 13 +++
> .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 19 ++
> drivers/gpu/drm/msm/dp/dp_display.c | 18 ++
> drivers/gpu/drm/msm/msm_drv.h | 17 -
> 5 files changed, 101 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 7e7796561009a..6280c6be6dca9 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -222,6 +222,41 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
> 15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
> };
>
> +u32 dpu_encoder_get_drm_fmt(struct dpu_encoder_phys *phys_enc)
> +{
> + struct drm_encoder *drm_enc;
> + struct dpu_encoder_virt *dpu_enc;
> + struct drm_display_info *info;
> + struct drm_display_mode *mode;
> +
> + drm_enc = phys_enc->parent;
> + dpu_enc = to_dpu_encoder_virt(drm_enc);
> + info = _enc->connector->display_info;
> + mode = _enc->cached_mode;
> +
> + if (drm_mode_is_420_only(info, mode))
> + return DRM_FORMAT_YUV420;
> +
> + return DRM_FORMAT_RGB888;
> +}
> +
> +bool dpu_encoder_needs_periph_flush(struct dpu_encoder_phys
> *phys_enc)
> +{
> + struct drm_encoder *drm_enc;
> + struct dpu_encoder_virt *dpu_enc;
> + struct msm_display_info *disp_info;
> + struct msm_drm_private *priv;
> + struct drm_display_mode *mode;
> +
> + drm_enc = phys_enc->parent;
> + dpu_enc = to_dpu_encoder_virt(drm_enc);
> + disp_info = _enc->disp_info;
> + priv = drm_enc->dev->dev_private;
> + mode = _enc->cached_mode;
> +
> + return phys_enc->hw_intf->cap->type == INTF_DP &&
> phys_enc->hw_cdm &&
> >>>
> >>> Do we really need to check for phys_enc->hw_cdm here?
> >>>
> >>
> >> hmmm I dont think so. If CDM was not there, then after the last patch,
> >> YUV420 removes will not be present at all.
> >>
> >> The only other case I could think of was, if for some reason CDM was
> >> used by some other interface such as WB, then hw_cdm will not be
> >> assigned.
> >>
> >> But, I think even for that msm_dp_needs_periph_flush() will take care
> >> of
> >> it because we use the cached_mode which is assigned only in mode_set().
> >>
> +
> msm_dp_needs_periph_flush(priv->dp[disp_info->h_tile_instance[0]],
> mode);
> +}
>
> bool dpu_encoder_is_widebus_enabled(const struct drm_encoder
> *drm_enc)
> {
> diff
Re: [PATCH v2] drm: ci: use clk_ignore_unused for apq8016
On 14/02/2024 10:30, Helen Koike wrote:
On 14/02/2024 05:37, Dmitry Baryshkov wrote:
If the ADV7511 bridge driver is compiled as a module, while DRM_MSM is
built-in, the clk_disable_unused congests with the runtime PM handling
of the DSI PHY for the clk_prepare_lock(). This causes apq8016 runner to
fail without completing any jobs ([1]). Drop the BM_CMDLINE which
duplicate the command line from the .baremetal-igt-arm64 clause and
enforce the clk_ignore_unused kernelarg instead to make apq8016 runner
work.
[1] https://gitlab.freedesktop.org/drm/msm/-/jobs/54990475
Fixes: 0119c894ab0d ("drm: Add initial ci/ subdirectory")
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Dmitry Baryshkov
Acked-by: Helen Koike
Applied to drm-misc-next.
Regards,
Helen
Thanks
Helen
---
Changes in v2:
- Added a comment, describing the issue and a way to reproduce it
(Javier)
---
drivers/gpu/drm/ci/test.yml | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ci/test.yml b/drivers/gpu/drm/ci/test.yml
index 7ffb620d7398..e64205286a27 100644
--- a/drivers/gpu/drm/ci/test.yml
+++ b/drivers/gpu/drm/ci/test.yml
@@ -119,7 +119,10 @@ msm:apq8016:
DRIVER_NAME: msm
BM_DTB:
https://${PIPELINE_ARTIFACTS_BASE}/arm64/apq8016-sbc-usb-host.dtb
GPU_VERSION: apq8016
- BM_CMDLINE: "ip=dhcp console=ttyMSM0,115200n8
$BM_KERNEL_EXTRA_ARGS root=/dev/nfs rw nfsrootdebug
nfsroot=,tcp,nfsvers=4.2 init=/init $BM_KERNELARGS"
+ # disabling unused clocks congests with the MDSS runtime PM
trying to
+ # disable those clocks and causes boot to fail.
+ # Reproducer: DRM_MSM=y, DRM_I2C_ADV7511=m
+ BM_KERNEL_EXTRA_ARGS: clk_ignore_unused
RUNNER_TAG: google-freedreno-db410c
script:
- ./install/bare-metal/fastboot.sh
Re: [PATCH v3 9/9] drm/ci: uprev IGT and update testlist
On 10/02/2024 15:20, Maíra Canal wrote: On 2/10/24 15:17, Maíra Canal wrote: On 1/30/24 12:03, Vignesh Raman wrote: Uprev IGT and add amd, v3d, vc4 and vgem specific tests to testlist. Have testlist.txt per driver and include a base testlist so that the driver specific tests will run only on those hardware. Signed-off-by: Vignesh Raman --- v3: - New patch in series to uprev IGT and update testlist. --- drivers/gpu/drm/ci/gitlab-ci.yml | 2 +- drivers/gpu/drm/ci/igt_runner.sh | 12 +- drivers/gpu/drm/ci/testlist-amdgpu.txt | 151 ++ drivers/gpu/drm/ci/testlist-msm.txt | 50 ++ drivers/gpu/drm/ci/testlist-panfrost.txt | 17 ++ drivers/gpu/drm/ci/testlist-v3d.txt | 73 + drivers/gpu/drm/ci/testlist-vc4.txt | 49 ++ drivers/gpu/drm/ci/testlist.txt | 100 .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 24 ++- .../drm/ci/xfails/amdgpu-stoney-flakes.txt | 9 +- .../gpu/drm/ci/xfails/amdgpu-stoney-skips.txt | 10 +- 11 files changed, 427 insertions(+), 70 deletions(-) create mode 100644 drivers/gpu/drm/ci/testlist-amdgpu.txt create mode 100644 drivers/gpu/drm/ci/testlist-msm.txt create mode 100644 drivers/gpu/drm/ci/testlist-panfrost.txt create mode 100644 drivers/gpu/drm/ci/testlist-v3d.txt create mode 100644 drivers/gpu/drm/ci/testlist-vc4.txt diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml b/drivers/gpu/drm/ci/gitlab-ci.yml index bc8cb3420476..e2b021616a8e 100644 --- a/drivers/gpu/drm/ci/gitlab-ci.yml +++ b/drivers/gpu/drm/ci/gitlab-ci.yml @@ -5,7 +5,7 @@ variables: UPSTREAM_REPO: git://anongit.freedesktop.org/drm/drm TARGET_BRANCH: drm-next - IGT_VERSION: d2af13d9f5be5ce23d996e4afd3e45990f5ab977 + IGT_VERSION: b0cc8160ebdc87ce08b7fd83bb3c99ff7a4d8610 DEQP_RUNNER_GIT_URL: https://gitlab.freedesktop.org/anholt/deqp-runner.git DEQP_RUNNER_GIT_TAG: v0.15.0 diff --git a/drivers/gpu/drm/ci/igt_runner.sh b/drivers/gpu/drm/ci/igt_runner.sh index f001e015d135..2fd09b9b7cf6 100755 --- a/drivers/gpu/drm/ci/igt_runner.sh +++ b/drivers/gpu/drm/ci/igt_runner.sh @@ -64,10 +64,20 @@ if ! grep -q "core_getversion" /install/testlist.txt; then fi set +e +if [ "$DRIVER_NAME" = "amdgpu" ]; then + TEST_LIST="/install/testlist-amdgpu.txt" +elif [ "$DRIVER_NAME" = "msm" ]; then + TEST_LIST="/install/testlist-msm.txt" +elif [ "$DRIVER_NAME" = "panfrost" ]; then + TEST_LIST="/install/testlist-panfrost.txt" +else + TEST_LIST="/install/testlist.txt" +fi + Isn't V3D and VC4 testlists missing? It would be nice if you could provide us a link to a working pipeline. Also, if possible, I would like to be CCed on the next version of this patch, as I have interest in the V3D/VC4 tests. Ah, one thing: it would be nice to add the testlists to the MAINTAINERS file. This way, maintainers can keep track of any changes. Make sense, +1 ^ Regards, Helen Best Regards, - Maíra igt-runner \ run \ --igt-folder /igt/libexec/igt-gpu-tools \ - --caselist /install/testlist.txt \ + --caselist $TEST_LIST \ --output /results \ $IGT_SKIPS \ $IGT_FLAKES \ diff --git a/drivers/gpu/drm/ci/testlist-amdgpu.txt b/drivers/gpu/drm/ci/testlist-amdgpu.txt new file mode 100644 index ..4486f86d340b --- /dev/null +++ b/drivers/gpu/drm/ci/testlist-amdgpu.txt @@ -0,0 +1,151 @@ +testlist.txt +amdgpu/amd_abm@dpms_cycle +amdgpu/amd_abm@backlight_monotonic_basic +amdgpu/amd_abm@backlight_monotonic_abm +amdgpu/amd_abm@abm_enabled +amdgpu/amd_abm@abm_gradual +amdgpu/amd_bo@amdgpu_bo_export_import +amdgpu/amd_bo@amdgpu_bo_metadata +amdgpu/amd_bo@amdgpu_bo_map_unmap +amdgpu/amd_bo@amdgpu_memory_alloc +amdgpu/amd_bo@amdgpu_mem_fail_alloc +amdgpu/amd_bo@amdgpu_bo_find_by_cpu_mapping +amdgpu/amd_cp_dma_misc@GTT_to_VRAM-AMDGPU_HW_IP_GFX0 +amdgpu/amd_cp_dma_misc@GTT_to_VRAM-AMDGPU_HW_IP_COMPUTE0 +amdgpu/amd_cp_dma_misc@VRAM_to_GTT-AMDGPU_HW_IP_GFX0 +amdgpu/amd_cp_dma_misc@VRAM_to_GTT-AMDGPU_HW_IP_COMPUTE0 +amdgpu/amd_cp_dma_misc@VRAM_to_VRAM-AMDGPU_HW_IP_GFX0 +amdgpu/amd_cp_dma_misc@VRAM_to_VRAM-AMDGPU_HW_IP_COMPUTE0 +amdgpu/amd_dispatch@amdgpu-dispatch-test-compute-with-IP-COMPUTE +amdgpu/amd_dispatch@amdgpu-dispatch-test-gfx-with-IP-GFX +amdgpu/amd_dispatch@amdgpu-dispatch-hang-test-gfx-with-IP-GFX +amdgpu/amd_dispatch@amdgpu-dispatch-hang-test-compute-with-IP-COMPUTE +amdgpu/amd_dispatch@amdgpu-reset-test-gfx-with-IP-GFX-and-COMPUTE +amdgpu/amd_hotplug@basic +amdgpu/amd_hotplug@basic-suspend +amdgpu/amd_jpeg_dec@amdgpu_cs_jpeg_decode +amdgpu/amd_max_bpc@4k-mode-max-bpc +amdgpu/amd_module_load@reload +amdgpu/amd_plane@test-mpo-4k +amdgpu/amd_plane@mpo-swizzle-toggle +amdgpu/amd_plane@mpo-swizzle-toggle-multihead +amdgpu/amd_plane@mpo-pan-rgb +amdgpu/amd_plane@mpo-pan-rgb-multihead +amdgpu/amd_plane@mpo-pan-nv12 +amdgpu/amd_plane@mpo-pan-nv12-multihead +amdgpu/amd_plane@mpo-pan-p010
Re: [PATCH 0/1] Always record job cycle and timestamp information
Hi Adrián, On 14/02/2024 12:14, Adrián Larumbe wrote: > A driver user expressed interest in being able to access engine usage stats > through fdinfo when debugfs is not built into their kernel. In the current > implementation, this wasn't possible, because it was assumed even for > inflight jobs enabling the cycle counter and timestamp registers would > incur in additional power consumption, so both were kept disabled until > toggled through debugfs. > > A second read of the TRM made me think otherwise, but this is something > that would be best clarified by someone from ARM's side. I'm afraid I can't give a definitive answer. This will probably vary depending on implementation. The command register enables/disables "propagation" of the cycle/timestamp values. This propagation will cost some power (gates are getting toggled) but whether that power is completely in the noise of the GPU as a whole I can't say. The out-of-tree kbase driver only enables the counters for jobs explicitly marked (BASE_JD_REQ_PERMON) or due to an explicit connection from a profiler. I'd be happier moving the debugfs file to sysfs rather than assuming that the power consumption is small enough for all platforms. Ideally we'd have some sort of kernel interface for a profiler to inform the kernel what it is interested in, but I can't immediately see how to make that useful across different drivers. kbase's profiling support is great with our profiling tools, but there's a very strong connection between the two. Steve > Adrián Larumbe (1): > drm/panfrost: Always record job cycle and timestamp information > > drivers/gpu/drm/panfrost/Makefile | 2 -- > drivers/gpu/drm/panfrost/panfrost_debugfs.c | 21 -- > drivers/gpu/drm/panfrost/panfrost_debugfs.h | 14 > drivers/gpu/drm/panfrost/panfrost_device.h | 1 - > drivers/gpu/drm/panfrost/panfrost_drv.c | 5 - > drivers/gpu/drm/panfrost/panfrost_job.c | 24 - > drivers/gpu/drm/panfrost/panfrost_job.h | 1 - > 7 files changed, 9 insertions(+), 59 deletions(-) > delete mode 100644 drivers/gpu/drm/panfrost/panfrost_debugfs.c > delete mode 100644 drivers/gpu/drm/panfrost/panfrost_debugfs.h > > > base-commit: 6b1f93ea345947c94bf3a7a6e668a2acfd310918
Re: drm/msm: DisplayPort regressions in 6.8-rc1
On Tue, Feb 13, 2024 at 10:00:13AM -0800, Abhinav Kumar wrote: > I do agree that pm runtime eDP driver got merged that time but I think > the issue is either a combination of that along with DRM aux bridge > https://patchwork.freedesktop.org/series/122584/ OR just the latter as > even that went in around the same time. Yes, indeed there was a lot of changes that went into the MSM drm driver in 6.8-rc1 and since I have not tried to debug this myself I can't say for sure which change or changes that triggered this regression (or possibly regressions). The fact that the USB-C/DP PHY appears to be involved (/soc@0/phy@88eb000) could indeed point to the series you mentioned. > Thats why perhaps this issue was not seen with the chromebooks we tested > on as they do not use pmic_glink (aux bridge). > > So we will need to debug this on sc8280xp specifically or an equivalent > device which uses aux bridge. I've hit the NULL-pointer deference three times now in the last few days on the sc8280xp CRD. But since it doesn't trigger on every boot it seems you need to go back to the series that could potentially have caused this regression and review them again. There's clearly something quite broken here. > On 2/13/2024 3:42 AM, Johan Hovold wrote: > > Since 6.8-rc1 the internal eDP display on the Lenovo ThinkPad X13s does > > not always show up on boot. > > [6.007872] [drm:drm_bridge_attach [drm]] *ERROR* failed to attach > > bridge /soc@0/phy@88eb000 to encoder TMDS-31: -16 > > and this can also manifest itself as a NULL-pointer dereference: > > > > [7.339447] Unable to handle kernel NULL pointer dereference at > > virtual address > > > > [7.643705] pc : drm_bridge_attach+0x70/0x1a8 [drm] > > [7.686415] lr : drm_aux_bridge_attach+0x24/0x38 [aux_bridge] > > > > [7.769039] Call trace: > > [7.771564] drm_bridge_attach+0x70/0x1a8 [drm] > > [7.776234] drm_aux_bridge_attach+0x24/0x38 [aux_bridge] > > [7.781782] drm_bridge_attach+0x80/0x1a8 [drm] > > [7.786454] dp_bridge_init+0xa8/0x15c [msm] > > [7.790856] msm_dp_modeset_init+0x28/0xc4 [msm] > > [7.795617] _dpu_kms_drm_obj_init+0x19c/0x680 [msm] > > [7.800731] dpu_kms_hw_init+0x348/0x4c4 [msm] > > [7.805306] msm_drm_kms_init+0x84/0x324 [msm] > > [7.809891] msm_drm_bind+0x1d8/0x3a8 [msm] > > [7.814196] try_to_bring_up_aggregate_device+0x1f0/0x2f8 > > [7.819747] __component_add+0xa4/0x18c > > [7.823703] component_add+0x14/0x20 > > [7.827389] dp_display_probe+0x47c/0x568 [msm] > > [7.832052] platform_probe+0x68/0xd8 > > > > Users have also reported random crashes at boot since 6.8-rc1, and I've > > been able to trigger hard crashes twice when testing an external display > > (USB-C/DP), which may also be related to the DP regressions. Johan
Re: [PATCH 0/5] Add display support for stm32mp135f-dk board
Hi Raphael
On 2/5/24 10:06, Raphael Gallais-Pou wrote:
This serie aims to enable display support for the stm32mp135f-dk board
Those are only patches of the device-tree since the driver support has
already been added [1].
It respectivelly:
- adds support for the display controller on stm32mp135
- adds pinctrl for the display controller
- enables panel, backlight and display controller on
stm32mp135f-dk
Finally it fixes the flags on the panel default mode in the
'panel-simple' driver, allowing to override the default mode by one
described in the device tree, and push further the blanking limit on the
panel.
[1] commit 1726cee3d053 ("drm/stm: ltdc: support of new hardware version")
Signed-off-by: Raphael Gallais-Pou
---
Raphael Gallais-Pou (5):
ARM: dts: stm32: add LTDC support for STM32MP13x SoC family
ARM: dts: stm32: add LTDC pinctrl on STM32MP13x SoC family
ARM: dts: stm32: enable display support on stm32mp135f-dk board
drm/panel: simple: fix flags on RK043FN48H
drm/panel: simple: push blanking limit on RK32FN48H
arch/arm/boot/dts/st/stm32mp13-pinctrl.dtsi | 57 +
arch/arm/boot/dts/st/stm32mp135.dtsi| 11 ++
arch/arm/boot/dts/st/stm32mp135f-dk.dts | 55
drivers/gpu/drm/panel/panel-simple.c| 7 ++--
4 files changed, 127 insertions(+), 3 deletions(-)
---
base-commit: 6613476e225e090cc9aad49be7fa504e290dd33d
change-id: 20240124-ltdc_mp13-2f86a782424c
Best regards,
I got the following errors during YAML verification:
arch/arm/boot/dts/st/stm32mp135f-dk.dtb: /soc/i2c@40012000/pinctrl@21:
failed to match any schema with compatible: ['microchip,mcp23017']
/local/home/frq08678/STLINUX/kernel/my-kernel/stm32/arch/arm/boot/dts/st/stm32mp135f-dk.dtb:
panel-backlight: 'default-brightness-level' does not match any of the
regexes: 'pinctrl-[0-9]+'
from schema $id:
http://devicetree.org/schemas/leds/backlight/gpio-backlight.yaml#
/local/home/frq08678/STLINUX/kernel/my-kernel/stm32/arch/arm/boot/dts/st/stm32mp135f-dk.dtb:
panel-rgb: data-mapping:0: 'bgr666' is not one of ['jeida-18',
'jeida-24', 'vesa-24']
from schema $id:
http://devicetree.org/schemas/display/panel/panel-simple.yaml#
/local/home/frq08678/STLINUX/kernel/my-kernel/stm32/arch/arm/boot/dts/st/stm32mp135f-dk.dtb:
panel-rgb: compatible: ['rocktech,rk043fn48h', 'panel-dpi'] is too long
from schema $id:
http://devicetree.org/schemas/display/panel/panel-simple.yaml#
/local/home/frq08678/STLINUX/kernel/my-kernel/stm32/arch/arm/boot/dts/st/stm32mp135f-dk.dtb:
panel-rgb: data-mapping: False schema does not allow ['bgr666']
from schema $id:
http://devicetree.org/schemas/display/panel/panel-simple.yaml#
/local/home/frq08678/STLINUX/kernel/my-kernel/stm32/arch/arm/boot/dts/st/stm32mp135f-dk.dtb:
panel-rgb: 'height-mm', 'panel-timing', 'width-mm' do not match any of
the regexes: 'pinctrl-[0-9]+'
from schema $id:
http://devicetree.org/schemas/display/panel/panel-simple.yaml#
/local/home/frq08678/STLINUX/kernel/my-kernel/stm32/arch/arm/boot/dts/st/stm32mp135f-dk.dtb:
panel-rgb: 'data-mapping' does not match any of the regexes:
'pinctrl-[0-9]+'
from schema $id:
http://devicetree.org/schemas/display/panel/panel-dpi.yaml#
Do I miss something ?
Alex
Re: [PATCH v2] drm: ci: use clk_ignore_unused for apq8016
On 14/02/2024 05:37, Dmitry Baryshkov wrote:
If the ADV7511 bridge driver is compiled as a module, while DRM_MSM is
built-in, the clk_disable_unused congests with the runtime PM handling
of the DSI PHY for the clk_prepare_lock(). This causes apq8016 runner to
fail without completing any jobs ([1]). Drop the BM_CMDLINE which
duplicate the command line from the .baremetal-igt-arm64 clause and
enforce the clk_ignore_unused kernelarg instead to make apq8016 runner
work.
[1] https://gitlab.freedesktop.org/drm/msm/-/jobs/54990475
Fixes: 0119c894ab0d ("drm: Add initial ci/ subdirectory")
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Dmitry Baryshkov
Acked-by: Helen Koike
Thanks
Helen
---
Changes in v2:
- Added a comment, describing the issue and a way to reproduce it
(Javier)
---
drivers/gpu/drm/ci/test.yml | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ci/test.yml b/drivers/gpu/drm/ci/test.yml
index 7ffb620d7398..e64205286a27 100644
--- a/drivers/gpu/drm/ci/test.yml
+++ b/drivers/gpu/drm/ci/test.yml
@@ -119,7 +119,10 @@ msm:apq8016:
DRIVER_NAME: msm
BM_DTB: https://${PIPELINE_ARTIFACTS_BASE}/arm64/apq8016-sbc-usb-host.dtb
GPU_VERSION: apq8016
-BM_CMDLINE: "ip=dhcp console=ttyMSM0,115200n8 $BM_KERNEL_EXTRA_ARGS
root=/dev/nfs rw nfsrootdebug nfsroot=,tcp,nfsvers=4.2 init=/init $BM_KERNELARGS"
+# disabling unused clocks congests with the MDSS runtime PM trying to
+# disable those clocks and causes boot to fail.
+# Reproducer: DRM_MSM=y, DRM_I2C_ADV7511=m
+BM_KERNEL_EXTRA_ARGS: clk_ignore_unused
RUNNER_TAG: google-freedreno-db410c
script:
- ./install/bare-metal/fastboot.sh
[PATCH v2 2/2] drm/tests/drm_buddy: add alloc_contiguous test
From: Matthew Auld
Sanity check DRM_BUDDY_CONTIGUOUS_ALLOCATION.
v2: Fix checkpatch warnings.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3097
Signed-off-by: Matthew Auld
Cc: Arunpravin Paneer Selvam
Cc: Limonciello
Cc: Christian König
Reviewed-by: Arunpravin Paneer Selvam
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/tests/drm_buddy_test.c | 89 ++
1 file changed, 89 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c
b/drivers/gpu/drm/tests/drm_buddy_test.c
index ea2af6bd9abe..fee6bec757d1 100644
--- a/drivers/gpu/drm/tests/drm_buddy_test.c
+++ b/drivers/gpu/drm/tests/drm_buddy_test.c
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
@@ -18,6 +19,93 @@ static inline u64 get_size(int order, u64 chunk_size)
return (1 << order) * chunk_size;
}
+static void drm_test_buddy_alloc_contiguous(struct kunit *test)
+{
+ u64 mm_size, ps = SZ_4K, i, n_pages, total;
+ struct drm_buddy_block *block;
+ struct drm_buddy mm;
+ LIST_HEAD(left);
+ LIST_HEAD(middle);
+ LIST_HEAD(right);
+ LIST_HEAD(allocated);
+
+ mm_size = 16 * 3 * SZ_4K;
+
+ KUNIT_EXPECT_FALSE(test, drm_buddy_init(, mm_size, ps));
+
+ /*
+* Idea is to fragment the address space by alternating block
+* allocations between three different lists; one for left, middle and
+* right. We can then free a list to simulate fragmentation. In
+* particular we want to exercise the DRM_BUDDY_CONTIGUOUS_ALLOCATION,
+* including the try_harder path.
+*/
+
+ i = 0;
+ n_pages = mm_size / ps;
+ do {
+ struct list_head *list;
+ int slot = i % 3;
+
+ if (slot == 0)
+ list =
+ else if (slot == 1)
+ list =
+ else
+ list =
+ KUNIT_ASSERT_FALSE_MSG(test,
+ drm_buddy_alloc_blocks(, 0, mm_size,
+ ps, ps, list, 0),
+ "buddy_alloc hit an error size=%d\n",
+ ps);
+ } while (++i < n_pages);
+
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%d\n", 3 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 3 * ps);
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 2 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 2 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 3 * ps);
+ /*
+* At this point we should have enough contiguous space for 2 blocks,
+* however they are never buddies (since we freed middle and right) so
+* will require the try_harder logic to find them.
+*/
+ KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 2 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc hit an error size=%d\n", 2 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc hit an error size=%d\n", 3 * ps);
+
+ total = 0;
+ list_for_each_entry(block, , link)
+ total += drm_buddy_block_size(, block);
+
+ KUNIT_ASSERT_EQ(test, total, ps * 2 + ps * 3);
+
+ drm_buddy_free_list(, );
+ drm_buddy_fini();
+}
+
static void drm_test_buddy_alloc_pathological(struct kunit *test)
{
u64 mm_size, size, start = 0;
@@ -280,6 +368,7 @@ static struct kunit_case drm_buddy_tests[] = {
[PATCH v2 1/2] drm/buddy: Fix alloc_range() error handling code
Few users have observed display corruption when they boot
the machine to KDE Plasma or playing games. We have root
caused the problem that whenever alloc_range() couldn't
find the required memory blocks the function was returning
SUCCESS in some of the corner cases.
The right approach would be if the total allocated size
is less than the required size, the function should
return -ENOSPC.
Cc: # 6.7+
Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory allocation")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3097
Tested-by: Mario Limonciello
Link:
https://patchwork.kernel.org/project/dri-devel/patch/20240207174456.341121-1-arunpravin.paneersel...@amd.com/
Acked-by: Christian König
Reviewed-by: Matthew Auld
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/drm_buddy.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index f57e6d74fb0e..c1a99bf4dffd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -539,6 +539,12 @@ static int __alloc_range(struct drm_buddy *mm,
} while (1);
list_splice_tail(, blocks);
+
+ if (total_allocated < size) {
+ err = -ENOSPC;
+ goto err_free;
+ }
+
return 0;
err_undo:
base-commit: b6ddaa63f728d26c12048aed76be99c24f435c41
--
2.25.1
Re: drm/msm: DisplayPort regressions in 6.8-rc1
On 13.02.24 19:00, Abhinav Kumar wrote: > > Thanks for the report. > > I do agree that pm runtime eDP driver got merged that time but I think > the issue is either a combination of that along with DRM aux bridge > https://patchwork.freedesktop.org/series/122584/ OR just the latter as > even that went in around the same time. In that case allow me a stupid question from the cheap seats: Is there anything affected users can do to help getting us closer to the real problem? Like testing a specific commit or two before or after the merge of one of those features for example? That might help to rule out a few things. Ciao, Thorsten > Thats why perhaps this issue was not seen with the chromebooks we tested > on as they do not use pmic_glink (aux bridge). > > So we will need to debug this on sc8280xp specifically or an equivalent > device which uses aux bridge. > > On 2/13/2024 3:42 AM, Johan Hovold wrote: >> Hi, >> >> Since 6.8-rc1 the internal eDP display on the Lenovo ThinkPad X13s does >> not always show up on boot. >> >> The logs indicate problems with the runtime PM and eDP rework that went >> into 6.8-rc1: >> >> [ 6.006236] Console: switching to colour dummy device 80x25 >> [ 6.007542] [drm:dpu_kms_hw_init:1048] dpu hardware >> revision:0x8000 >> [ 6.007872] [drm:drm_bridge_attach [drm]] *ERROR* failed to >> attach bridge /soc@0/phy@88eb000 to encoder TMDS-31: -16 >> [ 6.007934] [drm:dp_bridge_init [msm]] *ERROR* failed to attach >> panel bridge: -16 >> [ 6.007983] msm_dpu ae01000.display-controller: >> [drm:msm_dp_modeset_init [msm]] *ERROR* failed to create dp bridge: -16 >> [ 6.008030] [drm:_dpu_kms_initialize_displayport:588] [dpu >> error]modeset_init failed for DP, rc = -16 >> [ 6.008050] [drm:_dpu_kms_setup_displays:681] [dpu >> error]initialize_DP failed, rc = -16 >> [ 6.008068] [drm:dpu_kms_hw_init:1153] [dpu error]modeset init >> failed: -16 >> [ 6.008388] msm_dpu ae01000.display-controller: >> [drm:msm_drm_kms_init [msm]] *ERROR* kms hw init failed: -16 >> >> and this can also manifest itself as a NULL-pointer dereference: >> >> [ 7.339447] Unable to handle kernel NULL pointer dereference at >> virtual address >> >> [ 7.643705] pc : drm_bridge_attach+0x70/0x1a8 [drm] >> [ 7.686415] lr : drm_aux_bridge_attach+0x24/0x38 [aux_bridge] >> >> [ 7.769039] Call trace: >> [ 7.771564] drm_bridge_attach+0x70/0x1a8 [drm] >> [ 7.776234] drm_aux_bridge_attach+0x24/0x38 [aux_bridge] >> [ 7.781782] drm_bridge_attach+0x80/0x1a8 [drm] >> [ 7.786454] dp_bridge_init+0xa8/0x15c [msm] >> [ 7.790856] msm_dp_modeset_init+0x28/0xc4 [msm] >> [ 7.795617] _dpu_kms_drm_obj_init+0x19c/0x680 [msm] >> [ 7.800731] dpu_kms_hw_init+0x348/0x4c4 [msm] >> [ 7.805306] msm_drm_kms_init+0x84/0x324 [msm] >> [ 7.809891] msm_drm_bind+0x1d8/0x3a8 [msm] >> [ 7.814196] try_to_bring_up_aggregate_device+0x1f0/0x2f8 >> [ 7.819747] __component_add+0xa4/0x18c >> [ 7.823703] component_add+0x14/0x20 >> [ 7.827389] dp_display_probe+0x47c/0x568 [msm] >> [ 7.832052] platform_probe+0x68/0xd8 >> >> Users have also reported random crashes at boot since 6.8-rc1, and I've >> been able to trigger hard crashes twice when testing an external display >> (USB-C/DP), which may also be related to the DP regressions. >> >> I've opened an issue here: >> >> https://gitlab.freedesktop.org/drm/msm/-/issues/51 >> >> but I also want Thorsten's help to track this so that it gets fixed >> before 6.8 is released. >> >> #regzbot introduced: v6.7..v6.8-rc1 >> >> The following series is likely the culprit: >> >> >> https://lore.kernel.org/all/1701472789-25951-1-git-send-email-quic_khs...@quicinc.com/ >> >> Johan > >
