Re: [PATCH] arm64: dts: qcom: sm6115: fix USB PHY configuration
On 20/02/2024 22:23, Konrad Dybcio wrote:
> On 20.02.2024 18:31, Dmitry Baryshkov wrote:
>> The patch adding Type-C support for sm6115 was misapplied. All the
>> orientation switch configuration ended up at the UFS PHY node instead of
>> the USB PHY node. Move the data bits to the correct place.
>>
>> Fixes: a06a2f12f9e2 ("arm64: dts: qcom: qrb4210-rb2: enable USB-C port
>> handling")
>> Signed-off-by: Dmitry Baryshkov
>> ---
>
> So that's why UFS stopped working and I couldn't for the life of
> me guess why..
We discussed such cases in the past, because it is not the first (it's
3rd or 4th within last 1 - 1.5 years). I believe Bjorn should reject
patches which do not apply cleanly and ask to resubmit.
Mis-applied patch might cause issues which are tricky to debug.
Best regards,
Krzysztof
Re: [PATCH v14 7/7] phy: freescale: Add HDMI PHY driver for i.MX8MQ
Hi Alexander, Thanks for your comments, > > Hi, > > thanks for the update. > > Am Dienstag, 20. Februar 2024, 04:23:55 CET schrieb Sandor Yu: > > Add Cadence HDP-TX HDMI PHY driver for i.MX8MQ. > > > > Cadence HDP-TX PHY could be put in either DP mode or HDMI mode base > on > > the configuration chosen. > > HDMI PHY mode is configurated in the driver. > > > > Signed-off-by: Sandor Yu > > Tested-by: Alexander Stein > > This still works as before. I noticed there is a lot of code duplication with > patch 6. IMHO these PHY drivers should be merged into a single one where > the mode is configured using phy_set_mode() from cdns-mhdp8501-core.c. > This nicely matches my concerns regarding patch 5. > Yes, there are some registers offset are same and the clock management function could be reused for DP and HDMI PHY driver. But because of HDMI and DP PHY totally different work mode, the functions in struct phy_ops, Such as ->init, ->power_on/off and ->configure could not combine into a single one, So separate DP and HDMI PHY driver should be a better resolution. B.R Sandor > Best regards, > Alexander > > > --- > > v13->v14: > > *No change. > > > > v12->v13: > > - Fix build warning > > > > v11->v12: > > - Adjust clk disable order. > > - Return error code to replace -1 for function wait_for_ack(). > > - Use bool for variable pclk_in. > > - Add year 2024 to copyright. > > > > drivers/phy/freescale/Kconfig | 10 + > > drivers/phy/freescale/Makefile | 1 + > > drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c | 960 > > > > 3 files changed, 971 insertions(+) > > create mode 100644 drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c > > > > diff --git a/drivers/phy/freescale/Kconfig > > b/drivers/phy/freescale/Kconfig index c39709fd700ac..14f47b7cc77ab > > 100644 > > --- a/drivers/phy/freescale/Kconfig > > +++ b/drivers/phy/freescale/Kconfig > > @@ -45,6 +45,16 @@ config PHY_FSL_IMX8MQ_DP > > Enable this to support the Cadence HDPTX DP PHY driver > > on i.MX8MQ SOC. > > > > +config PHY_FSL_IMX8MQ_HDMI > > + tristate "Freescale i.MX8MQ HDMI PHY support" > > + depends on OF && HAS_IOMEM > > + depends on COMMON_CLK > > + select GENERIC_PHY > > + select CDNS_MHDP_HELPER > > + help > > + Enable this to support the Cadence HDPTX HDMI PHY driver > > + on i.MX8MQ SOC. > > + > > endif > > > > config PHY_FSL_LYNX_28G > > diff --git a/drivers/phy/freescale/Makefile > > b/drivers/phy/freescale/Makefile index 47e5285209fa8..1380ac31c2ead > > 100644 > > --- a/drivers/phy/freescale/Makefile > > +++ b/drivers/phy/freescale/Makefile > > @@ -1,5 +1,6 @@ > > # SPDX-License-Identifier: GPL-2.0-only > > obj-$(CONFIG_PHY_FSL_IMX8MQ_DP) += > phy-fsl-imx8mq-dp.o > > +obj-$(CONFIG_PHY_FSL_IMX8MQ_HDMI)+= phy-fsl-imx8mq-hdmi.o > > obj-$(CONFIG_PHY_FSL_IMX8MQ_USB) += phy-fsl-imx8mq-usb.o > > obj-$(CONFIG_PHY_MIXEL_LVDS_PHY) += phy-fsl-imx8qm-lvds-phy.o > > obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)+= phy-fsl-imx8-mipi-dphy.o > > diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c > > b/drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c > > new file mode 100644 > > index 0..537b1f45c91cc > > --- /dev/null > > +++ b/drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c > > @@ -0,0 +1,960 @@ > > +// SPDX-License-Identifier: GPL-2.0-only > > +/* > > + * Cadence High-Definition Multimedia Interface (HDMI) PHY driver > > + * > > + * Copyright (C) 2022-2024 NXP Semiconductor, Inc. > > + */ > > +#include > > +#include #include > > +#include #include #include > > + #include > > + > > +#define ADDR_PHY_AFE 0x8 > > + > > +/* PHY registers */ > > +#define CMN_SSM_BIAS_TMR 0x0022 > > +#define CMN_PLLSM0_USER_DEF_CTRL 0x002f > > +#define CMN_PSM_CLK_CTRL 0x0061 > > +#define CMN_CDIAG_REFCLK_CTRL0x0062 > > +#define CMN_PLL0_VCOCAL_START0x0081 > > +#define CMN_PLL0_VCOCAL_INIT_TMR 0x0084 > > +#define CMN_PLL0_VCOCAL_ITER_TMR 0x0085 > > +#define CMN_TXPUCAL_CTRL 0x00e0 > > +#define CMN_TXPDCAL_CTRL 0x00f0 > > +#define CMN_TXPU_ADJ_CTRL0x0108 > > +#define CMN_TXPD_ADJ_CTRL0x010c > > +#define CMN_DIAG_PLL0_FBH_OVRD 0x01c0 > > +#define CMN_DIAG_PLL0_FBL_OVRD 0x01c1 > > +#define CMN_DIAG_PLL0_OVRD 0x01c2 > > +#define CMN_DIAG_PLL0_TEST_MODE 0x01c4 > > +#define CMN_DIAG_PLL0_V2I_TUNE 0x01c5 > > +#define CMN_DIAG_PLL0_CP_TUNE0x01c6 > > +#define CMN_DIAG_PLL0_LF_PROG0x01c7 > > +#define CMN_DIAG_PLL0_PTATIS_TUNE1 0x01c8 > > +#define CMN_DIAG_PLL0_PTATIS_TUNE2 0x01c9 > > +#define CMN_DIAG_PLL0_INCLK_CTRL 0x01ca > > +#define CMN_DIAG_PLL0_PXL_DIVH
Re: [PATCH v14 5/7] dt-bindings: phy: Add Freescale iMX8MQ DP and HDMI PHY
Hi Alexander,
Thanks for your comments,
>
>
> Hi,
>
> thanks for the update.
>
> Am Dienstag, 20. Februar 2024, 04:23:53 CET schrieb Sandor Yu:
> > Add bindings for Freescale iMX8MQ DP and HDMI PHY.
> >
> > Signed-off-by: Sandor Yu
> > Reviewed-by: Rob Herring
> > ---
> > v9->v14:
> > *No change.
> >
> > .../bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml | 53
> > +++
> > 1 file changed, 53 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml
> > b/Documentation/devicetree/bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml
> > new file mode 100644
> > index 0..917f113503dca
> > --- /dev/null
> > +++
> b/Documentation/devicetree/bindings/phy/fsl,imx8mq-dp-hdmi-phy.yam
> > +++ l
> > @@ -0,0 +1,53 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id:
> > +http://devi/
> >
> +cetree.org%2Fschemas%2Fphy%2Ffsl%2Cimx8mq-dp-hdmi-phy.yaml%23
> ta=05
> >
> +%7C02%7CSandor.yu%40nxp.com%7Ce79b4d15c204494963c508dc31fbab5d
> %7C686e
> >
> +a1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638440204190687801%7C
> Unknown%7
> >
> +CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw
> iLCJX
> >
> +VCI6Mn0%3D%7C0%7C%7C%7C=rKWiYc1wbOvKMO%2BWnvT6agxo
> 9V%2B1ndZVTxh
> > +gLT0g7h8%3D=0
> > +$schema:
> > +http://devi/
> >
> +cetree.org%2Fmeta-schemas%2Fcore.yaml%23=05%7C02%7CSandor.y
> u%40n
> >
> +xp.com%7Ce79b4d15c204494963c508dc31fbab5d%7C686ea1d3bc2b4c6fa9
> 2cd99c5
> >
> +c301635%7C0%7C0%7C638440204190709341%7CUnknown%7CTWFpbGZsb
> 3d8eyJWIjoi
> >
> +MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0
> %7C%7C%
> >
> +7C=%2FuCSz0aVVsRLorOqrorbZIyT7iU5BavPKCbA9qL9qDI%3D
> ed=0
> > +
> > +title: Cadence HDP-TX DP/HDMI PHY for Freescale i.MX8MQ SoC
> > +
> > +maintainers:
> > + - Sandor Yu
> > +
> > +properties:
> > + compatible:
> > +enum:
> > + - fsl,imx8mq-dp-phy
> > + - fsl,imx8mq-hdmi-phy
>
> While reading cdns-mhdp8501-core.c I'm not so sure about this. There is only
> a single PHY which can be configured for either DP or HDMI.
> Using separate compatibles for that somehow bugs me.
> Maybe the DT maintainers can add some input if this should be single or
> double compatibles.
>
When user enable MHDP8501 HDMI or DP, he should clearly know which type he want
to enable,
>From board type, flash.bin(firmware) to dts(connector and phy type), they are
>all need align to HDMI or DP.
B.R
Sandor
> Thanks and best regards,
> Alexander
>
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + clocks:
> > +items:
> > + - description: PHY reference clock.
> > + - description: APB clock.
> > +
> > + clock-names:
> > +items:
> > + - const: ref
> > + - const: apb
> > +
> > + "#phy-cells":
> > +const: 0
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - clock-names
> > + - "#phy-cells"
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +#include
> > +dp_phy: phy@32c0 {
> > +compatible = "fsl,imx8mq-dp-phy";
> > +reg = <0x32c0 0x10>;
> > +#phy-cells = <0>;
> > +clocks = <_phy_27m>, <
> IMX8MQ_CLK_DISP_APB_ROOT>;
> > +clock-names = "ref", "apb";
> > +};
> >
>
>
> --
> TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> Amtsgericht München, HRB 105018
> Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
> http://www.tq-/
> group.com%2F=05%7C02%7CSandor.yu%40nxp.com%7Ce79b4d15c2044
> 94963c508dc31fbab5d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
> %7C638440204190726471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7
> C=7xs1%2FC%2BK1cSFDc3rlBEZdNBsYw6Gc8AR6CWr2Djz4s0%3D
> erved=0
>
[PATCH] drm/ttm: Fix an invalid freeing on already freed page in error path
If caching mode change fails due to, for example, OOM we
free the allocated pages in a two-step process. First the pages
for which the caching change has already succeeded. Secondly
the pages for which a caching change did not succeed.
However the second step was incorrectly freeing the pages already
freed in the first step.
Fix.
Signed-off-by: Thomas Hellström
Fixes: 379989e7cbdc ("drm/ttm/pool: Fix ttm_pool_alloc error path")
Cc: Christian König
Cc: Dave Airlie
Cc: Christian Koenig
Cc: Huang Rui
Cc: dri-devel@lists.freedesktop.org
Cc: # v6.4+
---
drivers/gpu/drm/ttm/ttm_pool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index b62f420a9f96..112438d965ff 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -387,7 +387,7 @@ static void ttm_pool_free_range(struct ttm_pool *pool,
struct ttm_tt *tt,
enum ttm_caching caching,
pgoff_t start_page, pgoff_t end_page)
{
- struct page **pages = tt->pages;
+ struct page **pages = >pages[start_page];
unsigned int order;
pgoff_t i, nr;
--
2.43.0
Re: [PATCH] drm/xe: skip building debugfs code for CONFIG_DEBUG_FS=n
Hi Lucas, On Tue, 20 Feb 2024 23:29:54 -0600 Lucas De Marchi wrote: > > Looking at > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=2d5c7b7eb345249cb34d42cbc2b97b4c57ea944e > it seems we still don't have drm-xe-next branch in linux-next. > > Stephen, could you please add it? Or do I have to do something on my end > before that? This is the branch: > > https://gitlab.freedesktop.org/drm/xe/kernel drm-xe-next Added from tomorrow. Currently the only contact is yourself. Do you want anyone else (or a mailing list) as well? Do you want the drm-xe-fixes branch included as well? Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgement of your code. The purpose of linux-next is for integration testing and to lower the impact of conflicts between subsystems in the next merge window. You will need to ensure that the patches/commits in your tree/series have been: * submitted under GPL v2 (or later) and include the Contributor's Signed-off-by, * posted to the relevant mailing list, * reviewed by you (or another maintainer of your subsystem tree), * successfully unit tested, and * destined for the current or next Linux merge window. Basically, this should be just what you would send to Linus (or ask him to fetch). It is allowed to be rebased if you deem it necessary. -- Cheers, Stephen Rothwell s...@canb.auug.org.au pgpbO8N1V04Uy.pgp Description: OpenPGP digital signature
[linux-next:master] BUILD REGRESSION 2d5c7b7eb345249cb34d42cbc2b97b4c57ea944e
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 2d5c7b7eb345249cb34d42cbc2b97b4c57ea944e Add linux-next specific files for 20240220 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202402210011.c42qmsp5-...@intel.com Error/Warning: (recently discovered and may have been fixed) arch/x86/entry/entry_fred.c:117:9: error: use of undeclared identifier 'POSTED_INTR_VECTOR' arch/x86/entry/entry_fred.c:118:9: error: use of undeclared identifier 'POSTED_INTR_WAKEUP_VECTOR' arch/x86/entry/entry_fred.c:119:9: error: use of undeclared identifier 'POSTED_INTR_NESTED_VECTOR' Unverified Error/Warning (likely false positive, please contact us if interested): mm/userfaultfd.c:740 mfill_atomic() warn: inconsistent returns '>map_changing_lock'. Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | `-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- alpha-randconfig-r062-20240220 | `-- fs-ntfs3-frecord.c:warning:unused-variable-i_size |-- arc-allmodconfig | `-- 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-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- arc-randconfig-002-20240220 | `-- fs-ntfs3-frecord.c:warning:unused-variable-i_size |-- arm-allmodconfig | `-- 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-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- arm-randconfig-004-20240220 | `-- fs-ntfs3-frecord.c:warning:unused-variable-i_size |-- 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 |-- arm64-randconfig-r131-20240220 | `-- io_uring-io_uring.c:sparse:sparse:cast-to-restricted-io_req_flags_t |-- csky-allmodconfig | `-- 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-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- csky-randconfig-001-20240220 | `-- fs-ntfs3-frecord.c:warning:unused-variable-i_size |-- csky-randconfig-r113-20240220 | |-- include-trace-..-..-drivers-bus-mhi-host-trace.h:sparse:sparse:cast-to-restricted-__le32 | |-- include-trace-..-..-drivers-bus-mhi-host-trace.h:sparse:sparse:cast-to-restricted-__le64 | |-- include-trace-..-..-drivers-bus-mhi-host-trace.h:sparse:sparse:restricted-__le32-degrades-to-integer | |-- include-trace-..-..-drivers-bus-mhi-host-trace.h:sparse:sparse:restricted-__le64-degrades-to-integer | `-- io_uring-io_uring.c:sparse:sparse:cast-to-restricted-io_req_flags_t |-- i386-allmodconfig | `-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- i386-allyesconfig | `-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- i386-buildonly-randconfig-001-20240220 | `-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- i386-randconfig-002-20240220 | `-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- i386-randconfig-012-20240220 | |-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg | `-- fs-ntfs3-frecord.c:warning:unused-variable-i_size |-- i386-randconfig-013-20240220 | `-- fs-ntfs3-frecord.c:warning:unused-variable-i_size |-- i386-randconfig-063-20240220 | |-- include-trace-..-..-drivers-bus-mhi-host-trace.h:sparse:sparse:cast-to-restricted-__le32 | |-- include-trace-..-..-drivers-bus-mhi-host-trace.h:sparse:sparse:cast-to-restricted-__le64 | |-- include-trace-..-..-drivers-bus-mhi-host-trace.h:sparse:sparse:restricted-__le32-degrades-to-integer | |-- include-trace-..-..-drivers-bus-mhi-host-trace.h:sparse:sparse:restricted-__le64-degrades-to-integer | `-- io_uring-io_uring.c:sparse:sparse:cast-to-restricted-io_req_flags_t |-- loongarch-allmodconfig | `-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- loongarch-randconfig-001-20240220 | |-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-mem
[PATCH v8 7/7] drm: atmel-hlcdc: add LCD controller layer definition for sam9x75
Add the LCD controller layer definition and descriptor structure for
sam9x75 for the following layers:
- Base Layer
- Overlay1 Layer
- Overlay2 Layer
- High End Overlay
Signed-off-by: Manikandan Muralidharan
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 100 +++
1 file changed, 100 insertions(+)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index b09df821cbc0..9ce429f889ca 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -467,6 +467,102 @@ static const struct atmel_hlcdc_dc_desc
atmel_hlcdc_dc_sam9x60 = {
.ops = _hlcdc_ops,
};
+static const struct atmel_hlcdc_layer_desc atmel_xlcdc_sam9x75_layers[] = {
+ {
+ .name = "base",
+ .formats = _hlcdc_plane_rgb_formats,
+ .regs_offset = 0x60,
+ .id = 0,
+ .type = ATMEL_HLCDC_BASE_LAYER,
+ .cfgs_offset = 0x1c,
+ .layout = {
+ .xstride = { 2 },
+ .default_color = 3,
+ .general_config = 4,
+ .disc_pos = 5,
+ .disc_size = 6,
+ },
+ .clut_offset = 0x700,
+ },
+ {
+ .name = "overlay1",
+ .formats = _hlcdc_plane_rgb_formats,
+ .regs_offset = 0x160,
+ .id = 1,
+ .type = ATMEL_HLCDC_OVERLAY_LAYER,
+ .cfgs_offset = 0x1c,
+ .layout = {
+ .pos = 2,
+ .size = 3,
+ .xstride = { 4 },
+ .pstride = { 5 },
+ .default_color = 6,
+ .chroma_key = 7,
+ .chroma_key_mask = 8,
+ .general_config = 9,
+ },
+ .clut_offset = 0xb00,
+ },
+ {
+ .name = "overlay2",
+ .formats = _hlcdc_plane_rgb_formats,
+ .regs_offset = 0x260,
+ .id = 2,
+ .type = ATMEL_HLCDC_OVERLAY_LAYER,
+ .cfgs_offset = 0x1c,
+ .layout = {
+ .pos = 2,
+ .size = 3,
+ .xstride = { 4 },
+ .pstride = { 5 },
+ .default_color = 6,
+ .chroma_key = 7,
+ .chroma_key_mask = 8,
+ .general_config = 9,
+ },
+ .clut_offset = 0xf00,
+ },
+ {
+ .name = "high-end-overlay",
+ .formats = _hlcdc_plane_rgb_and_yuv_formats,
+ .regs_offset = 0x360,
+ .id = 3,
+ .type = ATMEL_HLCDC_OVERLAY_LAYER,
+ .cfgs_offset = 0x30,
+ .layout = {
+ .pos = 2,
+ .size = 3,
+ .memsize = 4,
+ .xstride = { 5, 7 },
+ .pstride = { 6, 8 },
+ .default_color = 9,
+ .chroma_key = 10,
+ .chroma_key_mask = 11,
+ .general_config = 12,
+ .csc = 16,
+ .scaler_config = 23,
+ .vxs_config = 30,
+ .hxs_config = 31,
+ },
+ .clut_offset = 0x1300,
+ },
+};
+
+static const struct atmel_hlcdc_dc_desc atmel_xlcdc_dc_sam9x75 = {
+ .min_width = 0,
+ .min_height = 0,
+ .max_width = 2048,
+ .max_height = 2048,
+ .max_spw = 0x3ff,
+ .max_vpw = 0x3ff,
+ .max_hpw = 0x3ff,
+ .fixed_clksrc = true,
+ .is_xlcdc = true,
+ .nlayers = ARRAY_SIZE(atmel_xlcdc_sam9x75_layers),
+ .layers = atmel_xlcdc_sam9x75_layers,
+ .ops = _xlcdc_ops,
+};
+
static const struct of_device_id atmel_hlcdc_of_match[] = {
{
.compatible = "atmel,at91sam9n12-hlcdc",
@@ -492,6 +588,10 @@ static const struct of_device_id atmel_hlcdc_of_match[] = {
.compatible = "microchip,sam9x60-hlcdc",
.data = _hlcdc_dc_sam9x60,
},
+ {
+ .compatible = "microchip,sam9x75-xlcdc",
+ .data = _xlcdc_dc_sam9x75,
+ },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, atmel_hlcdc_of_match);
--
2.25.1
[PATCH v8 6/7] drm: atmel-hlcdc: add support for DSI output formats
Add support for the following DPI mode if the encoder type
is DSI as per the XLCDC IP datasheet:
- 16BPPCFG1
- 16BPPCFG2
- 16BPPCFG3
- 18BPPCFG1
- 18BPPCFG2
- 24BPP
Signed-off-by: Manikandan Muralidharan
[durai.manicka...@microchip.com: update output format using is_xlcdc flag]
Signed-off-by: Durai Manickam KR
---
.../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 74 +--
1 file changed, 68 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index fdd3a6bc0f79..0dbe85686fc2 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -301,11 +301,64 @@ static void atmel_hlcdc_crtc_atomic_enable(struct
drm_crtc *c,
}
-#define ATMEL_HLCDC_RGB444_OUTPUT BIT(0)
-#define ATMEL_HLCDC_RGB565_OUTPUT BIT(1)
-#define ATMEL_HLCDC_RGB666_OUTPUT BIT(2)
-#define ATMEL_HLCDC_RGB888_OUTPUT BIT(3)
-#define ATMEL_HLCDC_OUTPUT_MODE_MASK GENMASK(3, 0)
+#define ATMEL_HLCDC_RGB444_OUTPUT BIT(0)
+#define ATMEL_HLCDC_RGB565_OUTPUT BIT(1)
+#define ATMEL_HLCDC_RGB666_OUTPUT BIT(2)
+#define ATMEL_HLCDC_RGB888_OUTPUT BIT(3)
+#define ATMEL_HLCDC_DPI_RGB565C1_OUTPUTBIT(4)
+#define ATMEL_HLCDC_DPI_RGB565C2_OUTPUTBIT(5)
+#define ATMEL_HLCDC_DPI_RGB565C3_OUTPUTBIT(6)
+#define ATMEL_HLCDC_DPI_RGB666C1_OUTPUTBIT(7)
+#define ATMEL_HLCDC_DPI_RGB666C2_OUTPUTBIT(8)
+#define ATMEL_HLCDC_DPI_RGB888_OUTPUT BIT(9)
+#define ATMEL_HLCDC_OUTPUT_MODE_MASK GENMASK(3, 0)
+#define ATMEL_XLCDC_OUTPUT_MODE_MASK GENMASK(9, 0)
+
+static int atmel_hlcdc_connector_output_dsi(struct drm_encoder *encoder,
+ struct drm_display_info *info)
+{
+ int j;
+ unsigned int supported_fmts = 0;
+
+ switch (atmel_hlcdc_encoder_get_bus_fmt(encoder)) {
+ case 0:
+ break;
+ case MEDIA_BUS_FMT_RGB565_1X16:
+ return ATMEL_HLCDC_DPI_RGB565C1_OUTPUT;
+ case MEDIA_BUS_FMT_RGB666_1X18:
+ return ATMEL_HLCDC_DPI_RGB666C1_OUTPUT;
+ case MEDIA_BUS_FMT_RGB666_1X24_CPADHI:
+ return ATMEL_HLCDC_DPI_RGB666C2_OUTPUT;
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ return ATMEL_HLCDC_DPI_RGB888_OUTPUT;
+ default:
+ return -EINVAL;
+ }
+
+ for (j = 0; j < info->num_bus_formats; j++) {
+ switch (info->bus_formats[j]) {
+ case MEDIA_BUS_FMT_RGB565_1X16:
+ supported_fmts |=
+ ATMEL_HLCDC_DPI_RGB565C1_OUTPUT;
+ break;
+ case MEDIA_BUS_FMT_RGB666_1X18:
+ supported_fmts |=
+ ATMEL_HLCDC_DPI_RGB666C1_OUTPUT;
+ break;
+ case MEDIA_BUS_FMT_RGB666_1X24_CPADHI:
+ supported_fmts |=
+ ATMEL_HLCDC_DPI_RGB666C2_OUTPUT;
+ break;
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ supported_fmts |=
+ ATMEL_HLCDC_DPI_RGB888_OUTPUT;
+ break;
+ default:
+ break;
+ }
+ }
+ return supported_fmts;
+}
static int atmel_hlcdc_connector_output_mode(struct drm_connector_state *state)
{
@@ -318,6 +371,13 @@ static int atmel_hlcdc_connector_output_mode(struct
drm_connector_state *state)
encoder = state->best_encoder;
if (!encoder)
encoder = connector->encoder;
+ /*
+* atmel-hlcdc to support DSI formats with DSI video pipeline
+* when DRM_MODE_ENCODER_DSI type is set by
+* connector driver component.
+*/
+ if (encoder->encoder_type == DRM_MODE_ENCODER_DSI)
+ return atmel_hlcdc_connector_output_dsi(encoder, info);
switch (atmel_hlcdc_encoder_get_bus_fmt(encoder)) {
case 0:
@@ -358,7 +418,7 @@ static int atmel_hlcdc_connector_output_mode(struct
drm_connector_state *state)
static int atmel_hlcdc_crtc_select_output_mode(struct drm_crtc_state *state)
{
- unsigned int output_fmts = ATMEL_HLCDC_OUTPUT_MODE_MASK;
+ unsigned int output_fmts;
struct atmel_hlcdc_crtc_state *hstate;
struct drm_connector_state *cstate;
struct drm_connector *connector;
@@ -366,6 +426,8 @@ static int atmel_hlcdc_crtc_select_output_mode(struct
drm_crtc_state *state)
int i;
crtc = drm_crtc_to_atmel_hlcdc_crtc(state->crtc);
+ output_fmts = crtc->dc->desc->is_xlcdc ? ATMEL_XLCDC_OUTPUT_MODE_MASK :
+ ATMEL_HLCDC_OUTPUT_MODE_MASK;
for_each_new_connector_in_state(state->state, connector, cstate, i) {
unsigned int
[PATCH v8 5/7] drm: atmel-hlcdc: add vertical and horizontal scaling support for XLCDC
Update the vertical and horizontal scaler registers of XLCDC IP
with Bilinear and Bicubic co-efficients taps for Chroma and
Luma componenets of the Pixel.
Signed-off-by: Manikandan Muralidharan
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 4
.../gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 20 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
index 777987b7873d..fd9d9af4332c 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
@@ -198,6 +198,8 @@
* @disc_pos: discard area position register
* @disc_size: discard area size register
* @csc: color space conversion register
+ * @vxs_config: vertical scalar filter taps control register
+ * @hxs_config: horizontal scalar filter taps control register
*/
struct atmel_hlcdc_layer_cfg_layout {
int xstride[ATMEL_HLCDC_LAYER_MAX_PLANES];
@@ -217,6 +219,8 @@ struct atmel_hlcdc_layer_cfg_layout {
int disc_pos;
int disc_size;
int csc;
+ int vxs_config;
+ int hxs_config;
};
/**
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index 59ddd743ce92..a527badf865d 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -966,6 +966,26 @@ static void xlcdc_csc_init(struct atmel_hlcdc_plane *plane,
desc->layout.csc + i,
xlcdc_csc_coeffs[i]);
}
+
+ if (desc->layout.vxs_config && desc->layout.hxs_config) {
+ /*
+* Updating vxs.config and hxs.config fixes the
+* Green Color Issue in SAM9X7 EGT Video Player App
+*/
+ atmel_hlcdc_layer_write_cfg(>layer,
+ desc->layout.vxs_config,
+ ATMEL_XLCDC_LAYER_VXSYCFG_ONE |
+ ATMEL_XLCDC_LAYER_VXSYTAP2_ENABLE |
+ ATMEL_XLCDC_LAYER_VXSCCFG_ONE |
+ ATMEL_XLCDC_LAYER_VXSCTAP2_ENABLE);
+
+ atmel_hlcdc_layer_write_cfg(>layer,
+ desc->layout.hxs_config,
+ ATMEL_XLCDC_LAYER_HXSYCFG_ONE |
+ ATMEL_XLCDC_LAYER_HXSYTAP2_ENABLE |
+ ATMEL_XLCDC_LAYER_HXSCCFG_ONE |
+ ATMEL_XLCDC_LAYER_HXSCTAP2_ENABLE);
+ }
}
static int atmel_hlcdc_plane_init_properties(struct atmel_hlcdc_plane *plane)
--
2.25.1
[PATCH v8 4/7] drm: atmel-hlcdc: add DPI mode support for XLCDC
Add support for Display Pixel Interface (DPI) Compatible Mode
support in atmel-hlcdc driver for XLCDC IP along with legacy
pixel mapping. DPI mode BIT is configured in LCDC_CFG5 register.
Signed-off-by: Manikandan Muralidharan
[durai.manicka...@microchip.com: update DPI mode bit using is_xlcdc flag]
Signed-off-by: Durai Manickam KR
---
.../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 21 +--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 98a98b5fca85..fdd3a6bc0f79 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -30,10 +30,12 @@
*
* @base: base CRTC state
* @output_mode: RGBXXX output mode
+ * @dpi: output DPI mode
*/
struct atmel_hlcdc_crtc_state {
struct drm_crtc_state base;
unsigned int output_mode;
+ u8 dpi;
};
static inline struct atmel_hlcdc_crtc_state *
@@ -170,6 +172,8 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc
*c)
if (adj->flags & DRM_MODE_FLAG_NHSYNC)
cfg |= ATMEL_HLCDC_HSPOL;
+ } else {
+ cfg |= state->dpi << 11;
}
regmap_update_bits(regmap, ATMEL_HLCDC_CFG(5),
@@ -177,7 +181,9 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc
*c)
ATMEL_HLCDC_VSPDLYS | ATMEL_HLCDC_VSPDLYE |
ATMEL_HLCDC_DISPPOL | ATMEL_HLCDC_DISPDLY |
ATMEL_HLCDC_VSPSU | ATMEL_HLCDC_VSPHO |
- ATMEL_HLCDC_GUARDTIME_MASK | ATMEL_HLCDC_MODE_MASK,
+ ATMEL_HLCDC_GUARDTIME_MASK |
+ (crtc->dc->desc->is_xlcdc ? ATMEL_XLCDC_MODE_MASK |
+ ATMEL_XLCDC_DPI : ATMEL_HLCDC_MODE_MASK),
cfg);
clk_disable_unprepare(crtc->dc->hlcdc->sys_clk);
@@ -380,7 +386,15 @@ static int atmel_hlcdc_crtc_select_output_mode(struct
drm_crtc_state *state)
hstate = drm_crtc_state_to_atmel_hlcdc_crtc_state(state);
hstate->output_mode = fls(output_fmts) - 1;
-
+ if (crtc->dc->desc->is_xlcdc) {
+ /* check if MIPI DPI bit needs to be set */
+ if (fls(output_fmts) > 3) {
+ hstate->output_mode -= 4;
+ hstate->dpi = 1;
+ } else {
+ hstate->dpi = 0;
+ }
+ }
return 0;
}
@@ -484,6 +498,7 @@ static struct drm_crtc_state *
atmel_hlcdc_crtc_duplicate_state(struct drm_crtc *crtc)
{
struct atmel_hlcdc_crtc_state *state, *cur;
+ struct atmel_hlcdc_crtc *c = drm_crtc_to_atmel_hlcdc_crtc(crtc);
if (WARN_ON(!crtc->state))
return NULL;
@@ -495,6 +510,8 @@ atmel_hlcdc_crtc_duplicate_state(struct drm_crtc *crtc)
cur = drm_crtc_state_to_atmel_hlcdc_crtc_state(crtc->state);
state->output_mode = cur->output_mode;
+ if (c->dc->desc->is_xlcdc)
+ state->dpi = cur->dpi;
return >base;
}
--
2.25.1
[PATCH v8 3/7] drm: atmel_hlcdc: Add support for XLCDC using IP specific driver ops
Add XLCDC specific driver ops and is_xlcdc flag to separate the
functionality and to access the controller registers.
HEO scaling, window resampling, Alpha blending, YUV-to-RGB
conversion in XLCDC is derived and handled using additional
configuration bits and registers. Writing one to the Enable fields
of each layer in LCD_ATTRE is required to reflect the values set
in Configuration, FBA, Enable registers of each layer.
Signed-off-by: Manikandan Muralidharan
Co-developed-by: Hari Prasath Gujulan Elango
Signed-off-by: Hari Prasath Gujulan Elango
Co-developed-by: Durai Manickam KR
Signed-off-by: Durai Manickam KR
---
.../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 81 +---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 3 +
.../gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 182 +-
3 files changed, 242 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index cc5cf4c2faf7..98a98b5fca85 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -164,11 +164,13 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct
drm_crtc *c)
state = drm_crtc_state_to_atmel_hlcdc_crtc_state(c->state);
cfg = state->output_mode << 8;
- if (adj->flags & DRM_MODE_FLAG_NVSYNC)
- cfg |= ATMEL_HLCDC_VSPOL;
+ if (!crtc->dc->desc->is_xlcdc) {
+ if (adj->flags & DRM_MODE_FLAG_NVSYNC)
+ cfg |= ATMEL_HLCDC_VSPOL;
- if (adj->flags & DRM_MODE_FLAG_NHSYNC)
- cfg |= ATMEL_HLCDC_HSPOL;
+ if (adj->flags & DRM_MODE_FLAG_NHSYNC)
+ cfg |= ATMEL_HLCDC_HSPOL;
+ }
regmap_update_bits(regmap, ATMEL_HLCDC_CFG(5),
ATMEL_HLCDC_HSPOL | ATMEL_HLCDC_VSPOL |
@@ -202,20 +204,37 @@ static void atmel_hlcdc_crtc_atomic_disable(struct
drm_crtc *c,
pm_runtime_get_sync(dev->dev);
+ if (crtc->dc->desc->is_xlcdc) {
+ regmap_write(regmap, ATMEL_HLCDC_DIS, ATMEL_XLCDC_CM);
+ if (regmap_read_poll_timeout(regmap, ATMEL_HLCDC_SR, status,
+!(status & ATMEL_XLCDC_CM),
+10, 1000))
+ dev_warn(dev->dev, "Atmel LCDC status register CMSTS
timeout\n");
+
+ regmap_write(regmap, ATMEL_HLCDC_DIS, ATMEL_XLCDC_SD);
+ if (regmap_read_poll_timeout(regmap, ATMEL_HLCDC_SR, status,
+status & ATMEL_XLCDC_SD,
+10, 1000))
+ dev_warn(dev->dev, "Atmel LCDC status register SDSTS
timeout\n");
+ }
+
regmap_write(regmap, ATMEL_HLCDC_DIS, ATMEL_HLCDC_DISP);
- while (!regmap_read(regmap, ATMEL_HLCDC_SR, ) &&
- (status & ATMEL_HLCDC_DISP))
- cpu_relax();
+ if (regmap_read_poll_timeout(regmap, ATMEL_HLCDC_SR, status,
+!(status & ATMEL_HLCDC_DISP),
+ 10, 1000))
+ dev_warn(dev->dev, "Atmel LCDC status register DISPSTS
timeout\n");
regmap_write(regmap, ATMEL_HLCDC_DIS, ATMEL_HLCDC_SYNC);
- while (!regmap_read(regmap, ATMEL_HLCDC_SR, ) &&
- (status & ATMEL_HLCDC_SYNC))
- cpu_relax();
+ if (regmap_read_poll_timeout(regmap, ATMEL_HLCDC_SR, status,
+!(status & ATMEL_HLCDC_SYNC),
+ 10, 1000))
+ dev_warn(dev->dev, "Atmel LCDC status register LCDSTS
timeout\n");
regmap_write(regmap, ATMEL_HLCDC_DIS, ATMEL_HLCDC_PIXEL_CLK);
- while (!regmap_read(regmap, ATMEL_HLCDC_SR, ) &&
- (status & ATMEL_HLCDC_PIXEL_CLK))
- cpu_relax();
+ if (regmap_read_poll_timeout(regmap, ATMEL_HLCDC_SR, status,
+!(status & ATMEL_HLCDC_PIXEL_CLK),
+ 10, 1000))
+ dev_warn(dev->dev, "Atmel LCDC status register CLKSTS
timeout\n");
clk_disable_unprepare(crtc->dc->hlcdc->sys_clk);
pinctrl_pm_select_sleep_state(dev->dev);
@@ -241,20 +260,36 @@ static void atmel_hlcdc_crtc_atomic_enable(struct
drm_crtc *c,
clk_prepare_enable(crtc->dc->hlcdc->sys_clk);
regmap_write(regmap, ATMEL_HLCDC_EN, ATMEL_HLCDC_PIXEL_CLK);
- while (!regmap_read(regmap, ATMEL_HLCDC_SR, ) &&
- !(status & ATMEL_HLCDC_PIXEL_CLK))
- cpu_relax();
-
+ if (regmap_read_poll_timeout(regmap, ATMEL_HLCDC_SR, status,
+status & ATMEL_HLCDC_PIXEL_CLK,
+10, 1000))
+ dev_warn(dev->dev, "Atmel LCDC status register CLKSTS
timeout\n");
regmap_write(regmap, ATMEL_HLCDC_EN,
[PATCH v8 2/7] drm: atmel-hlcdc: Define XLCDC specific registers
From: Durai Manickam KR The register address of the XLCDC IP used in SAM9X7 SoC family are different from the previous HLCDC. Defining those address space with valid macros. Signed-off-by: Durai Manickam KR [manikanda...@microchip.com: Remove unused macro definitions] Signed-off-by: Manikandan Muralidharan --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 42 include/linux/mfd/atmel-hlcdc.h | 10 + 2 files changed, 52 insertions(+) diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h index ad732edfef0b..bc70a81b5275 100644 --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h @@ -15,6 +15,7 @@ #include +/* LCD controller common registers */ #define ATMEL_HLCDC_LAYER_CHER 0x0 #define ATMEL_HLCDC_LAYER_CHDR 0x4 #define ATMEL_HLCDC_LAYER_CHSR 0x8 @@ -128,6 +129,47 @@ #define ATMEL_HLCDC_MAX_LAYERS 6 +/* XLCDC controller specific registers */ +#define ATMEL_XLCDC_LAYER_ENR 0x10 +#define ATMEL_XLCDC_LAYER_EN BIT(0) + +#define ATMEL_XLCDC_LAYER_IER 0x0 +#define ATMEL_XLCDC_LAYER_IDR 0x4 +#define ATMEL_XLCDC_LAYER_ISR 0xc +#define ATMEL_XLCDC_LAYER_OVR_IRQ(p) BIT(2 + (8 * (p))) + +#define ATMEL_XLCDC_LAYER_PLANE_ADDR(p)(((p) * 0x4) + 0x18) + +#define ATMEL_XLCDC_LAYER_DMA_CFG 0 + +#define ATMEL_XLCDC_LAYER_DMA BIT(0) +#define ATMEL_XLCDC_LAYER_REP BIT(1) +#define ATMEL_XLCDC_LAYER_DISCEN BIT(4) + +#define ATMEL_XLCDC_LAYER_SFACTC_A0_MULT_AS(4 << 6) +#define ATMEL_XLCDC_LAYER_SFACTA_ONE BIT(9) +#define ATMEL_XLCDC_LAYER_DFACTC_M_A0_MULT_AS (6 << 11) +#define ATMEL_XLCDC_LAYER_DFACTA_ONE BIT(14) + +#define ATMEL_XLCDC_LAYER_A0_SHIFT 16 +#define ATMEL_XLCDC_LAYER_A0(x)\ + ((x) << ATMEL_XLCDC_LAYER_A0_SHIFT) + +#define ATMEL_XLCDC_LAYER_VSCALER_LUMA_ENABLE BIT(0) +#define ATMEL_XLCDC_LAYER_VSCALER_CHROMA_ENABLEBIT(1) +#define ATMEL_XLCDC_LAYER_HSCALER_LUMA_ENABLE BIT(4) +#define ATMEL_XLCDC_LAYER_HSCALER_CHROMA_ENABLEBIT(5) + +#define ATMEL_XLCDC_LAYER_VXSYCFG_ONE BIT(0) +#define ATMEL_XLCDC_LAYER_VXSYTAP2_ENABLE BIT(4) +#define ATMEL_XLCDC_LAYER_VXSCCFG_ONE BIT(16) +#define ATMEL_XLCDC_LAYER_VXSCTAP2_ENABLE BIT(20) + +#define ATMEL_XLCDC_LAYER_HXSYCFG_ONE BIT(0) +#define ATMEL_XLCDC_LAYER_HXSYTAP2_ENABLE BIT(4) +#define ATMEL_XLCDC_LAYER_HXSCCFG_ONE BIT(16) +#define ATMEL_XLCDC_LAYER_HXSCTAP2_ENABLE BIT(20) + /** * Atmel HLCDC Layer registers layout structure * diff --git a/include/linux/mfd/atmel-hlcdc.h b/include/linux/mfd/atmel-hlcdc.h index a186119a49b5..80d675a03b39 100644 --- a/include/linux/mfd/atmel-hlcdc.h +++ b/include/linux/mfd/atmel-hlcdc.h @@ -22,6 +22,8 @@ #define ATMEL_HLCDC_DITHER BIT(6) #define ATMEL_HLCDC_DISPDLYBIT(7) #define ATMEL_HLCDC_MODE_MASK GENMASK(9, 8) +#define ATMEL_XLCDC_MODE_MASK GENMASK(10, 8) +#define ATMEL_XLCDC_DPIBIT(11) #define ATMEL_HLCDC_PP BIT(10) #define ATMEL_HLCDC_VSPSU BIT(12) #define ATMEL_HLCDC_VSPHO BIT(13) @@ -34,6 +36,12 @@ #define ATMEL_HLCDC_IDR0x30 #define ATMEL_HLCDC_IMR0x34 #define ATMEL_HLCDC_ISR0x38 +#define ATMEL_XLCDC_ATTRE 0x3c + +#define ATMEL_XLCDC_BASE_UPDATEBIT(0) +#define ATMEL_XLCDC_OVR1_UPDATEBIT(1) +#define ATMEL_XLCDC_OVR3_UPDATEBIT(2) +#define ATMEL_XLCDC_HEO_UPDATE BIT(3) #define ATMEL_HLCDC_CLKPOL BIT(0) #define ATMEL_HLCDC_CLKSEL BIT(2) @@ -48,6 +56,8 @@ #define ATMEL_HLCDC_DISP BIT(2) #define ATMEL_HLCDC_PWMBIT(3) #define ATMEL_HLCDC_SIPBIT(4) +#define ATMEL_XLCDC_SD BIT(5) +#define ATMEL_XLCDC_CM BIT(6) #define ATMEL_HLCDC_SOFBIT(0) #define ATMEL_HLCDC_SYNCDISBIT(1) -- 2.25.1
[PATCH v8 1/7] drm: atmel-hlcdc: add driver ops to differentiate HLCDC and XLCDC IP
Add LCD IP specific ops in driver data to differentiate
HLCDC and XLCDC code within the atmel-hlcdc driver files.
XLCDC in SAM9X7 has different sets of registers and additional
configuration bits when compared to previous HLCDC IP. Read/write
operation on the controller register and functionality is now
separated using the LCD IP specific ops.
Signed-off-by: Manikandan Muralidharan
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 5 +
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 84 ++---
.../gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 167 +++---
3 files changed, 173 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 84c54e8622d1..b09df821cbc0 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -58,6 +58,7 @@ static const struct atmel_hlcdc_dc_desc
atmel_hlcdc_dc_at91sam9n12 = {
.conflicting_output_formats = true,
.nlayers = ARRAY_SIZE(atmel_hlcdc_at91sam9n12_layers),
.layers = atmel_hlcdc_at91sam9n12_layers,
+ .ops = _hlcdc_ops,
};
static const struct atmel_hlcdc_layer_desc atmel_hlcdc_at91sam9x5_layers[] = {
@@ -151,6 +152,7 @@ static const struct atmel_hlcdc_dc_desc
atmel_hlcdc_dc_at91sam9x5 = {
.conflicting_output_formats = true,
.nlayers = ARRAY_SIZE(atmel_hlcdc_at91sam9x5_layers),
.layers = atmel_hlcdc_at91sam9x5_layers,
+ .ops = _hlcdc_ops,
};
static const struct atmel_hlcdc_layer_desc atmel_hlcdc_sama5d3_layers[] = {
@@ -269,6 +271,7 @@ static const struct atmel_hlcdc_dc_desc
atmel_hlcdc_dc_sama5d3 = {
.conflicting_output_formats = true,
.nlayers = ARRAY_SIZE(atmel_hlcdc_sama5d3_layers),
.layers = atmel_hlcdc_sama5d3_layers,
+ .ops = _hlcdc_ops,
};
static const struct atmel_hlcdc_layer_desc atmel_hlcdc_sama5d4_layers[] = {
@@ -364,6 +367,7 @@ static const struct atmel_hlcdc_dc_desc
atmel_hlcdc_dc_sama5d4 = {
.max_hpw = 0x3ff,
.nlayers = ARRAY_SIZE(atmel_hlcdc_sama5d4_layers),
.layers = atmel_hlcdc_sama5d4_layers,
+ .ops = _hlcdc_ops,
};
static const struct atmel_hlcdc_layer_desc atmel_hlcdc_sam9x60_layers[] = {
@@ -460,6 +464,7 @@ static const struct atmel_hlcdc_dc_desc
atmel_hlcdc_dc_sam9x60 = {
.fixed_clksrc = true,
.nlayers = ARRAY_SIZE(atmel_hlcdc_sam9x60_layers),
.layers = atmel_hlcdc_sam9x60_layers,
+ .ops = _hlcdc_ops,
};
static const struct of_device_id atmel_hlcdc_of_match[] = {
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
index 5b5c774e0edf..ad732edfef0b 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
@@ -288,6 +288,64 @@ atmel_hlcdc_layer_to_plane(struct atmel_hlcdc_layer *layer)
return container_of(layer, struct atmel_hlcdc_plane, layer);
}
+/**
+ * Atmel HLCDC Display Controller.
+ *
+ * @desc: HLCDC Display Controller description
+ * @dscrpool: DMA coherent pool used to allocate DMA descriptors
+ * @hlcdc: pointer to the atmel_hlcdc structure provided by the MFD device
+ * @fbdev: framebuffer device attached to the Display Controller
+ * @crtc: CRTC provided by the display controller
+ * @planes: instantiated planes
+ * @layers: active HLCDC layers
+ * @suspend: used to store the HLCDC state when entering suspend
+ */
+struct atmel_hlcdc_dc {
+ const struct atmel_hlcdc_dc_desc *desc;
+ struct dma_pool *dscrpool;
+ struct atmel_hlcdc *hlcdc;
+ struct drm_crtc *crtc;
+ struct atmel_hlcdc_layer *layers[ATMEL_HLCDC_MAX_LAYERS];
+ struct {
+ u32 imr;
+ struct drm_atomic_state *state;
+ } suspend;
+};
+
+struct atmel_hlcdc_plane_state;
+
+/**
+ * struct atmel_lcdc_dc_ops - describes atmel_lcdc ops group
+ * to differentiate HLCDC and XLCDC IP code support
+ * @plane_setup_scaler: update the vertical and horizontal scaling factors
+ * @update_lcdc_buffers: update the each LCDC layers DMA registers
+ * @lcdc_atomic_disable: disable LCDC interrupts and layers
+ * @lcdc_update_general_settings: update each LCDC layers general
+ * confiugration register
+ * @lcdc_atomic_update: enable the LCDC layers and interrupts
+ * @lcdc_csc_init: update the color space conversion co-efficient of
+ * High-end overlay register
+ * @lcdc_irq_dbg: to raise alert incase of interrupt overrun in any LCDC layer
+ */
+struct atmel_lcdc_dc_ops {
+ void (*plane_setup_scaler)(struct atmel_hlcdc_plane *plane,
+ struct atmel_hlcdc_plane_state *state);
+ void (*update_lcdc_buffers)(struct atmel_hlcdc_plane *plane,
+ struct atmel_hlcdc_plane_state *state,
+ u32 sr, int i);
+ void (*lcdc_atomic_disable)(struct atmel_hlcdc_plane *plane);
+ void
[PATCH v8 0/7] Add support for XLCDC to sam9x7 SoC family.
This patch series aims to add support for XLCDC IP of sam9x7 SoC family to the DRM subsystem.XLCDC IP has additional registers and new configuration bits compared to the existing register set of HLCDC IP. The new compatible string "microchip,sam9x75-xlcdc" is defined for sam9x75 variant of the sam9x7 SoC family.The is_xlcdc flag under driver data and IP specific driver ops helps to differentiate the XLCDC and existing HLCDC code within the same driver. changes in v8: * Re-arrange the patch set to prepare and update the current HLCDC code base with the new LCDC IP based driver ops and then add support for XLCDC code changes. * Fix Cosmetic issues. changes in v7: * LCDC IP driver ops functions are declared static and its declaration are removed. changes in v6: * Fixed Cosmetic defects. * Added comments for readability. changes in v5: * return value of regmap_read_poll_timeout is checked in failure case. * HLCDC and XLCDC specific driver functions are now invoked using its IP specific driver ops w/o the need of checking is_xlcdc flag. * Removed empty spaces and blank lines. changes in v4: * fixed kernel warnings reported by kernel test robot. changes in v3: * Removed de-referencing the value of is_xlcdc flag multiple times in a single function. * Removed cpu_relax() call when using regmap_read_poll_timeout. * Updated xfactor and yfactor equations using shift operators * Defined CSC co-efficients in an array for code readability. changes in v2: * Change the driver compatible name from "microchip,sam9x7-xlcdc" to "microchip,sam9x75-xlcdc". * Move is_xlcdc flag to driver data. * Remove unsed Macro definitions. * Add co-developed-bys tags * Replace regmap_read() with regmap_read_poll_timeout() call * Split code into two helpers for code readablitity. --- Durai Manickam KR (1): drm: atmel-hlcdc: Define XLCDC specific registers Manikandan Muralidharan (6): drm: atmel-hlcdc: add driver ops to differentiate HLCDC and XLCDC IP drm: atmel_hlcdc: Add support for XLCDC using IP specific driver ops drm: atmel-hlcdc: add DPI mode support for XLCDC drm: atmel-hlcdc: add vertical and horizontal scaling support for XLCDC drm: atmel-hlcdc: add support for DSI output formats drm: atmel-hlcdc: add LCD controller layer definition for sam9x75 .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 176 +++-- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 105 + drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 133 +-- .../gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 369 +++--- include/linux/mfd/atmel-hlcdc.h | 10 + 5 files changed, 678 insertions(+), 115 deletions(-) -- 2.25.1
Re: Re: [PATCH] drm/xe: skip building debugfs code for CONFIG_DEBUG_FS=n
+Stephen
On Tue, Feb 13, 2024 at 03:58:54PM +0100, Arnd Bergmann wrote:
On Tue, Feb 13, 2024, at 15:55, Jani Nikula wrote:
On Tue, 13 Feb 2024, Arnd Bergmann wrote:
From: Arnd Bergmann
Some of the debugfs functions are stubbed out in these configurations,
so trying to build the .c file with the definition fails:
In file included from include/uapi/linux/posix_types.h:5,
from drivers/gpu/drm/i915/display/intel_pipe_crc.c:27:
drivers/gpu/drm/i915/display/intel_pipe_crc.c: At top level:
include/linux/stddef.h:8:16: error: expected identifier or '(' before 'void'
8 | #define NULL ((void *)0)
|^~~~
drivers/gpu/drm/i915/display/intel_pipe_crc.c:549:20: note: in expansion of
macro 'intel_crtc_get_crc_sources'
549 | const char *const *intel_crtc_get_crc_sources(struct drm_crtc *crtc,
|^~
Stop trying to build them by making the Makefile entries conditional,
same as for the i915 driver.
Already fixed by commit 439987f6f471 ("drm/xe: don't build debugfs files
when CONFIG_DEBUG_FS=n") in drm-xe-next.
Maybe that needs to be picked up for -fixes?
I made sure that this still happens in linux-next today, but
it does not seem to contain 439987f6f471.
Looking at
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=2d5c7b7eb345249cb34d42cbc2b97b4c57ea944e
it seems we still don't have drm-xe-next branch in linux-next.
Stephen, could you please add it? Or do I have to do something on my end
before that? This is the branch:
https://gitlab.freedesktop.org/drm/xe/kernel drm-xe-next
thanks
Lucas De Marchi
Arnd
Re: drm-misc migration to Gitlab server
Hi Stephen, On Tue, 20 Feb 2024 at 22:46, Stephen Rothwell wrote: > On Tue, 20 Feb 2024 11:25:05 + Daniel Stone wrote: > > cc sfr - once we move the DRM repos to a different location, what's > > the best way to update linux-next? > > These are (I think) all the drm trees/branches that I fetch every day: > > [...] > > If someone could just send me all the new equivalent URLs when the > change happens, I will fix them up in my config. Thanks a lot! We'll give you a shout with a couple of days' heads-up before we move then. Cheers, Daniel
Re: [PATCH v2 2/2] drm/i915/gt: Enable only one CCS for compute workload
Hi Tvrtko,
On Tue, Feb 20, 2024 at 02:48:31PM +, Tvrtko Ursulin wrote:
> On 20/02/2024 14:35, Andi Shyti wrote:
> > Enable only one CCS engine by default with all the compute sices
>
> slices
Thanks!
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > index 833987015b8b..7041acc77810 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > @@ -243,6 +243,15 @@ void intel_engines_driver_register(struct
> > drm_i915_private *i915)
> > if (engine->uabi_class == I915_NO_UABI_CLASS)
> > continue;
> > + /*
> > +* Do not list and do not count CCS engines other than the first
> > +*/
> > + if (engine->uabi_class == I915_ENGINE_CLASS_COMPUTE &&
> > + engine->uabi_instance > 0) {
> > + i915->engine_uabi_class_count[engine->uabi_class]--;
> > + continue;
> > + }
>
> It's a bit ugly to decrement after increment, instead of somehow
> restructuring the loop to satisfy both cases more elegantly.
yes, agree, indeed I had a hard time here to accept this change
myself.
But moving the check above where the counter was incremented it
would have been much uglier.
This check looks ugly everywhere you place it :-)
In any case, I'm working on a patch that is splitting this
function in two parts and there is some refactoring happening
here (for the first initialization and the dynamic update).
Please let me know if it's OK with you or you want me to fix it
in this run.
> And I wonder if
> internally (in dmesg when engine name is logged) we don't end up with ccs0
> ccs0 ccs0 ccs0.. for all instances.
I don't see this. Even in sysfs we see only one ccs. Where is it?
> > +
> > rb_link_node(>uabi_node, prev, p);
> > rb_insert_color(>uabi_node, >uabi_engines);
[...]
> > diff --git a/drivers/gpu/drm/i915/i915_query.c
> > b/drivers/gpu/drm/i915/i915_query.c
> > index 3baa2f54a86e..d5a5143971f5 100644
> > --- a/drivers/gpu/drm/i915/i915_query.c
> > +++ b/drivers/gpu/drm/i915/i915_query.c
> > @@ -124,6 +124,7 @@ static int query_geometry_subslices(struct
> > drm_i915_private *i915,
> > return fill_topology_info(sseu, query_item,
> > sseu->geometry_subslice_mask);
> > }
> > +
>
> Zap please.
yes... yes... I noticed it after sending the patch :-)
Thanks,
Andi
[PATCH] drm/i915/guc: Add Compute context hint
Allow user to provide a context hint. When this is set, KMD will
send a hint to GuC which results in special handling for this
context. SLPC will ramp the GT frequency aggressively every time
it switches to this context. The down freq threshold will also be
lower so GuC will ramp down the GT freq for this context more slowly.
We also disable waitboost for this context as that will interfere with
the strategy.
We need to enable the use of Compute strategy during SLPC init, but
it will apply only to contexts that set this bit during context
creation.
Userland can check whether this feature is supported using a new param-
I915_PARAM_HAS_COMPUTE_CONTEXT. This flag is true for all guc submission
enabled platforms since they use SLPC for freq management.
The Mesa usage model for this flag is here -
https://gitlab.freedesktop.org/sushmave/mesa/-/commits/compute_hint
Cc: Rodrigo Vivi
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 +++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 1 +
drivers/gpu/drm/i915/gt/intel_rps.c | 8 +++
.../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | 21 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 17 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 1 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 7 +++
drivers/gpu/drm/i915/i915_getparam.c | 11 ++
include/uapi/drm/i915_drm.h | 15 +
9 files changed, 89 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index dcbfe32fd30c..ceab7dbe9b47 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -879,6 +879,7 @@ static int set_proto_ctx_param(struct drm_i915_file_private
*fpriv,
struct i915_gem_proto_context *pc,
struct drm_i915_gem_context_param *args)
{
+ struct drm_i915_private *i915 = fpriv->i915;
int ret = 0;
switch (args->param) {
@@ -904,6 +905,13 @@ static int set_proto_ctx_param(struct
drm_i915_file_private *fpriv,
pc->user_flags &= ~BIT(UCONTEXT_BANNABLE);
break;
+ case I915_CONTEXT_PARAM_IS_COMPUTE:
+ if (!intel_uc_uses_guc_submission(_gt(i915)->uc))
+ ret = -EINVAL;
+ else
+ pc->user_flags |= BIT(UCONTEXT_COMPUTE);
+ break;
+
case I915_CONTEXT_PARAM_RECOVERABLE:
if (args->size)
ret = -EINVAL;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 03bc7f9d191b..db86d6f6245f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -338,6 +338,7 @@ struct i915_gem_context {
#define UCONTEXT_BANNABLE 2
#define UCONTEXT_RECOVERABLE 3
#define UCONTEXT_PERSISTENCE 4
+#define UCONTEXT_COMPUTE 5
/**
* @flags: small set of booleans
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 4feef874e6d6..1ed40cd61b70 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -24,6 +24,7 @@
#include "intel_pcode.h"
#include "intel_rps.h"
#include "vlv_sideband.h"
+#include "../gem/i915_gem_context.h"
#include "../../../platform/x86/intel_ips.h"
#define BUSY_MAX_EI20u /* ms */
@@ -1018,6 +1019,13 @@ void intel_rps_boost(struct i915_request *rq)
struct intel_rps *rps = _ONCE(rq->engine)->gt->rps;
if (rps_uses_slpc(rps)) {
+ const struct i915_gem_context *ctx;
+
+ ctx = i915_request_gem_context(rq);
+ if (ctx &&
+ test_bit(UCONTEXT_COMPUTE, >user_flags))
+ return;
+
slpc = rps_to_slpc(rps);
if (slpc->min_freq_softlimit >= slpc->boost_freq)
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_slpc_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_slpc_abi.h
index 811add10c30d..c34674e797c6 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_slpc_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_slpc_abi.h
@@ -207,6 +207,27 @@ struct slpc_shared_data {
u8 reserved_mode_definition[4096];
} __packed;
+struct slpc_context_frequency_request {
+ u32 frequency_request:16;
+ u32 reserved:12;
+ u32 is_compute:1;
+ u32 ignore_busyness:1;
+ u32 is_minimum:1;
+ u32 is_predefined:1;
+} __packed;
+
+#define SLPC_CTX_FREQ_REQ_IS_COMPUTE REG_BIT(28)
+
+struct slpc_optimized_strategies {
+ u32 compute:1;
+ u32 async_flip:1;
+ u32 media:1;
+
Re: [PATCH v2 2/2] drm/i915/gt: Enable only one CCS for compute workload
Hi Matt,
thanks a lot for looking into this.
On Tue, Feb 20, 2024 at 03:39:18PM -0800, Matt Roper wrote:
> On Tue, Feb 20, 2024 at 03:35:26PM +0100, Andi Shyti wrote:
[...]
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > index 833987015b8b..7041acc77810 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > @@ -243,6 +243,15 @@ void intel_engines_driver_register(struct
> > drm_i915_private *i915)
> > if (engine->uabi_class == I915_NO_UABI_CLASS)
> > continue;
> >
> > + /*
> > +* Do not list and do not count CCS engines other than the first
> > +*/
> > + if (engine->uabi_class == I915_ENGINE_CLASS_COMPUTE &&
> > + engine->uabi_instance > 0) {
> > + i915->engine_uabi_class_count[engine->uabi_class]--;
> > + continue;
> > + }
>
> Wouldn't it be simpler to just add a workaround to the end of
> engine_mask_apply_compute_fuses() if we want to ensure only a single
> compute engine gets exposed? Then both the driver internals and uapi
> will agree that's there's just one CCS (and on which one there is).
>
> If we want to do something fancy with "hotplugging" a new engine later
> on or whatever, that can be handled in the future series (although as
> noted on the previous patch, it sounds like these changes might not
> actually be aligned with the workaround we were trying to address).
The hotplugging capability is one of the features I was looking
for, actually.
I have done some more refactoring in this piece of code in
upcoming patches.
Will check, though, if I can do something with compute_fuses(),
even though, the other cslices are not really fused off (read
below).
> > +
> > rb_link_node(>uabi_node, prev, p);
> > rb_insert_color(>uabi_node, >uabi_engines);
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> > b/drivers/gpu/drm/i915/gt/intel_gt.c
> > index a425db5ed3a2..e19df4ef47f6 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> > @@ -168,6 +168,14 @@ static void init_unused_rings(struct intel_gt *gt)
> > }
> > }
> >
> > +static void intel_gt_apply_ccs_mode(struct intel_gt *gt)
> > +{
> > + if (!IS_DG2(gt->i915))
> > + return;
> > +
> > + intel_uncore_write(gt->uncore, XEHP_CCS_MODE, 0);
>
> This doesn't look right to me. A value of 0 means every cslice gets
> associated with CCS0.
Yes, that's what I'm trying to do. The behavior I'm looking for
is this one:
/*
...
* With 1 engine (ccs0):
* slice 0, 1, 2, 3: ccs0
*
* With 2 engines (ccs0, ccs1):
* slice 0, 2: ccs0
* slice 1, 3: ccs1
*
* With 4 engines (ccs0, ccs1, ccs2, ccs3):
* slice 0: ccs0
* slice 1: ccs1
* slice 2: ccs2
* slice 3: ccs3
...
*/
where the user can configure runtime the mode, making sure that
no client is connected to i915.
But, this needs to be written
As we are now forcing mode '1', then all cslices are connected
with ccs0.
> On a DG2-G11 platform, that will flat out break
> compute since CCS0 is never present (G11 only has a single CCS and it's
> always the hardware's CCS1). Even on a G10 or G12 this could also break
> things depending on the fusing of your card if the hardware CCS0 happens
> to be missing.
>
> Also, the register says that we need a field value of 0x7 for each
> cslice that's fused off. By passing 0, we're telling the CCS engine
> that it can use cslices that may not actually exist.
does it? Or do I need to write the id (0x0-0x3) of the user
engine? That's how the mode is calculated in this algorithm.
> > +}
> > +
[...]
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > index cf709f6c05ae..c148113770ea 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > @@ -1605,6 +1605,8 @@
> > #define GEN12_VOLTAGE_MASK REG_GENMASK(10, 0)
> > #define GEN12_CAGF_MASK REG_GENMASK(19, 11)
> >
> > +#define XEHP_CCS_MODE _MMIO(0x14804)
>
> Nitpick: this doesn't seem to be in the proper place and also breaks
> the file's convention of using tabs to move over to column 48 for the
> definition value.
This was something I actually forgot to fix. Thanks!
Re: [PATCH v2 2/2] drm/i915/gt: Enable only one CCS for compute workload
On Tue, Feb 20, 2024 at 03:35:26PM +0100, Andi Shyti wrote:
> Enable only one CCS engine by default with all the compute sices
> allocated to it.
>
> While generating the list of UABI engines to be exposed to the
> user, exclude any additional CCS engines beyond the first
> instance.
>
> This change can be tested with igt i915_query.
>
> Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Matt Roper
> Cc: # v6.2+
> ---
> drivers/gpu/drm/i915/gt/intel_engine_user.c | 9 +
> drivers/gpu/drm/i915/gt/intel_gt.c | 11 +++
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 ++
> drivers/gpu/drm/i915/i915_query.c | 1 +
> 4 files changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> index 833987015b8b..7041acc77810 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> @@ -243,6 +243,15 @@ void intel_engines_driver_register(struct
> drm_i915_private *i915)
> if (engine->uabi_class == I915_NO_UABI_CLASS)
> continue;
>
> + /*
> + * Do not list and do not count CCS engines other than the first
> + */
> + if (engine->uabi_class == I915_ENGINE_CLASS_COMPUTE &&
> + engine->uabi_instance > 0) {
> + i915->engine_uabi_class_count[engine->uabi_class]--;
> + continue;
> + }
Wouldn't it be simpler to just add a workaround to the end of
engine_mask_apply_compute_fuses() if we want to ensure only a single
compute engine gets exposed? Then both the driver internals and uapi
will agree that's there's just one CCS (and on which one there is).
If we want to do something fancy with "hotplugging" a new engine later
on or whatever, that can be handled in the future series (although as
noted on the previous patch, it sounds like these changes might not
actually be aligned with the workaround we were trying to address).
> +
> rb_link_node(>uabi_node, prev, p);
> rb_insert_color(>uabi_node, >uabi_engines);
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index a425db5ed3a2..e19df4ef47f6 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -168,6 +168,14 @@ static void init_unused_rings(struct intel_gt *gt)
> }
> }
>
> +static void intel_gt_apply_ccs_mode(struct intel_gt *gt)
> +{
> + if (!IS_DG2(gt->i915))
> + return;
> +
> + intel_uncore_write(gt->uncore, XEHP_CCS_MODE, 0);
This doesn't look right to me. A value of 0 means every cslice gets
associated with CCS0. On a DG2-G11 platform, that will flat out break
compute since CCS0 is never present (G11 only has a single CCS and it's
always the hardware's CCS1). Even on a G10 or G12 this could also break
things depending on the fusing of your card if the hardware CCS0 happens
to be missing.
Also, the register says that we need a field value of 0x7 for each
cslice that's fused off. By passing 0, we're telling the CCS engine
that it can use cslices that may not actually exist.
> +}
> +
> int intel_gt_init_hw(struct intel_gt *gt)
> {
> struct drm_i915_private *i915 = gt->i915;
> @@ -195,6 +203,9 @@ int intel_gt_init_hw(struct intel_gt *gt)
>
> intel_gt_init_swizzling(gt);
>
> + /* Configure CCS mode */
> + intel_gt_apply_ccs_mode(gt);
> +
> /*
>* At least 830 can leave some of the unused rings
>* "active" (ie. head != tail) after resume which
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index cf709f6c05ae..c148113770ea 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1605,6 +1605,8 @@
> #define GEN12_VOLTAGE_MASK REG_GENMASK(10, 0)
> #define GEN12_CAGF_MASKREG_GENMASK(19, 11)
>
> +#define XEHP_CCS_MODE _MMIO(0x14804)
Nitpick: this doesn't seem to be in the proper place and also breaks
the file's convention of using tabs to move over to column 48 for the
definition value.
Matt
> +
> #define GEN11_GT_INTR_DW(x) _MMIO(0x190018 + ((x) * 4))
> #define GEN11_CSME (31)
> #define GEN12_HECI_2 (30)
> diff --git a/drivers/gpu/drm/i915/i915_query.c
> b/drivers/gpu/drm/i915/i915_query.c
> index 3baa2f54a86e..d5a5143971f5 100644
> --- a/drivers/gpu/drm/i915/i915_query.c
> +++ b/drivers/gpu/drm/i915/i915_query.c
> @@ -124,6 +124,7 @@ static int query_geometry_subslices(struct
> drm_i915_private *i915,
> return fill_topology_info(sseu, query_item,
> sseu->geometry_subslice_mask);
> }
>
> +
> static
Re: [PATCH v2 1/2] drm/i915/gt: Disable HW load balancing for CCS
On Tue, Feb 20, 2024 at 03:35:25PM +0100, Andi Shyti wrote:
> The hardware should not dynamically balance the load between CCS
> engines. Wa_14019159160 recommends disabling it across all
> platforms.
>
> Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Matt Roper
> Cc: # v6.2+
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 50962cfd1353..cf709f6c05ae 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1478,6 +1478,7 @@
>
> #define GEN12_RCU_MODE _MMIO(0x14800)
> #define GEN12_RCU_MODE_CCS_ENABLE REG_BIT(0)
> +#define XEHP_RCU_MODE_FIXED_SLICE_CCS_MODE REG_BIT(1)
>
> #define CHV_FUSE_GT _MMIO(VLV_GUNIT_BASE + 0x2168)
> #define CHV_FGT_DISABLE_SS0(1 << 10)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index d67d44611c28..9126b37186fc 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2988,6 +2988,12 @@ general_render_compute_wa_init(struct intel_engine_cs
> *engine, struct i915_wa_li
> wa_mcr_masked_en(wal, GEN8_HALF_SLICE_CHICKEN1,
>GEN7_PSD_SINGLE_PORT_DISPATCH_ENABLE);
> }
> +
> + /*
> + * Wa_14019159160: disable the CCS load balancing
> + * indiscriminately for all the platforms
The database's description of this workaround is a bit confusing since
it's been modified a few times, but if I'm reading it correctly it
doesn't sound like this is what it's asking us to do. What I see says
that load balancing shouldn't be allowed specifically while the RCS is
active. If the RCS is sitting idle, I believe you're free to use as
many CCS engines as you like, with load balancing still active.
We already have other workarounds that prevent different address spaces
from executing on the RCS/CCS engines at the same time, so the part
about "same address space" in the description should already be
satisfied. It sounds like the issues now are if 2+ CCS's are in use and
something new shows up to run on the previously-idle RCS, or if
something's already running on the RCS and 1 CCS, and something new
shows up to run on an additional CCS. The workaround details make it
sound like it's supposed to be the GuC's responsibility to prevent the
new work from getting scheduled onto the additional engine while we're
already in one of those two situations, so I don't see anything asking
us to change the hardware-level load balance enable/disable (actually
the spec specifically tells us *not* to do this). Aren't we supposed to
be just setting a GuC workaround flag for this?
Matt
> + */
> + wa_masked_en(wal, GEN12_RCU_MODE, XEHP_RCU_MODE_FIXED_SLICE_CCS_MODE);
> }
>
> static void
> --
> 2.43.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v2] drm/msm/dpu: make "vblank timeout" more useful
On Wed, 21 Feb 2024 at 01:04, Abhinav Kumar wrote:
>
>
>
> On 2/20/2024 2:42 PM, Dmitry Baryshkov wrote:
> > On Wed, 21 Feb 2024 at 00:40, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 2/19/2024 3:52 AM, Dmitry Baryshkov wrote:
> >>> On Wed, 14 Feb 2024 at 22:36, Abhinav Kumar
> >>> wrote:
>
>
>
> 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.
> >>>
> >>> Excuse me, maybe I miss something. On the first timeout the snapshot
> >>> is created. It is held by the kernel until it is fully read out from
> >>> the userspace. Other snapshots will not interfere with this snapshot.
> >>>
> >>
> >> For every new snapshot a new devcoredump device will be created which
> >> should remain till it has been read. But now this will be created every
> >> blank. IMO, this is really too much data for no reason.
> >
> > No-no-no. If there is a devcoredump for a device, the next one will
> > not be created. See dev_coredumpm().
> > So all the snapshots will be created and then destroyed immediately.
> >
>
> hmm ... I have certainly seen devcd_count go higher than one (but not
> more than 2). I am wondering whether this was because of some race
> condition of the previous destroy / new create.
>
> But anyway, this part is clear now. thanks.
>
> >>
> >> Subsequent vblank timeouts are not going to give any new information
> >> compared to the existing snapshot of the first vblank timeout thats why
> >> we should just create the snapshot when the first error happens and stop.
> >>
> >> For other frame done timeouts, infact subsequent timeouts without any
> >> sort of recovery in between are quite misleading because hardware was
> >> already not able to fetch the previous frame so it will most likely not
> >> fetch the next one either till it has recovered. Typically thats why
> >> these vblank timeouts happen in a flurry as the hardware never really
> >> recovered from the first timeout.
> >>
> >>> Or are you worried that snapshotting takes time, so taking a snapshot
> >>> will also interfere with the vblank timings for the next vblank?
> >>>
> >>
> >> Yes this is another point.
> >
>
> snapshots will still be captured every vblank timeout and reading
> through the entire DPU reg space every vblank timeout is certainly
> something we can avoid.
Ack.
--
With best wishes
Dmitry
Re: [PATCH v2] drm/msm/dpu: make "vblank timeout" more useful
On 2/20/2024 2:42 PM, Dmitry Baryshkov wrote:
On Wed, 21 Feb 2024 at 00:40, Abhinav Kumar wrote:
On 2/19/2024 3:52 AM, Dmitry Baryshkov wrote:
On Wed, 14 Feb 2024 at 22:36, Abhinav Kumar wrote:
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.
Excuse me, maybe I miss something. On the first timeout the snapshot
is created. It is held by the kernel until it is fully read out from
the userspace. Other snapshots will not interfere with this snapshot.
For every new snapshot a new devcoredump device will be created which
should remain till it has been read. But now this will be created every
blank. IMO, this is really too much data for no reason.
No-no-no. If there is a devcoredump for a device, the next one will
not be created. See dev_coredumpm().
So all the snapshots will be created and then destroyed immediately.
hmm ... I have certainly seen devcd_count go higher than one (but not
more than 2). I am wondering whether this was because of some race
condition of the previous destroy / new create.
But anyway, this part is clear now. thanks.
Subsequent vblank timeouts are not going to give any new information
compared to the existing snapshot of the first vblank timeout thats why
we should just create the snapshot when the first error happens and stop.
For other frame done timeouts, infact subsequent timeouts without any
sort of recovery in between are quite misleading because hardware was
already not able to fetch the previous frame so it will most likely not
fetch the next one either till it has recovered. Typically thats why
these vblank timeouts happen in a flurry as the hardware never really
recovered from the first timeout.
Or are you worried that snapshotting takes time, so taking a snapshot
will also interfere with the vblank timings for the next vblank?
Yes this is another point.
snapshots will still be captured every vblank timeout and reading
through the entire DPU reg space every vblank timeout is certainly
something we can avoid.
Re: [PATCH RFC 3/3] drm/msm/dp: Add support for the X1E80100
On Wed, 21 Feb 2024 at 00:50, Abel Vesa wrote: > > Add the X1E80100 DP descs and compatible. This platform will be using > a single compatible for both eDP and DP mode. The actual mode will > be set in devicetree via is-edp flag. > > Signed-off-by: Abel Vesa > --- > drivers/gpu/drm/msm/dp/dp_display.c | 9 + > 1 file changed, 9 insertions(+) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH RFC 2/3] drm/msm/dp: Add support for setting the eDP mode from devicetree
On Wed, 21 Feb 2024 at 00:50, Abel Vesa wrote: > > Instead of relying on different compatibles for eDP and DP, use > the is-edp property from DT to figure out the connector type and > then pass on that information to the PHY. > > Signed-off-by: Abel Vesa > --- > drivers/gpu/drm/msm/dp/dp_ctrl.c| 11 +++ > drivers/gpu/drm/msm/dp/dp_ctrl.h| 1 + > drivers/gpu/drm/msm/dp/dp_display.c | 19 --- > 3 files changed, 28 insertions(+), 3 deletions(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
[PATCH RFC 1/3] dt-bindings: display: msm: dp-controller: document X1E80100 compatible
Add the X1E80100 to the list of compatibles and docoment the is-edp flag. This new flag will be used from now on to dictate the mode from devicetree, instead of having separate compatibles for eDP and DP. Signed-off-by: Abel Vesa --- Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml index ae53cbfb2193..ed11852e403d 100644 --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -27,6 +27,7 @@ properties: - qcom,sdm845-dp - qcom,sm8350-dp - qcom,sm8650-dp + - qcom,x1e80100-dp - items: - enum: - qcom,sm8150-dp @@ -73,6 +74,11 @@ properties: - description: phy 0 parent - description: phy 1 parent + is-edp: +$ref: /schemas/types.yaml#/definitions/flag +description: + Tells the controller to switch to eDP mode + phys: maxItems: 1 -- 2.34.1
[PATCH RFC 3/3] drm/msm/dp: Add support for the X1E80100
Add the X1E80100 DP descs and compatible. This platform will be using
a single compatible for both eDP and DP mode. The actual mode will
be set in devicetree via is-edp flag.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/dp/dp_display.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 9e58285d4ec6..7b8c695d521a 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -171,6 +171,14 @@ static const struct msm_dp_desc sm8650_dp_descs[] = {
{}
};
+static const struct msm_dp_desc x1e80100_dp_descs[] = {
+ { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .wide_bus_en =
true },
+ { .io_start = 0x0ae98000, .id = MSM_DP_CONTROLLER_1, .wide_bus_en =
true },
+ { .io_start = 0x0ae9a000, .id = MSM_DP_CONTROLLER_2, .wide_bus_en =
true },
+ { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_3, .wide_bus_en =
true },
+ {}
+};
+
static const struct of_device_id dp_dt_match[] = {
{ .compatible = "qcom,sc7180-dp", .data = _dp_descs },
{ .compatible = "qcom,sc7280-dp", .data = _dp_descs },
@@ -179,6 +187,7 @@ static const struct of_device_id dp_dt_match[] = {
{ .compatible = "qcom,sc8180x-edp", .data = _dp_descs },
{ .compatible = "qcom,sc8280xp-dp", .data = _dp_descs },
{ .compatible = "qcom,sc8280xp-edp", .data = _edp_descs },
+ { .compatible = "qcom,x1e80100-dp", .data = _dp_descs },
{ .compatible = "qcom,sdm845-dp", .data = _dp_descs },
{ .compatible = "qcom,sm8350-dp", .data = _dp_descs },
{ .compatible = "qcom,sm8650-dp", .data = _dp_descs },
--
2.34.1
[PATCH RFC 2/3] drm/msm/dp: Add support for setting the eDP mode from devicetree
Instead of relying on different compatibles for eDP and DP, use
the is-edp property from DT to figure out the connector type and
then pass on that information to the PHY.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/dp/dp_ctrl.c| 11 +++
drivers/gpu/drm/msm/dp/dp_ctrl.h| 1 +
drivers/gpu/drm/msm/dp/dp_display.c | 19 ---
3 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 320f17fce9a6..bd81cc6bd5e3 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1533,6 +1533,17 @@ void dp_ctrl_set_psr(struct dp_ctrl *dp_ctrl, bool enter)
}
}
+int dp_ctrl_phy_set_mode(struct dp_ctrl *dp_ctrl, int submode)
+{
+ struct dp_ctrl_private *ctrl;
+ struct phy *phy;
+
+ ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
+ phy = ctrl->phy;
+
+ return phy_set_mode_ext(phy, PHY_MODE_DP, submode);
+}
+
void dp_ctrl_phy_init(struct dp_ctrl *dp_ctrl)
{
struct dp_ctrl_private *ctrl;
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.h b/drivers/gpu/drm/msm/dp/dp_ctrl.h
index fa014cee7e21..a10d1b19d172 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.h
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.h
@@ -32,6 +32,7 @@ struct dp_ctrl *dp_ctrl_get(struct device *dev, struct
dp_link *link,
struct phy *phy);
void dp_ctrl_reset_irq_ctrl(struct dp_ctrl *dp_ctrl, bool enable);
+int dp_ctrl_phy_set_mode(struct dp_ctrl *dp_ctrl, int mode);
void dp_ctrl_phy_init(struct dp_ctrl *dp_ctrl);
void dp_ctrl_phy_exit(struct dp_ctrl *dp_ctrl);
void dp_ctrl_irq_phy_exit(struct dp_ctrl *dp_ctrl);
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index e4433891becb..9e58285d4ec6 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1229,6 +1229,7 @@ static int dp_display_probe(struct platform_device *pdev)
int rc = 0;
struct dp_display_private *dp;
const struct msm_dp_desc *desc;
+ bool is_edp = false;
if (!pdev || !pdev->dev.of_node) {
DRM_ERROR("pdev not found\n");
@@ -1243,13 +1244,19 @@ static int dp_display_probe(struct platform_device
*pdev)
if (!desc)
return -EINVAL;
+ if (dp->dp_display.connector_type == DRM_MODE_CONNECTOR_eDP ||
+ of_property_read_bool(pdev->dev.of_node, "is-edp"))
+ is_edp = true;
+
+ dp->dp_display.is_edp = is_edp;
dp->dp_display.pdev = pdev;
dp->name = "drm_dp";
dp->id = desc->id;
- dp->dp_display.connector_type = desc->connector_type;
dp->wide_bus_en = desc->wide_bus_en;
- dp->dp_display.is_edp =
- (dp->dp_display.connector_type == DRM_MODE_CONNECTOR_eDP);
+
+ dp->dp_display.connector_type = is_edp ?
+ DRM_MODE_CONNECTOR_eDP :
+ DRM_MODE_CONNECTOR_DisplayPort;
rc = dp_init_sub_modules(dp);
if (rc) {
@@ -1257,6 +1264,12 @@ static int dp_display_probe(struct platform_device *pdev)
return -EPROBE_DEFER;
}
+ rc = dp_ctrl_phy_set_mode(dp->ctrl, is_edp ? PHY_SUBMODE_EDP :
PHY_SUBMODE_DP);
+ if (rc) {
+ DRM_ERROR("setting PHY submode failed\n");
+ goto err;
+ }
+
/* setup event q */
mutex_init(>event_mutex);
init_waitqueue_head(>event_q);
--
2.34.1
[PATCH RFC 0/3] drm/msm/dp: Rework the eDP/DP modes and add support for X1E80100
Since this new platform supports both DP and eDP, it's the perfect time to drop the dual compatible (eDP and DP) and figure out a different way to specify the mode. After some off-list discussion, one suggested way was to add a 'is-edp' property to the controller node and call phy_set_mode to let the PHY know which mode it should configure itself. The PHY counterpart patchset is here: https://lore.kernel.org/all/20240220-x1e80100-phy-edp-compatible-refactor-v5-0-e8658adf5...@linaro.org/ Signed-off-by: Abel Vesa --- Abel Vesa (3): dt-bindings: display: msm: dp-controller: document X1E80100 compatible drm/msm/dp: Add support for setting the eDP mode from devicetree drm/msm/dp: Add support for the X1E80100 .../bindings/display/msm/dp-controller.yaml| 6 + drivers/gpu/drm/msm/dp/dp_ctrl.c | 11 + drivers/gpu/drm/msm/dp/dp_ctrl.h | 1 + drivers/gpu/drm/msm/dp/dp_display.c| 28 +++--- 4 files changed, 43 insertions(+), 3 deletions(-) --- base-commit: 2d5c7b7eb345249cb34d42cbc2b97b4c57ea944e change-id: 20231219-x1e80100-display-refactor-connector-e1c66548cae3 Best regards, -- Abel Vesa
Re: [RFC] drm/i915: Support replaying GPU hangs with captured context image
On Tue, Feb 13, 2024 at 01:14:34PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> When debugging GPU hangs Mesa developers are finding it useful to replay
> the captured error state against the simulator. But due various simulator
> limitations which prevent replicating all hangs, one step further is being
> able to replay against a real GPU.
>
> This is almost doable today with the missing part being able to upload the
> captured context image into the driver state prior to executing the
> uploaded hanging batch and all the buffers.
>
> To enable this last part we add a new context parameter called
> I915_CONTEXT_PARAM_CONTEXT_IMAGE. It follows the existing SSEU
> configuration pattern of being able to select which context to apply
> against, paired with the actual image and its size.
>
> Since this is adding a new concept of debug only uapi, we hide it behind
> a new kconfig option and also require activation with a module parameter.
> Together with a warning banner printed at driver load, all those combined
> should be sufficient to guard against inadvertently enabling the feature.
>
> In terms of implementation the only trivial change is shadowing of the
> default state from engine to context. We also allow the legacy context
> set param to be used since that removes the need to record the per context
> data in the proto context, while still allowing flexibility of specifying
> context images for any context.
>
> Mesa MR using the uapi can be seen at:
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27594
I just wonder if it would be better to split the default_state in a separate
patch but from what I could see it looks correct.
Also, I have to say that this approach is nice, clean and well protected.
And much simpler then I imagined when I saw the idea around.
Feel free to use:
Reviewed-by: Rodrigo Vivi
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Lionel Landwerlin
> Cc: Carlos Santa
> ---
> drivers/gpu/drm/i915/Kconfig.debug| 17 +++
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 106 ++
> drivers/gpu/drm/i915/gt/intel_context.c | 2 +
> drivers/gpu/drm/i915/gt/intel_context.h | 22
> drivers/gpu/drm/i915/gt/intel_context_types.h | 3 +
> drivers/gpu/drm/i915/gt/intel_lrc.c | 8 +-
> .../gpu/drm/i915/gt/intel_ring_submission.c | 8 +-
> drivers/gpu/drm/i915/i915_params.c| 5 +
> drivers/gpu/drm/i915/i915_params.h| 3 +-
> include/uapi/drm/i915_drm.h | 27 +
> 10 files changed, 194 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig.debug
> b/drivers/gpu/drm/i915/Kconfig.debug
> index 5b7162076850..32e9f70e91ed 100644
> --- a/drivers/gpu/drm/i915/Kconfig.debug
> +++ b/drivers/gpu/drm/i915/Kconfig.debug
> @@ -16,6 +16,23 @@ config DRM_I915_WERROR
>
> If in doubt, say "N".
>
> +config DRM_I915_REPLAY_GPU_HANGS_API
> + bool "Enable GPU hang replay userspace API"
> + depends on DRM_I915
> + depends on EXPERT
> + default n
> + help
> + Choose this option if you want to enable special and unstable
> + userspace API used for replaying GPU hangs on a running system.
> +
> + This API is intended to be used by userspace graphics stack developers
> + and provides no stability guarantees.
> +
> + The API needs to be activated at boot time using the
> + enable_debug_only_api module parameter.
> +
> + If in doubt, say "N".
> +
> config DRM_I915_DEBUG
> bool "Enable additional driver debugging"
> depends on DRM_I915
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index dcbfe32fd30c..1cfd624bd978 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -78,6 +78,7 @@
> #include "gt/intel_engine_user.h"
> #include "gt/intel_gpu_commands.h"
> #include "gt/intel_ring.h"
> +#include "gt/shmem_utils.h"
>
> #include "pxp/intel_pxp.h"
>
> @@ -949,6 +950,7 @@ static int set_proto_ctx_param(struct
> drm_i915_file_private *fpriv,
> case I915_CONTEXT_PARAM_NO_ZEROMAP:
> case I915_CONTEXT_PARAM_BAN_PERIOD:
> case I915_CONTEXT_PARAM_RINGSIZE:
> + case I915_CONTEXT_PARAM_CONTEXT_IMAGE:
> default:
> ret = -EINVAL;
> break;
> @@ -2092,6 +2094,88 @@ static int get_protected(struct i915_gem_context *ctx,
> return 0;
> }
>
> +static int set_context_image(struct i915_gem_context *ctx,
> + struct drm_i915_gem_context_param *args)
> +{
> + struct i915_gem_context_param_context_image user;
> + struct intel_context *ce;
> + struct file *shmem_state;
> + unsigned long lookup;
> + void *state;
> + int ret = 0;
> +
> + if (!IS_ENABLED(CONFIG_DRM_I915_REPLAY_GPU_HANGS_API))
> + return -EINVAL;
> +
> + if
Re: drm-misc migration to Gitlab server
Hi Daniel, On Tue, 20 Feb 2024 11:25:05 + Daniel Stone wrote: > > On Tue, 20 Feb 2024 at 09:05, Maxime Ripard wrote: > > On Tue, Feb 20, 2024 at 09:49:25AM +0100, Maxime Ripard wrote: > > > This will be mostly transparent to current committers and users: we'll > > > still use dim, in the exact same way, the only change will be the URL of > > > the repo. This will also be transparent to linux-next, since the > > > linux-next branch lives in its own repo and is pushed by dim when > > > pushing a branch. > > > > Actually, I double-checked and linux-next pulls our branches directly, > > so once the transition is over we'll have to notify them too. > > cc sfr - once we move the DRM repos to a different location, what's > the best way to update linux-next? > > That being said, we could set up read-only pull mirrors in the old > location ... something I want to do in March (because what else are > you going to do on holiday?) is to kill the write repos on kemper > (git.fd.o), move them to being on molly (cgit/anongit.fd.o) only, and > just have a cronjob that regularly pulls from all the gl.fd.o repos, > rather than pushing from GitLab. These are (I think) all the drm trees/branches that I fetch every day: git://anongit.freedesktop.org/drm-intel#for-linux-next git://anongit.freedesktop.org/drm-intel#for-linux-next-fixes git://anongit.freedesktop.org/drm/drm-misc#for-linux-next git://anongit.freedesktop.org/drm/drm-misc#for-linux-next-fixes git://git.freedesktop.org/git/drm/drm.git#drm-fixes git://git.freedesktop.org/git/drm/drm.git#drm-next git://git.freedesktop.org/git/drm/drm.git#topic/drm-ci git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git#for-linux-next https://gitlab.freedesktop.org/agd5f/linux#drm-next https://gitlab.freedesktop.org/drm/msm.git#msm-next https://gitlab.freedesktop.org/drm/tegra.git#for-next https://gitlab.freedesktop.org/lumag/msm.git#msm-next-lumag If someone could just send me all the new equivalent URLs when the change happens, I will fix them up in my config. -- Cheers, Stephen Rothwell pgpxX0CUBJ8uy.pgp Description: OpenPGP digital signature
Re: [PATCH v2] drm/msm/dpu: make "vblank timeout" more useful
On Wed, 21 Feb 2024 at 00:40, Abhinav Kumar wrote:
>
>
>
> On 2/19/2024 3:52 AM, Dmitry Baryshkov wrote:
> > On Wed, 14 Feb 2024 at 22:36, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> 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.
> >
> > Excuse me, maybe I miss something. On the first timeout the snapshot
> > is created. It is held by the kernel until it is fully read out from
> > the userspace. Other snapshots will not interfere with this snapshot.
> >
>
> For every new snapshot a new devcoredump device will be created which
> should remain till it has been read. But now this will be created every
> blank. IMO, this is really too much data for no reason.
No-no-no. If there is a devcoredump for a device, the next one will
not be created. See dev_coredumpm().
So all the snapshots will be created and then destroyed immediately.
>
> Subsequent vblank timeouts are not going to give any new information
> compared to the existing snapshot of the first vblank timeout thats why
> we should just create the snapshot when the first error happens and stop.
>
> For other frame done timeouts, infact subsequent timeouts without any
> sort of recovery in between are quite misleading because hardware was
> already not able to fetch the previous frame so it will most likely not
> fetch the next one either till it has recovered. Typically thats why
> these vblank timeouts happen in a flurry as the hardware never really
> recovered from the first timeout.
>
> > Or are you worried that snapshotting takes time, so taking a snapshot
> > will also interfere with the vblank timings for the next vblank?
> >
>
> Yes this is another point.
--
With best wishes
Dmitry
Re: [PATCH v2] drm/msm/dpu: make "vblank timeout" more useful
On 2/19/2024 3:52 AM, Dmitry Baryshkov wrote:
On Wed, 14 Feb 2024 at 22:36, Abhinav Kumar wrote:
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.
Excuse me, maybe I miss something. On the first timeout the snapshot
is created. It is held by the kernel until it is fully read out from
the userspace. Other snapshots will not interfere with this snapshot.
For every new snapshot a new devcoredump device will be created which
should remain till it has been read. But now this will be created every
blank. IMO, this is really too much data for no reason.
Subsequent vblank timeouts are not going to give any new information
compared to the existing snapshot of the first vblank timeout thats why
we should just create the snapshot when the first error happens and stop.
For other frame done timeouts, infact subsequent timeouts without any
sort of recovery in between are quite misleading because hardware was
already not able to fetch the previous frame so it will most likely not
fetch the next one either till it has recovered. Typically thats why
these vblank timeouts happen in a flurry as the hardware never really
recovered from the first timeout.
Or are you worried that snapshotting takes time, so taking a snapshot
will also interfere with the vblank timings for the next vblank?
Yes this is another point.
linux-next: manual merge of the drm-misc-fixes tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-misc-fixes tree got a conflict in:
drivers/gpu/drm/tests/drm_buddy_test.c
between commit:
fca7526b7d89 ("drm/tests/drm_buddy: fix build failure on 32-bit targets")
from Linus' tree and commit:
335126937753 ("drm/tests/drm_buddy: fix 32b build")
from the drm-misc-fixes tree.
I fixed it up (I just used the version from Linus' tree) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging. You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpsH3DOTT6qM.pgp
Description: OpenPGP digital signature
Re: [PATCH v3] drm/i915/guc: Simplify/extend platform check for Wa_14018913170
On Tue, Feb 20, 2024 at 11:52:04AM -0800, John Harrison wrote:
> On 2/19/2024 12:28, Rodrigo Vivi wrote:
> > On Fri, Feb 16, 2024 at 10:38:41AM -0800, john.c.harri...@intel.com wrote:
> > > From: John Harrison
> > >
> > > The above w/a is required for every platform that the i915 driver
> > > supports. It is fixed on the latest platforms but they are only
> > > supported by Xe instead of i915. So just remove the platform check
> > > completely and keep the code simple.
> > Well, I was going to say that I would prefer a GMD version greater-than
> > check to be future proof. However if this code gets used in some other
> > new platform a new specific guc support would likely need to be added
> > as well right?
> There is no future for i915. That's the point. The only platforms that have
> the hardware fix are all ones that will only ever be supported by the Xe
> driver. So if such a platform were to be backported to i915 then there would
> be a lot more work than just adding a new GuC firmware platform.
>
> And going backwards, the bug affects all platforms that have a GuC. So if
> any GuC code is being executed at all, then this w/a is applicable.
>
> >
> > Perhaps at least adding a comment in the code?
> Such as this?
> /*
> * Wa_14018913170: Applicable to all platforms supported by i915.
I believe only this first line would be enough. but up to you and feel free
to put my rv-b with whatever version you get.
so
> * don't bother testing for all X/Y/Z platforms explicitly.
> */
>
> John.
>
>
> >
> > with that
> > Reviewed-by: Rodrigo Vivi
> >
> >
> > > Signed-off-by: John Harrison
> > > ---
> > > drivers/gpu/drm/i915/gt/uc/intel_guc.c | 3 +--
> > > 1 file changed, 1 insertion(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > > b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > > index 2b450c43bbd7f..a3662edb42032 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > > @@ -321,8 +321,7 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
> > > /* Wa_14018913170 */
> > > if (GUC_FIRMWARE_VER(guc) >= MAKE_GUC_VER(70, 7, 0)) {
> > > - if (IS_DG2(gt->i915) || IS_METEORLAKE(gt->i915) ||
> > > IS_PONTEVECCHIO(gt->i915))
> > > - flags |= GUC_WA_ENABLE_TSC_CHECK_ON_RC6;
> > > + flags |= GUC_WA_ENABLE_TSC_CHECK_ON_RC6;
> > > }
> > > return flags;
> > > --
> > > 2.43.0
> > >
>
Re: [PATCH] arm64: dts: qcom: sm6115: fix USB PHY configuration
On 20.02.2024 18:31, Dmitry Baryshkov wrote:
> The patch adding Type-C support for sm6115 was misapplied. All the
> orientation switch configuration ended up at the UFS PHY node instead of
> the USB PHY node. Move the data bits to the correct place.
>
> Fixes: a06a2f12f9e2 ("arm64: dts: qcom: qrb4210-rb2: enable USB-C port
> handling")
> Signed-off-by: Dmitry Baryshkov
> ---
So that's why UFS stopped working and I couldn't for the life of
me guess why..
Konrad
Re: drm/msm: Second DisplayPort regression in 6.8-rc1
Hi Johan On 2/19/2024 2:41 AM, Johan Hovold wrote: On Sat, Feb 17, 2024 at 04:14:58PM +0100, Johan Hovold wrote: On Wed, Feb 14, 2024 at 02:52:06PM +0100, Johan Hovold wrote: On Tue, Feb 13, 2024 at 10:00:13AM -0800, Abhinav Kumar wrote: Since Dmitry had trouble reproducing this issue I took a closer look at the DRM aux bridge series that Abhinav pointed and was able to track down the bridge regressions and come up with a reproducer. I just posted a series fixing this here: https://lore.kernel.org/lkml/20240217150228.5788-1-johan+lin...@kernel.org/ As I mentioned in the cover letter, I am still seeing intermittent hard resets around the time that the DRM subsystem is initialising, which suggests that we may be dealing with two separate DRM regressions here however. If the hard resets are triggered by something like unclocked hardware, perhaps that bit could this be related to the runtime PM rework? It seems my initial suspicion that at least some of these regressions were related to the runtime PM work was correct. The hard resets happens when the DP controller is runtime suspended after being probed: [ 16.748475] bus: 'platform': __driver_probe_device: matched device ae0.display-subsystem with driver msm-mdss [ 16.759444] msm-mdss ae0.display-subsystem: Adding to iommu group 21 [ 16.795226] bus: 'platform': __driver_probe_device: matched device ae01000.display-controller with driver msm_dpu [ 16.807542] probe of ae01000.display-controller returned -517 after 3 usecs [ 16.821552] bus: 'platform': __driver_probe_device: matched device ae9.displayport-controller with driver msm-dp-display [ 16.837749] probe of ae9.displayport-controller returned -517 after 1 usecs [ OK ] Listening on Load/Save RF Kill Swit[ 16.854659] bus: 'platform': __dch Status /dev/rfkill Watch. [ 16.868458] probe of ae98000.displayport-controller returned -517 after 2 usecs [ 16.880012] bus: 'platform': __driver_probe_device: matched device aea.displayport-controller with driver msm-dp-display [ 16.891856] probe of aea.displayport-controller returned -517 after 2 usecs [ 16.903825] probe of ae0.display-subsystem returned 0 after 144497 usecs [ 16.911636] bus: 'platform': __driver_probe_device: matched device ae01000.display-controller with driver msm_dpu [ 16.942092] probe of ae01000.display-controller returned 0 after 19593 usecs Starting Load/Save Screen Backligh…rightness[ 16.959146] bus: 'platform': _ of backlight:backlight... [ 16.995355] msm-dp-display ae9.displayport-controller: dp_display_probe - probe tail [ 17.004032] probe of ae9.displayport-controller returned 0 after 30225 usecs [ 17.012308] bus: 'platform': __driver_probe_device: matched device ae98000.displayport-controller with driver msm-dp-display [ 17.050193] msm-dp-display ae98000.displayport-controller: dp_display_probe - probe tail Starting Network Name Resolution... [ 17.058925] probe of ae98000.displayport-controller returned 0 after 34774 usecs [ 17.074925] bus: 'platform': __driver_probe_device: matched device aea.displayport-controller with driver msm-dp-display [Starting Network Time Synchronization... [ 17.112000] msm-dp-display aea.displayport-controller: dp_display_probe - populate aux bus [ 17.125208] msm-dp-display aea.displayport-controller: dp_pm_runtime_resume Starting Record System Boot/Shutdown in UTMP... Starting Virtual Console Setup... [ OK ] Finished Load/Save Screen Backlight Brightness of backlight:backlight. [ 17.197909] msm-dp-display aea.displayport-controller: dp_pm_runtime_suspend [ 17.198079] probe of aea0Format: Log Type - Time(microsec) - Message - Optional Info Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic S - QC_IMAGE_VERSION_STRING=BOOT.MXF.1.1-00470-MAKENA-1 S - IMAGE_VARIANT_STRING=SocMakenaWP S - OEM_IMAGE_VERSION_STRING=crm-ubuntu92 < machine is reset by hypervisor > Presumably the reset happens when controller is being shut down while still being used by the EFI framebuffer. I am not sure if we can conclude like that. Even if we shut off the controller when the framebuffer was still being fetched that should only cause a blank screen and not a reset because we really don't trigger a new register write / read while its fetching so as such there is no new hardware access. One thing I must accept is that there are two differences between sc8280xp where we are hitting these resets and sc7180/sc7280 chromebooks where we tested it more thoroughly without any such issues: 1) with the chromebooks we have depthcharge and not the QC UEFI. If we are suspecting a hand-off issue here, will it help if we try to disable the display in EFI by using "fastboot oem select-display-panel none" (assuming this is a fastboot enabled device) and see if you still hit the reset issue? 2) chromebooks used
[PATCH v2 20/21] drm/i915/dp: Read DPRX for all long HPD pulses
The TBT DP tunnel BW request logic in the Thunderbolt Connection Manager
depends on the GFX driver reading out the sink's DPRX capabilities in
response to a long HPD pulse. Since in i915 this read-out can be blocked
by another connector's/encoder's hotplug event handling (which is
serialized by drm_mode_config::connection_mutex), do a dummy DPRX read-out
in the encoder's HPD pulse handler (which is not blocked by other
encoders).
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 35ef17439038a..f7f8bd5742ad4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6162,6 +6162,7 @@ intel_dp_hpd_pulse(struct intel_digital_port *dig_port,
bool long_hpd)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
struct intel_dp *intel_dp = _port->dp;
+ u8 dpcd[DP_RECEIVER_CAP_SIZE];
if (dig_port->base.type == INTEL_OUTPUT_EDP &&
(long_hpd || !intel_pps_have_panel_power_or_vdd(intel_dp))) {
@@ -6184,6 +6185,17 @@ intel_dp_hpd_pulse(struct intel_digital_port *dig_port,
bool long_hpd)
dig_port->base.base.name,
long_hpd ? "long" : "short");
+ /*
+* TBT DP tunnels require the GFX driver to read out the DPRX caps in
+* response to long HPD pulses. The DP hotplug handler does that,
+* however the hotplug handler may be blocked by another
+* connector's/encoder's hotplug handler. Since the TBT CM may not
+* complete the DP tunnel BW request for the latter connector/encoder
+* waiting for this encoder's DPRX read, perform a dummy read here.
+*/
+ if (long_hpd)
+ intel_dp_read_dprx_caps(intel_dp, dpcd);
+
if (long_hpd) {
intel_dp->reset_link_params = true;
return IRQ_NONE;
--
2.39.2
[PATCH v2 19/21] drm/i915/dp: Suspend/resume DP tunnels
Suspend and resume DP tunnels during system suspend/resume, disabling
the BW allocation mode during suspend, re-enabling it after resume. This
reflects the link's BW management component (Thunderbolt CM) disabling
BWA during suspend. Before any BW requests the driver must read the
sink's DPRX capabilities (since the BW manager requires this
information, so snoops for it on AUX), so ensure this read takes place.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index a3dfcbb710027..35ef17439038a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -36,6 +36,7 @@
#include
#include
+#include
#include
#include
#include
@@ -3313,18 +3314,21 @@ void intel_dp_sync_state(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state)
{
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
-
- if (!crtc_state)
- return;
+ bool dpcd_updated = false;
/*
* Don't clobber DPCD if it's been already read out during output
* setup (eDP) or detect.
*/
- if (intel_dp->dpcd[DP_DPCD_REV] == 0)
+ if (crtc_state && intel_dp->dpcd[DP_DPCD_REV] == 0) {
intel_dp_get_dpcd(intel_dp);
+ dpcd_updated = true;
+ }
- intel_dp_reset_max_link_params(intel_dp);
+ intel_dp_tunnel_resume(intel_dp, crtc_state, dpcd_updated);
+
+ if (crtc_state)
+ intel_dp_reset_max_link_params(intel_dp);
}
bool intel_dp_initial_fastset_check(struct intel_encoder *encoder,
@@ -5947,6 +5951,8 @@ void intel_dp_encoder_suspend(struct intel_encoder
*intel_encoder)
struct intel_dp *intel_dp = enc_to_intel_dp(intel_encoder);
intel_pps_vdd_off_sync(intel_dp);
+
+ intel_dp_tunnel_suspend(intel_dp);
}
void intel_dp_encoder_shutdown(struct intel_encoder *intel_encoder)
--
2.39.2
[PATCH v2 21/21] drm/i915/dp: Enable DP tunnel BW allocation mode
Detect DP tunnels and enable the BW allocation mode on them. Send a
hotplug notification to userspace in response to a BW change.
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_display_driver.c | 20 +++
drivers/gpu/drm/i915/display/intel_dp.c | 14 +++--
2 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
b/drivers/gpu/drm/i915/display/intel_display_driver.c
index 4f7ba7eb03d27..87dd07e0d138d 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.c
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
@@ -35,6 +35,7 @@
#include "intel_dkl_phy.h"
#include "intel_dmc.h"
#include "intel_dp.h"
+#include "intel_dp_tunnel.h"
#include "intel_dpll.h"
#include "intel_dpll_mgr.h"
#include "intel_fb.h"
@@ -434,10 +435,8 @@ int intel_display_driver_probe_nogem(struct
drm_i915_private *i915)
for_each_pipe(i915, pipe) {
ret = intel_crtc_init(i915, pipe);
- if (ret) {
- intel_mode_config_cleanup(i915);
- return ret;
- }
+ if (ret)
+ goto err_mode_config;
}
intel_plane_possible_crtcs_init(i915);
@@ -457,6 +456,10 @@ int intel_display_driver_probe_nogem(struct
drm_i915_private *i915)
intel_vga_disable(i915);
intel_setup_outputs(i915);
+ ret = intel_dp_tunnel_mgr_init(i915);
+ if (ret)
+ goto err_hdcp;
+
intel_display_driver_disable_user_access(i915);
drm_modeset_lock_all(dev);
@@ -475,6 +478,13 @@ int intel_display_driver_probe_nogem(struct
drm_i915_private *i915)
ilk_wm_sanitize(i915);
return 0;
+
+err_hdcp:
+ intel_hdcp_component_fini(i915);
+err_mode_config:
+ intel_mode_config_cleanup(i915);
+
+ return ret;
}
/* part #3: call after gem init */
@@ -599,6 +609,8 @@ void intel_display_driver_remove_noirq(struct
drm_i915_private *i915)
intel_mode_config_cleanup(i915);
+ intel_dp_tunnel_mgr_cleanup(i915);
+
intel_overlay_cleanup(i915);
intel_gmbus_teardown(i915);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index f7f8bd5742ad4..789b5fa074fd0 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5726,6 +5726,7 @@ intel_dp_detect(struct drm_connector *connector,
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct intel_encoder *encoder = _port->base;
enum drm_connector_status status;
+ int ret;
drm_dbg_kms(_priv->drm, "[CONNECTOR:%d:%s]\n",
connector->base.id, connector->name);
@@ -5761,9 +5762,18 @@ intel_dp_detect(struct drm_connector *connector,
intel_dp->is_mst);
}
+ intel_dp_tunnel_disconnect(intel_dp);
+
goto out;
}
+ ret = intel_dp_tunnel_detect(intel_dp, ctx);
+ if (ret == -EDEADLK)
+ return ret;
+
+ if (ret == 1)
+ intel_connector->base.epoch_counter++;
+
intel_dp_detect_dsc_caps(intel_dp, intel_connector);
intel_dp_configure_mst(intel_dp);
@@ -5794,8 +5804,6 @@ intel_dp_detect(struct drm_connector *connector,
* with an IRQ_HPD, so force a link status check.
*/
if (!intel_dp_is_edp(intel_dp)) {
- int ret;
-
ret = intel_dp_retrain_link(encoder, ctx);
if (ret)
return ret;
@@ -5935,6 +5943,8 @@ void intel_dp_encoder_flush_work(struct drm_encoder
*encoder)
intel_dp_mst_encoder_cleanup(dig_port);
+ intel_dp_tunnel_destroy(intel_dp);
+
intel_pps_vdd_off_sync(intel_dp);
/*
--
2.39.2
[PATCH v2 18/21] drm/i915/dp: Call intel_dp_sync_state() always for DDI DP encoders
A follow-up change will need to resume DP tunnels during system resume, so call intel_dp_sync_state() always for DDI encoders, so this function can resume the tunnels for all DP connectors. Signed-off-by: Imre Deak Reviewed-by: Uma Shankar --- drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index ed7301808604d..c587a8efeafcf 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -4151,7 +4151,7 @@ static void intel_ddi_sync_state(struct intel_encoder *encoder, intel_tc_port_sanitize_mode(enc_to_dig_port(encoder), crtc_state); - if (crtc_state && intel_crtc_has_dp_encoder(crtc_state)) + if (intel_encoder_is_dp(encoder)) intel_dp_sync_state(encoder, crtc_state); } -- 2.39.2
[PATCH v2 15/21] drm/i915/dp: Compute DP tunnel BW during encoder state computation
Compute the BW required through a DP tunnel on links with such tunnels
detected and add the corresponding atomic state during a modeset.
v2:
- Fix error check of intel_dp_tunnel_compute_stream_bw(). (Ville)
- Move intel_dp_tunnel_atomic_cleanup_inherited_state() to this patch.
(Ville)
- Move intel_dp_tunnel_atomic_clear_stream_bw() to this patch.
Signed-off-by: Imre Deak
Reviewed-by: Uma Shankar (v1)
---
drivers/gpu/drm/i915/display/intel_atomic.c | 2 ++
drivers/gpu/drm/i915/display/intel_display.c | 2 ++
drivers/gpu/drm/i915/display/intel_dp.c | 16
drivers/gpu/drm/i915/display/intel_dp_mst.c | 13 -
4 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 798cb90361a83..2bb270f82932e 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -352,6 +352,8 @@ void intel_atomic_state_clear(struct drm_atomic_state *s)
/* state->internal not reset on purpose */
state->dpll_set = state->modeset = false;
+
+ intel_dp_tunnel_atomic_cleanup_inherited_state(state);
}
struct intel_crtc_state *
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 16973ebb7865d..20647c97e86fa 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4541,6 +4541,8 @@ intel_crtc_prepare_cleared_state(struct
intel_atomic_state *state,
/* free the old crtc_state->hw members */
intel_crtc_free_hw_state(crtc_state);
+ intel_dp_tunnel_atomic_clear_stream_bw(state, crtc_state);
+
/* FIXME: before the switch to atomic started, a new pipe_config was
* kzalloc'd. Code that depends on any field being zero should be
* fixed, so that the crtc_state can be safely duplicated. For now,
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index f4f748d95ad17..5ad7808788745 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2875,6 +2875,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
struct drm_connector_state *conn_state)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_atomic_state *state =
to_intel_atomic_state(conn_state->state);
struct drm_display_mode *adjusted_mode = _config->hw.adjusted_mode;
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
const struct drm_display_mode *fixed_mode;
@@ -2975,7 +2976,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
intel_dp_compute_vsc_sdp(intel_dp, pipe_config, conn_state);
intel_dp_compute_hdr_metadata_infoframe_sdp(intel_dp, pipe_config,
conn_state);
- return 0;
+ return intel_dp_tunnel_atomic_compute_stream_bw(state, intel_dp,
connector,
+ pipe_config);
}
void intel_dp_set_link_params(struct intel_dp *intel_dp,
@@ -6063,6 +6065,15 @@ static int intel_dp_connector_atomic_check(struct
drm_connector *conn,
return ret;
}
+ if (!intel_connector_needs_modeset(state, conn))
+ return 0;
+
+ ret = intel_dp_tunnel_atomic_check_state(state,
+intel_dp,
+intel_conn);
+ if (ret)
+ return ret;
+
/*
* We don't enable port sync on BDW due to missing w/as and
* due to not having adjusted the modeset sequence appropriately.
@@ -6070,9 +6081,6 @@ static int intel_dp_connector_atomic_check(struct
drm_connector *conn,
if (DISPLAY_VER(dev_priv) < 9)
return 0;
- if (!intel_connector_needs_modeset(state, conn))
- return 0;
-
if (conn->has_tile) {
ret = intel_modeset_tile_group(state, conn->tile_group->id);
if (ret)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 4b6c8ff974297..db1254b036f18 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -42,6 +42,7 @@
#include "intel_dp.h"
#include "intel_dp_hdcp.h"
#include "intel_dp_mst.h"
+#include "intel_dp_tunnel.h"
#include "intel_dpio_phy.h"
#include "intel_hdcp.h"
#include "intel_hotplug.h"
@@ -523,6 +524,7 @@ static int intel_dp_mst_compute_config(struct intel_encoder
*encoder,
struct drm_connector_state *conn_state)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_atomic_state *state =
to_intel_atomic_state(conn_state->state);
struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
[PATCH v2 17/21] drm/i915/dp: Handle DP tunnel IRQs
Handle DP tunnel IRQs a sink (or rather a BW management component like
the Thunderbolt Connection Manager) raises to signal the completion of a
BW request by the driver, or to signal any state change related to the
link BW.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 37 +++--
include/drm/display/drm_dp.h| 1 +
2 files changed, 29 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5ad7808788745..a3dfcbb710027 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4904,13 +4904,15 @@ static bool intel_dp_mst_link_status(struct intel_dp
*intel_dp)
* - %true if pending interrupts were serviced (or no interrupts were
* pending) w/o detecting an error condition.
* - %false if an error condition - like AUX failure or a loss of link - is
- * detected, which needs servicing from the hotplug work.
+ * detected, or another condition - like a DP tunnel BW state change - needs
+ * servicing from the hotplug work.
*/
static bool
intel_dp_check_mst_status(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
bool link_ok = true;
+ bool reprobe_needed = false;
drm_WARN_ON_ONCE(>drm, intel_dp->active_mst_links < 0);
@@ -4937,6 +4939,13 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
intel_dp_mst_hpd_irq(intel_dp, esi, ack);
+ if (esi[3] & DP_TUNNELING_IRQ) {
+ if
(drm_dp_tunnel_handle_irq(i915->display.dp_tunnel_mgr,
+_dp->aux))
+ reprobe_needed = true;
+ ack[3] |= DP_TUNNELING_IRQ;
+ }
+
if (!memchr_inv(ack, 0, sizeof(ack)))
break;
@@ -4947,7 +4956,7 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
drm_dp_mst_hpd_irq_send_new_request(_dp->mst_mgr);
}
- return link_ok;
+ return link_ok && !reprobe_needed;
}
static void
@@ -5304,23 +5313,32 @@ static void intel_dp_check_device_service_irq(struct
intel_dp *intel_dp)
drm_dbg_kms(>drm, "Sink specific irq unhandled\n");
}
-static void intel_dp_check_link_service_irq(struct intel_dp *intel_dp)
+static bool intel_dp_check_link_service_irq(struct intel_dp *intel_dp)
{
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ bool reprobe_needed = false;
u8 val;
if (intel_dp->dpcd[DP_DPCD_REV] < 0x11)
- return;
+ return false;
if (drm_dp_dpcd_readb(_dp->aux,
DP_LINK_SERVICE_IRQ_VECTOR_ESI0, ) != 1 ||
!val)
- return;
+ return false;
+
+ if ((val & DP_TUNNELING_IRQ) &&
+ drm_dp_tunnel_handle_irq(i915->display.dp_tunnel_mgr,
+_dp->aux))
+ reprobe_needed = true;
if (drm_dp_dpcd_writeb(_dp->aux,
DP_LINK_SERVICE_IRQ_VECTOR_ESI0, val) != 1)
- return;
+ return reprobe_needed;
if (val & HDMI_LINK_STATUS_CHANGED)
intel_dp_handle_hdmi_link_status_change(intel_dp);
+
+ return reprobe_needed;
}
/*
@@ -5341,6 +5359,7 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
u8 old_sink_count = intel_dp->sink_count;
+ bool reprobe_needed = false;
bool ret;
/*
@@ -5363,7 +5382,7 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
}
intel_dp_check_device_service_irq(intel_dp);
- intel_dp_check_link_service_irq(intel_dp);
+ reprobe_needed = intel_dp_check_link_service_irq(intel_dp);
/* Handle CEC interrupts, if any */
drm_dp_cec_irq(_dp->aux);
@@ -5390,10 +5409,10 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
* FIXME get rid of the ad-hoc phy test modeset code
* and properly incorporate it into the normal modeset.
*/
- return false;
+ reprobe_needed = true;
}
- return true;
+ return !reprobe_needed;
}
/* XXX this is probably wrong for multiple downstream ports */
diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index 8bfd5d007be8d..4891bd916d26a 100644
--- a/include/drm/display/drm_dp.h
+++ b/include/drm/display/drm_dp.h
@@ -1081,6 +1081,7 @@
# define STREAM_STATUS_CHANGED (1 << 2)
# define HDMI_LINK_STATUS_CHANGED(1 << 3)
# define CONNECTED_OFF_ENTRY_REQUESTED (1 << 4)
+# define DP_TUNNELING_IRQ(1 << 5)
#define DP_PSR_ERROR_STATUS 0x2006 /* XXX 1.2? */
# define DP_PSR_LINK_CRC_ERROR
[PATCH v2 16/21] drm/i915/dp: Allocate/free DP tunnel BW in the encoder enable/disable hooks
Allocate and free the DP tunnel BW required by a stream while enabling/disabling the stream during a modeset. v2: - Move the allocation up from encoder hooks to intel_atomic_commit_tail(). Signed-off-by: Imre Deak Reviewed-by: Uma Shankar (v1) --- drivers/gpu/drm/i915/display/intel_ddi.c | 1 + drivers/gpu/drm/i915/display/intel_display.c | 2 ++ 2 files changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index bea4415902044..ed7301808604d 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -54,6 +54,7 @@ #include "intel_dp_aux.h" #include "intel_dp_link_training.h" #include "intel_dp_mst.h" +#include "intel_dp_tunnel.h" #include "intel_dpio_phy.h" #include "intel_dsi.h" #include "intel_fdi.h" diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 20647c97e86fa..445efe0087cde 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -7123,6 +7123,8 @@ static void intel_atomic_commit_tail(struct intel_atomic_state *state) intel_commit_modeset_disables(state); + intel_dp_tunnel_atomic_alloc_bw(state); + /* FIXME: Eventually get rid of our crtc->config pointer */ for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) crtc->config = new_crtc_state; -- 2.39.2
[PATCH v2 14/21] drm/i915/dp: Account for tunnel BW limit in intel_dp_max_link_data_rate()
Take any link BW limitation into account in
intel_dp_max_link_data_rate(). Such a limitation can be due to multiple
displays on (Thunderbolt) links with DP tunnels sharing the link BW.
Signed-off-by: Imre Deak
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 32 +
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index d0452d3e534a7..f4f748d95ad17 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -63,6 +63,7 @@
#include "intel_dp_hdcp.h"
#include "intel_dp_link_training.h"
#include "intel_dp_mst.h"
+#include "intel_dp_tunnel.h"
#include "intel_dpio_phy.h"
#include "intel_dpll.h"
#include "intel_fifo_underrun.h"
@@ -152,6 +153,22 @@ int intel_dp_link_symbol_clock(int rate)
return DIV_ROUND_CLOSEST(rate * 10, intel_dp_link_symbol_size(rate));
}
+static int max_dprx_rate(struct intel_dp *intel_dp)
+{
+ if (intel_dp_tunnel_bw_alloc_is_enabled(intel_dp))
+ return drm_dp_tunnel_max_dprx_rate(intel_dp->tunnel);
+
+ return drm_dp_bw_code_to_link_rate(intel_dp->dpcd[DP_MAX_LINK_RATE]);
+}
+
+static int max_dprx_lane_count(struct intel_dp *intel_dp)
+{
+ if (intel_dp_tunnel_bw_alloc_is_enabled(intel_dp))
+ return drm_dp_tunnel_max_dprx_lane_count(intel_dp->tunnel);
+
+ return drm_dp_max_lane_count(intel_dp->dpcd);
+}
+
static void intel_dp_set_default_sink_rates(struct intel_dp *intel_dp)
{
intel_dp->sink_rates[0] = 162000;
@@ -180,7 +197,7 @@ static void intel_dp_set_dpcd_sink_rates(struct intel_dp
*intel_dp)
/*
* Sink rates for 8b/10b.
*/
- max_rate =
drm_dp_bw_code_to_link_rate(intel_dp->dpcd[DP_MAX_LINK_RATE]);
+ max_rate = max_dprx_rate(intel_dp);
max_lttpr_rate =
drm_dp_lttpr_max_link_rate(intel_dp->lttpr_common_caps);
if (max_lttpr_rate)
max_rate = min(max_rate, max_lttpr_rate);
@@ -259,7 +276,7 @@ static void intel_dp_set_max_sink_lane_count(struct
intel_dp *intel_dp)
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct intel_encoder *encoder = _dig_port->base;
- intel_dp->max_sink_lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
+ intel_dp->max_sink_lane_count = max_dprx_lane_count(intel_dp);
switch (intel_dp->max_sink_lane_count) {
case 1:
@@ -389,14 +406,21 @@ int intel_dp_effective_data_rate(int pixel_clock, int
bpp_x16,
* @max_dprx_rate: Maximum data rate of the DPRX
* @max_dprx_lanes: Maximum lane count of the DPRX
*
- * Calculate the maximum data rate for the provided link parameters.
+ * Calculate the maximum data rate for the provided link parameters taking into
+ * account any BW limitations by a DP tunnel attached to @intel_dp.
*
* Returns the maximum data rate in kBps units.
*/
int intel_dp_max_link_data_rate(struct intel_dp *intel_dp,
int max_dprx_rate, int max_dprx_lanes)
{
- return drm_dp_max_dprx_data_rate(max_dprx_rate, max_dprx_lanes);
+ int max_rate = drm_dp_max_dprx_data_rate(max_dprx_rate, max_dprx_lanes);
+
+ if (intel_dp_tunnel_bw_alloc_is_enabled(intel_dp))
+ max_rate = min(max_rate,
+ drm_dp_tunnel_available_bw(intel_dp->tunnel));
+
+ return max_rate;
}
bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp)
--
2.39.2
[PATCH v2 12/21] drm/i915/dp: Add support for DP tunnel BW allocation
Add support to enable the DP tunnel BW allocation mode. Follow-up patches will call the required helpers added here to prepare for a modeset on a link with DP tunnels, the last change in the patchset actually enabling BWA. With BWA enabled, the driver will expose the full mode list a display supports, regardless of any BW limitation on a shared (Thunderbolt) link. Such BW limits will be checked against only during a modeset, when the driver has the full knowledge of each display's BW requirement. If the link BW changes in a way that a connector's modelist may also change, userspace will get a hotplug notification for all the connectors sharing the same link (so it can adjust the mode used for a display). The BW limitation can change at any point, asynchronously to modesets on a given connector, so a modeset can fail even though the atomic check for it passed. In such scenarios userspace will get a bad link notification and in response is supposed to retry the modeset. v2: - Fix old vs. new connector state in intel_dp_tunnel_atomic_check_state(). (Ville) - Fix propagating the error from intel_dp_tunnel_atomic_compute_stream_bw(). (Ville) - Move tunnel==NULL checks from driver to DRM core helpers. (Ville) - Simplify return flow from intel_dp_tunnel_detect(). (Ville) - s/dp_tunnel_state/inherited_dp_tunnels (Ville) - Simplify struct intel_dp_tunnel_inherited_state. (Ville) - Unconstify object pointers (vs. states) where possible. (Ville) - Init crtc_state while declaring it in check_group_state(). (Ville) - Join obj->base.id, obj->name arg lines in debug prints to reduce LOC. (Ville) - Add/rework intel_dp_tunnel_atomic_alloc_bw() to prepare for moving the BW allocation from encoder hooks up to intel_atomic_commit_tail() later in the patchset. - Disable BW alloc mode during system suspend. - Allocate the required BW for all tunnels during system resume. - Add intel_dp_tunnel_atomic_clear_stream_bw() instead of the open-coded sequence in a follow-up patch. - Add function documentation to all exported functions. - Add CONFIG_USB4 dependency to CONFIG_DRM_I915_DP_TUNNEL. Cc: Ville Syrjälä Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/Kconfig | 14 + drivers/gpu/drm/i915/Kconfig.debug| 1 + drivers/gpu/drm/i915/Makefile | 3 + drivers/gpu/drm/i915/display/intel_atomic.c | 2 + drivers/gpu/drm/i915/display/intel_crtc.c | 25 + drivers/gpu/drm/i915/display/intel_crtc.h | 1 + .../gpu/drm/i915/display/intel_display_core.h | 1 + .../drm/i915/display/intel_display_types.h| 9 + .../gpu/drm/i915/display/intel_dp_tunnel.c| 815 ++ .../gpu/drm/i915/display/intel_dp_tunnel.h| 133 +++ 10 files changed, 1004 insertions(+) create mode 100644 drivers/gpu/drm/i915/display/intel_dp_tunnel.c create mode 100644 drivers/gpu/drm/i915/display/intel_dp_tunnel.h diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index 3089029abba48..5932024f8f954 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -155,6 +155,20 @@ config DRM_I915_PXP protected session and manage the status of the alive software session, as well as its life cycle. +config DRM_I915_DP_TUNNEL + bool "Enable DP tunnel support" + depends on DRM_I915 + depends on USB4 + select DRM_DISPLAY_DP_TUNNEL + default y + help + Choose this option to detect DP tunnels and enable the Bandwidth + Allocation mode for such tunnels. This allows using the maximum + resolution allowed by the link BW on all displays sharing the + link BW, for instance on a Thunderbolt link. + + If in doubt, say "Y". + menu "drm/i915 Debugging" depends on DRM_I915 depends on EXPERT diff --git a/drivers/gpu/drm/i915/Kconfig.debug b/drivers/gpu/drm/i915/Kconfig.debug index 5b7162076850c..bc18e2d9ea05d 100644 --- a/drivers/gpu/drm/i915/Kconfig.debug +++ b/drivers/gpu/drm/i915/Kconfig.debug @@ -28,6 +28,7 @@ config DRM_I915_DEBUG select STACKDEPOT select STACKTRACE select DRM_DP_AUX_CHARDEV + select DRM_DISPLAY_DEBUG_DP_TUNNEL_STATE if DRM_I915_DP_TUNNEL select X86_MSR # used by igt/pm_rpm select DRM_VGEM # used by igt/prime_vgem (dmabuf interop checks) select DRM_DEBUG_MM if DRM=y diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index c13f14edb5088..3ef6ed41e62b4 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -369,6 +369,9 @@ i915-y += \ display/vlv_dsi.o \ display/vlv_dsi_pll.o +i915-$(CONFIG_DRM_I915_DP_TUNNEL) += \ + display/intel_dp_tunnel.o + i915-y += \ i915_perf.o diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c b/drivers/gpu/drm/i915/display/intel_atomic.c index ec0d5168b5035..96ab37e158995 100644 --- a/drivers/gpu/drm/i915/display/intel_atomic.c +++
[PATCH v2 10/21] drm/i915/dp: Add intel_dp_max_link_data_rate()
Add intel_dp_max_link_data_rate() to get the link BW vs. the sink DPRX
BW used by a follow-up patch enabling the DP tunnel BW allocation mode.
The link BW can be below the DPRX BW due to a BW limitation on a link
shared by multiple sinks.
Signed-off-by: Imre Deak
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 32 +
drivers/gpu/drm/i915/display/intel_dp.h | 2 ++
drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 +-
3 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 520c04245c2df..d9e75922ff8f5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -383,6 +383,22 @@ int intel_dp_effective_data_rate(int pixel_clock, int
bpp_x16,
100 * 16 * 8);
}
+/**
+ * intel_dp_max_link_data_rate: Calculate the maximum rate for the given link
params
+ * @intel_dp: Intel DP object
+ * @max_dprx_rate: Maximum data rate of the DPRX
+ * @max_dprx_lanes: Maximum lane count of the DPRX
+ *
+ * Calculate the maximum data rate for the provided link parameters.
+ *
+ * Returns the maximum data rate in kBps units.
+ */
+int intel_dp_max_link_data_rate(struct intel_dp *intel_dp,
+ int max_dprx_rate, int max_dprx_lanes)
+{
+ return drm_dp_max_dprx_data_rate(max_dprx_rate, max_dprx_lanes);
+}
+
bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
@@ -612,7 +628,7 @@ static bool intel_dp_can_link_train_fallback_for_edp(struct
intel_dp *intel_dp,
int mode_rate, max_rate;
mode_rate = intel_dp_link_required(fixed_mode->clock, 18);
- max_rate = drm_dp_max_dprx_data_rate(link_rate, lane_count);
+ max_rate = intel_dp_max_link_data_rate(intel_dp, link_rate, lane_count);
if (mode_rate > max_rate)
return false;
@@ -1216,7 +1232,8 @@ intel_dp_mode_valid(struct drm_connector *_connector,
max_link_clock = intel_dp_max_link_rate(intel_dp);
max_lanes = intel_dp_max_lane_count(intel_dp);
- max_rate = drm_dp_max_dprx_data_rate(max_link_clock, max_lanes);
+ max_rate = intel_dp_max_link_data_rate(intel_dp, max_link_clock,
max_lanes);
+
mode_rate = intel_dp_link_required(target_clock,
intel_dp_mode_min_output_bpp(connector, mode));
@@ -1566,8 +1583,10 @@ intel_dp_compute_link_config_wide(struct intel_dp
*intel_dp,
for (lane_count = limits->min_lane_count;
lane_count <= limits->max_lane_count;
lane_count <<= 1) {
- link_avail =
drm_dp_max_dprx_data_rate(link_rate,
-
lane_count);
+ link_avail =
intel_dp_max_link_data_rate(intel_dp,
+
link_rate,
+
lane_count);
+
if (mode_rate <= link_avail) {
pipe_config->lane_count = lane_count;
@@ -2427,8 +2446,9 @@ intel_dp_compute_link_config(struct intel_encoder
*encoder,
pipe_config->pipe_bpp,
BPP_X16_ARGS(pipe_config->dsc.compressed_bpp_x16),
intel_dp_config_required_rate(pipe_config),
- drm_dp_max_dprx_data_rate(pipe_config->port_clock,
- pipe_config->lane_count));
+ intel_dp_max_link_data_rate(intel_dp,
+ pipe_config->port_clock,
+ pipe_config->lane_count));
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index 10e859b62bbe9..564a587e2d018 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -115,6 +115,8 @@ bool intel_dp_get_colorimetry_status(struct intel_dp
*intel_dp);
int intel_dp_link_required(int pixel_clock, int bpp);
int intel_dp_effective_data_rate(int pixel_clock, int bpp_x16,
int bw_overhead);
+int intel_dp_max_link_data_rate(struct intel_dp *intel_dp,
+ int max_dprx_rate, int max_dprx_lanes);
bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp);
bool intel_dp_needs_vsc_sdp(const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index b4d4bb90126e9..4b6c8ff974297 100644
---
[PATCH v2 11/21] drm/i915/dp: Add way to get active pipes with syncing commits
Add a way to get the active pipes through a given DP port by syncing
against a related pending non-blocking commit. Atm
intel_dp_get_active_pipes() will only try to sync a given pipe and if
that would block ignore the pipe. A follow-up change enabling the DP
tunnel BW allocation mode will need to ensure that all active pipes are
returned.
This change will use intel_crtc_state::uapi.commit instead of the
corresponding commit in the connector state. This shouldn't make a
difference, since the two commit objects match for an active pipe.
A follow-up patchset will remove syncing during TC port reset, which
should reset a port/pipe even if syncing against a commit would block.
Syncing OTOH is not needed there, since the commit used for the reset
implies a sync already. For now add a TODO comment for this.
v2:
- Add a separate function to try-sync the pipes. (Ville)
Cc: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_crtc.c | 27 +++
drivers/gpu/drm/i915/display/intel_crtc.h | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 6 ++---
drivers/gpu/drm/i915/display/intel_tc.c | 7 ++
4 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
b/drivers/gpu/drm/i915/display/intel_crtc.c
index 25593f6aae7de..17ed2e62cc66a 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -654,3 +654,30 @@ void intel_pipe_update_end(struct intel_atomic_state
*state,
out:
intel_psr_unlock(new_crtc_state);
}
+
+/**
+ * intel_crtc_try_sync_pipes - Try syncing pending commits on a set of pipes
+ * @i915: i915 device object
+ * @pipe_mask: Mask of pipes to sync
+ *
+ * Try to sync a pending non-blocking commit for the provided pipes in
+ * @pipe_mask. The commit won't be synced if this would block.
+ *
+ * Return a mask of the pipes that got synced or didn't need syncing.
+ */
+u32 intel_crtc_try_sync_pipes(struct drm_i915_private *i915, u32 pipe_mask)
+{
+ struct intel_crtc *crtc;
+ u32 synced = 0;
+
+ for_each_intel_crtc_in_pipe_mask(>drm, crtc, pipe_mask) {
+ const struct intel_crtc_state *crtc_state =
+ to_intel_crtc_state(crtc->base.state);
+
+ if (!crtc_state->uapi.commit ||
+ try_wait_for_completion(_state->uapi.commit->hw_done))
+ synced |= BIT(crtc->pipe);
+ }
+
+ return synced;
+}
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.h
b/drivers/gpu/drm/i915/display/intel_crtc.h
index 22d7993d1f0ba..71a5b93166da7 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.h
+++ b/drivers/gpu/drm/i915/display/intel_crtc.h
@@ -47,5 +47,6 @@ struct intel_crtc *intel_crtc_for_pipe(struct
drm_i915_private *i915,
void intel_wait_for_vblank_if_active(struct drm_i915_private *i915,
enum pipe pipe);
void intel_crtc_wait_for_next_vblank(struct intel_crtc *crtc);
+u32 intel_crtc_try_sync_pipes(struct drm_i915_private *i915, u32 pipe_mask);
#endif
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index d9e75922ff8f5..d0452d3e534a7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5048,10 +5048,6 @@ int intel_dp_get_active_pipes(struct intel_dp *intel_dp,
if (!crtc_state->hw.active)
continue;
- if (conn_state->commit &&
- !try_wait_for_completion(_state->commit->hw_done))
- continue;
-
*pipe_mask |= BIT(crtc->pipe);
}
drm_connector_list_iter_end(_iter);
@@ -5091,6 +5087,8 @@ int intel_dp_retrain_link(struct intel_encoder *encoder,
if (ret)
return ret;
+ pipe_mask &= intel_crtc_try_sync_pipes(dev_priv, pipe_mask);
+
if (pipe_mask == 0)
return 0;
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index 6b374d481cd9e..14d17903a81f5 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -7,6 +7,7 @@
#include "i915_reg.h"
#include "intel_atomic.h"
#include "intel_cx0_phy_regs.h"
+#include "intel_crtc.h"
#include "intel_ddi.h"
#include "intel_de.h"
#include "intel_display.h"
@@ -1663,6 +1664,12 @@ static int reset_link_commit(struct intel_tc_port *tc,
if (ret)
return ret;
+ /*
+* TODO: remove the following, since an output must be reset
+* even if we had to wait for a non-blocking commit on a pipe.
+*/
+ pipe_mask &= intel_crtc_try_sync_pipes(i915, pipe_mask);
+
if (!pipe_mask)
return 0;
--
2.39.2
[PATCH v2 13/21] drm/i915/dp: Add DP tunnel atomic state and check BW limit
Add the atomic state during a modeset required to enable the DP tunnel BW allocation mode on links where such a tunnel was detected. This state applies to an already enabled output, the state added for a newly enabled output will be computed and added/cleared to/from the atomic state in a follow-up patch. v2: - s/old_crtc_state/crtc_state in intel_crtc_duplicate_state(). - Move intel_dp_tunnel_atomic_cleanup_inherited_state() to a follow-up patch adding the corresponding state. (Ville) - Move intel_dp_tunnel_atomic_clear_stream_bw() to a follow-up patch adding the corresponding state. Cc: Ville Syrjälä Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/display/intel_atomic.c | 6 ++ drivers/gpu/drm/i915/display/intel_display.c | 12 drivers/gpu/drm/i915/display/intel_link_bw.c | 5 + 3 files changed, 23 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c b/drivers/gpu/drm/i915/display/intel_atomic.c index 96ab37e158995..798cb90361a83 100644 --- a/drivers/gpu/drm/i915/display/intel_atomic.c +++ b/drivers/gpu/drm/i915/display/intel_atomic.c @@ -260,6 +260,10 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc) if (crtc_state->post_csc_lut) drm_property_blob_get(crtc_state->post_csc_lut); + if (crtc_state->dp_tunnel_ref.tunnel) + drm_dp_tunnel_ref_get(crtc_state->dp_tunnel_ref.tunnel, + _state->dp_tunnel_ref); + crtc_state->update_pipe = false; crtc_state->update_m_n = false; crtc_state->update_lrr = false; @@ -311,6 +315,8 @@ intel_crtc_destroy_state(struct drm_crtc *crtc, __drm_atomic_helper_crtc_destroy_state(_state->uapi); intel_crtc_free_hw_state(crtc_state); + if (crtc_state->dp_tunnel_ref.tunnel) + drm_dp_tunnel_ref_put(_state->dp_tunnel_ref); kfree(crtc_state); } diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index e1a4200f67a7e..16973ebb7865d 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -33,6 +33,7 @@ #include #include +#include #include #include #include @@ -73,6 +74,7 @@ #include "intel_dp.h" #include "intel_dp_link_training.h" #include "intel_dp_mst.h" +#include "intel_dp_tunnel.h" #include "intel_dpll.h" #include "intel_dpll_mgr.h" #include "intel_dpt.h" @@ -4490,6 +4492,8 @@ copy_bigjoiner_crtc_state_modeset(struct intel_atomic_state *state, saved_state->crc_enabled = slave_crtc_state->crc_enabled; intel_crtc_free_hw_state(slave_crtc_state); + if (slave_crtc_state->dp_tunnel_ref.tunnel) + drm_dp_tunnel_ref_put(_crtc_state->dp_tunnel_ref); memcpy(slave_crtc_state, saved_state, sizeof(*slave_crtc_state)); kfree(saved_state); @@ -4505,6 +4509,10 @@ copy_bigjoiner_crtc_state_modeset(struct intel_atomic_state *state, _crtc_state->hw.adjusted_mode); slave_crtc_state->hw.scaling_filter = master_crtc_state->hw.scaling_filter; + if (master_crtc_state->dp_tunnel_ref.tunnel) + drm_dp_tunnel_ref_get(master_crtc_state->dp_tunnel_ref.tunnel, + _crtc_state->dp_tunnel_ref); + copy_bigjoiner_crtc_state_nomodeset(state, slave_crtc); slave_crtc_state->uapi.mode_changed = master_crtc_state->uapi.mode_changed; @@ -5365,6 +5373,10 @@ static int intel_modeset_pipe(struct intel_atomic_state *state, if (ret) return ret; + ret = intel_dp_tunnel_atomic_add_state_for_crtc(state, crtc); + if (ret) + return ret; + ret = intel_dp_mst_add_topology_state_for_crtc(state, crtc); if (ret) return ret; diff --git a/drivers/gpu/drm/i915/display/intel_link_bw.c b/drivers/gpu/drm/i915/display/intel_link_bw.c index 27ea858897c9f..dfd7d5e23f3fa 100644 --- a/drivers/gpu/drm/i915/display/intel_link_bw.c +++ b/drivers/gpu/drm/i915/display/intel_link_bw.c @@ -9,6 +9,7 @@ #include "intel_crtc.h" #include "intel_display_types.h" #include "intel_dp_mst.h" +#include "intel_dp_tunnel.h" #include "intel_fdi.h" #include "intel_link_bw.h" @@ -163,6 +164,10 @@ static int check_all_link_config(struct intel_atomic_state *state, if (ret) return ret; + ret = intel_dp_tunnel_atomic_check_link(state, limits); + if (ret) + return ret; + ret = intel_fdi_atomic_check_link(state, limits); if (ret) return ret; -- 2.39.2
[PATCH v2 08/21] drm/i915/dp: Factor out intel_dp_update_sink_caps()
Factor out a function updating the sink's link rate and lane count
capabilities, used by a follow-up patch enabling the DP tunnel BW
allocation mode.
Signed-off-by: Imre Deak
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 11 ---
drivers/gpu/drm/i915/display/intel_dp.h | 1 +
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 20e04cbdffcae..520c04245c2df 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3944,6 +3944,13 @@ intel_dp_has_sink_count(struct intel_dp *intel_dp)
_dp->desc);
}
+void intel_dp_update_sink_caps(struct intel_dp *intel_dp)
+{
+ intel_dp_set_sink_rates(intel_dp);
+ intel_dp_set_max_sink_lane_count(intel_dp);
+ intel_dp_set_common_rates(intel_dp);
+}
+
static bool
intel_dp_get_dpcd(struct intel_dp *intel_dp)
{
@@ -3960,9 +3967,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
drm_dp_read_desc(_dp->aux, _dp->desc,
drm_dp_is_branch(intel_dp->dpcd));
- intel_dp_set_sink_rates(intel_dp);
- intel_dp_set_max_sink_lane_count(intel_dp);
- intel_dp_set_common_rates(intel_dp);
+ intel_dp_update_sink_caps(intel_dp);
}
if (intel_dp_has_sink_count(intel_dp)) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index ee0600b4425e1..10e859b62bbe9 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -104,6 +104,7 @@ int intel_dp_config_required_rate(const struct
intel_crtc_state *crtc_state);
int intel_dp_rate_select(struct intel_dp *intel_dp, int rate);
int intel_dp_max_common_rate(struct intel_dp *intel_dp);
int intel_dp_max_common_lane_count(struct intel_dp *intel_dp);
+void intel_dp_update_sink_caps(struct intel_dp *intel_dp);
void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
u8 *link_bw, u8 *rate_select);
--
2.39.2
[PATCH v2 09/21] drm/i915/dp: Factor out intel_dp_read_dprx_caps()
Factor out a function to read the sink's DPRX capabilities used by a
follow-up patch enabling the DP tunnel BW allocation mode.
Signed-off-by: Imre Deak
Reviewed-by: Uma Shankar
---
.../drm/i915/display/intel_dp_link_training.c | 30 +++
.../drm/i915/display/intel_dp_link_training.h | 1 +
2 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 7b140cbf8dd31..fb84ca98bb7ab 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -162,6 +162,28 @@ static int intel_dp_init_lttpr(struct intel_dp *intel_dp,
const u8 dpcd[DP_RECEI
return lttpr_count;
}
+int intel_dp_read_dprx_caps(struct intel_dp *intel_dp, u8
dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+
+ if (intel_dp_is_edp(intel_dp))
+ return 0;
+
+ /*
+* Detecting LTTPRs must be avoided on platforms with an AUX timeout
+* period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1).
+*/
+ if (DISPLAY_VER(i915) >= 10 && !IS_GEMINILAKE(i915))
+ if (drm_dp_dpcd_probe(_dp->aux,
+
DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV))
+ return -EIO;
+
+ if (drm_dp_read_dpcd_caps(_dp->aux, dpcd))
+ return -EIO;
+
+ return 0;
+}
+
/**
* intel_dp_init_lttpr_and_dprx_caps - detect LTTPR and DPRX caps, init the
LTTPR link training mode
* @intel_dp: Intel DP struct
@@ -192,12 +214,10 @@ int intel_dp_init_lttpr_and_dprx_caps(struct intel_dp
*intel_dp)
if (!intel_dp_is_edp(intel_dp) &&
(DISPLAY_VER(i915) >= 10 && !IS_GEMINILAKE(i915))) {
u8 dpcd[DP_RECEIVER_CAP_SIZE];
+ int err = intel_dp_read_dprx_caps(intel_dp, dpcd);
- if (drm_dp_dpcd_probe(_dp->aux,
DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV))
- return -EIO;
-
- if (drm_dp_read_dpcd_caps(_dp->aux, dpcd))
- return -EIO;
+ if (err != 0)
+ return err;
lttpr_count = intel_dp_init_lttpr(intel_dp, dpcd);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
index 2c8f2775891b0..19836a8a4f904 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
@@ -11,6 +11,7 @@
struct intel_crtc_state;
struct intel_dp;
+int intel_dp_read_dprx_caps(struct intel_dp *intel_dp, u8
dpcd[DP_RECEIVER_CAP_SIZE]);
int intel_dp_init_lttpr_and_dprx_caps(struct intel_dp *intel_dp);
void intel_dp_get_adjust_train(struct intel_dp *intel_dp,
--
2.39.2
[PATCH v2 07/21] drm/i915/dp: Export intel_dp_max_common_rate/lane_count()
Export intel_dp_max_common_rate() and intel_dp_max_lane_count() used by
a follow-up patch enabling the DP tunnel BW allocation mode.
Signed-off-by: Imre Deak
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
drivers/gpu/drm/i915/display/intel_dp.h | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index c7e3e4efc324e..20e04cbdffcae 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -309,7 +309,7 @@ static int intel_dp_common_rate(struct intel_dp *intel_dp,
int index)
}
/* Theoretical max between source and sink */
-static int intel_dp_max_common_rate(struct intel_dp *intel_dp)
+int intel_dp_max_common_rate(struct intel_dp *intel_dp)
{
return intel_dp_common_rate(intel_dp, intel_dp->num_common_rates - 1);
}
@@ -326,7 +326,7 @@ static int intel_dp_max_source_lane_count(struct
intel_digital_port *dig_port)
}
/* Theoretical max between source and sink */
-static int intel_dp_max_common_lane_count(struct intel_dp *intel_dp)
+int intel_dp_max_common_lane_count(struct intel_dp *intel_dp)
{
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
int source_max = intel_dp_max_source_lane_count(dig_port);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index 4667870fed31a..ee0600b4425e1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -102,6 +102,8 @@ int intel_dp_max_link_rate(struct intel_dp *intel_dp);
int intel_dp_max_lane_count(struct intel_dp *intel_dp);
int intel_dp_config_required_rate(const struct intel_crtc_state *crtc_state);
int intel_dp_rate_select(struct intel_dp *intel_dp, int rate);
+int intel_dp_max_common_rate(struct intel_dp *intel_dp);
+int intel_dp_max_common_lane_count(struct intel_dp *intel_dp);
void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
u8 *link_bw, u8 *rate_select);
--
2.39.2
[PATCH v2 04/21] drm/i915/dp: Add support to notify MST connectors to retry modesets
On shared (Thunderbolt) links with DP tunnels, the modeset may need to
be retried on all connectors on the link due to a link BW limitation
arising only after the atomic check phase. To support this add a helper
function queuing a work to retry the modeset on a given port's connector
and at the same time any MST connector with streams through the same
port. A follow-up change enabling the DP tunnel Bandwidth Allocation
Mode will take this into use.
v2:
- Send the uevent only to enabled MST connectors. (Jouni)
Cc: Jouni Högander
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_display.c | 5 ++-
drivers/gpu/drm/i915/display/intel_dp.c | 45 ++-
drivers/gpu/drm/i915/display/intel_dp.h | 6 +++
.../drm/i915/display/intel_dp_link_training.c | 3 +-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +
5 files changed, 55 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 485c38d71f106..2ee26d19c200b 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8085,8 +8085,9 @@ void intel_hpd_poll_fini(struct drm_i915_private *i915)
/* Kill all the work that may have been queued by hpd. */
drm_connector_list_iter_begin(>drm, _iter);
for_each_intel_connector_iter(connector, _iter) {
- if (connector->modeset_retry_work.func)
- cancel_work_sync(>modeset_retry_work);
+ if (connector->modeset_retry_work.func &&
+ cancel_work_sync(>modeset_retry_work))
+ drm_connector_put(>base);
if (connector->hdcp.shim) {
cancel_delayed_work_sync(>hdcp.check_work);
cancel_work_sync(>hdcp.prop_work);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 217196196e50a..88606e336a920 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2842,6 +2842,40 @@ intel_dp_audio_compute_config(struct intel_encoder
*encoder,
intel_dp_is_uhbr(pipe_config);
}
+void intel_dp_queue_modeset_retry_work(struct intel_connector *connector)
+{
+ struct drm_i915_private *i915 = to_i915(connector->base.dev);
+
+ drm_connector_get(>base);
+ if (!queue_work(i915->unordered_wq, >modeset_retry_work))
+ drm_connector_put(>base);
+}
+
+void
+intel_dp_queue_modeset_retry_for_link(struct intel_atomic_state *state,
+ struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state)
+{
+ struct intel_connector *connector;
+ struct intel_digital_connector_state *conn_state;
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ int i;
+
+ if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST)) {
+ intel_dp_queue_modeset_retry_work(intel_dp->attached_connector);
+
+ return;
+ }
+
+ for_each_new_intel_connector_in_state(state, connector, conn_state, i) {
+ if (!conn_state->base.crtc)
+ continue;
+
+ if (connector->mst_port == intel_dp)
+ intel_dp_queue_modeset_retry_work(connector);
+ }
+}
+
int
intel_dp_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
@@ -6441,6 +6475,14 @@ static void intel_dp_modeset_retry_work_fn(struct
work_struct *work)
mutex_unlock(>dev->mode_config.mutex);
/* Send Hotplug uevent so userspace can reprobe */
drm_kms_helper_connector_hotplug_event(connector);
+
+ drm_connector_put(connector);
+}
+
+void intel_dp_init_modeset_retry_work(struct intel_connector *connector)
+{
+ INIT_WORK(>modeset_retry_work,
+ intel_dp_modeset_retry_work_fn);
}
bool
@@ -6457,8 +6499,7 @@ intel_dp_init_connector(struct intel_digital_port
*dig_port,
int type;
/* Initialize the work for modeset in case of link train failure */
- INIT_WORK(_connector->modeset_retry_work,
- intel_dp_modeset_retry_work_fn);
+ intel_dp_init_modeset_retry_work(intel_connector);
if (drm_WARN(dev, dig_port->max_lanes < 1,
"Not enough lanes (%d) for DP on [ENCODER:%d:%s]\n",
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index 530cc97bc42f4..e2875e03afba0 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -43,6 +43,12 @@ void intel_dp_adjust_compliance_config(struct intel_dp
*intel_dp,
bool intel_dp_limited_color_range(const struct intel_crtc_state *crtc_state,
const struct drm_connector_state
[PATCH v2 06/21] drm/i915/dp: Factor out intel_dp_config_required_rate()
Factor out intel_dp_config_required_rate() used by a follow-up patch
enabling the DP tunnel BW allocation mode.
Signed-off-by: Imre Deak
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 43 +++--
drivers/gpu/drm/i915/display/intel_dp.h | 1 +
2 files changed, 20 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0a2ee43392142..c7e3e4efc324e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2343,6 +2343,17 @@ intel_dp_compute_config_limits(struct intel_dp *intel_dp,
limits);
}
+int intel_dp_config_required_rate(const struct intel_crtc_state *crtc_state)
+{
+ const struct drm_display_mode *adjusted_mode =
+ _state->hw.adjusted_mode;
+ int bpp = crtc_state->dsc.compression_enable ?
+ to_bpp_int_roundup(crtc_state->dsc.compressed_bpp_x16) :
+ crtc_state->pipe_bpp;
+
+ return intel_dp_link_required(adjusted_mode->crtc_clock, bpp);
+}
+
static int
intel_dp_compute_link_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
@@ -2410,31 +2421,15 @@ intel_dp_compute_link_config(struct intel_encoder
*encoder,
return ret;
}
- if (pipe_config->dsc.compression_enable) {
- drm_dbg_kms(>drm,
- "DP lane count %d clock %d Input bpp %d Compressed
bpp " BPP_X16_FMT "\n",
- pipe_config->lane_count, pipe_config->port_clock,
- pipe_config->pipe_bpp,
- BPP_X16_ARGS(pipe_config->dsc.compressed_bpp_x16));
+ drm_dbg_kms(>drm,
+ "DP lane count %d clock %d bpp input %d compressed "
BPP_X16_FMT " link rate required %d available %d\n",
+ pipe_config->lane_count, pipe_config->port_clock,
+ pipe_config->pipe_bpp,
+ BPP_X16_ARGS(pipe_config->dsc.compressed_bpp_x16),
+ intel_dp_config_required_rate(pipe_config),
+ drm_dp_max_dprx_data_rate(pipe_config->port_clock,
+ pipe_config->lane_count));
- drm_dbg_kms(>drm,
- "DP link rate required %i available %i\n",
- intel_dp_link_required(adjusted_mode->crtc_clock,
-
to_bpp_int_roundup(pipe_config->dsc.compressed_bpp_x16)),
- drm_dp_max_dprx_data_rate(pipe_config->port_clock,
- pipe_config->lane_count));
- } else {
- drm_dbg_kms(>drm, "DP lane count %d clock %d bpp %d\n",
- pipe_config->lane_count, pipe_config->port_clock,
- pipe_config->pipe_bpp);
-
- drm_dbg_kms(>drm,
- "DP link rate required %i available %i\n",
- intel_dp_link_required(adjusted_mode->crtc_clock,
- pipe_config->pipe_bpp),
- drm_dp_max_dprx_data_rate(pipe_config->port_clock,
- pipe_config->lane_count));
- }
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index 20252984b3b04..4667870fed31a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -100,6 +100,7 @@ void intel_dp_mst_suspend(struct drm_i915_private
*dev_priv);
void intel_dp_mst_resume(struct drm_i915_private *dev_priv);
int intel_dp_max_link_rate(struct intel_dp *intel_dp);
int intel_dp_max_lane_count(struct intel_dp *intel_dp);
+int intel_dp_config_required_rate(const struct intel_crtc_state *crtc_state);
int intel_dp_rate_select(struct intel_dp *intel_dp, int rate);
void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
--
2.39.2
[PATCH v2 05/21] drm/i915/dp: Use drm_dp_max_dprx_data_rate()
Instead of intel_dp_max_data_rate() use the equivalent
drm_dp_max_dprx_data_rate() which was copied from the former one in a
previous patch.
Signed-off-by: Imre Deak
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/display/intel_dp.c | 62 +++-
drivers/gpu/drm/i915/display/intel_dp.h | 1 -
drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
4 files changed, 10 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 2ee26d19c200b..e1a4200f67a7e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2478,7 +2478,7 @@ intel_link_compute_m_n(u16 bits_per_pixel_x16, int nlanes,
u32 link_symbol_clock = intel_dp_link_symbol_clock(link_clock);
u32 data_m = intel_dp_effective_data_rate(pixel_clock,
bits_per_pixel_x16,
bw_overhead);
- u32 data_n = intel_dp_max_data_rate(link_clock, nlanes);
+ u32 data_n = drm_dp_max_dprx_data_rate(link_clock, nlanes);
/*
* Windows/BIOS uses fixed M/N values always. Follow suit.
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 88606e336a920..0a2ee43392142 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -383,52 +383,6 @@ int intel_dp_effective_data_rate(int pixel_clock, int
bpp_x16,
100 * 16 * 8);
}
-/*
- * Given a link rate and lanes, get the data bandwidth.
- *
- * Data bandwidth is the actual payload rate, which depends on the data
- * bandwidth efficiency and the link rate.
- *
- * For 8b/10b channel encoding, SST and non-FEC, the data bandwidth efficiency
- * is 80%. For example, for a 1.62 Gbps link, 1.62*10^9 bps * 0.80 * (1/8) =
- * 162000 kBps. With 8-bit symbols, we have 162000 kHz symbol clock. Just by
- * coincidence, the port clock in kHz matches the data bandwidth in kBps, and
- * they equal the link bit rate in Gbps multiplied by 10. (Note that this
no
- * longer holds for data bandwidth as soon as FEC or MST is taken into
account!)
- *
- * For 128b/132b channel encoding, the data bandwidth efficiency is 96.71%. For
- * example, for a 10 Gbps link, 10*10^9 bps * 0.9671 * (1/8) = 1208875
- * kBps. With 32-bit symbols, we have 312500 kHz symbol clock. The value
100
- * does not match the symbol clock, the port clock (not even if you think in
- * terms of a byte clock), nor the data bandwidth. It only matches the link bit
- * rate in units of 1 bps.
- */
-int
-intel_dp_max_data_rate(int max_link_rate, int max_lanes)
-{
- int ch_coding_efficiency =
-
drm_dp_bw_channel_coding_efficiency(drm_dp_is_uhbr_rate(max_link_rate));
- int max_link_rate_kbps = max_link_rate * 10;
-
- /*
-* UHBR rates always use 128b/132b channel encoding, and have
-* 97.71% data bandwidth efficiency. Consider max_link_rate the
-* link bit rate in units of 1 bps.
-*/
- /*
-* Lower than UHBR rates always use 8b/10b channel encoding, and have
-* 80% data bandwidth efficiency for SST non-FEC. However, this turns
-* out to be a nop by coincidence:
-*
-* int max_link_rate_kbps = max_link_rate * 10;
-* max_link_rate_kbps = DIV_ROUND_DOWN_ULL(max_link_rate_kbps * 8,
10);
-* max_link_rate = max_link_rate_kbps / 8;
-*/
- return DIV_ROUND_DOWN_ULL(mul_u32_u32(max_link_rate_kbps * max_lanes,
- ch_coding_efficiency),
- 100 * 8);
-}
-
bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
@@ -658,7 +612,7 @@ static bool intel_dp_can_link_train_fallback_for_edp(struct
intel_dp *intel_dp,
int mode_rate, max_rate;
mode_rate = intel_dp_link_required(fixed_mode->clock, 18);
- max_rate = intel_dp_max_data_rate(link_rate, lane_count);
+ max_rate = drm_dp_max_dprx_data_rate(link_rate, lane_count);
if (mode_rate > max_rate)
return false;
@@ -1262,7 +1216,7 @@ intel_dp_mode_valid(struct drm_connector *_connector,
max_link_clock = intel_dp_max_link_rate(intel_dp);
max_lanes = intel_dp_max_lane_count(intel_dp);
- max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
+ max_rate = drm_dp_max_dprx_data_rate(max_link_clock, max_lanes);
mode_rate = intel_dp_link_required(target_clock,
intel_dp_mode_min_output_bpp(connector, mode));
@@ -1612,8 +1566,8 @@ intel_dp_compute_link_config_wide(struct intel_dp
*intel_dp,
for (lane_count = limits->min_lane_count;
[PATCH v2 03/21] drm/i915: Fix display bpp limit computation during system resume
The system resume display mode restoration should happen with an output
configuration matching that of the suspend time saved mode. Since the
restored mode configuration is subject to the bpp fallback logic,
starting out with an unlimited bpp and reducing the bpp as required by
any (MST) link BW limit, the resulting bpp will match the one during
suspend only if the BW limit checks during suspend and resume are
applied in an identical way. The latter is not guaranteed at the moment,
since the pre-suspend MST topology may not be in place during resume
(for instance if the MST sink was disconnected while being suspended),
which makes the MST link BW check accept the unlimited bpp mode
configuration unconditionally without ensuring that the required BW fits
into the available MST link BW.
To fix the above, initialize the bpp fallback logic with the max link
bpp / force-FEC limits left behind by the suspend time mode save.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_display.c | 3 +--
drivers/gpu/drm/i915/display/intel_link_bw.c | 22
drivers/gpu/drm/i915/display/intel_link_bw.h | 2 +-
3 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 00ac65a140298..485c38d71f106 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6252,12 +6252,11 @@ static int intel_atomic_check_config(struct
intel_atomic_state *state,
static int intel_atomic_check_config_and_link(struct intel_atomic_state *state)
{
- struct drm_i915_private *i915 = to_i915(state->base.dev);
struct intel_link_bw_limits new_limits;
struct intel_link_bw_limits old_limits;
int ret;
- intel_link_bw_init_limits(i915, _limits);
+ intel_link_bw_init_limits(state, _limits);
old_limits = new_limits;
while (true) {
diff --git a/drivers/gpu/drm/i915/display/intel_link_bw.c
b/drivers/gpu/drm/i915/display/intel_link_bw.c
index 9c6d35a405a18..27ea858897c9f 100644
--- a/drivers/gpu/drm/i915/display/intel_link_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_link_bw.c
@@ -6,6 +6,7 @@
#include "i915_drv.h"
#include "intel_atomic.h"
+#include "intel_crtc.h"
#include "intel_display_types.h"
#include "intel_dp_mst.h"
#include "intel_fdi.h"
@@ -13,19 +14,32 @@
/**
* intel_link_bw_init_limits - initialize BW limits
- * @i915: device instance
+ * @state: Atomic state
* @limits: link BW limits
*
* Initialize @limits.
*/
-void intel_link_bw_init_limits(struct drm_i915_private *i915, struct
intel_link_bw_limits *limits)
+void intel_link_bw_init_limits(struct intel_atomic_state *state,
+ struct intel_link_bw_limits *limits)
{
+ struct drm_i915_private *i915 = to_i915(state->base.dev);
enum pipe pipe;
limits->force_fec_pipes = 0;
limits->bpp_limit_reached_pipes = 0;
- for_each_pipe(i915, pipe)
- limits->max_bpp_x16[pipe] = INT_MAX;
+ for_each_pipe(i915, pipe) {
+ const struct intel_crtc_state *crtc_state =
+ intel_atomic_get_new_crtc_state(state,
+
intel_crtc_for_pipe(i915, pipe));
+
+ if (state->base.duplicated && crtc_state) {
+ limits->max_bpp_x16[pipe] =
crtc_state->max_link_bpp_x16;
+ if (crtc_state->fec_enable)
+ limits->force_fec_pipes |= BIT(pipe);
+ } else {
+ limits->max_bpp_x16[pipe] = INT_MAX;
+ }
+ }
}
/**
diff --git a/drivers/gpu/drm/i915/display/intel_link_bw.h
b/drivers/gpu/drm/i915/display/intel_link_bw.h
index 2cf57307cc249..6b0ccfff59dab 100644
--- a/drivers/gpu/drm/i915/display/intel_link_bw.h
+++ b/drivers/gpu/drm/i915/display/intel_link_bw.h
@@ -22,7 +22,7 @@ struct intel_link_bw_limits {
int max_bpp_x16[I915_MAX_PIPES];
};
-void intel_link_bw_init_limits(struct drm_i915_private *i915,
+void intel_link_bw_init_limits(struct intel_atomic_state *state,
struct intel_link_bw_limits *limits);
int intel_link_bw_reduce_bpp(struct intel_atomic_state *state,
struct intel_link_bw_limits *limits,
--
2.39.2
[PATCH v2 02/21] drm/dp: Add support for DP tunneling
Add support for Display Port tunneling. For now this includes the support for Bandwidth Allocation Mode (BWA), leaving adding Panel Replay support for later. BWA allows using displays that share the same (Thunderbolt) link with their maximum resolution. Atm, this may not be possible due to the coarse granularity of partitioning the link BW among the displays on the link: the BW allocation policy is in a SW/FW/HW component on the link (on Thunderbolt it's the SW or FW Connection Manager), independent of the driver. This policy will set the DPRX maximum rate and lane count DPCD registers the GFX driver will see (0x0, 0x1, 0x02200, 0x02201) based on the available link BW. The granularity of the current BW allocation policy is coarse, based on the required link rate in the 1.62Gbs..8.1Gbps range and it may prevent using higher resolutions all together: the display connected first will get a share of the link BW which corresponds to its full DPRX capability (regardless of the actual mode it uses). A subsequent display connected will only get the remaining BW, which could be well below its full capability. BWA solves the above coarse granularity (reducing it to a 250Mbs..1Gps range) and first-come/first-served issues by letting the driver request the BW for each display on a link which reflects the actual modes the displays use. This patch adds the DRM core helper functions, while a follow-up change in the patchset takes them into use in the i915 driver. v2: - Fix prepare_to_wait vs. wake-up cond check order in allocate_tunnel_bw(). (Ville) - Move tunnel==NULL checks from callers in drivers to here. (Ville) - Avoid var inits in declaration blocks that can fail or have side-effects. (Ville) - Use u8 for driver and group IDs. (Ville) - Simplify API removing drm_dp_tunnel_get/put_untracked(). (Ville) - Reuse str_yes_no() instead of a local yes_no_chr(). (Ville) - s/drm_dp_tunnel_atomic_clear_state()/free_tunnel_state() and unexport the function. (Ville) - s/clear_tunnel_group_state()/free_group_state() and move kfree() to this function. (Ville) - Add separate group_free_bw() helper and describe what the tunnel estimated BW includes. (Ville) - Improve help text for CONFIG_DRM_DISPLAY_DP_TUNNEL. (Ville) - Add code comment explaining the purpose of DPCD reg read helpers. (Ville) - Add code comment describing the tunnel group name prefix format. (Ville) - Report the allocated BW as undetermined until the first allocation request. - Skip allocation requests matching the previous request. - Clear any stale BW request status flags before a new request. - Add missing error return check of drm_dp_tunnel_atomic_get_group_state() in drm_dp_tunnel_atomic_set_stream_bw(). - Add drm_dp_tunnel_get_allocated_bw(). - s/drm_dp_tunnel_atomic_get_tunnel_bw/drm_dp_tunnel_atomic_get_required_bw - Fix return value description in function doc of drm_dp_tunnel_detect(). - Add function documentation to all exported functions. Cc: Ville Syrjälä Signed-off-by: Imre Deak --- drivers/gpu/drm/display/Kconfig | 21 + drivers/gpu/drm/display/Makefile|2 + drivers/gpu/drm/display/drm_dp_tunnel.c | 1929 +++ include/drm/display/drm_dp.h| 60 + include/drm/display/drm_dp_tunnel.h | 248 +++ 5 files changed, 2260 insertions(+) create mode 100644 drivers/gpu/drm/display/drm_dp_tunnel.c create mode 100644 include/drm/display/drm_dp_tunnel.h diff --git a/drivers/gpu/drm/display/Kconfig b/drivers/gpu/drm/display/Kconfig index 09712b88a5b83..c0f56888c3280 100644 --- a/drivers/gpu/drm/display/Kconfig +++ b/drivers/gpu/drm/display/Kconfig @@ -17,6 +17,27 @@ config DRM_DISPLAY_DP_HELPER help DRM display helpers for DisplayPort. +config DRM_DISPLAY_DP_TUNNEL + bool + select DRM_DISPLAY_DP_HELPER + help + Enable support for DisplayPort tunnels. This allows drivers to use + DP tunnel features like the Bandwidth Allocation mode to maximize the + BW utilization for display streams on Thunderbolt links. + +config DRM_DISPLAY_DEBUG_DP_TUNNEL_STATE + bool "Enable debugging the DP tunnel state" + depends on REF_TRACKER + depends on DRM_DISPLAY_DP_TUNNEL + depends on DEBUG_KERNEL + depends on EXPERT + help + Enables debugging the DP tunnel manager's state, including the + consistency of all managed tunnels' reference counting and the state of + streams contained in tunnels. + + If in doubt, say "N". + config DRM_DISPLAY_HDCP_HELPER bool depends on DRM_DISPLAY_HELPER diff --git a/drivers/gpu/drm/display/Makefile b/drivers/gpu/drm/display/Makefile index 17ac4a1006a80..7ca61333c6696 100644 --- a/drivers/gpu/drm/display/Makefile +++ b/drivers/gpu/drm/display/Makefile @@ -8,6 +8,8 @@ drm_display_helper-$(CONFIG_DRM_DISPLAY_DP_HELPER) += \ drm_dp_helper.o \ drm_dp_mst_topology.o \ drm_dsc_helper.o
[PATCH v2 00/21] drm/i915: Add Display Port tunnel BW allocation support
This is v2 of [1], with the following changes: - Several functional/typo/formatting fixes, detailed in the patches. - Move the BW allocation from encoder hooks to intel_atomic_commit_tail() fixing the allocation for MST streams enabled/disabled w/o a full modeset (i.e. w/o re-enabling the master stream). - Fix an MST mode restore issue during system resume, which also lead to a tunnel BW allocation failure. (Patch 3) - Ensure a DPCD DPRX cap read as required by the TBT CM any time a long HPD pulse is detected. (Patch 20) - Explicitly disable the BW allocation mode during system suspend. The patchset is also available at: https://github.com/ideak/linux/commits/dp_tun_bw_alloc Cc: Mika Westerberg Cc: Ville Syrjälä Cc: Uma Shankar Cc: Jouni Högander Cc: Saranya Gopal Cc: Rajaram Regupathy Cc: Gil Fine Cc: Naama Shachar Cc: Pengfei Xu [1] https://lore.kernel.org/all/20240123102850.390126-1-imre.d...@intel.com Imre Deak (21): drm/dp: Add drm_dp_max_dprx_data_rate() drm/dp: Add support for DP tunneling drm/i915: Fix display bpp limit computation during system resume drm/i915/dp: Add support to notify MST connectors to retry modesets drm/i915/dp: Use drm_dp_max_dprx_data_rate() drm/i915/dp: Factor out intel_dp_config_required_rate() drm/i915/dp: Export intel_dp_max_common_rate/lane_count() drm/i915/dp: Factor out intel_dp_update_sink_caps() drm/i915/dp: Factor out intel_dp_read_dprx_caps() drm/i915/dp: Add intel_dp_max_link_data_rate() drm/i915/dp: Add way to get active pipes with syncing commits drm/i915/dp: Add support for DP tunnel BW allocation drm/i915/dp: Add DP tunnel atomic state and check BW limit drm/i915/dp: Account for tunnel BW limit in intel_dp_max_link_data_rate() drm/i915/dp: Compute DP tunnel BW during encoder state computation drm/i915/dp: Allocate/free DP tunnel BW in the encoder enable/disable hooks drm/i915/dp: Handle DP tunnel IRQs drm/i915/dp: Call intel_dp_sync_state() always for DDI DP encoders drm/i915/dp: Suspend/resume DP tunnels drm/i915/dp: Read DPRX for all long HPD pulses drm/i915/dp: Enable DP tunnel BW allocation mode drivers/gpu/drm/display/Kconfig | 21 + drivers/gpu/drm/display/Makefile |2 + drivers/gpu/drm/display/drm_dp_helper.c | 30 + drivers/gpu/drm/display/drm_dp_tunnel.c | 1929 + drivers/gpu/drm/i915/Kconfig | 14 + drivers/gpu/drm/i915/Kconfig.debug|1 + drivers/gpu/drm/i915/Makefile |3 + drivers/gpu/drm/i915/display/intel_atomic.c | 10 + drivers/gpu/drm/i915/display/intel_crtc.c | 52 + drivers/gpu/drm/i915/display/intel_crtc.h |2 + drivers/gpu/drm/i915/display/intel_ddi.c |3 +- drivers/gpu/drm/i915/display/intel_display.c | 26 +- .../gpu/drm/i915/display/intel_display_core.h |1 + .../drm/i915/display/intel_display_driver.c | 20 +- .../drm/i915/display/intel_display_types.h|9 + drivers/gpu/drm/i915/display/intel_dp.c | 292 ++- drivers/gpu/drm/i915/display/intel_dp.h | 13 +- .../drm/i915/display/intel_dp_link_training.c | 33 +- .../drm/i915/display/intel_dp_link_training.h |1 + drivers/gpu/drm/i915/display/intel_dp_mst.c | 18 +- .../gpu/drm/i915/display/intel_dp_tunnel.c| 815 +++ .../gpu/drm/i915/display/intel_dp_tunnel.h| 133 ++ drivers/gpu/drm/i915/display/intel_link_bw.c | 27 +- drivers/gpu/drm/i915/display/intel_link_bw.h |2 +- drivers/gpu/drm/i915/display/intel_tc.c |7 + include/drm/display/drm_dp.h | 61 + include/drm/display/drm_dp_helper.h |2 + include/drm/display/drm_dp_tunnel.h | 248 +++ 28 files changed, 3650 insertions(+), 125 deletions(-) create mode 100644 drivers/gpu/drm/display/drm_dp_tunnel.c create mode 100644 drivers/gpu/drm/i915/display/intel_dp_tunnel.c create mode 100644 drivers/gpu/drm/i915/display/intel_dp_tunnel.h create mode 100644 include/drm/display/drm_dp_tunnel.h -- 2.39.2
[PATCH v2 01/21] drm/dp: Add drm_dp_max_dprx_data_rate()
Copy intel_dp_max_data_rate() to DRM core. It will be needed by a
follow-up DP tunnel patch, checking the maximum rate the DPRX (sink)
supports. Accordingly use the drm_dp_max_dprx_data_rate() name for
clarity. This patchset will also switch calling the new DRM function
in i915 instead of intel_dp_max_data_rate().
While at it simplify the function documentation/comments, removing
parts described already by drm_dp_bw_channel_coding_efficiency().
v2: (Ville)
- Remove max_link_rate_kbps.
- Simplify the function documentation.
Cc: Ville Syrjälä
Signed-off-by: Imre Deak
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/display/drm_dp_helper.c | 30 +
include/drm/display/drm_dp_helper.h | 2 ++
2 files changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index 8d6ce46471ae6..d046dfa79504f 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -4055,3 +4055,33 @@ int drm_dp_bw_channel_coding_efficiency(bool is_uhbr)
return 80;
}
EXPORT_SYMBOL(drm_dp_bw_channel_coding_efficiency);
+
+/**
+ * drm_dp_max_dprx_data_rate - Get the max data bandwidth of a DPRX sink
+ * @max_link_rate: max DPRX link rate in 10kbps units
+ * @max_lanes: max DPRX lane count
+ *
+ * Given a link rate and lanes, get the data bandwidth.
+ *
+ * Data bandwidth is the actual payload rate, which depends on the data
+ * bandwidth efficiency and the link rate.
+ *
+ * Note that protocol layers above the DPRX link level considered here can
+ * further limit the maximum data rate. Such layers are the MST topology (with
+ * limits on the link between the source and first branch device as well as on
+ * the whole MST path until the DPRX link) and (Thunderbolt) DP tunnels -
+ * which in turn can encapsulate an MST link with its own limit - with each
+ * SST or MST encapsulated tunnel sharing the BW of a tunnel group.
+ *
+ * Returns the maximum data rate in kBps units.
+ */
+int drm_dp_max_dprx_data_rate(int max_link_rate, int max_lanes)
+{
+ int ch_coding_efficiency =
+
drm_dp_bw_channel_coding_efficiency(drm_dp_is_uhbr_rate(max_link_rate));
+
+ return DIV_ROUND_DOWN_ULL(mul_u32_u32(max_link_rate * 10 * max_lanes,
+ ch_coding_efficiency),
+ 100 * 8);
+}
+EXPORT_SYMBOL(drm_dp_max_dprx_data_rate);
diff --git a/include/drm/display/drm_dp_helper.h
b/include/drm/display/drm_dp_helper.h
index d02014a87f127..65dae9a9f2fb6 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -812,4 +812,6 @@ int drm_dp_bw_overhead(int lane_count, int hactive,
int bpp_x16, unsigned long flags);
int drm_dp_bw_channel_coding_efficiency(bool is_uhbr);
+int drm_dp_max_dprx_data_rate(int max_link_rate, int max_lanes);
+
#endif /* _DRM_DP_HELPER_H_ */
--
2.39.2
Re: [PATCH v3 2/2] drm/dp: drop the size parameter from drm_dp_vsc_sdp_pack()
On Tue, 20 Feb 2024 at 21:54, Abhinav Kumar wrote: > > Currently the size parameter of drm_dp_vsc_sdp_pack() is always > the size of struct dp_sdp. Hence lets drop this parameter and > use sizeof() directly. > > Suggested-by: Dmitry Baryshkov > Signed-off-by: Abhinav Kumar > --- > drivers/gpu/drm/display/drm_dp_helper.c | 8 ++-- > drivers/gpu/drm/i915/display/intel_dp.c | 3 +-- > include/drm/display/drm_dp_helper.h | 3 +-- > 3 files changed, 4 insertions(+), 10 deletions(-) Thank you! Acked-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: Re: [PATCH] drm/xe/guc: Remove usage of the deprecated ida_simple_xx() API
On Tue, Feb 20, 2024 at 02:34:53PM -0600, Lucas De Marchi wrote:
On Sun, Jan 14, 2024 at 04:09:16PM +0100, Christophe JAILLET wrote:
ida_alloc() and ida_free() should be preferred to the deprecated
ida_simple_get() and ida_simple_remove().
Note that the upper limit of ida_simple_get() is exclusive, but the one of
ida_alloc_max() is inclusive. So a -1 has been added when needed.
Signed-off-by: Christophe JAILLET
Reviewed-by: Lucas De Marchi
just noticed we already have CI results for this. Applied to
drm-xe-next, thanks.
Lucas De Marchi
Lucas De Marchi
---
drivers/gpu/drm/xe/xe_guc_submit.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c
b/drivers/gpu/drm/xe/xe_guc_submit.c
index 21ac68e3246f..11ffacd1dd58 100644
--- a/drivers/gpu/drm/xe/xe_guc_submit.c
+++ b/drivers/gpu/drm/xe/xe_guc_submit.c
@@ -311,7 +311,7 @@ static void __release_guc_id(struct xe_guc *guc, struct
xe_exec_queue *q, u32 xa
q->guc->id - GUC_ID_START_MLRC,
order_base_2(q->width));
else
- ida_simple_remove(>submission_state.guc_ids, q->guc->id);
+ ida_free(>submission_state.guc_ids, q->guc->id);
}
static int alloc_guc_id(struct xe_guc *guc, struct xe_exec_queue *q)
@@ -335,8 +335,8 @@ static int alloc_guc_id(struct xe_guc *guc, struct
xe_exec_queue *q)
ret = bitmap_find_free_region(bitmap, GUC_ID_NUMBER_MLRC,
order_base_2(q->width));
} else {
- ret = ida_simple_get(>submission_state.guc_ids, 0,
-GUC_ID_NUMBER_SLRC, GFP_NOWAIT);
+ ret = ida_alloc_max(>submission_state.guc_ids,
+ GUC_ID_NUMBER_SLRC - 1, GFP_NOWAIT);
}
if (ret < 0)
return ret;
--
2.43.0
Re: [PATCH] drm/xe/guc: Remove usage of the deprecated ida_simple_xx() API
On Sun, Jan 14, 2024 at 04:09:16PM +0100, Christophe JAILLET wrote:
ida_alloc() and ida_free() should be preferred to the deprecated
ida_simple_get() and ida_simple_remove().
Note that the upper limit of ida_simple_get() is exclusive, but the one of
ida_alloc_max() is inclusive. So a -1 has been added when needed.
Signed-off-by: Christophe JAILLET
Reviewed-by: Lucas De Marchi
Lucas De Marchi
---
drivers/gpu/drm/xe/xe_guc_submit.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c
b/drivers/gpu/drm/xe/xe_guc_submit.c
index 21ac68e3246f..11ffacd1dd58 100644
--- a/drivers/gpu/drm/xe/xe_guc_submit.c
+++ b/drivers/gpu/drm/xe/xe_guc_submit.c
@@ -311,7 +311,7 @@ static void __release_guc_id(struct xe_guc *guc, struct
xe_exec_queue *q, u32 xa
q->guc->id - GUC_ID_START_MLRC,
order_base_2(q->width));
else
- ida_simple_remove(>submission_state.guc_ids, q->guc->id);
+ ida_free(>submission_state.guc_ids, q->guc->id);
}
static int alloc_guc_id(struct xe_guc *guc, struct xe_exec_queue *q)
@@ -335,8 +335,8 @@ static int alloc_guc_id(struct xe_guc *guc, struct
xe_exec_queue *q)
ret = bitmap_find_free_region(bitmap, GUC_ID_NUMBER_MLRC,
order_base_2(q->width));
} else {
- ret = ida_simple_get(>submission_state.guc_ids, 0,
-GUC_ID_NUMBER_SLRC, GFP_NOWAIT);
+ ret = ida_alloc_max(>submission_state.guc_ids,
+ GUC_ID_NUMBER_SLRC - 1, GFP_NOWAIT);
}
if (ret < 0)
return ret;
--
2.43.0
Re: [PATCH 1/2] drm/nouveau: don't fini scheduler if not initialized
On 2/20/24 20:45, Timur Tabi wrote: On Mon, 2024-02-19 at 10:32 +0100, Danilo Krummrich wrote: Looks like I spoke too soon, I just hit the problem with the drm-next tree. Did you apply the patch to drm-next? Ugh, you're right. I don't how I got confused, but I could have sworn that I saw your two patches in drm-next, but they are not there. Sorry for the noise. No worries, thanks for testing! :-)
[PATCH v3 2/2] drm/dp: drop the size parameter from drm_dp_vsc_sdp_pack()
Currently the size parameter of drm_dp_vsc_sdp_pack() is always
the size of struct dp_sdp. Hence lets drop this parameter and
use sizeof() directly.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/display/drm_dp_helper.c | 8 ++--
drivers/gpu/drm/i915/display/intel_dp.c | 3 +--
include/drm/display/drm_dp_helper.h | 3 +--
3 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index 6c91f400ecb1..10ee82e34de7 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2918,19 +2918,15 @@ EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
* @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)
+ struct dp_sdp *sdp)
{
size_t length = sizeof(struct dp_sdp);
- if (size < length)
- return -ENOSPC;
-
- memset(sdp, 0, size);
+ memset(sdp, 0, sizeof(struct dp_sdp));
/*
* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index a9458df475e2..e13121dc3a03 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4181,8 +4181,7 @@ static void intel_write_dp_sdp(struct intel_encoder
*encoder,
switch (type) {
case DP_SDP_VSC:
- len = drm_dp_vsc_sdp_pack(_state->infoframes.vsc, ,
- sizeof(sdp));
+ len = drm_dp_vsc_sdp_pack(_state->infoframes.vsc, );
break;
case HDMI_PACKET_TYPE_GAMUT_METADATA:
len = intel_dp_hdr_metadata_infoframe_sdp_pack(dev_priv,
diff --git a/include/drm/display/drm_dp_helper.h
b/include/drm/display/drm_dp_helper.h
index 8474504d4c88..1f41994796d3 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -812,7 +812,6 @@ int drm_dp_bw_overhead(int lane_count, int hactive,
int bpp_x16, unsigned long flags);
int drm_dp_bw_channel_coding_efficiency(bool is_uhbr);
-ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
- struct dp_sdp *sdp, size_t size);
+ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc, struct dp_sdp
*sdp);
#endif /* _DRM_DP_HELPER_H_ */
--
2.34.1
[PATCH v3 1/2] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper
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.
changes in v2:
- rebased on top of drm-tip
Acked-by: Dmitry Baryshkov
Signed-off-by: Abhinav Kumar
Acked-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_helper.c | 78 +
drivers/gpu/drm/i915/display/intel_dp.c | 71 +-
include/drm/display/drm_dp_helper.h | 3 +
3 files changed, 83 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index 8d6ce46471ae..6c91f400ecb1 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2913,6 +2913,84 @@ void drm_dp_vsc_sdp_log(struct drm_printer *p, const
struct drm_dp_vsc_sdp *vsc)
}
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)
+{
+ 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 217196196e50..a9458df475e2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4089,73 +4089,6 @@ intel_dp_needs_vsc_sdp(const struct intel_crtc_state
*crtc_state,
return false;
}
-static ssize_t intel_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
-struct dp_sdp *sdp, size_t size)
-{
- 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
Re: [PATCH v3] drm/i915/guc: Simplify/extend platform check for Wa_14018913170
On 2/19/2024 12:28, Rodrigo Vivi wrote:
On Fri, Feb 16, 2024 at 10:38:41AM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
The above w/a is required for every platform that the i915 driver
supports. It is fixed on the latest platforms but they are only
supported by Xe instead of i915. So just remove the platform check
completely and keep the code simple.
Well, I was going to say that I would prefer a GMD version greater-than
check to be future proof. However if this code gets used in some other
new platform a new specific guc support would likely need to be added
as well right?
There is no future for i915. That's the point. The only platforms that
have the hardware fix are all ones that will only ever be supported by
the Xe driver. So if such a platform were to be backported to i915 then
there would be a lot more work than just adding a new GuC firmware platform.
And going backwards, the bug affects all platforms that have a GuC. So
if any GuC code is being executed at all, then this w/a is applicable.
Perhaps at least adding a comment in the code?
Such as this?
/*
* Wa_14018913170: Applicable to all platforms supported by i915 so
* don't bother testing for all X/Y/Z platforms explicitly.
*/
John.
with that
Reviewed-by: Rodrigo Vivi
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 2b450c43bbd7f..a3662edb42032 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -321,8 +321,7 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
/* Wa_14018913170 */
if (GUC_FIRMWARE_VER(guc) >= MAKE_GUC_VER(70, 7, 0)) {
- if (IS_DG2(gt->i915) || IS_METEORLAKE(gt->i915) ||
IS_PONTEVECCHIO(gt->i915))
- flags |= GUC_WA_ENABLE_TSC_CHECK_ON_RC6;
+ flags |= GUC_WA_ENABLE_TSC_CHECK_ON_RC6;
}
return flags;
--
2.43.0
Re: [PATCH v2] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper
On 2/20/2024 11:41 AM, Ville Syrjälä wrote: On Tue, Feb 20, 2024 at 11:27:18AM -0800, Abhinav Kumar wrote: On 2/20/2024 11:20 AM, Dmitry Baryshkov wrote: On Tue, 20 Feb 2024 at 21:05, Dmitry Baryshkov wrote: On Tue, 20 Feb 2024 at 20:53, Abhinav Kumar wrote: On 2/20/2024 10:49 AM, Dmitry Baryshkov wrote: On Thu, 15 Feb 2024 at 21:08, 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. changes in v2: - rebased on top of drm-tip Acked-by: Dmitry Baryshkov v1 had an explicit comment before the ack: Yes, I remember the comment. I did not make any changes to v2 other than just rebasing it on drm-tip to get the ack from i915 folks. From my side, with the promise of the size fixup. However I observe neither a second patch removing the size argument nor it being dropped as a part of this patch. Yes, now that in v2 we got the ack for this patch, I can spin a v3 with the addition of the next patch to remove the size OR as another series so as to not block the main series which needs this patch. I would prefer the latter. It doesn't work this way. The comment should have been fixed for v2. This probably deserves some explanation. Currently there is only one user of this function. So it is easy to fix it. Once there are several users, you have to fix all of them at the same time, patching different drm subtrees. That complicates the life of maintainers. Yes, understood. Its easier to fix it now if its really needed. Actually, I think the reason the size was passed was to make sure a valid struct dp_sdp *sdp was being passed. The size is supposed to be the size of *hardware* buffer where this gets written into. But looks like this wasn't done correctly when the code was copy-pasted from the HDMI inforframe code. Alright, in that case, let me post a patch to drop this and let me know if that works for you.
Re: [PATCH 1/2] drm/nouveau: don't fini scheduler if not initialized
On Mon, 2024-02-19 at 10:32 +0100, Danilo Krummrich wrote: Looks like I spoke too soon, I just hit the problem with the drm-next tree. Did you apply the patch to drm-next? Ugh, you're right. I don't how I got confused, but I could have sworn that I saw your two patches in drm-next, but they are not there. Sorry for the noise.
Re: [PATCH v2] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper
On Tue, Feb 20, 2024 at 11:27:18AM -0800, Abhinav Kumar wrote: > > > On 2/20/2024 11:20 AM, Dmitry Baryshkov wrote: > > On Tue, 20 Feb 2024 at 21:05, Dmitry Baryshkov > > wrote: > >> > >> On Tue, 20 Feb 2024 at 20:53, Abhinav Kumar > >> wrote: > >>> > >>> > >>> > >>> On 2/20/2024 10:49 AM, Dmitry Baryshkov wrote: > On Thu, 15 Feb 2024 at 21:08, 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. > > > > changes in v2: > > - rebased on top of drm-tip > > > > Acked-by: Dmitry Baryshkov > > v1 had an explicit comment before the ack: > > >>> > >>> Yes, I remember the comment. I did not make any changes to v2 other than > >>> just rebasing it on drm-tip to get the ack from i915 folks. > >>> > > From my side, with the promise of the size fixup. > > However I observe neither a second patch removing the size argument > nor it being dropped as a part of this patch. > > >>> > >>> Yes, now that in v2 we got the ack for this patch, I can spin a v3 with > >>> the addition of the next patch to remove the size OR as another series > >>> so as to not block the main series which needs this patch. > >>> > >>> I would prefer the latter. > >> > >> It doesn't work this way. The comment should have been fixed for v2. > > > > This probably deserves some explanation. Currently there is only one > > user of this function. So it is easy to fix it. Once there are several > > users, you have to fix all of them at the same time, patching > > different drm subtrees. That complicates the life of maintainers. > > > > Yes, understood. Its easier to fix it now if its really needed. > > Actually, I think the reason the size was passed was to make sure > a valid struct dp_sdp *sdp was being passed. The size is supposed to be the size of *hardware* buffer where this gets written into. But looks like this wasn't done correctly when the code was copy-pasted from the HDMI inforframe code. -- Ville Syrjälä Intel
Re: [PATCH v2] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper
On 2/20/2024 11:20 AM, Dmitry Baryshkov wrote: On Tue, 20 Feb 2024 at 21:05, Dmitry Baryshkov wrote: On Tue, 20 Feb 2024 at 20:53, Abhinav Kumar wrote: On 2/20/2024 10:49 AM, Dmitry Baryshkov wrote: On Thu, 15 Feb 2024 at 21:08, 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. changes in v2: - rebased on top of drm-tip Acked-by: Dmitry Baryshkov v1 had an explicit comment before the ack: Yes, I remember the comment. I did not make any changes to v2 other than just rebasing it on drm-tip to get the ack from i915 folks. From my side, with the promise of the size fixup. However I observe neither a second patch removing the size argument nor it being dropped as a part of this patch. Yes, now that in v2 we got the ack for this patch, I can spin a v3 with the addition of the next patch to remove the size OR as another series so as to not block the main series which needs this patch. I would prefer the latter. It doesn't work this way. The comment should have been fixed for v2. This probably deserves some explanation. Currently there is only one user of this function. So it is easy to fix it. Once there are several users, you have to fix all of them at the same time, patching different drm subtrees. That complicates the life of maintainers. Yes, understood. Its easier to fix it now if its really needed. Actually, I think the reason the size was passed was to make sure a valid struct dp_sdp *sdp was being passed. If we drop the size, we need to have a if (!sdp) check as there is a memset followed by dereference. So maybe, if we want to keep this API protected, its not too bad to have?
Re: [PATCH] drm/i915/tv: Fix TV mode
On Tue, Feb 20, 2024 at 08:06:01PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 20, 2024 at 12:57:06PM -0500, Rodrigo Vivi wrote:
> > On Tue, Feb 20, 2024 at 07:52:21PM +0200, Ville Syrjälä wrote:
> > > On Tue, Feb 20, 2024 at 02:12:51PM +0100, Maxime Ripard wrote:
> > > > Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed
> > > > to update all the users of the struct drm_tv_connector_state mode field,
> > > > which resulted in a build failure in i915.
> > > >
> > > > However, a subsequent commit in the same series reintroduced a mode
> > > > field in that structure, with a different semantic but the same type,
> > > > with the assumption that all previous users were updated.
> > > >
> > > > Since that didn't happen, the i915 driver now compiles, but mixes
> > > > accesses to the legacy_mode field and the newer mode field, but with the
> > > > previous semantics.
> > > >
> > > > This obviously doesn't work very well, so we need to update the accesses
> > > > that weren't in the legacy renaming commit.
> > > >
> > > > Fixes: 1fd4a5a36f9f ("drm/connector: Rename legacy TV property")
> > > > Reported-by: Ville Syrjälä
> > > > Signed-off-by: Maxime Ripard
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_sdvo.c | 10 +-
> > > > drivers/gpu/drm/i915/display/intel_tv.c | 10 +-
> > > > 2 files changed, 10 insertions(+), 10 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > > b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > > index 825638702ac1..5f9e748adc89 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > > @@ -1220,7 +1220,7 @@ static bool intel_sdvo_set_tv_format(struct
> > > > intel_sdvo *intel_sdvo,
> > > > struct intel_sdvo_tv_format format;
> > > > u32 format_map;
> > > >
> > > > - format_map = 1 << conn_state->tv.mode;
> > > > + format_map = 1 << conn_state->tv.legacy_mode;
> > > > memset(, 0, sizeof(format));
> > > > memcpy(, _map, min(sizeof(format),
> > > > sizeof(format_map)));
> > > >
> > > > @@ -2323,7 +2323,7 @@ static int intel_sdvo_get_tv_modes(struct
> > > > drm_connector *connector)
> > > > * Read the list of supported input resolutions for the
> > > > selected TV
> > > > * format.
> > > > */
> > > > - format_map = 1 << conn_state->tv.mode;
> > > > + format_map = 1 << conn_state->tv.legacy_mode;
> > > > memcpy(_res, _map,
> > > >min(sizeof(format_map), sizeof(struct
> > > > intel_sdvo_sdtv_resolution_request)));
> > > >
> > > > @@ -2388,7 +2388,7 @@ intel_sdvo_connector_atomic_get_property(struct
> > > > drm_connector *connector,
> > > > int i;
> > > >
> > > > for (i = 0; i <
> > > > intel_sdvo_connector->format_supported_num; i++)
> > > > - if (state->tv.mode ==
> > > > intel_sdvo_connector->tv_format_supported[i]) {
> > > > + if (state->tv.legacy_mode ==
> > > > intel_sdvo_connector->tv_format_supported[i]) {
> > > > *val = i;
> > > >
> > > > return 0;
> > > > @@ -2444,7 +2444,7 @@ intel_sdvo_connector_atomic_set_property(struct
> > > > drm_connector *connector,
> > > > struct intel_sdvo_connector_state *sdvo_state =
> > > > to_intel_sdvo_connector_state(state);
> > > >
> > > > if (property == intel_sdvo_connector->tv_format) {
> > > > - state->tv.mode =
> > > > intel_sdvo_connector->tv_format_supported[val];
> > > > + state->tv.legacy_mode =
> > > > intel_sdvo_connector->tv_format_supported[val];
> > > >
> > > > if (state->crtc) {
> > > > struct drm_crtc_state *crtc_state =
> > > > @@ -3108,7 +3108,7 @@ static bool intel_sdvo_tv_create_property(struct
> > > > intel_sdvo *intel_sdvo,
> > > > drm_property_add_enum(intel_sdvo_connector->tv_format,
> > > > i,
> > > >
> > > > tv_format_names[intel_sdvo_connector->tv_format_supported[i]]);
> > > >
> > > > - intel_sdvo_connector->base.base.state->tv.mode =
> > > > intel_sdvo_connector->tv_format_supported[0];
> > > > + intel_sdvo_connector->base.base.state->tv.legacy_mode =
> > > > intel_sdvo_connector->tv_format_supported[0];
> > > >
> > > > drm_object_attach_property(_sdvo_connector->base.base.base,
> > > >intel_sdvo_connector->tv_format, 0);
> > > > return true;
> > >
> > > Hmm. I didn't realize we are using this in the SDVO code as well.
> > > I don't *think* that one is actually broken since it has its own
> > > .{set,get}_property() hooks. But I suppose doing the rename
> > > there as well is a good idea anyway.
> > >
> > > Can you split the SDVO vs. TV into separate patches? We need to
> > > backport
Re: [PATCH v2] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper
On Tue, 20 Feb 2024 at 21:05, Dmitry Baryshkov wrote: > > On Tue, 20 Feb 2024 at 20:53, Abhinav Kumar wrote: > > > > > > > > On 2/20/2024 10:49 AM, Dmitry Baryshkov wrote: > > > On Thu, 15 Feb 2024 at 21:08, 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. > > >> > > >> changes in v2: > > >> - rebased on top of drm-tip > > >> > > >> Acked-by: Dmitry Baryshkov > > > > > > v1 had an explicit comment before the ack: > > > > > > > Yes, I remember the comment. I did not make any changes to v2 other than > > just rebasing it on drm-tip to get the ack from i915 folks. > > > > >> From my side, with the promise of the size fixup. > > > > > > However I observe neither a second patch removing the size argument > > > nor it being dropped as a part of this patch. > > > > > > > Yes, now that in v2 we got the ack for this patch, I can spin a v3 with > > the addition of the next patch to remove the size OR as another series > > so as to not block the main series which needs this patch. > > > > I would prefer the latter. > > It doesn't work this way. The comment should have been fixed for v2. This probably deserves some explanation. Currently there is only one user of this function. So it is easy to fix it. Once there are several users, you have to fix all of them at the same time, patching different drm subtrees. That complicates the life of maintainers. -- With best wishes Dmitry
Re: [PATCH v2] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper
On Tue, 20 Feb 2024 at 21:09, Abhinav Kumar wrote: > > > > On 2/20/2024 11:05 AM, Dmitry Baryshkov wrote: > > On Tue, 20 Feb 2024 at 20:53, Abhinav Kumar > > wrote: > >> > >> > >> > >> On 2/20/2024 10:49 AM, Dmitry Baryshkov wrote: > >>> On Thu, 15 Feb 2024 at 21:08, 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. > > changes in v2: > - rebased on top of drm-tip > > Acked-by: Dmitry Baryshkov > >>> > >>> v1 had an explicit comment before the ack: > >>> > >> > >> Yes, I remember the comment. I did not make any changes to v2 other than > >> just rebasing it on drm-tip to get the ack from i915 folks. > >> > From my side, with the promise of the size fixup. > >>> > >>> However I observe neither a second patch removing the size argument > >>> nor it being dropped as a part of this patch. > >>> > >> > >> Yes, now that in v2 we got the ack for this patch, I can spin a v3 with > >> the addition of the next patch to remove the size OR as another series > >> so as to not block the main series which needs this patch. > >> > >> I would prefer the latter. > > > > It doesn't work this way. The comment should have been fixed for v2. > > > > Ack, I can post a v3 now by adding the removal in patch 2 of this series. Yes, please. -- With best wishes Dmitry
Re: [PATCH v4 13/19] drm/msm/dp: add VSC SDP support for YUV420 over DP
On 2/20/2024 10:09 AM, Dmitry Baryshkov wrote:
On Tue, 20 Feb 2024 at 19:55, Paloma Arellano wrote:
On 2/17/2024 12:56 AM, Dmitry Baryshkov wrote:
On Sat, 17 Feb 2024 at 01:03, Paloma Arellano wrote:
+ }
+
+ panel = container_of(dp_panel, struct dp_panel_private, dp_panel);
+ catalog = panel->catalog;
+ dp_mode = _panel->dp_mode;
+
+ memset(_sdp_data, 0, sizeof(vsc_sdp_data));
+
+ /* VSC SDP header as per table 2-118 of DP 1.4 specification */
+ vsc_sdp_data.sdp_type = DP_SDP_VSC;
+ vsc_sdp_data.revision = 0x05;
+ vsc_sdp_data.length = 0x13;
+
+ /* VSC SDP Payload for DB16 */
+ vsc_sdp_data.pixelformat = DP_PIXELFORMAT_YUV420;
+ vsc_sdp_data.colorimetry = DP_COLORIMETRY_DEFAULT;
+
+ /* VSC SDP Payload for DB17 */
+ vsc_sdp_data.bpc = dp_mode->bpp / 3;
+ vsc_sdp_data.dynamic_range = DP_DYNAMIC_RANGE_CTA;
+
+ /* VSC SDP Payload for DB18 */
+ vsc_sdp_data.content_type = DP_CONTENT_TYPE_GRAPHICS;
+
+ len = dp_utils_pack_vsc_sdp(_sdp_data, _sdp, header);
+ if (len < 0) {
+ DRM_ERROR("unable to pack vsc sdp\n");
+ return len;
+ }
So, at this point we have the header data both in vsc_sdp.sdp_header
and in the packed header. The relationship between them becomes less
obvious. Could you please pack dp_sdp_header into u32[2] just before
writing it? It really makes little sense to pass both at the same
time.
Just want to clear some stuff up. Do you want to call the
dp_utils_pack_sdp_header() function right before
dp_catalog_panel_send_vsc_sdp()? The point of putting the
dp_utils_pack_sdp_header() function inside dp_utils_pack_vsc_sdp() is so
that all of the packing could be in the same location. Although I agree
that we are passing the same values twice, I believe that having it the
way it is currently is better since it shows that the
drm_dp_vsc_sdp_pack() and dp_utils_pack_sdp_header() are related since
they're packing the data to the set of GENERIC0 registers.
I'm perfectly fine with dp_utils_pack_sdp_header() being called from
within dp_catalog_panel_send_vsc_sdp(). This way you are not passing
extra data and it is perfectly clear how the SDP header is handled
before being written to the hardware.
Ack. Sounds good, I'll implement it that way
Re: [PATCH v2] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper
On 2/20/2024 11:05 AM, Dmitry Baryshkov wrote: On Tue, 20 Feb 2024 at 20:53, Abhinav Kumar wrote: On 2/20/2024 10:49 AM, Dmitry Baryshkov wrote: On Thu, 15 Feb 2024 at 21:08, 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. changes in v2: - rebased on top of drm-tip Acked-by: Dmitry Baryshkov v1 had an explicit comment before the ack: Yes, I remember the comment. I did not make any changes to v2 other than just rebasing it on drm-tip to get the ack from i915 folks. From my side, with the promise of the size fixup. However I observe neither a second patch removing the size argument nor it being dropped as a part of this patch. Yes, now that in v2 we got the ack for this patch, I can spin a v3 with the addition of the next patch to remove the size OR as another series so as to not block the main series which needs this patch. I would prefer the latter. It doesn't work this way. The comment should have been fixed for v2. Ack, I can post a v3 now by adding the removal in patch 2 of this series.
Re: [PATCH v2] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper
On Tue, 20 Feb 2024 at 20:53, Abhinav Kumar wrote: > > > > On 2/20/2024 10:49 AM, Dmitry Baryshkov wrote: > > On Thu, 15 Feb 2024 at 21:08, 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. > >> > >> changes in v2: > >> - rebased on top of drm-tip > >> > >> Acked-by: Dmitry Baryshkov > > > > v1 had an explicit comment before the ack: > > > > Yes, I remember the comment. I did not make any changes to v2 other than > just rebasing it on drm-tip to get the ack from i915 folks. > > >> From my side, with the promise of the size fixup. > > > > However I observe neither a second patch removing the size argument > > nor it being dropped as a part of this patch. > > > > Yes, now that in v2 we got the ack for this patch, I can spin a v3 with > the addition of the next patch to remove the size OR as another series > so as to not block the main series which needs this patch. > > I would prefer the latter. It doesn't work this way. The comment should have been fixed for v2. -- With best wishes Dmitry
Re: [PATCH] drm/xe/guc: Remove usage of the deprecated ida_simple_xx() API
Le 14/01/2024 à 16:09, Christophe JAILLET a écrit :
ida_alloc() and ida_free() should be preferred to the deprecated
ida_simple_get() and ida_simple_remove().
Note that the upper limit of ida_simple_get() is exclusive, but the one of
ida_alloc_max() is inclusive. So a -1 has been added when needed.
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/xe/xe_guc_submit.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c
b/drivers/gpu/drm/xe/xe_guc_submit.c
index 21ac68e3246f..11ffacd1dd58 100644
--- a/drivers/gpu/drm/xe/xe_guc_submit.c
+++ b/drivers/gpu/drm/xe/xe_guc_submit.c
@@ -311,7 +311,7 @@ static void __release_guc_id(struct xe_guc *guc, struct
xe_exec_queue *q, u32 xa
q->guc->id - GUC_ID_START_MLRC,
order_base_2(q->width));
else
- ida_simple_remove(>submission_state.guc_ids, q->guc->id);
+ ida_free(>submission_state.guc_ids, q->guc->id);
}
static int alloc_guc_id(struct xe_guc *guc, struct xe_exec_queue *q)
@@ -335,8 +335,8 @@ static int alloc_guc_id(struct xe_guc *guc, struct
xe_exec_queue *q)
ret = bitmap_find_free_region(bitmap, GUC_ID_NUMBER_MLRC,
order_base_2(q->width));
} else {
- ret = ida_simple_get(>submission_state.guc_ids, 0,
-GUC_ID_NUMBER_SLRC, GFP_NOWAIT);
+ ret = ida_alloc_max(>submission_state.guc_ids,
+ GUC_ID_NUMBER_SLRC - 1, GFP_NOWAIT);
}
if (ret < 0)
return ret;
Hi,
gentle reminder.
All patches to remove the ida_simple API have been sent.
And Matthew Wilcox seems happy with the on going work. (see [1])
Based on next-20240220
$git grep ida_simple_get | wc -l
36
https://elixir.bootlin.com/linux/v6.8-rc3/A/ident/ida_simple_get
50
https://elixir.bootlin.com/linux/v6.7.4/A/ident/ida_simple_get
81
Thanks
CJ
[1]: https://lore.kernel.org/all/zaqrugvz734zj...@casper.infradead.org/
Re: [PATCH v2] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper
On 2/20/2024 10:49 AM, Dmitry Baryshkov wrote:
On Thu, 15 Feb 2024 at 21:08, 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.
changes in v2:
- rebased on top of drm-tip
Acked-by: Dmitry Baryshkov
v1 had an explicit comment before the ack:
Yes, I remember the comment. I did not make any changes to v2 other than
just rebasing it on drm-tip to get the ack from i915 folks.
From my side, with the promise of the size fixup.
However I observe neither a second patch removing the size argument
nor it being dropped as a part of this patch.
Yes, now that in v2 we got the ack for this patch, I can spin a v3 with
the addition of the next patch to remove the size OR as another series
so as to not block the main series which needs this patch.
I would prefer the latter.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/display/drm_dp_helper.c | 78 +
drivers/gpu/drm/i915/display/intel_dp.c | 71 +-
include/drm/display/drm_dp_helper.h | 3 +
3 files changed, 83 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index 8d6ce46471ae..6c91f400ecb1 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2913,6 +2913,84 @@ void drm_dp_vsc_sdp_log(struct drm_printer *p, const
struct drm_dp_vsc_sdp *vsc)
}
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)
+{
+ 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 217196196e50..a9458df475e2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4089,73 +4089,6 @@ intel_dp_needs_vsc_sdp(const struct intel_crtc_state
*crtc_state,
return false;
}
-static ssize_t intel_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
-struct dp_sdp *sdp, size_t size)
-{
- 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
Re: [PATCH v2] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper
On Thu, 15 Feb 2024 at 21:08, 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.
>
> changes in v2:
> - rebased on top of drm-tip
>
> Acked-by: Dmitry Baryshkov
v1 had an explicit comment before the ack:
>From my side, with the promise of the size fixup.
However I observe neither a second patch removing the size argument
nor it being dropped as a part of this patch.
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/display/drm_dp_helper.c | 78 +
> drivers/gpu/drm/i915/display/intel_dp.c | 71 +-
> include/drm/display/drm_dp_helper.h | 3 +
> 3 files changed, 83 insertions(+), 69 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> b/drivers/gpu/drm/display/drm_dp_helper.c
> index 8d6ce46471ae..6c91f400ecb1 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -2913,6 +2913,84 @@ void drm_dp_vsc_sdp_log(struct drm_printer *p, const
> struct drm_dp_vsc_sdp *vsc)
> }
> 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)
> +{
> + 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 217196196e50..a9458df475e2 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4089,73 +4089,6 @@ intel_dp_needs_vsc_sdp(const struct intel_crtc_state
> *crtc_state,
> return false;
> }
>
> -static ssize_t intel_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
> -struct dp_sdp *sdp, size_t size)
> -{
> - 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 */
> -
Re: [PATCH 2/2] dma-buf: heaps: secure_heap: Add qcom secure system heap
On 11/22/2023 5:47 AM, Pratyush Brahma wrote:
> From: Vijayanand Jitta
>
> Add secure system for Pixel and Non pixel video usecases, this
> allocates from system heap and secures using qcom_scm_aasign_mem.
^^
typo
>
> Change-Id: If0702f85bff651843c6a5c83694043364229e66b
> Signed-off-by: Vijayanand Jitta
Please get these patches reviewed internally before sending to mailing
list for basic checks. You can review go/upstream when within Qualcomm corp
network.
Pavan mentioned S-o-B is incorrect. Commit text should also not have Change-Id.
Please be sure to send to linux-arm-msm mailing list as well since this affects
Qualcomm chipsets
> ---
> drivers/dma-buf/heaps/secure_heap.c | 163 +++-
> 1 file changed, 160 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dma-buf/heaps/secure_heap.c
> b/drivers/dma-buf/heaps/secure_heap.c
> index 04e2ee000e19..cdcf4b3f5333 100644
> --- a/drivers/dma-buf/heaps/secure_heap.c
> +++ b/drivers/dma-buf/heaps/secure_heap.c
> @@ -58,6 +58,11 @@ enum secure_memory_type {
>* protect it, then the detail memory management also is inside the TEE.
>*/
> SECURE_MEMORY_TYPE_MTK_CM_CMA = 2,
> + /*
> + * QCOM secure system heap, use system heap to alloc/free.
> + * and use qcom_scm_assign_mem to secure the memory.
> + */
> + SECURE_MEMORY_TYPE_QCOM_SYSTEM = 3,
> };
>
> struct secure_buffer {
> @@ -69,6 +74,7 @@ struct secure_buffer {
>*/
> u32 sec_handle;
> struct page *cma_page;
> + struct sg_table sg_table;
> };
>
> #define TEE_MEM_COMMAND_ID_BASE_MTK 0x1
> @@ -329,11 +335,26 @@ static int secure_heap_qcom_secure_memory(struct
> secure_heap *sec_heap,
> next[0].vmid = data->vmid;
> next[0].perm = data->perm;
>
> -
> - ret = qcom_scm_assign_mem(page_to_phys(sec_buf->cma_page),
> + if (sec_heap->mem_type == SECURE_MEMORY_TYPE_CMA) {
> + ret = qcom_scm_assign_mem(page_to_phys(sec_buf->cma_page),
> sec_buf->size, _perms,
> next, 1);
> + } else if (sec_heap->mem_type == SECURE_MEMORY_TYPE_QCOM_SYSTEM) {
> + struct sg_table *table;
> + struct scatterlist *sg;
> + int i = 0;
> +
> + table = _buf->sg_table;
> + for_each_sgtable_sg(table, sg, i) {
> + struct page *page = sg_page(sg);
>
> + ret = qcom_scm_assign_mem(page_to_phys(page),
> + page_size(page), _perms,
> + next, 1);
> + if (ret)
> + break;
> + }
> + }
> return ret;
> }
>
> @@ -347,9 +368,24 @@ static void secure_heap_qcom_unsecure_memory(struct
> secure_heap *sec_heap,
> next[0].vmid = QCOM_SCM_VMID_HLOS;
> next[0].perm = QCOM_SCM_PERM_RWX;
>
> - qcom_scm_assign_mem(page_to_phys(sec_buf->cma_page),
> + if (sec_heap->mem_type == SECURE_MEMORY_TYPE_CMA) {
> + qcom_scm_assign_mem(page_to_phys(sec_buf->cma_page),
> sec_buf->size, _perms,
> next, 1);
> + } else if (sec_heap->mem_type == SECURE_MEMORY_TYPE_QCOM_SYSTEM) {
> + struct sg_table *table;
> + struct scatterlist *sg;
> + int i = 0;
> +
> + table = _buf->sg_table;
> + for_each_sgtable_sg(table, sg, i) {
> + struct page *page = sg_page(sg);
> +
> + qcom_scm_assign_mem(page_to_phys(page),
> + page_size(page), _perms,
> + next, 1);
> + }
> + }
> }
>
> const struct secure_heap_prv_data qcom_cma_sec_mem_data = {
> @@ -361,6 +397,117 @@ const struct secure_heap_prv_data qcom_cma_sec_mem_data
> = {
> .unsecure_the_memory= secure_heap_qcom_unsecure_memory,
> };
>
> +/* Using system heap allocator */
> +#define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO)
> +#define HIGH_ORDER_GFP (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \
> + | __GFP_NORETRY) & ~__GFP_RECLAIM) \
> + | __GFP_COMP)
> +static gfp_t order_flags[] = {HIGH_ORDER_GFP, HIGH_ORDER_GFP, LOW_ORDER_GFP};
> +static const unsigned int orders[] = {8, 4, 0};
> +#define NUM_ORDERS ARRAY_SIZE(orders)
> +
> +static struct page *alloc_largest_available(unsigned long size,
> + unsigned int max_order)
> +{
> + struct page *page;
> + int i;
> +
> + for (i = 0; i < NUM_ORDERS; i++) {
> + if (size < (PAGE_SIZE << orders[i]))
> + continue;
> + if (max_order < orders[i])
> +
Re: [PATCH v4 13/19] drm/msm/dp: add VSC SDP support for YUV420 over DP
On Tue, 20 Feb 2024 at 19:55, Paloma Arellano wrote:
>
>
> On 2/17/2024 12:56 AM, Dmitry Baryshkov wrote:
> > On Sat, 17 Feb 2024 at 01:03, Paloma Arellano
> > wrote:
> >> + }
> >> +
> >> + panel = container_of(dp_panel, struct dp_panel_private, dp_panel);
> >> + catalog = panel->catalog;
> >> + dp_mode = _panel->dp_mode;
> >> +
> >> + memset(_sdp_data, 0, sizeof(vsc_sdp_data));
> >> +
> >> + /* VSC SDP header as per table 2-118 of DP 1.4 specification */
> >> + vsc_sdp_data.sdp_type = DP_SDP_VSC;
> >> + vsc_sdp_data.revision = 0x05;
> >> + vsc_sdp_data.length = 0x13;
> >> +
> >> + /* VSC SDP Payload for DB16 */
> >> + vsc_sdp_data.pixelformat = DP_PIXELFORMAT_YUV420;
> >> + vsc_sdp_data.colorimetry = DP_COLORIMETRY_DEFAULT;
> >> +
> >> + /* VSC SDP Payload for DB17 */
> >> + vsc_sdp_data.bpc = dp_mode->bpp / 3;
> >> + vsc_sdp_data.dynamic_range = DP_DYNAMIC_RANGE_CTA;
> >> +
> >> + /* VSC SDP Payload for DB18 */
> >> + vsc_sdp_data.content_type = DP_CONTENT_TYPE_GRAPHICS;
> >> +
> >> + len = dp_utils_pack_vsc_sdp(_sdp_data, _sdp, header);
> >> + if (len < 0) {
> >> + DRM_ERROR("unable to pack vsc sdp\n");
> >> + return len;
> >> + }
> > So, at this point we have the header data both in vsc_sdp.sdp_header
> > and in the packed header. The relationship between them becomes less
> > obvious. Could you please pack dp_sdp_header into u32[2] just before
> > writing it? It really makes little sense to pass both at the same
> > time.
>
>
> Just want to clear some stuff up. Do you want to call the
> dp_utils_pack_sdp_header() function right before
> dp_catalog_panel_send_vsc_sdp()? The point of putting the
> dp_utils_pack_sdp_header() function inside dp_utils_pack_vsc_sdp() is so
> that all of the packing could be in the same location. Although I agree
> that we are passing the same values twice, I believe that having it the
> way it is currently is better since it shows that the
> drm_dp_vsc_sdp_pack() and dp_utils_pack_sdp_header() are related since
> they're packing the data to the set of GENERIC0 registers.
I'm perfectly fine with dp_utils_pack_sdp_header() being called from
within dp_catalog_panel_send_vsc_sdp(). This way you are not passing
extra data and it is perfectly clear how the SDP header is handled
before being written to the hardware.
--
With best wishes
Dmitry
Re: [PATCH] drm/i915/tv: Fix TV mode
On Tue, Feb 20, 2024 at 12:57:06PM -0500, Rodrigo Vivi wrote:
> On Tue, Feb 20, 2024 at 07:52:21PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 20, 2024 at 02:12:51PM +0100, Maxime Ripard wrote:
> > > Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed
> > > to update all the users of the struct drm_tv_connector_state mode field,
> > > which resulted in a build failure in i915.
> > >
> > > However, a subsequent commit in the same series reintroduced a mode
> > > field in that structure, with a different semantic but the same type,
> > > with the assumption that all previous users were updated.
> > >
> > > Since that didn't happen, the i915 driver now compiles, but mixes
> > > accesses to the legacy_mode field and the newer mode field, but with the
> > > previous semantics.
> > >
> > > This obviously doesn't work very well, so we need to update the accesses
> > > that weren't in the legacy renaming commit.
> > >
> > > Fixes: 1fd4a5a36f9f ("drm/connector: Rename legacy TV property")
> > > Reported-by: Ville Syrjälä
> > > Signed-off-by: Maxime Ripard
> > > ---
> > > drivers/gpu/drm/i915/display/intel_sdvo.c | 10 +-
> > > drivers/gpu/drm/i915/display/intel_tv.c | 10 +-
> > > 2 files changed, 10 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > index 825638702ac1..5f9e748adc89 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > @@ -1220,7 +1220,7 @@ static bool intel_sdvo_set_tv_format(struct
> > > intel_sdvo *intel_sdvo,
> > > struct intel_sdvo_tv_format format;
> > > u32 format_map;
> > >
> > > - format_map = 1 << conn_state->tv.mode;
> > > + format_map = 1 << conn_state->tv.legacy_mode;
> > > memset(, 0, sizeof(format));
> > > memcpy(, _map, min(sizeof(format), sizeof(format_map)));
> > >
> > > @@ -2323,7 +2323,7 @@ static int intel_sdvo_get_tv_modes(struct
> > > drm_connector *connector)
> > >* Read the list of supported input resolutions for the selected TV
> > >* format.
> > >*/
> > > - format_map = 1 << conn_state->tv.mode;
> > > + format_map = 1 << conn_state->tv.legacy_mode;
> > > memcpy(_res, _map,
> > > min(sizeof(format_map), sizeof(struct
> > > intel_sdvo_sdtv_resolution_request)));
> > >
> > > @@ -2388,7 +2388,7 @@ intel_sdvo_connector_atomic_get_property(struct
> > > drm_connector *connector,
> > > int i;
> > >
> > > for (i = 0; i < intel_sdvo_connector->format_supported_num; i++)
> > > - if (state->tv.mode ==
> > > intel_sdvo_connector->tv_format_supported[i]) {
> > > + if (state->tv.legacy_mode ==
> > > intel_sdvo_connector->tv_format_supported[i]) {
> > > *val = i;
> > >
> > > return 0;
> > > @@ -2444,7 +2444,7 @@ intel_sdvo_connector_atomic_set_property(struct
> > > drm_connector *connector,
> > > struct intel_sdvo_connector_state *sdvo_state =
> > > to_intel_sdvo_connector_state(state);
> > >
> > > if (property == intel_sdvo_connector->tv_format) {
> > > - state->tv.mode = intel_sdvo_connector->tv_format_supported[val];
> > > + state->tv.legacy_mode =
> > > intel_sdvo_connector->tv_format_supported[val];
> > >
> > > if (state->crtc) {
> > > struct drm_crtc_state *crtc_state =
> > > @@ -3108,7 +3108,7 @@ static bool intel_sdvo_tv_create_property(struct
> > > intel_sdvo *intel_sdvo,
> > > drm_property_add_enum(intel_sdvo_connector->tv_format, i,
> > >
> > > tv_format_names[intel_sdvo_connector->tv_format_supported[i]]);
> > >
> > > - intel_sdvo_connector->base.base.state->tv.mode =
> > > intel_sdvo_connector->tv_format_supported[0];
> > > + intel_sdvo_connector->base.base.state->tv.legacy_mode =
> > > intel_sdvo_connector->tv_format_supported[0];
> > > drm_object_attach_property(_sdvo_connector->base.base.base,
> > > intel_sdvo_connector->tv_format, 0);
> > > return true;
> >
> > Hmm. I didn't realize we are using this in the SDVO code as well.
> > I don't *think* that one is actually broken since it has its own
> > .{set,get}_property() hooks. But I suppose doing the rename
> > there as well is a good idea anyway.
> >
> > Can you split the SDVO vs. TV into separate patches? We need to
> > backport at least the TV part, and a smaller patch means less
> > chance of conflicts. Or if you prefer I can chunk it up while
> > pushing.
>
> hmm ouch... I shouldn't had rushed with it, I'm sorry.
> But I already merged this as is.
Did you at least slap a cc:stable on it? Or maybe the Fixes: tag is
enough these days...
>
> >
> > Both parts are
> > Reviewed-by: Ville Syrjälä
> >
> > Thanks.
> >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_tv.c
> > >
Re: [PATCH] arm64: dts: qcom: sm6115: fix USB PHY configuration
On Tue, 20 Feb 2024 19:31:04 +0200, Dmitry Baryshkov wrote: > The patch adding Type-C support for sm6115 was misapplied. All the > orientation switch configuration ended up at the UFS PHY node instead of > the USB PHY node. Move the data bits to the correct place. > > Applied, thanks! [1/1] arm64: dts: qcom: sm6115: fix USB PHY configuration commit: f176168bcb95bd1fdd32f5a794e68b7a36ac8740 Best regards, -- Bjorn Andersson
Re: [PATCH] drm/i915/tv: Fix TV mode
On Tue, Feb 20, 2024 at 07:52:21PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 20, 2024 at 02:12:51PM +0100, Maxime Ripard wrote:
> > Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed
> > to update all the users of the struct drm_tv_connector_state mode field,
> > which resulted in a build failure in i915.
> >
> > However, a subsequent commit in the same series reintroduced a mode
> > field in that structure, with a different semantic but the same type,
> > with the assumption that all previous users were updated.
> >
> > Since that didn't happen, the i915 driver now compiles, but mixes
> > accesses to the legacy_mode field and the newer mode field, but with the
> > previous semantics.
> >
> > This obviously doesn't work very well, so we need to update the accesses
> > that weren't in the legacy renaming commit.
> >
> > Fixes: 1fd4a5a36f9f ("drm/connector: Rename legacy TV property")
> > Reported-by: Ville Syrjälä
> > Signed-off-by: Maxime Ripard
> > ---
> > drivers/gpu/drm/i915/display/intel_sdvo.c | 10 +-
> > drivers/gpu/drm/i915/display/intel_tv.c | 10 +-
> > 2 files changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> > b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > index 825638702ac1..5f9e748adc89 100644
> > --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> > +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > @@ -1220,7 +1220,7 @@ static bool intel_sdvo_set_tv_format(struct
> > intel_sdvo *intel_sdvo,
> > struct intel_sdvo_tv_format format;
> > u32 format_map;
> >
> > - format_map = 1 << conn_state->tv.mode;
> > + format_map = 1 << conn_state->tv.legacy_mode;
> > memset(, 0, sizeof(format));
> > memcpy(, _map, min(sizeof(format), sizeof(format_map)));
> >
> > @@ -2323,7 +2323,7 @@ static int intel_sdvo_get_tv_modes(struct
> > drm_connector *connector)
> > * Read the list of supported input resolutions for the selected TV
> > * format.
> > */
> > - format_map = 1 << conn_state->tv.mode;
> > + format_map = 1 << conn_state->tv.legacy_mode;
> > memcpy(_res, _map,
> >min(sizeof(format_map), sizeof(struct
> > intel_sdvo_sdtv_resolution_request)));
> >
> > @@ -2388,7 +2388,7 @@ intel_sdvo_connector_atomic_get_property(struct
> > drm_connector *connector,
> > int i;
> >
> > for (i = 0; i < intel_sdvo_connector->format_supported_num; i++)
> > - if (state->tv.mode ==
> > intel_sdvo_connector->tv_format_supported[i]) {
> > + if (state->tv.legacy_mode ==
> > intel_sdvo_connector->tv_format_supported[i]) {
> > *val = i;
> >
> > return 0;
> > @@ -2444,7 +2444,7 @@ intel_sdvo_connector_atomic_set_property(struct
> > drm_connector *connector,
> > struct intel_sdvo_connector_state *sdvo_state =
> > to_intel_sdvo_connector_state(state);
> >
> > if (property == intel_sdvo_connector->tv_format) {
> > - state->tv.mode = intel_sdvo_connector->tv_format_supported[val];
> > + state->tv.legacy_mode =
> > intel_sdvo_connector->tv_format_supported[val];
> >
> > if (state->crtc) {
> > struct drm_crtc_state *crtc_state =
> > @@ -3108,7 +3108,7 @@ static bool intel_sdvo_tv_create_property(struct
> > intel_sdvo *intel_sdvo,
> > drm_property_add_enum(intel_sdvo_connector->tv_format, i,
> >
> > tv_format_names[intel_sdvo_connector->tv_format_supported[i]]);
> >
> > - intel_sdvo_connector->base.base.state->tv.mode =
> > intel_sdvo_connector->tv_format_supported[0];
> > + intel_sdvo_connector->base.base.state->tv.legacy_mode =
> > intel_sdvo_connector->tv_format_supported[0];
> > drm_object_attach_property(_sdvo_connector->base.base.base,
> >intel_sdvo_connector->tv_format, 0);
> > return true;
>
> Hmm. I didn't realize we are using this in the SDVO code as well.
> I don't *think* that one is actually broken since it has its own
> .{set,get}_property() hooks. But I suppose doing the rename
> there as well is a good idea anyway.
>
> Can you split the SDVO vs. TV into separate patches? We need to
> backport at least the TV part, and a smaller patch means less
> chance of conflicts. Or if you prefer I can chunk it up while
> pushing.
hmm ouch... I shouldn't had rushed with it, I'm sorry.
But I already merged this as is.
>
> Both parts are
> Reviewed-by: Ville Syrjälä
>
> Thanks.
>
> > diff --git a/drivers/gpu/drm/i915/display/intel_tv.c
> > b/drivers/gpu/drm/i915/display/intel_tv.c
> > index a96bcfcf90a3..2b77d399f1a1 100644
> > --- a/drivers/gpu/drm/i915/display/intel_tv.c
> > +++ b/drivers/gpu/drm/i915/display/intel_tv.c
> > @@ -950,7 +950,7 @@ intel_disable_tv(struct intel_atomic_state *state,
> >
> > static const struct tv_mode *intel_tv_mode_find(const struct
> >
Re: [PATCH v4 13/19] drm/msm/dp: add VSC SDP support for YUV420 over DP
On 2/17/2024 12:56 AM, Dmitry Baryshkov wrote:
On Sat, 17 Feb 2024 at 01:03, 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 v4:
- Remove struct msm_dp_sdp_with_parity
- Use dp_utils_pack_sdp_header() to pack the SDP header and
parity bytes into a buffer
- Use this buffer when writing the VSC SDP data in
dp_catalog_panel_send_vsc_sdp()
- Write to all of the MMSS_DP_GENERIC0 registers instead of just
the ones with non-zero values
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 | 107
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 | 56 +++
drivers/gpu/drm/msm/dp/dp_utils.h | 4 ++
7 files changed, 236 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 5d84c089e520a..c6e57812a239e 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -901,6 +901,113 @@ 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 dp_sdp *vsc_sdp,
+ u32 *header)
+{
+ struct dp_catalog_private *catalog;
+ u32 val;
+ int i;
+
+ if (!dp_catalog) {
+ DRM_ERROR("invalid input\n");
+ return;
+ }
We are two or three levels deep in the dp_catalog. Do we really need
to check that dp_catalog is not NULL?
Side note: I think we should drop most of such checks. They add
nothing, just clobber the code.
Ack. The dp_catalog checks do seem unnecessary.
+ catalog = container_of(dp_catalog, struct dp_catalog_private,
dp_catalog);
+
+ dp_write_link(catalog, MMSS_DP_GENERIC0_0, header[0]);
+ dp_write_link(catalog, MMSS_DP_GENERIC0_1, header[1]);
+
+ for (i = 0; i < sizeof(vsc_sdp->db); i += 4) {
+ val = ((vsc_sdp->db[i]) | (vsc_sdp->db[i + 1] << 8) | (vsc_sdp->db[i
+ 2] << 16) |
+ (vsc_sdp->db[i + 3] << 24));
+ dp_write_link(catalog, MMSS_DP_GENERIC0_2 + i, 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
dp_sdp *vsc_sdp,
+u32 *header)
+{
+ 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,
Re: [PATCH] drm/i915/tv: Fix TV mode
On Tue, Feb 20, 2024 at 02:12:51PM +0100, Maxime Ripard wrote:
> Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed
> to update all the users of the struct drm_tv_connector_state mode field,
> which resulted in a build failure in i915.
>
> However, a subsequent commit in the same series reintroduced a mode
> field in that structure, with a different semantic but the same type,
> with the assumption that all previous users were updated.
>
> Since that didn't happen, the i915 driver now compiles, but mixes
> accesses to the legacy_mode field and the newer mode field, but with the
> previous semantics.
>
> This obviously doesn't work very well, so we need to update the accesses
> that weren't in the legacy renaming commit.
>
> Fixes: 1fd4a5a36f9f ("drm/connector: Rename legacy TV property")
> Reported-by: Ville Syrjälä
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/i915/display/intel_sdvo.c | 10 +-
> drivers/gpu/drm/i915/display/intel_tv.c | 10 +-
> 2 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> b/drivers/gpu/drm/i915/display/intel_sdvo.c
> index 825638702ac1..5f9e748adc89 100644
> --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> @@ -1220,7 +1220,7 @@ static bool intel_sdvo_set_tv_format(struct intel_sdvo
> *intel_sdvo,
> struct intel_sdvo_tv_format format;
> u32 format_map;
>
> - format_map = 1 << conn_state->tv.mode;
> + format_map = 1 << conn_state->tv.legacy_mode;
> memset(, 0, sizeof(format));
> memcpy(, _map, min(sizeof(format), sizeof(format_map)));
>
> @@ -2323,7 +2323,7 @@ static int intel_sdvo_get_tv_modes(struct drm_connector
> *connector)
>* Read the list of supported input resolutions for the selected TV
>* format.
>*/
> - format_map = 1 << conn_state->tv.mode;
> + format_map = 1 << conn_state->tv.legacy_mode;
> memcpy(_res, _map,
> min(sizeof(format_map), sizeof(struct
> intel_sdvo_sdtv_resolution_request)));
>
> @@ -2388,7 +2388,7 @@ intel_sdvo_connector_atomic_get_property(struct
> drm_connector *connector,
> int i;
>
> for (i = 0; i < intel_sdvo_connector->format_supported_num; i++)
> - if (state->tv.mode ==
> intel_sdvo_connector->tv_format_supported[i]) {
> + if (state->tv.legacy_mode ==
> intel_sdvo_connector->tv_format_supported[i]) {
> *val = i;
>
> return 0;
> @@ -2444,7 +2444,7 @@ intel_sdvo_connector_atomic_set_property(struct
> drm_connector *connector,
> struct intel_sdvo_connector_state *sdvo_state =
> to_intel_sdvo_connector_state(state);
>
> if (property == intel_sdvo_connector->tv_format) {
> - state->tv.mode = intel_sdvo_connector->tv_format_supported[val];
> + state->tv.legacy_mode =
> intel_sdvo_connector->tv_format_supported[val];
>
> if (state->crtc) {
> struct drm_crtc_state *crtc_state =
> @@ -3108,7 +3108,7 @@ static bool intel_sdvo_tv_create_property(struct
> intel_sdvo *intel_sdvo,
> drm_property_add_enum(intel_sdvo_connector->tv_format, i,
>
> tv_format_names[intel_sdvo_connector->tv_format_supported[i]]);
>
> - intel_sdvo_connector->base.base.state->tv.mode =
> intel_sdvo_connector->tv_format_supported[0];
> + intel_sdvo_connector->base.base.state->tv.legacy_mode =
> intel_sdvo_connector->tv_format_supported[0];
> drm_object_attach_property(_sdvo_connector->base.base.base,
> intel_sdvo_connector->tv_format, 0);
> return true;
Hmm. I didn't realize we are using this in the SDVO code as well.
I don't *think* that one is actually broken since it has its own
.{set,get}_property() hooks. But I suppose doing the rename
there as well is a good idea anyway.
Can you split the SDVO vs. TV into separate patches? We need to
backport at least the TV part, and a smaller patch means less
chance of conflicts. Or if you prefer I can chunk it up while
pushing.
Both parts are
Reviewed-by: Ville Syrjälä
Thanks.
> diff --git a/drivers/gpu/drm/i915/display/intel_tv.c
> b/drivers/gpu/drm/i915/display/intel_tv.c
> index a96bcfcf90a3..2b77d399f1a1 100644
> --- a/drivers/gpu/drm/i915/display/intel_tv.c
> +++ b/drivers/gpu/drm/i915/display/intel_tv.c
> @@ -950,7 +950,7 @@ intel_disable_tv(struct intel_atomic_state *state,
>
> static const struct tv_mode *intel_tv_mode_find(const struct
> drm_connector_state *conn_state)
> {
> - int format = conn_state->tv.mode;
> + int format = conn_state->tv.legacy_mode;
>
> return _modes[format];
> }
> @@ -1705,7 +1705,7 @@ static void intel_tv_find_better_format(struct
> drm_connector *connector)
> break;
> }
>
> -
Re: [PATCH] drm/i915/tv: Fix TV mode
On Tue, Feb 20, 2024 at 02:12:51PM +0100, Maxime Ripard wrote:
> Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed
> to update all the users of the struct drm_tv_connector_state mode field,
> which resulted in a build failure in i915.
>
> However, a subsequent commit in the same series reintroduced a mode
> field in that structure, with a different semantic but the same type,
> with the assumption that all previous users were updated.
just for the record, commit 7d63cd8526f1 ("drm/connector: Add TV standard
property")
>
> Since that didn't happen, the i915 driver now compiles, but mixes
> accesses to the legacy_mode field and the newer mode field, but with the
> previous semantics.
>
> This obviously doesn't work very well, so we need to update the accesses
> that weren't in the legacy renaming commit.
>
> Fixes: 1fd4a5a36f9f ("drm/connector: Rename legacy TV property")
> Reported-by: Ville Syrjälä
> Signed-off-by: Maxime Ripard
Reviewed-by: Rodrigo Vivi
and pushing to drm-intel-next soon...
> ---
> drivers/gpu/drm/i915/display/intel_sdvo.c | 10 +-
> drivers/gpu/drm/i915/display/intel_tv.c | 10 +-
> 2 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> b/drivers/gpu/drm/i915/display/intel_sdvo.c
> index 825638702ac1..5f9e748adc89 100644
> --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> @@ -1220,7 +1220,7 @@ static bool intel_sdvo_set_tv_format(struct intel_sdvo
> *intel_sdvo,
> struct intel_sdvo_tv_format format;
> u32 format_map;
>
> - format_map = 1 << conn_state->tv.mode;
> + format_map = 1 << conn_state->tv.legacy_mode;
> memset(, 0, sizeof(format));
> memcpy(, _map, min(sizeof(format), sizeof(format_map)));
>
> @@ -2323,7 +2323,7 @@ static int intel_sdvo_get_tv_modes(struct drm_connector
> *connector)
>* Read the list of supported input resolutions for the selected TV
>* format.
>*/
> - format_map = 1 << conn_state->tv.mode;
> + format_map = 1 << conn_state->tv.legacy_mode;
> memcpy(_res, _map,
> min(sizeof(format_map), sizeof(struct
> intel_sdvo_sdtv_resolution_request)));
>
> @@ -2388,7 +2388,7 @@ intel_sdvo_connector_atomic_get_property(struct
> drm_connector *connector,
> int i;
>
> for (i = 0; i < intel_sdvo_connector->format_supported_num; i++)
> - if (state->tv.mode ==
> intel_sdvo_connector->tv_format_supported[i]) {
> + if (state->tv.legacy_mode ==
> intel_sdvo_connector->tv_format_supported[i]) {
> *val = i;
>
> return 0;
> @@ -2444,7 +2444,7 @@ intel_sdvo_connector_atomic_set_property(struct
> drm_connector *connector,
> struct intel_sdvo_connector_state *sdvo_state =
> to_intel_sdvo_connector_state(state);
>
> if (property == intel_sdvo_connector->tv_format) {
> - state->tv.mode = intel_sdvo_connector->tv_format_supported[val];
> + state->tv.legacy_mode =
> intel_sdvo_connector->tv_format_supported[val];
>
> if (state->crtc) {
> struct drm_crtc_state *crtc_state =
> @@ -3108,7 +3108,7 @@ static bool intel_sdvo_tv_create_property(struct
> intel_sdvo *intel_sdvo,
> drm_property_add_enum(intel_sdvo_connector->tv_format, i,
>
> tv_format_names[intel_sdvo_connector->tv_format_supported[i]]);
>
> - intel_sdvo_connector->base.base.state->tv.mode =
> intel_sdvo_connector->tv_format_supported[0];
> + intel_sdvo_connector->base.base.state->tv.legacy_mode =
> intel_sdvo_connector->tv_format_supported[0];
> drm_object_attach_property(_sdvo_connector->base.base.base,
> intel_sdvo_connector->tv_format, 0);
> return true;
> diff --git a/drivers/gpu/drm/i915/display/intel_tv.c
> b/drivers/gpu/drm/i915/display/intel_tv.c
> index a96bcfcf90a3..2b77d399f1a1 100644
> --- a/drivers/gpu/drm/i915/display/intel_tv.c
> +++ b/drivers/gpu/drm/i915/display/intel_tv.c
> @@ -950,7 +950,7 @@ intel_disable_tv(struct intel_atomic_state *state,
>
> static const struct tv_mode *intel_tv_mode_find(const struct
> drm_connector_state *conn_state)
> {
> - int format = conn_state->tv.mode;
> + int format = conn_state->tv.legacy_mode;
>
> return _modes[format];
> }
> @@ -1705,7 +1705,7 @@ static void intel_tv_find_better_format(struct
> drm_connector *connector)
> break;
> }
>
> - connector->state->tv.mode = i;
> + connector->state->tv.legacy_mode = i;
> }
>
> static int
> @@ -1863,7 +1863,7 @@ static int intel_tv_atomic_check(struct drm_connector
> *connector,
> old_state = drm_atomic_get_old_connector_state(state, connector);
> new_crtc_state =
Re: [PATCH] drm/edid/firmware: Remove built-in EDIDs
Hi Maxime
On Tue, 20 Feb 2024 at 16:10, Maxime Ripard wrote:
>
> The EDID firmware loading mechanism introduced a few built-in EDIDs that
> could be forced on any connector, bypassing the EDIDs it exposes.
>
> While convenient, this limited set of EDIDs doesn't take into account
> the connector type, and we can end up with an EDID that is completely
> invalid for a given connector.
>
> For example, the edid/800x600.bin file matches the following EDID:
>
> edid-decode (hex):
>
> 00 ff ff ff ff ff ff 00 31 d8 00 00 00 00 00 00
> 05 16 01 03 6d 1b 14 78 ea 5e c0 a4 59 4a 98 25
> 20 50 54 01 00 00 45 40 01 01 01 01 01 01 01 01
> 01 01 01 01 01 01 a0 0f 20 00 31 58 1c 20 28 80
> 14 00 15 d0 10 00 00 1e 00 00 00 ff 00 4c 69 6e
> 75 78 20 23 30 0a 20 20 20 20 00 00 00 fd 00 3b
> 3d 24 26 05 00 0a 20 20 20 20 20 20 00 00 00 fc
> 00 4c 69 6e 75 78 20 53 56 47 41 0a 20 20 00 c2
>
>
>
> Block 0, Base EDID:
> EDID Structure Version & Revision: 1.3
> Vendor & Product Identification:
> Manufacturer: LNX
> Model: 0
> Made in: week 5 of 2012
> Basic Display Parameters & Features:
> Analog display
> Signal Level Standard: 0.700 : 0.000 : 0.700 V p-p
> Blank level equals black level
> Sync: Separate Composite Serration
> Maximum image size: 27 cm x 20 cm
> Gamma: 2.20
> DPMS levels: Standby Suspend Off
> RGB color display
> First detailed timing is the preferred timing
> Color Characteristics:
> Red : 0.6416, 0.3486
> Green: 0.2919, 0.5957
> Blue : 0.1474, 0.1250
> White: 0.3125, 0.3281
> Established Timings I & II:
> DMT 0x09: 800x60060.316541 Hz 4:3 37.879 kHz 40.00
> MHz
> Standard Timings:
> DMT 0x09: 800x60060.316541 Hz 4:3 37.879 kHz 40.00
> MHz
> Detailed Timing Descriptors:
> DTD 1: 800x60060.316541 Hz 4:3 37.879 kHz 40.00 MHz
> (277 mm x 208 mm)
>Hfront 40 Hsync 128 Hback 88 Hpol P
>Vfront1 Vsync 4 Vback 23 Vpol P
> Display Product Serial Number: 'Linux #0'
> Display Range Limits:
> Monitor ranges (GTF): 59-61 Hz V, 36-38 kHz H, max dotclock 50 MHz
> Display Product Name: 'Linux SVGA'
> Checksum: 0xc2
>
> So, an analog monitor EDID. However, if the connector was an HDMI
> monitor for example, it breaks the HDMI specification that requires,
> among other things, a digital display, the VIC 1 mode and an HDMI Forum
> Vendor Specific Data Block in an CTA-861 extension.
>
> We thus end up with a completely invalid EDID, which thus might confuse
> HDMI-related code that could parse it.
>
> After some discussions on IRC, we identified mainly two ways to fix
> this:
>
> - We can either create more EDIDs for each connector type to provide
> a built-in EDID that matches the resolution passed in the name, and
> still be a sensible EDID for that connector type;
>
> - Or we can just prevent the EDID to be exposed to userspace if it's
> built-in.
>
> Or possibly both.
>
> However, the conclusion was that maybe we just don't need the built-in
> EDIDs at all and we should just get rid of them. So here we are.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/drm_edid_load.c | 160 +++-
Needs to be removed from the docs too:
"The code (see drivers/gpu/drm/drm_edid_load.c) contains built-in data
sets for commonly used screen resolutions (800x600, 1024x768,
1280x1024, 1600x1200, 1680x1050, 1920x1080) as binary blobs,..."
https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/edid.rst
I'm sad to see these go, but c'est la vie. Descriptions of using these
built in EDIDs abound in various tutorials, so those are all now
invalid :/
Dave
> 1 file changed, 13 insertions(+), 147 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
> index 60fcb80bce61..d1c7e8298702 100644
> --- a/drivers/gpu/drm/drm_edid_load.c
> +++ b/drivers/gpu/drm/drm_edid_load.c
> @@ -20,162 +20,28 @@
>
> static char edid_firmware[PATH_MAX];
> module_param_string(edid_firmware, edid_firmware, sizeof(edid_firmware),
> 0644);
> -MODULE_PARM_DESC(edid_firmware, "Do not probe monitor, use specified EDID
> blob "
> - "from built-in data or /lib/firmware instead. ");
> -
> -#define GENERIC_EDIDS 6
> -static const char * const generic_edid_name[GENERIC_EDIDS] = {
> - "edid/800x600.bin",
> - "edid/1024x768.bin",
> - "edid/1280x1024.bin",
> - "edid/1600x1200.bin",
> - "edid/1680x1050.bin",
> - "edid/1920x1080.bin",
> -};
> -
> -static const u8 generic_edid[GENERIC_EDIDS][128] = {
> - {
> - 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00,
> - 0x31, 0xd8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x05, 0x16, 0x01, 0x03, 0x6d, 0x1b, 0x14, 0x78,
> - 0xea, 0x5e, 0xc0,
[PATCH] arm64: dts: qcom: sm6115: fix USB PHY configuration
The patch adding Type-C support for sm6115 was misapplied. All the
orientation switch configuration ended up at the UFS PHY node instead of
the USB PHY node. Move the data bits to the correct place.
Fixes: a06a2f12f9e2 ("arm64: dts: qcom: qrb4210-rb2: enable USB-C port
handling")
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm6115.dtsi | 42 ++--
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi
b/arch/arm64/boot/dts/qcom/sm6115.dtsi
index ee65ab073ba6..b344f6f6d556 100644
--- a/arch/arm64/boot/dts/qcom/sm6115.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi
@@ -884,10 +884,31 @@ usb_qmpphy: phy@1615000 {
clock-output-names = "usb3_phy_pipe_clk_src";
#phy-cells = <0>;
+ orientation-switch;
qcom,tcsr-reg = <_regs 0xb244>;
status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ usb_qmpphy_out: endpoint {
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ usb_qmpphy_usb_ss_in: endpoint {
+ remote-endpoint =
<_dwc3_ss>;
+ };
+ };
+ };
};
system_noc: interconnect@188 {
@@ -1213,29 +1234,8 @@ ufs_mem_phy: phy@4807000 {
reset-names = "ufsphy";
#phy-cells = <0>;
- orientation-switch;
status = "disabled";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
-
- usb_qmpphy_out: endpoint {
- };
- };
-
- port@1 {
- reg = <1>;
-
- usb_qmpphy_usb_ss_in: endpoint {
- remote-endpoint =
<_dwc3_ss>;
- };
- };
- };
};
gpi_dma0: dma-controller@4a0 {
--
2.39.2
[PATCH] drm/msm/a6xx: specify UBWC config for sc7180
Historically the Adreno driver has not been updating memory
configuration registers on a618 (SC7180 platform) implying that the
default configuration is fine. After the rework performed in the commit
8814455a0e54 ("drm/msm: Refactor UBWC config setting") the function
a6xx_calc_ubwc_config() still contained this shortcut and did not
calculate UBWC configuration. However the function which now actually
updates hardware registers, a6xx_set_ubwc_config(), doesn't contain such
check.
Rather than adding the check to a6xx_set_ubwc_config(), fill in the
UBWC config for a618 (based on readings from SC7180).
Reported-by: Leonard Lausen
Link: https://gitlab.freedesktop.org/drm/msm/-/issues/49
Fixes: 8814455a0e54 ("drm/msm: Refactor UBWC config setting")
Cc: Connor Abbott
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index c9c55e2ea584..dc80e5940f51 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1292,9 +1292,8 @@ static void a6xx_calc_ubwc_config(struct adreno_gpu *gpu)
gpu->ubwc_config.ubwc_mode = 1;
}
- /* a618 is using the hw default values */
if (adreno_is_a618(gpu))
- return;
+ gpu->ubwc_config.highest_bank_bit = 14;
if (adreno_is_a619_holi(gpu))
gpu->ubwc_config.highest_bank_bit = 13;
---
base-commit: 41c177cf354126a22443b5c80cec9fdd313e67e1
change-id: 20240220-fd-sc7180-explicit-ubwc-40953fa55947
Best regards,
--
Dmitry Baryshkov
Re: [PATCH 4/4] ARM: dts: qcom: msm8974-hammerhead: Hook up backlight
On Tue, Feb 20, 2024 at 05:45:32PM +0100, Luca Weiss wrote:
> On Dienstag, 20. Februar 2024 15:12:10 CET Daniel Thompson wrote:
> > On Tue, Feb 20, 2024 at 12:11:22AM +0100, Luca Weiss wrote:
> > > Connect the panel with the backlight nodes so that the backlight can be
> > > turned off when the display is blanked.
> > >
> > > Signed-off-by: Luca Weiss
> >
> > Reviewed-by: Daniel Thompson
> >
> >
> > > ---
> > > arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git
> > > a/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
> > > b/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
> > > index 4aaae8537a3f..8eaa5b162815 100644
> > > --- a/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
> > > +++ b/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
> > > @@ -182,7 +182,7 @@ _i2c5 {
> > > status = "okay";
> > > clock-frequency = <355000>;
> > >
> > > - led-controller@38 {
> > > + backlight: led-controller@38 {
> >
> > Again... a minor nit regarding existing problems but this node doesn't
> > follow the generic naming recommendations:
> > https://devicetree-specification.readthedocs.io/en/stable/devicetree-basics.html#generic-names-recommendation
>
> "led-controller" is listed on that page, or do you mean something else?
That's the point ;-). It is supposed to be called backlight@38!
Daniel.
Re: [PATCH RESEND 0/4] Ensure all backlight drivers zero the properties structure
On Dienstag, 20. Februar 2024 16:35:23 CET Daniel Thompson wrote: > [Sorry for the RESEND so soon... embarrassingly I got Lee's e-mail > address wrong the first time!] > > Luca Weiss recently shared a patch to zero the properties structure for > lm3630a... and shortly afterwards I realized I should probably scan for > a similar class of errors in other drivers. Thanks for fixing the other drivers! Was definitely a fun one to debug :) > > Results follow in the next four patches (they could all be one patch but > for the fact there are different Fixes: tags)! > > Daniel Thompson (4): > backlight: da9052: Fully initialize backlight_properties during probe > backlight: lm3639: Fully initialize backlight_properties during probe > backlight: lp8788: Fully initialize backlight_properties during probe > backlight: mp3309c: Fully initialize backlight_properties during probe > > drivers/video/backlight/da9052_bl.c | 1 + > drivers/video/backlight/lm3639_bl.c | 1 + > drivers/video/backlight/lp8788_bl.c | 1 + > drivers/video/backlight/mp3309c.c | 1 + > 4 files changed, 4 insertions(+) > > > base-commit: b401b621758e46812da61fa58a67c3fd8d91de0d > -- > 2.43.0 > >
Re: [PATCH 4/4] ARM: dts: qcom: msm8974-hammerhead: Hook up backlight
On Dienstag, 20. Februar 2024 15:12:10 CET Daniel Thompson wrote:
> On Tue, Feb 20, 2024 at 12:11:22AM +0100, Luca Weiss wrote:
> > Connect the panel with the backlight nodes so that the backlight can be
> > turned off when the display is blanked.
> >
> > Signed-off-by: Luca Weiss
>
> Reviewed-by: Daniel Thompson
>
>
> > ---
> > arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
> > b/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
> > index 4aaae8537a3f..8eaa5b162815 100644
> > --- a/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
> > +++ b/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
> > @@ -182,7 +182,7 @@ _i2c5 {
> > status = "okay";
> > clock-frequency = <355000>;
> >
> > - led-controller@38 {
> > + backlight: led-controller@38 {
>
> Again... a minor nit regarding existing problems but this node doesn't
> follow the generic naming recommendations:
> https://devicetree-specification.readthedocs.io/en/stable/devicetree-basics.html#generic-names-recommendation
"led-controller" is listed on that page, or do you mean something else?
>
>
> Daniel.
>
Re: [PATCH] drm/edid/firmware: Remove built-in EDIDs
Am 20.02.24 um 17:10 schrieb Maxime Ripard:
The EDID firmware loading mechanism introduced a few built-in EDIDs that
could be forced on any connector, bypassing the EDIDs it exposes.
While convenient, this limited set of EDIDs doesn't take into account
the connector type, and we can end up with an EDID that is completely
invalid for a given connector.
For example, the edid/800x600.bin file matches the following EDID:
edid-decode (hex):
00 ff ff ff ff ff ff 00 31 d8 00 00 00 00 00 00
05 16 01 03 6d 1b 14 78 ea 5e c0 a4 59 4a 98 25
20 50 54 01 00 00 45 40 01 01 01 01 01 01 01 01
01 01 01 01 01 01 a0 0f 20 00 31 58 1c 20 28 80
14 00 15 d0 10 00 00 1e 00 00 00 ff 00 4c 69 6e
75 78 20 23 30 0a 20 20 20 20 00 00 00 fd 00 3b
3d 24 26 05 00 0a 20 20 20 20 20 20 00 00 00 fc
00 4c 69 6e 75 78 20 53 56 47 41 0a 20 20 00 c2
Block 0, Base EDID:
EDID Structure Version & Revision: 1.3
Vendor & Product Identification:
Manufacturer: LNX
Model: 0
Made in: week 5 of 2012
Basic Display Parameters & Features:
Analog display
Signal Level Standard: 0.700 : 0.000 : 0.700 V p-p
Blank level equals black level
Sync: Separate Composite Serration
Maximum image size: 27 cm x 20 cm
Gamma: 2.20
DPMS levels: Standby Suspend Off
RGB color display
First detailed timing is the preferred timing
Color Characteristics:
Red : 0.6416, 0.3486
Green: 0.2919, 0.5957
Blue : 0.1474, 0.1250
White: 0.3125, 0.3281
Established Timings I & II:
DMT 0x09: 800x60060.316541 Hz 4:3 37.879 kHz 40.00
MHz
Standard Timings:
DMT 0x09: 800x60060.316541 Hz 4:3 37.879 kHz 40.00
MHz
Detailed Timing Descriptors:
DTD 1: 800x60060.316541 Hz 4:3 37.879 kHz 40.00 MHz
(277 mm x 208 mm)
Hfront 40 Hsync 128 Hback 88 Hpol P
Vfront1 Vsync 4 Vback 23 Vpol P
Display Product Serial Number: 'Linux #0'
Display Range Limits:
Monitor ranges (GTF): 59-61 Hz V, 36-38 kHz H, max dotclock 50 MHz
Display Product Name: 'Linux SVGA'
Checksum: 0xc2
So, an analog monitor EDID. However, if the connector was an HDMI
monitor for example, it breaks the HDMI specification that requires,
among other things, a digital display, the VIC 1 mode and an HDMI Forum
Vendor Specific Data Block in an CTA-861 extension.
We thus end up with a completely invalid EDID, which thus might confuse
HDMI-related code that could parse it.
After some discussions on IRC, we identified mainly two ways to fix
this:
- We can either create more EDIDs for each connector type to provide
a built-in EDID that matches the resolution passed in the name, and
still be a sensible EDID for that connector type;
- Or we can just prevent the EDID to be exposed to userspace if it's
built-in.
Or possibly both.
However, the conclusion was that maybe we just don't need the built-in
EDIDs at all and we should just get rid of them. So here we are.
Signed-off-by: Maxime Ripard
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_edid_load.c | 160 +++-
1 file changed, 13 insertions(+), 147 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index 60fcb80bce61..d1c7e8298702 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -20,162 +20,28 @@
static char edid_firmware[PATH_MAX];
module_param_string(edid_firmware, edid_firmware, sizeof(edid_firmware),
0644);
-MODULE_PARM_DESC(edid_firmware, "Do not probe monitor, use specified EDID blob
"
- "from built-in data or /lib/firmware instead. ");
-
-#define GENERIC_EDIDS 6
-static const char * const generic_edid_name[GENERIC_EDIDS] = {
- "edid/800x600.bin",
- "edid/1024x768.bin",
- "edid/1280x1024.bin",
- "edid/1600x1200.bin",
- "edid/1680x1050.bin",
- "edid/1920x1080.bin",
-};
-
-static const u8 generic_edid[GENERIC_EDIDS][128] = {
- {
- 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00,
- 0x31, 0xd8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- 0x05, 0x16, 0x01, 0x03, 0x6d, 0x1b, 0x14, 0x78,
- 0xea, 0x5e, 0xc0, 0xa4, 0x59, 0x4a, 0x98, 0x25,
- 0x20, 0x50, 0x54, 0x01, 0x00, 0x00, 0x45, 0x40,
- 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
- 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0xa0, 0x0f,
- 0x20, 0x00, 0x31, 0x58, 0x1c, 0x20, 0x28, 0x80,
- 0x14, 0x00, 0x15, 0xd0, 0x10, 0x00, 0x00, 0x1e,
- 0x00, 0x00, 0x00, 0xff, 0x00, 0x4c, 0x69, 0x6e,
- 0x75, 0x78, 0x20, 0x23, 0x30, 0x0a, 0x20, 0x20,
- 0x20, 0x20, 0x00, 0x00, 0x00, 0xfd, 0x00, 0x3b,
- 0x3d, 0x24, 0x26, 0x05, 0x00, 0x0a, 0x20, 0x20,
- 0x20, 0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0xfc,
- 0x00, 0x4c, 0x69, 0x6e,
Re: [PATCH 3/4] backlight: lm3630a: Use backlight_get_brightness helper in update_status
On Dienstag, 20. Februar 2024 15:11:07 CET Daniel Thompson wrote: > On Tue, Feb 20, 2024 at 12:11:21AM +0100, Luca Weiss wrote: > > As per documentation "drivers are expected to use this function in their > > update_status() operation to get the brightness value.". > > > > With this we can also drop the manual backlight_is_blank() handling > > since backlight_get_brightness() is already handling this correctly. > > > > Signed-off-by: Luca Weiss > > Reviewed-by: Daniel Thompson > > However... > > > --- > > /* disable sleep */ > > @@ -201,9 +202,9 @@ static int lm3630a_bank_a_update_status(struct > > backlight_device *bl) > > goto out_i2c_err; > > usleep_range(1000, 2000); > > /* minimum brightness is 0x04 */ > > - ret = lm3630a_write(pchip, REG_BRT_A, bl->props.brightness); > > + ret = lm3630a_write(pchip, REG_BRT_A, brightness); > > ... then handling of the minimum brightness looks weird in this driver. > > The range of the backlight is 0..max_brightness. Sadly the drivers > are inconsistant regarding whether zero means off or just minimum, > however three certainly isn't supposed to mean off! In other words the > offsetting should be handled by driver rather than hoping userspace has > some magic LM3630A mode. I could also try and fix that.. 1. Treat 1..4 as 4, so have backlight on at that minimum level? Probably wouldn't be noticable that brightness 1=2=3=4. And the backlight will be on compared to off as it is now. 2. Decrease max_brightness by 4 values, so probably 0..251 and shift the values up in the driver so we get 4..255? Or would you have some other idea here? Regards Luca > > You didn't introduce this so this patch still has my R-b ... > > > Daniel. >
Re: [PATCH v2] accel/ivpu: Don't enable any tiles by default on VPU40xx
Applied to drm-misc-fixes
On 20.02.2024 14:16, Jacek Lawrynowicz wrote:
> From: Andrzej Kacprowski
>
> There is no point in requesting 1 tile on VPU40xx as the FW will
> probably need more tiles to run workloads, so it will have to
> reconfigure PLL anyway. Don't enable any tiles and allow the FW to
> perform initial tile configuration.
>
> This improves NPU boot stability as the tiles are always enabled only
> by the FW from the same initial state.
>
> Fixes: 79cdc56c4a54 ("accel/ivpu: Add initial support for VPU 4")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Andrzej Kacprowski
> Signed-off-by: Jacek Lawrynowicz
> ---
> drivers/accel/ivpu/ivpu_hw_40xx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/accel/ivpu/ivpu_hw_40xx.c
> b/drivers/accel/ivpu/ivpu_hw_40xx.c
> index 1c995307c113..a1523d0b1ef3 100644
> --- a/drivers/accel/ivpu/ivpu_hw_40xx.c
> +++ b/drivers/accel/ivpu/ivpu_hw_40xx.c
> @@ -24,7 +24,7 @@
> #define SKU_HW_ID_SHIFT 16u
> #define SKU_HW_ID_MASK 0xu
>
> -#define PLL_CONFIG_DEFAULT 0x1
> +#define PLL_CONFIG_DEFAULT 0x0
> #define PLL_CDYN_DEFAULT 0x80
> #define PLL_EPP_DEFAULT 0x80
> #define PLL_REF_CLK_FREQ (50 * 100)
[PATCH] drm/edid/firmware: Remove built-in EDIDs
The EDID firmware loading mechanism introduced a few built-in EDIDs that
could be forced on any connector, bypassing the EDIDs it exposes.
While convenient, this limited set of EDIDs doesn't take into account
the connector type, and we can end up with an EDID that is completely
invalid for a given connector.
For example, the edid/800x600.bin file matches the following EDID:
edid-decode (hex):
00 ff ff ff ff ff ff 00 31 d8 00 00 00 00 00 00
05 16 01 03 6d 1b 14 78 ea 5e c0 a4 59 4a 98 25
20 50 54 01 00 00 45 40 01 01 01 01 01 01 01 01
01 01 01 01 01 01 a0 0f 20 00 31 58 1c 20 28 80
14 00 15 d0 10 00 00 1e 00 00 00 ff 00 4c 69 6e
75 78 20 23 30 0a 20 20 20 20 00 00 00 fd 00 3b
3d 24 26 05 00 0a 20 20 20 20 20 20 00 00 00 fc
00 4c 69 6e 75 78 20 53 56 47 41 0a 20 20 00 c2
Block 0, Base EDID:
EDID Structure Version & Revision: 1.3
Vendor & Product Identification:
Manufacturer: LNX
Model: 0
Made in: week 5 of 2012
Basic Display Parameters & Features:
Analog display
Signal Level Standard: 0.700 : 0.000 : 0.700 V p-p
Blank level equals black level
Sync: Separate Composite Serration
Maximum image size: 27 cm x 20 cm
Gamma: 2.20
DPMS levels: Standby Suspend Off
RGB color display
First detailed timing is the preferred timing
Color Characteristics:
Red : 0.6416, 0.3486
Green: 0.2919, 0.5957
Blue : 0.1474, 0.1250
White: 0.3125, 0.3281
Established Timings I & II:
DMT 0x09: 800x60060.316541 Hz 4:3 37.879 kHz 40.00 MHz
Standard Timings:
DMT 0x09: 800x60060.316541 Hz 4:3 37.879 kHz 40.00 MHz
Detailed Timing Descriptors:
DTD 1: 800x60060.316541 Hz 4:3 37.879 kHz 40.00 MHz
(277 mm x 208 mm)
Hfront 40 Hsync 128 Hback 88 Hpol P
Vfront1 Vsync 4 Vback 23 Vpol P
Display Product Serial Number: 'Linux #0'
Display Range Limits:
Monitor ranges (GTF): 59-61 Hz V, 36-38 kHz H, max dotclock 50 MHz
Display Product Name: 'Linux SVGA'
Checksum: 0xc2
So, an analog monitor EDID. However, if the connector was an HDMI
monitor for example, it breaks the HDMI specification that requires,
among other things, a digital display, the VIC 1 mode and an HDMI Forum
Vendor Specific Data Block in an CTA-861 extension.
We thus end up with a completely invalid EDID, which thus might confuse
HDMI-related code that could parse it.
After some discussions on IRC, we identified mainly two ways to fix
this:
- We can either create more EDIDs for each connector type to provide
a built-in EDID that matches the resolution passed in the name, and
still be a sensible EDID for that connector type;
- Or we can just prevent the EDID to be exposed to userspace if it's
built-in.
Or possibly both.
However, the conclusion was that maybe we just don't need the built-in
EDIDs at all and we should just get rid of them. So here we are.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_edid_load.c | 160 +++-
1 file changed, 13 insertions(+), 147 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index 60fcb80bce61..d1c7e8298702 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -20,162 +20,28 @@
static char edid_firmware[PATH_MAX];
module_param_string(edid_firmware, edid_firmware, sizeof(edid_firmware), 0644);
-MODULE_PARM_DESC(edid_firmware, "Do not probe monitor, use specified EDID blob
"
- "from built-in data or /lib/firmware instead. ");
-
-#define GENERIC_EDIDS 6
-static const char * const generic_edid_name[GENERIC_EDIDS] = {
- "edid/800x600.bin",
- "edid/1024x768.bin",
- "edid/1280x1024.bin",
- "edid/1600x1200.bin",
- "edid/1680x1050.bin",
- "edid/1920x1080.bin",
-};
-
-static const u8 generic_edid[GENERIC_EDIDS][128] = {
- {
- 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00,
- 0x31, 0xd8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- 0x05, 0x16, 0x01, 0x03, 0x6d, 0x1b, 0x14, 0x78,
- 0xea, 0x5e, 0xc0, 0xa4, 0x59, 0x4a, 0x98, 0x25,
- 0x20, 0x50, 0x54, 0x01, 0x00, 0x00, 0x45, 0x40,
- 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
- 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0xa0, 0x0f,
- 0x20, 0x00, 0x31, 0x58, 0x1c, 0x20, 0x28, 0x80,
- 0x14, 0x00, 0x15, 0xd0, 0x10, 0x00, 0x00, 0x1e,
- 0x00, 0x00, 0x00, 0xff, 0x00, 0x4c, 0x69, 0x6e,
- 0x75, 0x78, 0x20, 0x23, 0x30, 0x0a, 0x20, 0x20,
- 0x20, 0x20, 0x00, 0x00, 0x00, 0xfd, 0x00, 0x3b,
- 0x3d, 0x24, 0x26, 0x05, 0x00, 0x0a, 0x20, 0x20,
- 0x20, 0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0xfc,
- 0x00, 0x4c, 0x69, 0x6e, 0x75, 0x78, 0x20, 0x53,
- 0x56, 0x47, 0x41, 0x0a, 0x20, 0x20, 0x00, 0xc2,
- },
- {
- 0x00, 0xff, 0xff, 0xff, 0xff,
[PATCH 12/13] accel/habanalabs: keep explicit size of reserved memory for FW
From: Tomer Tayar
The reserved memory for FW is currently saved in an ASIC property in
units of MB, just like the value that comes from FW.
Except the fact that it is not clear from the property's name, it means
also that a calculation to actual size is required everywhere that it is
used.
Modify the property to hold the size in bytes.
Signed-off-by: Tomer Tayar
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/firmware_if.c | 2 +-
drivers/accel/habanalabs/common/habanalabs.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/accel/habanalabs/common/firmware_if.c
b/drivers/accel/habanalabs/common/firmware_if.c
index 4246162b6807..348418643709 100644
--- a/drivers/accel/habanalabs/common/firmware_if.c
+++ b/drivers/accel/habanalabs/common/firmware_if.c
@@ -2749,7 +2749,7 @@ static int hl_fw_dynamic_init_cpu(struct hl_device *hdev,
if (hdev->asic_prop.support_dynamic_resereved_fw_size)
hdev->asic_prop.reserved_fw_mem_size =
-
le32_to_cpu(fw_loader->dynamic_loader.comm_desc.rsvd_mem_size_mb);
+
le32_to_cpu(fw_loader->dynamic_loader.comm_desc.rsvd_mem_size_mb) * SZ_1M;
if (!(hdev->fw_components & FW_TYPE_BOOT_CPU)) {
struct lkd_fw_binning_info *binning_info;
diff --git a/drivers/accel/habanalabs/common/habanalabs.h
b/drivers/accel/habanalabs/common/habanalabs.h
index 40107a4eba93..55495861f432 100644
--- a/drivers/accel/habanalabs/common/habanalabs.h
+++ b/drivers/accel/habanalabs/common/habanalabs.h
@@ -650,7 +650,7 @@ struct hl_hints_range {
* @glbl_err_max_cause_num: global err max cause number.
* @hbw_flush_reg: register to read to generate HBW flush. value of 0 means
HBW flush is
* not supported.
- * @reserved_fw_mem_size: size in MB of dram memory reserved for FW.
+ * @reserved_fw_mem_size: size of dram memory reserved for FW.
* @collective_first_sob: first sync object available for collective use
* @collective_first_mon: first monitor available for collective use
* @sync_stream_first_sob: first sync object available for sync stream use
--
2.34.1
[PATCH 10/13] accel/habanalabs/hwmon: rate limit errors user can generate
From: Ofir Bitton
Fetching sensor data can fail due to various reasons. In order
not to pollute the kernel log, those error prints must be
rate limited.
Signed-off-by: Ofir Bitton
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/hwmon.c | 29 +
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/accel/habanalabs/common/hwmon.c
b/drivers/accel/habanalabs/common/hwmon.c
index 1ee2ee07e9ed..36b951b5f503 100644
--- a/drivers/accel/habanalabs/common/hwmon.c
+++ b/drivers/accel/habanalabs/common/hwmon.c
@@ -46,7 +46,7 @@ static u32 fixup_flags_legacy_fw(struct hl_device *hdev, enum
hwmon_sensor_types
break;
default:
- dev_err(hdev->dev, "unsupported h/w sensor type %d\n", type);
+ dev_err_ratelimited(hdev->dev, "unsupported h/w sensor type
%d\n", type);
flags = cpucp_flags;
break;
}
@@ -134,7 +134,7 @@ static u32 adjust_hwmon_flags(struct hl_device *hdev, enum
hwmon_sensor_types ty
break;
default:
- dev_err(hdev->dev, "unsupported h/w sensor type %d\n",
type);
+ dev_err_ratelimited(hdev->dev, "unsupported h/w sensor
type %d\n", type);
flags = cpucp_flags;
break;
}
@@ -162,7 +162,8 @@ int hl_build_hwmon_channel_info(struct hl_device *hdev,
struct cpucp_sensor *sen
break;
if (type >= HWMON_NR_SENSOR_TYPES) {
- dev_err(hdev->dev, "Got wrong sensor type %d from
device\n", type);
+ dev_err_ratelimited(hdev->dev,
+ "Got wrong sensor type %d from device\n", type);
return -EINVAL;
}
@@ -584,7 +585,7 @@ int hl_get_temperature(struct hl_device *hdev,
*value = (long) result;
if (rc) {
- dev_err(hdev->dev,
+ dev_err_ratelimited(hdev->dev,
"Failed to get temperature from sensor %d, error %d\n",
sensor_index, rc);
*value = 0;
@@ -611,7 +612,7 @@ int hl_set_temperature(struct hl_device *hdev,
0, NULL);
if (rc)
- dev_err(hdev->dev,
+ dev_err_ratelimited(hdev->dev,
"Failed to set temperature of sensor %d, error %d\n",
sensor_index, rc);
@@ -638,7 +639,7 @@ int hl_get_voltage(struct hl_device *hdev,
*value = (long) result;
if (rc) {
- dev_err(hdev->dev,
+ dev_err_ratelimited(hdev->dev,
"Failed to get voltage from sensor %d, error %d\n",
sensor_index, rc);
*value = 0;
@@ -667,7 +668,7 @@ int hl_get_current(struct hl_device *hdev,
*value = (long) result;
if (rc) {
- dev_err(hdev->dev,
+ dev_err_ratelimited(hdev->dev,
"Failed to get current from sensor %d, error %d\n",
sensor_index, rc);
*value = 0;
@@ -696,7 +697,7 @@ int hl_get_fan_speed(struct hl_device *hdev,
*value = (long) result;
if (rc) {
- dev_err(hdev->dev,
+ dev_err_ratelimited(hdev->dev,
"Failed to get fan speed from sensor %d, error %d\n",
sensor_index, rc);
*value = 0;
@@ -725,7 +726,7 @@ int hl_get_pwm_info(struct hl_device *hdev,
*value = (long) result;
if (rc) {
- dev_err(hdev->dev,
+ dev_err_ratelimited(hdev->dev,
"Failed to get pwm info from sensor %d, error %d\n",
sensor_index, rc);
*value = 0;
@@ -752,7 +753,7 @@ void hl_set_pwm_info(struct hl_device *hdev, int
sensor_index, u32 attr,
0, NULL);
if (rc)
- dev_err(hdev->dev,
+ dev_err_ratelimited(hdev->dev,
"Failed to set pwm info to sensor %d, error %d\n",
sensor_index, rc);
}
@@ -775,7 +776,7 @@ int hl_set_voltage(struct hl_device *hdev,
0, NULL);
if (rc)
- dev_err(hdev->dev,
+ dev_err_ratelimited(hdev->dev,
"Failed to set voltage of sensor %d, error %d\n",
sensor_index, rc);
@@ -800,7 +801,7 @@ int hl_set_current(struct hl_device *hdev,
0, NULL);
if (rc)
- dev_err(hdev->dev,
+ dev_err_ratelimited(hdev->dev,
"Failed to set current of sensor %d, error %d\n",
[PATCH 09/13] accel/habanalabs/gaudi2: drain event lacks rd/wr indication
From: Ofir Bitton
Due to a H/W issue, AXI drain event does not include a read/write
indication, hence we remove this print.
Signed-off-by: Ofir Bitton
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/gaudi2/gaudi2.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/accel/habanalabs/gaudi2/gaudi2.c
b/drivers/accel/habanalabs/gaudi2/gaudi2.c
index 189d8da6a624..ba1518f2bf5c 100644
--- a/drivers/accel/habanalabs/gaudi2/gaudi2.c
+++ b/drivers/accel/habanalabs/gaudi2/gaudi2.c
@@ -9548,25 +9548,17 @@ static int gaudi2_handle_pcie_p2p_msix(struct hl_device
*hdev, u16 event_type)
static int gaudi2_handle_pcie_drain(struct hl_device *hdev,
struct hl_eq_pcie_drain_ind_data *drain_data)
{
- u64 lbw_rd, lbw_wr, hbw_rd, hbw_wr, cause, error_count = 0;
+ u64 cause, error_count = 0;
cause = le64_to_cpu(drain_data->intr_cause.intr_cause_data);
- lbw_rd = le64_to_cpu(drain_data->drain_rd_addr_lbw);
- lbw_wr = le64_to_cpu(drain_data->drain_wr_addr_lbw);
- hbw_rd = le64_to_cpu(drain_data->drain_rd_addr_hbw);
- hbw_wr = le64_to_cpu(drain_data->drain_wr_addr_hbw);
if (cause & BIT_ULL(0)) {
- dev_err_ratelimited(hdev->dev,
- "PCIE AXI drain LBW completed, read_err %u, write_err
%u\n",
- !!lbw_rd, !!lbw_wr);
+ dev_err_ratelimited(hdev->dev, "PCIE AXI drain LBW
completed\n");
error_count++;
}
if (cause & BIT_ULL(1)) {
- dev_err_ratelimited(hdev->dev,
- "PCIE AXI drain HBW completed, raddr %#llx, waddr
%#llx\n",
- hbw_rd, hbw_wr);
+ dev_err_ratelimited(hdev->dev, "PCIE AXI drain HBW
completed\n");
error_count++;
}
--
2.34.1
