RE: [PATCH v2] drm/amd/display: Only define DP 2.0 symbols if not already defined
We have merged such DRM definition dependencies previously through a topic
branch in order to avoid redefining inside the driver.
But yes guarding this with ifdef is good.
Reviewed-by: Manasi Navare
Manasi
-Original Message-
From: Zuo, Jerry
Sent: Tuesday, September 28, 2021 11:11 PM
To: Wentland, Harry ; Deucher, Alexander
; amd-...@lists.freedesktop.org
Cc: Nikula, Jani ; Li, Sun peng (Leo)
; nat...@kernel.org; intel-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org; ville.syrj...@linux.intel.com; Navare, Manasi
D ; Koenig, Christian ;
Pan, Xinhui ; s...@canb.auug.org.au;
linux-n...@vger.kernel.org; airl...@gmail.com; daniel.vet...@ffwll.ch;
Wentland, Harry
Subject: RE: [PATCH v2] drm/amd/display: Only define DP 2.0 symbols if not
already defined
[AMD Official Use Only]
> -Original Message-
> From: Harry Wentland
> Sent: September 28, 2021 1:08 PM
> To: Deucher, Alexander ; amd-
> g...@lists.freedesktop.org; Zuo, Jerry
> Cc: jani.nik...@intel.com; Li, Sun peng (Leo) ;
> nat...@kernel.org; intel-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; ville.syrj...@linux.intel.com;
> manasi.d.nav...@intel.com; Koenig, Christian
> ; Pan, Xinhui ;
> s...@canb.auug.org.au; linux- n...@vger.kernel.org; airl...@gmail.com;
> daniel.vet...@ffwll.ch; Wentland, Harry
> Subject: [PATCH v2] drm/amd/display: Only define DP 2.0 symbols if not
> already defined
>
> [Why]
> For some reason we're defining DP 2.0 definitions inside our driver.
> Now that patches to introduce relevant definitions are slated to be
> merged into drm- next this is causing conflicts.
>
> In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:33:
> In file included
> from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:70:
> In file included
> from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu_mode.h:36:
> ./include/drm/drm_dp_helper.h:1322:9: error:
> 'DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER' macro redefined [-
> Werror,-Wmacro-redefined]
> ^
> ./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: note:
> previous definition is here
> ^
> 1 error generated.
>
> v2: Add one missing endif
>
> [How]
> Guard all display driver defines with #ifndef for now. Once we pull in
> the new definitions into amd-staging-drm-next we will follow up and
> drop definitions from our driver and provide follow-up header updates
> for any addition DP
> 2.0 definitions required by our driver.
>
> Signed-off-by: Harry Wentland
Reviewed-by: Fangzhi Zuo
> ---
> drivers/gpu/drm/amd/display/dc/dc_dp_types.h | 54
> ++--
> 1 file changed, 49 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
> b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
> index a5e798b5da79..9de86ff5ef1b 100644
> --- a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
> +++ b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
> @@ -860,28 +860,72 @@ struct psr_caps { };
>
> #if defined(CONFIG_DRM_AMD_DC_DCN)
> +#ifndef DP_MAIN_LINK_CHANNEL_CODING_CAP
> #define DP_MAIN_LINK_CHANNEL_CODING_CAP 0x006
> +#endif
> +#ifndef DP_SINK_VIDEO_FALLBACK_FORMATS
> #define DP_SINK_VIDEO_FALLBACK_FORMATS 0x020
> +#endif
> +#ifndef DP_FEC_CAPABILITY_1
> #define DP_FEC_CAPABILITY_1 0x091
> +#endif
> +#ifndef DP_DFP_CAPABILITY_EXTENSION_SUPPORT
> #define DP_DFP_CAPABILITY_EXTENSION_SUPPORT 0x0A3
> +#endif
> +#ifndef DP_DSC_CONFIGURATION
> #define DP_DSC_CONFIGURATION 0x161
> +#endif
> +#ifndef DP_PHY_SQUARE_PATTERN
> #define DP_PHY_SQUARE_PATTERN0x249
> +#endif
> +#ifndef DP_128b_132b_SUPPORTED_LINK_RATES
> #define DP_128b_132b_SUPPORTED_LINK_RATES0x2215
> +#endif
> +#ifndef DP_128b_132b_TRAINING_AUX_RD_INTERVAL
> #define DP_128b_132b_TRAINING_AUX_RD_INTERVAL
> 0x2216
> +#endif
> +#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_7_0
> #define DP_TEST_264BIT_CUSTOM_PATTERN_7_00X2230
> +#endif
> +#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_263_256
> #define DP_TEST_264BIT_CUSTOM_PATTERN_263_256
> 0X2250
> +#endif
> +#ifndef DP_DSC_SUPPORT_AND_DECODER_COUNT
> #define DP_DSC_SUPPORT_AND_DECODER_COUNT 0x2260
> +#endif
> +#ifndef DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0
> #define DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0
> 0x2270
> -# define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK (1 <<
> 0)
> -# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK
> (0b111 << 1)
> -# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT 1
> -# define DP_DSC_DECODER_COUNT_MASK (0b111 << 5)
> -# define DP_DSC_DECODER_COUNT_SHIFT 5
> +#endif
> +#ifndef DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK
> +#define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK(1 <<
> 0)
> +#endif
> +#ifndef DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK
> +#define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK
>
Re: [PATCH][next] nouveau/svm: Use kvcalloc() instead of kvzalloc()
Lack of documentation inside Linux here is a bit annoying, but do I understand it correctly, that the main (and probably only) difference is that kvcalloc checks whether the multiplication overflows and returns NULL in this case? On Wed, Sep 29, 2021 at 12:21 AM Gustavo A. R. Silva wrote: > > Use 2-factor argument form kvcalloc() instead of kvzalloc(). > > Link: https://github.com/KSPP/linux/issues/162 > Signed-off-by: Gustavo A. R. Silva > --- > drivers/gpu/drm/nouveau/nouveau_svm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c > b/drivers/gpu/drm/nouveau/nouveau_svm.c > index b0c3422cb01f..1a896a24288a 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_svm.c > +++ b/drivers/gpu/drm/nouveau/nouveau_svm.c > @@ -992,7 +992,7 @@ nouveau_svm_fault_buffer_ctor(struct nouveau_svm *svm, > s32 oclass, int id) > if (ret) > return ret; > > - buffer->fault = kvzalloc(sizeof(*buffer->fault) * buffer->entries, > GFP_KERNEL); > + buffer->fault = kvcalloc(sizeof(*buffer->fault), buffer->entries, > GFP_KERNEL); > if (!buffer->fault) > return -ENOMEM; > > -- > 2.27.0 >
Re: [PATCH v3 2/4] drm/rockchip: dsi: Reconfigure hardware on resume()
On Wed, Sep 29, 2021 at 5:36 AM Brian Norris wrote:
>
> Since commit 43c2de1002d2, we perform most HW configuration in the
> bind() function. This configuration may be lost on suspend/resume, so we
> need to call it again. That may lead to errors like this after system
> suspend/resume:
>
> dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO
> panel-kingdisplay-kd097d04 ff96.mipi.0: failed write init cmds: -110
>
> Tested on Acer Chromebook Tab 10 (RK3399 Gru-Scarlet).
>
> Note that early mailing list versions of this driver borrowed Rockchip's
> downstream/BSP solution, to do HW configuration in mode_set() (which
> *is* called at the appropriate pre-enable() times), but that was
> discarded along the way. I've avoided that still, because mode_set()
> documentation doesn't suggest this kind of purpose as far as I can tell.
>
> Fixes: 43c2de1002d2 ("drm/rockchip: dsi: move all lane config except LCDC mux
> to bind()")
> Cc:
> Signed-off-by: Brian Norris
Reviewed-by: Chen-Yu Tsai
Re: [PATCH v3 1/4] drm/rockchip: dsi: Hold pm-runtime across bind/unbind
On Wed, Sep 29, 2021 at 5:36 AM Brian Norris wrote:
>
> In commit 43c2de1002d2, we moved most HW configuration to bind(), but we
> didn't move the runtime PM management. Therefore, depending on initial
> boot state, runtime-PM workqueue delays, and other timing factors, we
> may disable our power domain in between the hardware configuration
> (bind()) and when we enable the display. This can cause us to lose
> hardware state and fail to configure our display. For example:
>
> dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO
> panel-innolux-p079zca ff96.mipi.0: failed to write command 0
>
> or:
>
> dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO
> panel-kingdisplay-kd097d04 ff96.mipi.0: failed write init cmds: -110
>
> We should match the runtime PM to the lifetime of the bind()/unbind()
> cycle.
>
> Tested on Acer Chrometab 10 (RK3399 Gru-Scarlet), with panel drivers
> built either as modules or built-in.
>
> Side notes: it seems one is more likely to see this problem when the
> panel driver is built into the kernel. I've also seen this problem
> bisect down to commits that simply changed Kconfig dependencies, because
> it changed the order in which driver init functions were compiled into
> the kernel, and therefore the ordering and timing of built-in device
> probe.
>
> Fixes: 43c2de1002d2 ("drm/rockchip: dsi: move all lane config except LCDC mux
> to bind()")
> Link:
> https://lore.kernel.org/linux-rockchip/9aedfb528600ecf871885f7293ca4207c84d16c1.ca...@gmail.com/
> Reported-by:
> Cc:
> Signed-off-by: Brian Norris
> Tested-by: Nícolas F. R. A. Prado
Reviewed-by: Chen-Yu Tsai
[PATCH v8 12/12] arm64: dts: mediatek: Get rid of mediatek, larb for MM nodes
After adding device_link between the IOMMU consumer and smi,
the mediatek,larb is unnecessary now.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 16
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 6 --
2 files changed, 22 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index d9e005ae5bb0..205c221696a6 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -1009,7 +1009,6 @@
< CLK_MM_MUTEX_32K>;
power-domains = < MT8173_POWER_DOMAIN_MM>;
iommus = < M4U_PORT_MDP_RDMA0>;
- mediatek,larb = <>;
mediatek,vpu = <>;
};
@@ -1020,7 +1019,6 @@
< CLK_MM_MUTEX_32K>;
power-domains = < MT8173_POWER_DOMAIN_MM>;
iommus = < M4U_PORT_MDP_RDMA1>;
- mediatek,larb = <>;
};
mdp_rsz0: rsz@14003000 {
@@ -1050,7 +1048,6 @@
clocks = < CLK_MM_MDP_WDMA>;
power-domains = < MT8173_POWER_DOMAIN_MM>;
iommus = < M4U_PORT_MDP_WDMA>;
- mediatek,larb = <>;
};
mdp_wrot0: wrot@14007000 {
@@ -1059,7 +1056,6 @@
clocks = < CLK_MM_MDP_WROT0>;
power-domains = < MT8173_POWER_DOMAIN_MM>;
iommus = < M4U_PORT_MDP_WROT0>;
- mediatek,larb = <>;
};
mdp_wrot1: wrot@14008000 {
@@ -1068,7 +1064,6 @@
clocks = < CLK_MM_MDP_WROT1>;
power-domains = < MT8173_POWER_DOMAIN_MM>;
iommus = < M4U_PORT_MDP_WROT1>;
- mediatek,larb = <>;
};
ovl0: ovl@1400c000 {
@@ -1078,7 +1073,6 @@
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_OVL0>;
iommus = < M4U_PORT_DISP_OVL0>;
- mediatek,larb = <>;
mediatek,gce-client-reg = < SUBSYS_1400 0xc000
0x1000>;
};
@@ -1089,7 +1083,6 @@
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_OVL1>;
iommus = < M4U_PORT_DISP_OVL1>;
- mediatek,larb = <>;
mediatek,gce-client-reg = < SUBSYS_1400 0xd000
0x1000>;
};
@@ -1100,7 +1093,6 @@
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_RDMA0>;
iommus = < M4U_PORT_DISP_RDMA0>;
- mediatek,larb = <>;
mediatek,gce-client-reg = < SUBSYS_1400 0xe000
0x1000>;
};
@@ -,7 +1103,6 @@
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_RDMA1>;
iommus = < M4U_PORT_DISP_RDMA1>;
- mediatek,larb = <>;
mediatek,gce-client-reg = < SUBSYS_1400 0xf000
0x1000>;
};
@@ -1122,7 +1113,6 @@
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_RDMA2>;
iommus = < M4U_PORT_DISP_RDMA2>;
- mediatek,larb = <>;
mediatek,gce-client-reg = < SUBSYS_1401 0
0x1000>;
};
@@ -1133,7 +1123,6 @@
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_WDMA0>;
iommus = < M4U_PORT_DISP_WDMA0>;
- mediatek,larb = <>;
mediatek,gce-client-reg = < SUBSYS_1401 0x1000
0x1000>;
};
@@ -1144,7 +1133,6 @@
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_WDMA1>;
iommus = < M4U_PORT_DISP_WDMA1>;
- mediatek,larb = <>;
mediatek,gce-client-reg = < SUBSYS_1401 0x2000
0x1000>;
};
@@ -1395,7 +1383,6 @@
<0 0x16027800 0 0x800>, /* VDEC_HWB */
<0 0x16028400 0 0x400>; /* VDEC_HWG */
interrupts = ;
- mediatek,larb = <>;
iommus = < M4U_PORT_HW_VDEC_MC_EXT>,
< M4U_PORT_HW_VDEC_PP_EXT>,
< M4U_PORT_HW_VDEC_AVC_MV_EXT>,
@@ -1463,7 +1450,6 @@
[PATCH v8 11/12] arm: dts: mediatek: Get rid of mediatek, larb for MM nodes
After adding device_link between the IOMMU consumer and smi, the
mediatek,larb is unnecessary now.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
arch/arm/boot/dts/mt2701.dtsi | 2 --
arch/arm/boot/dts/mt7623n.dtsi | 5 -
2 files changed, 7 deletions(-)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 4776f85d6d5b..ef583cfd3baf 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -564,7 +564,6 @@
clock-names = "jpgdec-smi",
"jpgdec";
power-domains = < MT2701_POWER_DOMAIN_ISP>;
- mediatek,larb = <>;
iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
< MT2701_M4U_PORT_JPGDEC_BSDMA>;
};
@@ -577,7 +576,6 @@
clocks = < CLK_IMG_VENC>;
clock-names = "jpgenc";
power-domains = < MT2701_POWER_DOMAIN_ISP>;
- mediatek,larb = <>;
iommus = < MT2701_M4U_PORT_JPGENC_RDMA>,
< MT2701_M4U_PORT_JPGENC_BSDMA>;
};
diff --git a/arch/arm/boot/dts/mt7623n.dtsi b/arch/arm/boot/dts/mt7623n.dtsi
index bcb0846e29fd..3adab5cd1fef 100644
--- a/arch/arm/boot/dts/mt7623n.dtsi
+++ b/arch/arm/boot/dts/mt7623n.dtsi
@@ -121,7 +121,6 @@
clock-names = "jpgdec-smi",
"jpgdec";
power-domains = < MT2701_POWER_DOMAIN_ISP>;
- mediatek,larb = <>;
iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
< MT2701_M4U_PORT_JPGDEC_BSDMA>;
};
@@ -144,7 +143,6 @@
interrupts = ;
clocks = < CLK_MM_DISP_OVL>;
iommus = < MT2701_M4U_PORT_DISP_OVL_0>;
- mediatek,larb = <>;
};
rdma0: rdma@14008000 {
@@ -154,7 +152,6 @@
interrupts = ;
clocks = < CLK_MM_DISP_RDMA>;
iommus = < MT2701_M4U_PORT_DISP_RDMA>;
- mediatek,larb = <>;
};
wdma@14009000 {
@@ -164,7 +161,6 @@
interrupts = ;
clocks = < CLK_MM_DISP_WDMA>;
iommus = < MT2701_M4U_PORT_DISP_WDMA>;
- mediatek,larb = <>;
};
bls: pwm@1400a000 {
@@ -215,7 +211,6 @@
interrupts = ;
clocks = < CLK_MM_DISP_RDMA1>;
iommus = < MT2701_M4U_PORT_DISP_RDMA1>;
- mediatek,larb = <>;
};
dpi0: dpi@14014000 {
--
2.18.0
[PATCH v8 10/12] memory: mtk-smi: Get rid of mtk_smi_larb_get/put
After adding device_link between the iommu consumer and smi-larb,
the pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. we can get rid of mtk_smi_larb_get/put.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Krzysztof Kozlowski
Acked-by: Matthias Brugger
Reviewed-by: Dafna Hirschfeld
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
drivers/memory/mtk-smi.c | 14 --
include/soc/mediatek/smi.h | 20
2 files changed, 34 deletions(-)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index c5fb51f73b34..7c61c924e220 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -134,20 +134,6 @@ static void mtk_smi_clk_disable(const struct mtk_smi *smi)
clk_disable_unprepare(smi->clk_apb);
}
-int mtk_smi_larb_get(struct device *larbdev)
-{
- int ret = pm_runtime_resume_and_get(larbdev);
-
- return (ret < 0) ? ret : 0;
-}
-EXPORT_SYMBOL_GPL(mtk_smi_larb_get);
-
-void mtk_smi_larb_put(struct device *larbdev)
-{
- pm_runtime_put_sync(larbdev);
-}
-EXPORT_SYMBOL_GPL(mtk_smi_larb_put);
-
static int
mtk_smi_larb_bind(struct device *dev, struct device *master, void *data)
{
diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
index 15e3397cec58..11f7d6b59642 100644
--- a/include/soc/mediatek/smi.h
+++ b/include/soc/mediatek/smi.h
@@ -19,26 +19,6 @@ struct mtk_smi_larb_iommu {
unsigned char bank[32];
};
-/*
- * mtk_smi_larb_get: Enable the power domain and clocks for this local arbiter.
- * It also initialize some basic setting(like iommu).
- * mtk_smi_larb_put: Disable the power domain and clocks for this local
arbiter.
- * Both should be called in non-atomic context.
- *
- * Returns 0 if successful, negative on failure.
- */
-int mtk_smi_larb_get(struct device *larbdev);
-void mtk_smi_larb_put(struct device *larbdev);
-
-#else
-
-static inline int mtk_smi_larb_get(struct device *larbdev)
-{
- return 0;
-}
-
-static inline void mtk_smi_larb_put(struct device *larbdev) { }
-
#endif
#endif
--
2.18.0
[PATCH v8 09/12] media: mtk-vcodec: Get rid of mtk_smi_larb_get/put
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the vcodec device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Tiffany Lin
CC: Irui Wang
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Tiffany Lin
Reviewed-by: Dafna Hirschfeld
---
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 37 +++-
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 3 --
.../platform/mtk-vcodec/mtk_vcodec_enc.c | 1 -
.../platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 44 +++
4 files changed, 10 insertions(+), 75 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
index 6038db96f71c..d0bf9aa3b29d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -8,14 +8,12 @@
#include
#include
#include
-#include
#include "mtk_vcodec_dec_pm.h"
#include "mtk_vcodec_util.h"
int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
{
- struct device_node *node;
struct platform_device *pdev;
struct mtk_vcodec_pm *pm;
struct mtk_vcodec_clk *dec_clk;
@@ -26,18 +24,7 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
pm = >pm;
pm->mtkdev = mtkdev;
dec_clk = >vdec_clk;
- node = of_parse_phandle(pdev->dev.of_node, "mediatek,larb", 0);
- if (!node) {
- mtk_v4l2_err("of_parse_phandle mediatek,larb fail!");
- return -1;
- }
- pdev = of_find_device_by_node(node);
- of_node_put(node);
- if (WARN_ON(!pdev)) {
- return -1;
- }
- pm->larbvdec = >dev;
pdev = mtkdev->plat_dev;
pm->dev = >dev;
@@ -47,14 +34,11 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
dec_clk->clk_info = devm_kcalloc(>dev,
dec_clk->clk_num, sizeof(*clk_info),
GFP_KERNEL);
- if (!dec_clk->clk_info) {
- ret = -ENOMEM;
- goto put_device;
- }
+ if (!dec_clk->clk_info)
+ return -ENOMEM;
} else {
mtk_v4l2_err("Failed to get vdec clock count");
- ret = -EINVAL;
- goto put_device;
+ return -EINVAL;
}
for (i = 0; i < dec_clk->clk_num; i++) {
@@ -63,29 +47,24 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
"clock-names", i, _info->clk_name);
if (ret) {
mtk_v4l2_err("Failed to get clock name id = %d", i);
- goto put_device;
+ return ret;
}
clk_info->vcodec_clk = devm_clk_get(>dev,
clk_info->clk_name);
if (IS_ERR(clk_info->vcodec_clk)) {
mtk_v4l2_err("devm_clk_get (%d)%s fail", i,
clk_info->clk_name);
- ret = PTR_ERR(clk_info->vcodec_clk);
- goto put_device;
+ return PTR_ERR(clk_info->vcodec_clk);
}
}
pm_runtime_enable(>dev);
return 0;
-put_device:
- put_device(pm->larbvdec);
- return ret;
}
void mtk_vcodec_release_dec_pm(struct mtk_vcodec_dev *dev)
{
pm_runtime_disable(dev->pm.dev);
- put_device(dev->pm.larbvdec);
}
int mtk_vcodec_dec_pw_on(struct mtk_vcodec_pm *pm)
@@ -122,11 +101,6 @@ void mtk_vcodec_dec_clock_on(struct mtk_vcodec_pm *pm)
}
}
- ret = mtk_smi_larb_get(pm->larbvdec);
- if (ret) {
- mtk_v4l2_err("mtk_smi_larb_get larbvdec fail %d", ret);
- goto error;
- }
return;
error:
@@ -139,7 +113,6 @@ void mtk_vcodec_dec_clock_off(struct mtk_vcodec_pm *pm)
struct mtk_vcodec_clk *dec_clk = >vdec_clk;
int i = 0;
- mtk_smi_larb_put(pm->larbvdec);
for (i = dec_clk->clk_num - 1; i >= 0; i--)
clk_disable_unprepare(dec_clk->clk_info[i].vcodec_clk);
}
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index c6c7672fecfb..64b73dd880ce 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -189,10 +189,7 @@ struct mtk_vcodec_clk {
*/
struct mtk_vcodec_pm {
struct mtk_vcodec_clk vdec_clk;
- struct device *larbvdec;
-
struct mtk_vcodec_clk venc_clk;
- struct device *larbvenc;
struct device *dev;
struct mtk_vcodec_dev *mtkdev;
};
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
index
[PATCH v8 08/12] drm/mediatek: Get rid of mtk_smi_larb_get/put
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the drm device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: CK Hu
CC: Philipp Zabel
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Chun-Kuang Hu
Reviewed-by: Dafna Hirschfeld
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 10 --
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 36 ++---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 -
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +--
4 files changed, 3 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 455ea23c6130..445c30cc823f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -12,7 +12,6 @@
#include
#include
-#include
#include
#include
@@ -643,22 +642,14 @@ static void mtk_drm_crtc_atomic_enable(struct drm_crtc
*crtc,
DRM_DEBUG_DRIVER("%s %d\n", __func__, crtc->base.id);
- ret = mtk_smi_larb_get(comp->larb_dev);
- if (ret) {
- DRM_ERROR("Failed to get larb: %d\n", ret);
- return;
- }
-
ret = pm_runtime_resume_and_get(comp->dev);
if (ret < 0) {
- mtk_smi_larb_put(comp->larb_dev);
DRM_DEV_ERROR(comp->dev, "Failed to enable power domain: %d\n",
ret);
return;
}
ret = mtk_crtc_ddp_hw_init(mtk_crtc);
if (ret) {
- mtk_smi_larb_put(comp->larb_dev);
pm_runtime_put(comp->dev);
return;
}
@@ -695,7 +686,6 @@ static void mtk_drm_crtc_atomic_disable(struct drm_crtc
*crtc,
drm_crtc_vblank_off(crtc);
mtk_crtc_ddp_hw_fini(mtk_crtc);
- mtk_smi_larb_put(comp->larb_dev);
ret = pm_runtime_put(comp->dev);
if (ret < 0)
DRM_DEV_ERROR(comp->dev, "Failed to disable power domain:
%d\n", ret);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 99cbf44463e4..48642e814370 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -414,37 +414,15 @@ unsigned int mtk_drm_find_possible_crtc_by_comp(struct
drm_device *drm,
return ret;
}
-static int mtk_ddp_get_larb_dev(struct device_node *node, struct mtk_ddp_comp
*comp,
- struct device *dev)
-{
- struct device_node *larb_node;
- struct platform_device *larb_pdev;
-
- larb_node = of_parse_phandle(node, "mediatek,larb", 0);
- if (!larb_node) {
- dev_err(dev, "Missing mediadek,larb phandle in %pOF node\n",
node);
- return -EINVAL;
- }
-
- larb_pdev = of_find_device_by_node(larb_node);
- if (!larb_pdev) {
- dev_warn(dev, "Waiting for larb device %pOF\n", larb_node);
- of_node_put(larb_node);
- return -EPROBE_DEFER;
- }
- of_node_put(larb_node);
- comp->larb_dev = _pdev->dev;
-
- return 0;
-}
-
int mtk_ddp_comp_init(struct device_node *node, struct mtk_ddp_comp *comp,
enum mtk_ddp_comp_id comp_id)
{
struct platform_device *comp_pdev;
enum mtk_ddp_comp_type type;
struct mtk_ddp_comp_dev *priv;
+#if IS_REACHABLE(CONFIG_MTK_CMDQ)
int ret;
+#endif
if (comp_id < 0 || comp_id >= DDP_COMPONENT_ID_MAX)
return -EINVAL;
@@ -460,16 +438,6 @@ int mtk_ddp_comp_init(struct device_node *node, struct
mtk_ddp_comp *comp,
}
comp->dev = _pdev->dev;
- /* Only DMA capable components need the LARB property */
- if (type == MTK_DISP_OVL ||
- type == MTK_DISP_OVL_2L ||
- type == MTK_DISP_RDMA ||
- type == MTK_DISP_WDMA) {
- ret = mtk_ddp_get_larb_dev(node, comp, comp->dev);
- if (ret)
- return ret;
- }
-
if (type == MTK_DISP_AAL ||
type == MTK_DISP_BLS ||
type == MTK_DISP_CCORR ||
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index bb914d976cf5..1b582262b682 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -70,7 +70,6 @@ struct mtk_ddp_comp_funcs {
struct mtk_ddp_comp {
struct device *dev;
int irq;
- struct device *larb_dev;
enum mtk_ddp_comp_id id;
const struct mtk_ddp_comp_funcs *funcs;
};
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index aec39724ebeb..c234293fc2c3 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -603,11 +603,8 @@ static int mtk_drm_probe(struct
[PATCH v8 07/12] drm/mediatek: Add pm runtime support for ovl and rdma
From: Yongqiang Niu
Prepare for smi cleaning up "mediatek,larb".
Display use the dispsys device to call pm_rumtime_get_sync before.
This patch add pm_runtime_xx with ovl and rdma device whose nodes has
"iommus" property, then display could help pm_runtime_get for smi via
ovl or rdma device.
CC: CK Hu
Signed-off-by: Yongqiang Niu
Signed-off-by: Yong Wu
(Yong: Use pm_runtime_resume_and_get instead of pm_runtime_get_sync)
Acked-by: Chun-Kuang Hu
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 8 +++-
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 9 -
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 13 -
3 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 5326989d5206..716eac6831f2 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include "mtk_disp_drv.h"
@@ -414,9 +415,13 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
return ret;
}
+ pm_runtime_enable(dev);
+
ret = component_add(dev, _disp_ovl_component_ops);
- if (ret)
+ if (ret) {
+ pm_runtime_disable(dev);
dev_err(dev, "Failed to add component: %d\n", ret);
+ }
return ret;
}
@@ -424,6 +429,7 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
static int mtk_disp_ovl_remove(struct platform_device *pdev)
{
component_del(>dev, _disp_ovl_component_ops);
+ pm_runtime_disable(>dev);
return 0;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 75d7f45579e2..251f034acb09 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include "mtk_disp_drv.h"
@@ -327,9 +328,13 @@ static int mtk_disp_rdma_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, priv);
+ pm_runtime_enable(dev);
+
ret = component_add(dev, _disp_rdma_component_ops);
- if (ret)
+ if (ret) {
+ pm_runtime_disable(dev);
dev_err(dev, "Failed to add component: %d\n", ret);
+ }
return ret;
}
@@ -338,6 +343,8 @@ static int mtk_disp_rdma_remove(struct platform_device
*pdev)
{
component_del(>dev, _disp_rdma_component_ops);
+ pm_runtime_disable(>dev);
+
return 0;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 5f81489fc60c..455ea23c6130 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -649,9 +649,17 @@ static void mtk_drm_crtc_atomic_enable(struct drm_crtc
*crtc,
return;
}
+ ret = pm_runtime_resume_and_get(comp->dev);
+ if (ret < 0) {
+ mtk_smi_larb_put(comp->larb_dev);
+ DRM_DEV_ERROR(comp->dev, "Failed to enable power domain: %d\n",
ret);
+ return;
+ }
+
ret = mtk_crtc_ddp_hw_init(mtk_crtc);
if (ret) {
mtk_smi_larb_put(comp->larb_dev);
+ pm_runtime_put(comp->dev);
return;
}
@@ -664,7 +672,7 @@ static void mtk_drm_crtc_atomic_disable(struct drm_crtc
*crtc,
{
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
- int i;
+ int i, ret;
DRM_DEBUG_DRIVER("%s %d\n", __func__, crtc->base.id);
if (!mtk_crtc->enabled)
@@ -688,6 +696,9 @@ static void mtk_drm_crtc_atomic_disable(struct drm_crtc
*crtc,
drm_crtc_vblank_off(crtc);
mtk_crtc_ddp_hw_fini(mtk_crtc);
mtk_smi_larb_put(comp->larb_dev);
+ ret = pm_runtime_put(comp->dev);
+ if (ret < 0)
+ DRM_DEV_ERROR(comp->dev, "Failed to disable power domain:
%d\n", ret);
mtk_crtc->enabled = false;
}
--
2.18.0
[PATCH v8 06/12] media: mtk-mdp: Get rid of mtk_smi_larb_get/put
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the mdp device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Minghsiu Tsai
CC: Houlong Wei
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Reviewed-by: Houlong Wei
Reviewed-by: Dafna Hirschfeld
---
drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 40 ---
drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 2 -
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 1 -
3 files changed, 43 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
index b3426a551bea..1e3833f1c9ae 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
@@ -9,7 +9,6 @@
#include
#include
#include
-#include
#include "mtk_mdp_comp.h"
@@ -18,14 +17,6 @@ void mtk_mdp_comp_clock_on(struct device *dev, struct
mtk_mdp_comp *comp)
{
int i, err;
- if (comp->larb_dev) {
- err = mtk_smi_larb_get(comp->larb_dev);
- if (err)
- dev_err(dev,
- "failed to get larb, err %d. type:%d\n",
- err, comp->type);
- }
-
for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
if (IS_ERR(comp->clk[i]))
continue;
@@ -46,17 +37,12 @@ void mtk_mdp_comp_clock_off(struct device *dev, struct
mtk_mdp_comp *comp)
continue;
clk_disable_unprepare(comp->clk[i]);
}
-
- if (comp->larb_dev)
- mtk_smi_larb_put(comp->larb_dev);
}
int mtk_mdp_comp_init(struct device *dev, struct device_node *node,
struct mtk_mdp_comp *comp,
enum mtk_mdp_comp_type comp_type)
{
- struct device_node *larb_node;
- struct platform_device *larb_pdev;
int ret;
int i;
@@ -77,32 +63,6 @@ int mtk_mdp_comp_init(struct device *dev, struct device_node
*node,
break;
}
- /* Only DMA capable components need the LARB property */
- comp->larb_dev = NULL;
- if (comp->type != MTK_MDP_RDMA &&
- comp->type != MTK_MDP_WDMA &&
- comp->type != MTK_MDP_WROT)
- return 0;
-
- larb_node = of_parse_phandle(node, "mediatek,larb", 0);
- if (!larb_node) {
- dev_err(dev,
- "Missing mediadek,larb phandle in %pOF node\n", node);
- ret = -EINVAL;
- goto put_dev;
- }
-
- larb_pdev = of_find_device_by_node(larb_node);
- if (!larb_pdev) {
- dev_warn(dev, "Waiting for larb device %pOF\n", larb_node);
- of_node_put(larb_node);
- ret = -EPROBE_DEFER;
- goto put_dev;
- }
- of_node_put(larb_node);
-
- comp->larb_dev = _pdev->dev;
-
return 0;
put_dev:
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
index 7897766c96bb..ae41dd3cd72a 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
@@ -26,14 +26,12 @@ enum mtk_mdp_comp_type {
* @node: list node to track sibing MDP components
* @dev_node: component device node
* @clk: clocks required for component
- * @larb_dev: SMI device required for component
* @type: component type
*/
struct mtk_mdp_comp {
struct list_headnode;
struct device_node *dev_node;
struct clk *clk[2];
- struct device *larb_dev;
enum mtk_mdp_comp_type type;
};
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index 976aa1f4829b..70a8eab16863 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -17,7 +17,6 @@
#include
#include
#include
-#include
#include "mtk_mdp_core.h"
#include "mtk_mdp_m2m.h"
--
2.18.0
[PATCH v8 05/12] media: mtk-jpeg: Get rid of mtk_smi_larb_get/put
MediaTek IOMMU has already added device_link between the consumer
and smi-larb device. If the jpg device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
After removing the larb_get operations, then mtk_jpeg_clk_init is
also unnecessary. Remove it too.
CC: Rick Chang
CC: Xia Jiang
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Rick Chang
Reviewed-by: Dafna Hirschfeld
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
.../media/platform/mtk-jpeg/mtk_jpeg_core.c | 45 +--
.../media/platform/mtk-jpeg/mtk_jpeg_core.h | 2 -
2 files changed, 2 insertions(+), 45 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index a89c7b206eef..4fea2c512434 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -22,7 +22,6 @@
#include
#include
#include
-#include
#include "mtk_jpeg_enc_hw.h"
#include "mtk_jpeg_dec_hw.h"
@@ -1055,10 +1054,6 @@ static void mtk_jpeg_clk_on(struct mtk_jpeg_dev *jpeg)
{
int ret;
- ret = mtk_smi_larb_get(jpeg->larb);
- if (ret)
- dev_err(jpeg->dev, "mtk_smi_larb_get larbvdec fail %d\n", ret);
-
ret = clk_bulk_prepare_enable(jpeg->variant->num_clks,
jpeg->variant->clks);
if (ret)
@@ -1069,7 +1064,6 @@ static void mtk_jpeg_clk_off(struct mtk_jpeg_dev *jpeg)
{
clk_bulk_disable_unprepare(jpeg->variant->num_clks,
jpeg->variant->clks);
- mtk_smi_larb_put(jpeg->larb);
}
static irqreturn_t mtk_jpeg_enc_done(struct mtk_jpeg_dev *jpeg)
@@ -1284,35 +1278,6 @@ static struct clk_bulk_data mtk_jpeg_clocks[] = {
{ .id = "jpgenc" },
};
-static int mtk_jpeg_clk_init(struct mtk_jpeg_dev *jpeg)
-{
- struct device_node *node;
- struct platform_device *pdev;
- int ret;
-
- node = of_parse_phandle(jpeg->dev->of_node, "mediatek,larb", 0);
- if (!node)
- return -EINVAL;
- pdev = of_find_device_by_node(node);
- if (WARN_ON(!pdev)) {
- of_node_put(node);
- return -EINVAL;
- }
- of_node_put(node);
-
- jpeg->larb = >dev;
-
- ret = devm_clk_bulk_get(jpeg->dev, jpeg->variant->num_clks,
- jpeg->variant->clks);
- if (ret) {
- dev_err(>dev, "failed to get jpeg clock:%d\n", ret);
- put_device(>dev);
- return ret;
- }
-
- return 0;
-}
-
static void mtk_jpeg_job_timeout_work(struct work_struct *work)
{
struct mtk_jpeg_dev *jpeg = container_of(work, struct mtk_jpeg_dev,
@@ -1333,11 +1298,6 @@ static void mtk_jpeg_job_timeout_work(struct work_struct
*work)
v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
}
-static inline void mtk_jpeg_clk_release(struct mtk_jpeg_dev *jpeg)
-{
- put_device(jpeg->larb);
-}
-
static int mtk_jpeg_probe(struct platform_device *pdev)
{
struct mtk_jpeg_dev *jpeg;
@@ -1376,7 +1336,8 @@ static int mtk_jpeg_probe(struct platform_device *pdev)
goto err_req_irq;
}
- ret = mtk_jpeg_clk_init(jpeg);
+ ret = devm_clk_bulk_get(jpeg->dev, jpeg->variant->num_clks,
+ jpeg->variant->clks);
if (ret) {
dev_err(>dev, "Failed to init clk, err %d\n", ret);
goto err_clk_init;
@@ -1442,7 +1403,6 @@ static int mtk_jpeg_probe(struct platform_device *pdev)
v4l2_device_unregister(>v4l2_dev);
err_dev_register:
- mtk_jpeg_clk_release(jpeg);
err_clk_init:
@@ -1460,7 +1420,6 @@ static int mtk_jpeg_remove(struct platform_device *pdev)
video_device_release(jpeg->vdev);
v4l2_m2m_release(jpeg->m2m_dev);
v4l2_device_unregister(>v4l2_dev);
- mtk_jpeg_clk_release(jpeg);
return 0;
}
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
index 595f7f10c9fd..3e4811a41ba2 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
@@ -85,7 +85,6 @@ struct mtk_jpeg_variant {
* @alloc_ctx: videobuf2 memory allocator's context
* @vdev: video device node for jpeg mem2mem mode
* @reg_base: JPEG registers mapping
- * @larb: SMI device
* @job_timeout_work: IRQ timeout structure
* @variant: driver variant to be used
*/
@@ -99,7 +98,6 @@ struct mtk_jpeg_dev {
void*alloc_ctx;
struct video_device *vdev;
void __iomem*reg_base;
- struct device *larb;
struct delayed_work job_timeout_work;
const struct mtk_jpeg_variant *variant;
};
--
2.18.0
[PATCH v8 04/12] iommu/mediatek: Add device_link between the consumer and the larb devices
MediaTek IOMMU-SMI diagram is like below. all the consumer connect with
smi-larb, then connect with smi-common.
M4U
|
smi-common
|
-
| |...
| |
larb1 larb2
| |
vdec venc
When the consumer works, it should enable the smi-larb's power which
also need enable the smi-common's power firstly.
Thus, First of all, use the device link connect the consumer and the
smi-larbs. then add device link between the smi-larb and smi-common.
This patch adds device_link between the consumer and the larbs.
When device_link_add, I add the flag DL_FLAG_STATELESS to avoid calling
pm_runtime_xx to keep the original status of clocks. It can avoid two
issues:
1) Display HW show fastlogo abnormally reported in [1]. At the beggining,
all the clocks are enabled before entering kernel, but the clocks for
display HW(always in larb0) will be gated after clk_enable and clk_disable
called from device_link_add(->pm_runtime_resume) and rpm_idle. The clock
operation happened before display driver probe. At that time, the display
HW will be abnormal.
2) A deadlock issue reported in [2]. Use DL_FLAG_STATELESS to skip
pm_runtime_xx to avoid the deadlock.
Corresponding, DL_FLAG_AUTOREMOVE_CONSUMER can't be added, then
device_link_removed should be added explicitly.
[1] https://lore.kernel.org/linux-mediatek/1564213888.22908.4.camel@mhfsdcap03/
[2] https://lore.kernel.org/patchwork/patch/1086569/
Suggested-by: Tomasz Figa
Signed-off-by: Yong Wu
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
drivers/iommu/mtk_iommu.c| 22 ++
drivers/iommu/mtk_iommu_v1.c | 20 +++-
2 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index d5848f78a677..a2fa55899434 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -560,22 +560,44 @@ static struct iommu_device *mtk_iommu_probe_device(struct
device *dev)
{
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
struct mtk_iommu_data *data;
+ struct device_link *link;
+ struct device *larbdev;
+ unsigned int larbid;
if (!fwspec || fwspec->ops != _iommu_ops)
return ERR_PTR(-ENODEV); /* Not a iommu client device */
data = dev_iommu_priv_get(dev);
+ /*
+* Link the consumer device with the smi-larb device(supplier)
+* The device in each a larb is a independent HW. thus only link
+* one larb here.
+*/
+ larbid = MTK_M4U_TO_LARB(fwspec->ids[0]);
+ larbdev = data->larb_imu[larbid].dev;
+ link = device_link_add(dev, larbdev,
+ DL_FLAG_PM_RUNTIME | DL_FLAG_STATELESS);
+ if (!link)
+ dev_err(dev, "Unable to link %s\n", dev_name(larbdev));
return >iommu;
}
static void mtk_iommu_release_device(struct device *dev)
{
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+ struct mtk_iommu_data *data;
+ struct device *larbdev;
+ unsigned int larbid;
if (!fwspec || fwspec->ops != _iommu_ops)
return;
+ data = dev_iommu_priv_get(dev);
+ larbid = MTK_M4U_TO_LARB(fwspec->ids[0]);
+ larbdev = data->larb_imu[larbid].dev;
+ device_link_remove(dev, larbdev);
+
iommu_fwspec_free(dev);
}
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 4d7809432239..e6f13459470e 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -423,7 +423,9 @@ static struct iommu_device *mtk_iommu_probe_device(struct
device *dev)
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
struct of_phandle_args iommu_spec;
struct mtk_iommu_data *data;
- int err, idx = 0;
+ int err, idx = 0, larbid;
+ struct device_link *link;
+ struct device *larbdev;
/*
* In the deferred case, free the existed fwspec.
@@ -453,6 +455,14 @@ static struct iommu_device *mtk_iommu_probe_device(struct
device *dev)
data = dev_iommu_priv_get(dev);
+ /* Link the consumer device with the smi-larb device(supplier) */
+ larbid = mt2701_m4u_to_larb(fwspec->ids[0]);
+ larbdev = data->larb_imu[larbid].dev;
+ link = device_link_add(dev, larbdev,
+ DL_FLAG_PM_RUNTIME | DL_FLAG_STATELESS);
+ if (!link)
+ dev_err(dev, "Unable to link %s\n", dev_name(larbdev));
+
return >iommu;
}
@@ -473,10 +483,18 @@ static void mtk_iommu_probe_finalize(struct device *dev)
static void mtk_iommu_release_device(struct device *dev)
{
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+ struct mtk_iommu_data *data;
+ struct device *larbdev;
+ unsigned int larbid;
if (!fwspec || fwspec->ops != _iommu_ops)
return;
+ data =
[PATCH v8 03/12] iommu/mediatek: Add probe_defer for smi-larb
Prepare for adding device_link.
The iommu consumer should use device_link to connect with the
smi-larb(supplier). then the smi-larb should run before the iommu
consumer. Here we delay the iommu driver until the smi driver is ready,
then all the iommu consumers always are after the smi driver.
When there is no this patch, if some consumer drivers run before
smi-larb, the supplier link_status is DL_DEV_NO_DRIVER(0) in the
device_link_add, then device_links_driver_bound will use WARN_ON
to complain that the link_status of supplier is not right.
device_is_bound may be more elegant here. but it is not allowed to
EXPORT from https://lore.kernel.org/patchwork/patch/1334670/.
Signed-off-by: Yong Wu
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
drivers/iommu/mtk_iommu.c| 2 +-
drivers/iommu/mtk_iommu_v1.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index d837adfd1da5..d5848f78a677 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -844,7 +844,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
id = i;
plarbdev = of_find_device_by_node(larbnode);
- if (!plarbdev) {
+ if (!plarbdev || !plarbdev->dev.driver) {
of_node_put(larbnode);
return -EPROBE_DEFER;
}
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 1467ba1e4417..4d7809432239 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -602,7 +602,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
}
plarbdev = of_find_device_by_node(larbnode);
- if (!plarbdev) {
+ if (!plarbdev || !plarbdev->dev.driver) {
of_node_put(larbnode);
return -EPROBE_DEFER;
}
--
2.18.0
[PATCH v8 02/12] iommu/mediatek-v1: Free the existed fwspec if the master dev already has
When the iommu master device enters of_iommu_xlate, the ops may be
NULL(iommu dev is defered), then it will initialize the fwspec here:
[] (dev_iommu_fwspec_set) from []
(iommu_fwspec_init+0xbc/0xd4)
[] (iommu_fwspec_init) from []
(of_iommu_xlate+0x7c/0x12c)
[] (of_iommu_xlate) from []
(of_iommu_configure+0x144/0x1e8)
BUT the mtk_iommu_v1.c only supports arm32, the probing flow still is a bit
weird. We always expect create the fwspec internally. otherwise it will
enter here and return fail.
static int mtk_iommu_create_mapping(struct device *dev,
struct of_phandle_args *args)
{
...
if (!fwspec) {
} else if (dev_iommu_fwspec_get(dev)->ops != _iommu_ops) {
>>Enter here. return fail.
return -EINVAL;
}
...
}
Thus, Free the existed fwspec if the master device already has fwspec.
This issue is reported at:
https://lore.kernel.org/linux-mediatek/trinity-7d9ebdc9-4849-4d93-bfb5-429dcb4ee449-1626253158870@3c-app-gmx-bs01/
Reported-by: Frank Wunderlich
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu_v1.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index be22fcf988ce..1467ba1e4417 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -425,6 +425,15 @@ static struct iommu_device *mtk_iommu_probe_device(struct
device *dev)
struct mtk_iommu_data *data;
int err, idx = 0;
+ /*
+* In the deferred case, free the existed fwspec.
+* Always initialize the fwspec internally.
+*/
+ if (fwspec) {
+ iommu_fwspec_free(dev);
+ fwspec = dev_iommu_fwspec_get(dev);
+ }
+
while (!of_parse_phandle_with_args(dev->of_node, "iommus",
"#iommu-cells",
idx, _spec)) {
--
2.18.0
[PATCH v8 01/12] dt-binding: mediatek: Get rid of mediatek, larb for multimedia HW
After adding device_link between the consumer with the smi-larbs,
if the consumer call its owner pm_runtime_get(_sync), the
pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. Thus, the consumer don't need the property.
And IOMMU also know which larb this consumer connects with from
iommu id in the "iommus=" property.
Signed-off-by: Yong Wu
Reviewed-by: Rob Herring
Reviewed-by: Evan Green
---
.../bindings/display/mediatek/mediatek,disp.txt | 9 -
.../devicetree/bindings/media/mediatek-jpeg-decoder.yaml | 9 -
.../devicetree/bindings/media/mediatek-jpeg-encoder.yaml | 9 -
Documentation/devicetree/bindings/media/mediatek-mdp.txt | 8
.../devicetree/bindings/media/mediatek-vcodec.txt| 4
5 files changed, 39 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index fbb59c9ddda6..867bd82e2f03 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -61,8 +61,6 @@ Required properties (DMA function blocks):
"mediatek,-disp-rdma"
"mediatek,-disp-wdma"
the supported chips are mt2701, mt8167 and mt8173.
-- larb: Should contain a phandle pointing to the local arbiter device as
defined
- in
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
- iommus: Should point to the respective IOMMU block with master port as
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
for details.
@@ -91,7 +89,6 @@ ovl0: ovl@1400c000 {
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_OVL0>;
iommus = < M4U_PORT_DISP_OVL0>;
- mediatek,larb = <>;
};
ovl1: ovl@1400d000 {
@@ -101,7 +98,6 @@ ovl1: ovl@1400d000 {
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_OVL1>;
iommus = < M4U_PORT_DISP_OVL1>;
- mediatek,larb = <>;
};
rdma0: rdma@1400e000 {
@@ -111,7 +107,6 @@ rdma0: rdma@1400e000 {
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_RDMA0>;
iommus = < M4U_PORT_DISP_RDMA0>;
- mediatek,larb = <>;
mediatek,rdma-fifosize = <8192>;
};
@@ -122,7 +117,6 @@ rdma1: rdma@1400f000 {
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_RDMA1>;
iommus = < M4U_PORT_DISP_RDMA1>;
- mediatek,larb = <>;
};
rdma2: rdma@1401 {
@@ -132,7 +126,6 @@ rdma2: rdma@1401 {
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_RDMA2>;
iommus = < M4U_PORT_DISP_RDMA2>;
- mediatek,larb = <>;
};
wdma0: wdma@14011000 {
@@ -142,7 +135,6 @@ wdma0: wdma@14011000 {
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_WDMA0>;
iommus = < M4U_PORT_DISP_WDMA0>;
- mediatek,larb = <>;
};
wdma1: wdma@14012000 {
@@ -152,7 +144,6 @@ wdma1: wdma@14012000 {
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_WDMA1>;
iommus = < M4U_PORT_DISP_WDMA1>;
- mediatek,larb = <>;
};
color0: color@14013000 {
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
index 9b87f036f178..052e752157b4 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
@@ -42,13 +42,6 @@ properties:
power-domains:
maxItems: 1
- mediatek,larb:
-$ref: '/schemas/types.yaml#/definitions/phandle'
-description: |
- Must contain the local arbiters in the current Socs, see
-
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
- for details.
-
iommus:
maxItems: 2
description: |
@@ -63,7 +56,6 @@ required:
- clocks
- clock-names
- power-domains
- - mediatek,larb
- iommus
additionalProperties: false
@@ -83,7 +75,6 @@ examples:
clock-names = "jpgdec-smi",
"jpgdec";
power-domains = < MT2701_POWER_DOMAIN_ISP>;
- mediatek,larb = <>;
iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
< MT2701_M4U_PORT_JPGDEC_BSDMA>;
};
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
index fcd9b829e036..8bfdfdfaba59 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
@@ -35,13 +35,6 @@ properties:
power-domains:
maxItems: 1
- mediatek,larb:
-$ref: '/schemas/types.yaml#/definitions/phandle'
-description: |
- Must contain the local arbiters in the current Socs, see
-
[PATCH v8 00/12] Clean up "mediatek,larb"
MediaTek IOMMU block diagram always like below: M4U | smi-common | - | | ... | | larb1 larb2 | | vdec venc All the consumer connect with smi-larb, then connect with smi-common. When the consumer works, it should enable the smi-larb's power which also need enable the smi-common's power firstly. Thus, Firstly, use the device link connect the consumer and the smi-larbs. then add device link between the smi-larb and smi-common. After adding the device_link, then "mediatek,larb" property can be removed. the iommu consumer don't need call the mtk_smi_larb_get/put to enable the power and clock of smi-larb and smi-common. About the MM dt-binding/dtsi patches, I guess they should go together, thus I don't split them for each a MM module and each a SoC. Base on a jpeg dtbing patchset[1] that already got the necessary R-b. [1] https://lore.kernel.org/linux-mediatek/20210702102304.3346429-1-hsi...@chromium.org/ Change notes: v8: 1) Rebase on v5.15-rc1. 2) Don't rebase the below mdp patchset that may still need more discuss. https://lore.kernel.org/linux-mediatek/20210709022324.1607884-1-ei...@chromium.org/ 3) Add Frank's Tested-by. Remove Dafna's Tested-by as he requested. v7: https://lore.kernel.org/linux-mediatek/20210730025238.22456-1-yong...@mediatek.com/ 1) Fix a arm32 boot fail issue. reported from Frank. 2) Add a return fail in the mtk drm. suggested by Dafna. v6: https://lore.kernel.org/linux-mediatek/20210714025626.5528-1-yong...@mediatek.com/ 1) rebase on v5.14-rc1. 2) Fix the issue commented in v5 from Dafna and Hsin-Yi. 3) Remove the patches about using pm_runtime_resume_and_get since they have already been merged by other patches. v5: https://lore.kernel.org/linux-mediatek/20210410091128.31823-1-yong...@mediatek.com/ 1) Base v5.12-rc2. 2) Remove changing the mtk-iommu to module_platform_driver patch, It have already been a independent patch. v4: https://lore.kernel.org/linux-mediatek/1590826218-23653-1-git-send-email-yong...@mediatek.com/ base on v5.7-rc1. 1) Move drm PM patch before smi patchs. 2) Change builtin_platform_driver to module_platform_driver since we may need build as module. 3) Rebase many patchset as above. v3: https://lore.kernel.org/linux-iommu/1567503456-24725-1-git-send-email-yong...@mediatek.com/ 1) rebase on v5.3-rc1 and the latest mt8183 patchset. 2) Use device_is_bound to check whether the driver is ready from Matthias. 3) Add DL_FLAG_STATELESS flag when calling device_link_add and explain the reason in the commit message[3/14]. 4) Add a display patch[12/14] into this series. otherwise it may affect display HW fastlogo even though it don't happen in mt8183. v2: https://lore.kernel.org/linux-iommu/1560171313-28299-1-git-send-email-yong...@mediatek.com/ 1) rebase on v5.2-rc1. 2) Move adding device_link between the consumer and smi-larb into iommu_add_device from Robin. 3) add DL_FLAG_AUTOREMOVE_CONSUMER even though the smi is built-in from Evan. 4) Remove the shutdown callback in iommu. v1: https://lore.kernel.org/linux-iommu/1546318276-18993-1-git-send-email-yong...@mediatek.com/ Yong Wu (11): dt-binding: mediatek: Get rid of mediatek, larb for multimedia HW iommu/mediatek-v1: Free the existed fwspec if the master dev already has iommu/mediatek: Add probe_defer for smi-larb iommu/mediatek: Add device_link between the consumer and the larb devices media: mtk-jpeg: Get rid of mtk_smi_larb_get/put media: mtk-mdp: Get rid of mtk_smi_larb_get/put drm/mediatek: Get rid of mtk_smi_larb_get/put media: mtk-vcodec: Get rid of mtk_smi_larb_get/put memory: mtk-smi: Get rid of mtk_smi_larb_get/put arm: dts: mediatek: Get rid of mediatek,larb for MM nodes arm64: dts: mediatek: Get rid of mediatek,larb for MM nodes Yongqiang Niu (1): drm/mediatek: Add pm runtime support for ovl and rdma .../display/mediatek/mediatek,disp.txt| 9 .../bindings/media/mediatek-jpeg-decoder.yaml | 9 .../bindings/media/mediatek-jpeg-encoder.yaml | 9 .../bindings/media/mediatek-mdp.txt | 8 .../bindings/media/mediatek-vcodec.txt| 4 -- arch/arm/boot/dts/mt2701.dtsi | 2 - arch/arm/boot/dts/mt7623n.dtsi| 5 --- arch/arm64/boot/dts/mediatek/mt8173.dtsi | 16 --- arch/arm64/boot/dts/mediatek/mt8183.dtsi | 6 --- drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 8 +++- drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 9 +++- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 15 --- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 36 +-- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 - drivers/gpu/drm/mediatek/mtk_drm_drv.c| 5 +-- drivers/iommu/mtk_iommu.c | 24 +- drivers/iommu/mtk_iommu_v1.c | 31
Re: [Intel-gfx] [PATCH 23/27] drm/i915/guc: Implement no mid batch preemption for multi-lrc
On Tue, Sep 28, 2021 at 04:33:24PM -0700, John Harrison wrote:
> On 9/28/2021 15:33, Matthew Brost wrote:
> > On Tue, Sep 28, 2021 at 03:20:42PM -0700, John Harrison wrote:
> > > On 8/20/2021 15:44, Matthew Brost wrote:
> > > > For some users of multi-lrc, e.g. split frame, it isn't safe to preempt
> > > > mid BB. To safely enable preemption at the BB boundary, a handshake
> > > > between to parent and child is needed. This is implemented via custom
> > > > emit_bb_start & emit_fini_breadcrumb functions and enabled via by
> > > via by -> by
> > >
> > > > default if a context is configured by set parallel extension.
> > > I tend to agree with Tvrtko that this should probably be an opt in change.
> > > Is there a flags word passed in when creating the context?
> > >
> > I don't disagree but the uAPI in this series is where we landed. It has
> > been acked all by the relevant parties in the RFC, ported to our
> > internal tree, and the media UMD has been updated / posted. Concerns
> > with the uAPI should've been raised in the RFC phase, not now. I really
> > don't feel like changing this uAPI another time.
> The counter argument is that once a UAPI has been merged, it cannot be
> changed. Ever. So it is worth taking the trouble to get it right first time.
>
> The proposal isn't a major re-write of the interface. It is simply a request
> to set an extra flag when creating the context.
>
We are basically just talking about the polarity of a flag at this
point. Either by default you can't be preempted mid batch (current GPU /
UMD requirement) or by default you can be preempted mid-batch (no
current GPU / UMD can do this yet but add flags that everyone opts
into). I think Daniel's opinion was just default to what the current GPU
/ UMD wants and if future requirements arise we add flags to the
interface. I understand both points of view for flag / not flag but in
the end it doesn't really matter. Either way the interface works now and
will in the future too.
>
> >
> > > Also, it's not just a change in pre-emption behaviour but a change in
> > > synchronisation too, right? Previously, if you had a whole bunch of back
> > > to
> > > back submissions then one child could run ahead of another and/or the
> > > parent. After this change, there is a forced regroup at the end of each
> > > batch. So while one could end sooner/later than the others, they can't
> > > ever
> > > get an entire batch (or more) ahead or behind. Or was that synchronisation
> > > already in there through other means anyway?
> > >
> > Yes, each parent / child sync at the of each batch - this is the only
> > way safely insert preemption points. Without this the GuC could attempt
> > a preemption and hang the batches.
> To be clear, I'm not saying that this is wrong. I'm just saying that this
> appears to be new behaviour with this patch but it is not explicitly called
> out in the description of the patch.
>
Will add some comments explaining this behavior (unless I already have
them).
>
> >
> > > > Signed-off-by: Matthew Brost
> > > > ---
> > > >drivers/gpu/drm/i915/gt/intel_context.c | 2 +-
> > > >drivers/gpu/drm/i915/gt/intel_context_types.h | 3 +
> > > >drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 2 +-
> > > >.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 283
> > > > +-
> > > >4 files changed, 287 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > > > b/drivers/gpu/drm/i915/gt/intel_context.c
> > > > index 5615be32879c..2de62649e275 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > > > @@ -561,7 +561,7 @@ void intel_context_bind_parent_child(struct
> > > > intel_context *parent,
> > > > GEM_BUG_ON(intel_context_is_child(child));
> > > > GEM_BUG_ON(intel_context_is_parent(child));
> > > > - parent->guc_number_children++;
> > > > + child->guc_child_index = parent->guc_number_children++;
> > > > list_add_tail(>guc_child_link,
> > > > >guc_child_list);
> > > > child->parent = parent;
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > > b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > > index 713d85b0b364..727f91e7f7c2 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > > @@ -246,6 +246,9 @@ struct intel_context {
> > > > /** @guc_number_children: number of children if parent
> > > > */
> > > > u8 guc_number_children;
> > > > + /** @guc_child_index: index into guc_child_list if
> > > > child */
> > > > + u8 guc_child_index;
> > > > +
> > > > /**
> > > > * @parent_page: page in context used by parent for
> > > > work queue,
> > > > * work queue descriptor
> > > > diff --git
Re: [PATCH v5 15/16] drm/mediatek: modify mediatek-drm for mt8195 multi mmsys support
Hi, Nancy:
Nancy.Lin 於 2021年9月6日 週一 下午3:15寫道：
>
> MT8195 have two mmsys. Modify drm for MT8195 multi-mmsys support.
> The two mmsys (vdosys0 and vdosys1) will bring up two drm drivers,
> only one drm driver register as the drm device.
> Each drm driver binds its own component. The first bind drm driver
> will allocate the drm device, and the last bind drm driver registers
> the drm device to drm core. Each crtc path is created with the
> corresponding drm driver data.
>
> Signed-off-by: Nancy.Lin
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 25 +-
> drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 3 +-
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 360 +++-
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 8 +-
> 4 files changed, 320 insertions(+), 76 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 474efb844249..68cb15c38c3f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -737,21 +737,28 @@ static int mtk_drm_crtc_init_comp_planes(struct
> drm_device *drm_dev,
> }
>
> int mtk_drm_crtc_create(struct drm_device *drm_dev,
> - const enum mtk_ddp_comp_id *path, unsigned int
> path_len)
> + const enum mtk_ddp_comp_id *path, unsigned int
> path_len,
> + int priv_data_index)
> {
> struct mtk_drm_private *priv = drm_dev->dev_private;
> struct device *dev = drm_dev->dev;
> struct mtk_drm_crtc *mtk_crtc;
> unsigned int num_comp_planes = 0;
> - int pipe = priv->num_pipes;
> int ret;
> int i;
> bool has_ctm = false;
> uint gamma_lut_size = 0;
> + struct drm_crtc *tmp;
> + int crtc_i = 0;
>
> if (!path)
> return 0;
>
> + priv = priv->all_drm_private[priv_data_index];
> +
> + drm_for_each_crtc(tmp, drm_dev)
> + crtc_i++;
> +
> for (i = 0; i < path_len; i++) {
> enum mtk_ddp_comp_id comp_id = path[i];
> struct device_node *node;
> @@ -760,7 +767,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> if (!node) {
> dev_info(dev,
> "Not creating crtc %d because component %d
> is disabled or missing\n",
> -pipe, comp_id);
> +crtc_i, comp_id);
> return 0;
> }
> }
> @@ -816,25 +823,25 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
>
> for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
> ret = mtk_drm_crtc_init_comp_planes(drm_dev, mtk_crtc, i,
> - pipe);
> + crtc_i);
> if (ret)
> return ret;
> }
>
> - ret = mtk_drm_crtc_init(drm_dev, mtk_crtc, pipe);
> + ret = mtk_drm_crtc_init(drm_dev, mtk_crtc, crtc_i);
> if (ret < 0)
> return ret;
>
> if (gamma_lut_size)
> drm_mode_crtc_set_gamma_size(_crtc->base, gamma_lut_size);
> drm_crtc_enable_color_mgmt(_crtc->base, 0, has_ctm,
> gamma_lut_size);
> - priv->num_pipes++;
> mutex_init(_crtc->hw_lock);
>
> #if IS_REACHABLE(CONFIG_MTK_CMDQ)
> + i = (priv->data->mmsys_dev_num > 1) ? 0 :
> drm_crtc_index(_crtc->base);
> +
> mtk_crtc->cmdq_client =
> - cmdq_mbox_create(mtk_crtc->mmsys_dev,
> -drm_crtc_index(_crtc->base));
> + cmdq_mbox_create(mtk_crtc->mmsys_dev, i);
> if (IS_ERR(mtk_crtc->cmdq_client)) {
> dev_dbg(dev, "mtk_crtc %d failed to create mailbox client,
> writing register by CPU now\n",
> drm_crtc_index(_crtc->base));
> @@ -844,7 +851,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> if (mtk_crtc->cmdq_client) {
> ret = of_property_read_u32_index(priv->mutex_node,
> "mediatek,gce-events",
> -
> drm_crtc_index(_crtc->base),
> +i,
> _crtc->cmdq_event);
> if (ret) {
> dev_dbg(dev, "mtk_crtc %d failed to get
> mediatek,gce-events property\n",
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> index cb9a36c48d4f..a57eb12d7c05 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> @@ -17,7 +17,8 @@
> void mtk_drm_crtc_commit(struct drm_crtc *crtc);
> int mtk_drm_crtc_create(struct drm_device *drm_dev,
> const enum
Re: [Intel-gfx] [PATCH 23/27] drm/i915/guc: Implement no mid batch preemption for multi-lrc
On 9/28/2021 15:33, Matthew Brost wrote:
On Tue, Sep 28, 2021 at 03:20:42PM -0700, John Harrison wrote:
On 8/20/2021 15:44, Matthew Brost wrote:
For some users of multi-lrc, e.g. split frame, it isn't safe to preempt
mid BB. To safely enable preemption at the BB boundary, a handshake
between to parent and child is needed. This is implemented via custom
emit_bb_start & emit_fini_breadcrumb functions and enabled via by
via by -> by
default if a context is configured by set parallel extension.
I tend to agree with Tvrtko that this should probably be an opt in change.
Is there a flags word passed in when creating the context?
I don't disagree but the uAPI in this series is where we landed. It has
been acked all by the relevant parties in the RFC, ported to our
internal tree, and the media UMD has been updated / posted. Concerns
with the uAPI should've been raised in the RFC phase, not now. I really
don't feel like changing this uAPI another time.
The counter argument is that once a UAPI has been merged, it cannot be
changed. Ever. So it is worth taking the trouble to get it right first
time.
The proposal isn't a major re-write of the interface. It is simply a
request to set an extra flag when creating the context.
Also, it's not just a change in pre-emption behaviour but a change in
synchronisation too, right? Previously, if you had a whole bunch of back to
back submissions then one child could run ahead of another and/or the
parent. After this change, there is a forced regroup at the end of each
batch. So while one could end sooner/later than the others, they can't ever
get an entire batch (or more) ahead or behind. Or was that synchronisation
already in there through other means anyway?
Yes, each parent / child sync at the of each batch - this is the only
way safely insert preemption points. Without this the GuC could attempt
a preemption and hang the batches.
To be clear, I'm not saying that this is wrong. I'm just saying that
this appears to be new behaviour with this patch but it is not
explicitly called out in the description of the patch.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 2 +-
drivers/gpu/drm/i915/gt/intel_context_types.h | 3 +
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 2 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 283 +-
4 files changed, 287 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 5615be32879c..2de62649e275 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -561,7 +561,7 @@ void intel_context_bind_parent_child(struct intel_context
*parent,
GEM_BUG_ON(intel_context_is_child(child));
GEM_BUG_ON(intel_context_is_parent(child));
- parent->guc_number_children++;
+ child->guc_child_index = parent->guc_number_children++;
list_add_tail(>guc_child_link,
>guc_child_list);
child->parent = parent;
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 713d85b0b364..727f91e7f7c2 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -246,6 +246,9 @@ struct intel_context {
/** @guc_number_children: number of children if parent */
u8 guc_number_children;
+ /** @guc_child_index: index into guc_child_list if child */
+ u8 guc_child_index;
+
/**
* @parent_page: page in context used by parent for work queue,
* work queue descriptor
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index 6cd26dc060d1..9f61cfa5566a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -188,7 +188,7 @@ struct guc_process_desc {
u32 wq_status;
u32 engine_presence;
u32 priority;
- u32 reserved[30];
+ u32 reserved[36];
What is this extra space for? All the extra storage is grabbed from after
the end of this structure, isn't it?
This is the size of process descriptor in the GuC spec. Even though this
is unused space we really don't want the child go / join memory using
anything within the process descriptor.
Okay. So it's more that the code was previously broken and we just
hadn't hit a problem because of it? Again, worth adding a comment in the
description to call it out as a bug fix.
} __packed;
#define CONTEXT_REGISTRATION_FLAG_KMDBIT(0)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 91330525330d..1a18f99bf12a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -11,6 +11,7 @@
[Bug 211875] CPU frequency scaling lost after "WARNING: CPU: 2 PID: 2358578 at smu8_send_msg_to_smc_with_parameter+0xfe/0x140 [amdgpu]"
https://bugzilla.kernel.org/show_bug.cgi?id=211875 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |UNREPRODUCIBLE --- Comment #12 from Erhard F. (erhar...@mailbox.org) --- Sold the hardware, can no longer test nor reproduce. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [Intel-gfx] [PATCH 23/27] drm/i915/guc: Implement no mid batch preemption for multi-lrc
On Tue, Sep 28, 2021 at 03:20:42PM -0700, John Harrison wrote:
> On 8/20/2021 15:44, Matthew Brost wrote:
> > For some users of multi-lrc, e.g. split frame, it isn't safe to preempt
> > mid BB. To safely enable preemption at the BB boundary, a handshake
> > between to parent and child is needed. This is implemented via custom
> > emit_bb_start & emit_fini_breadcrumb functions and enabled via by
> via by -> by
>
> > default if a context is configured by set parallel extension.
> I tend to agree with Tvrtko that this should probably be an opt in change.
> Is there a flags word passed in when creating the context?
>
I don't disagree but the uAPI in this series is where we landed. It has
been acked all by the relevant parties in the RFC, ported to our
internal tree, and the media UMD has been updated / posted. Concerns
with the uAPI should've been raised in the RFC phase, not now. I really
don't feel like changing this uAPI another time.
> Also, it's not just a change in pre-emption behaviour but a change in
> synchronisation too, right? Previously, if you had a whole bunch of back to
> back submissions then one child could run ahead of another and/or the
> parent. After this change, there is a forced regroup at the end of each
> batch. So while one could end sooner/later than the others, they can't ever
> get an entire batch (or more) ahead or behind. Or was that synchronisation
> already in there through other means anyway?
>
Yes, each parent / child sync at the of each batch - this is the only
way safely insert preemption points. Without this the GuC could attempt
a preemption and hang the batches.
> >
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/intel_context.c | 2 +-
> > drivers/gpu/drm/i915/gt/intel_context_types.h | 3 +
> > drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 2 +-
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 283 +-
> > 4 files changed, 287 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > b/drivers/gpu/drm/i915/gt/intel_context.c
> > index 5615be32879c..2de62649e275 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > @@ -561,7 +561,7 @@ void intel_context_bind_parent_child(struct
> > intel_context *parent,
> > GEM_BUG_ON(intel_context_is_child(child));
> > GEM_BUG_ON(intel_context_is_parent(child));
> > - parent->guc_number_children++;
> > + child->guc_child_index = parent->guc_number_children++;
> > list_add_tail(>guc_child_link,
> > >guc_child_list);
> > child->parent = parent;
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > index 713d85b0b364..727f91e7f7c2 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > @@ -246,6 +246,9 @@ struct intel_context {
> > /** @guc_number_children: number of children if parent */
> > u8 guc_number_children;
> > + /** @guc_child_index: index into guc_child_list if child */
> > + u8 guc_child_index;
> > +
> > /**
> > * @parent_page: page in context used by parent for work queue,
> > * work queue descriptor
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> > index 6cd26dc060d1..9f61cfa5566a 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> > @@ -188,7 +188,7 @@ struct guc_process_desc {
> > u32 wq_status;
> > u32 engine_presence;
> > u32 priority;
> > - u32 reserved[30];
> > + u32 reserved[36];
> What is this extra space for? All the extra storage is grabbed from after
> the end of this structure, isn't it?
>
This is the size of process descriptor in the GuC spec. Even though this
is unused space we really don't want the child go / join memory using
anything within the process descriptor.
> > } __packed;
> > #define CONTEXT_REGISTRATION_FLAG_KMD BIT(0)
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > index 91330525330d..1a18f99bf12a 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -11,6 +11,7 @@
> > #include "gt/intel_context.h"
> > #include "gt/intel_engine_pm.h"
> > #include "gt/intel_engine_heartbeat.h"
> > +#include "gt/intel_gpu_commands.h"
> > #include "gt/intel_gt.h"
> > #include "gt/intel_gt_irq.h"
> > #include "gt/intel_gt_pm.h"
> > @@ -366,10 +367,14 @@ static struct i915_priolist *to_priolist(struct
> > rb_node *rb)
> > /*
> >* When using multi-lrc submission an extra page in the context state is
> > - * reserved for the process descriptor and work queue.
> > + * reserved for
[PATCH] drm/locking: add backtrace for locking contended locks without backoff
If drm_modeset_lock() returns -EDEADLK, the caller is supposed to drop
all currently held locks using drm_modeset_backoff(). Failing to do so
will result in warnings and backtraces on the paths trying to lock a
contended lock. Add support for optionally printing the backtrace on the
path that hit the deadlock and didn't gracefully handle the situation.
For example, the patch [1] inadvertently dropped the return value check
and error return on replacing calc_watermark_data() with
intel_compute_global_watermarks(). The backtraces on the subsequent
locking paths hitting WARN_ON(ctx->contended) were unhelpful, but adding
the backtrace to the deadlock path produced this helpful printout:
<7> [98.002465] drm_modeset_lock attempting to lock a contended lock without
backoff:
drm_modeset_lock+0x107/0x130
drm_atomic_get_plane_state+0x76/0x150
skl_compute_wm+0x251d/0x2b20 [i915]
intel_atomic_check+0x1942/0x29e0 [i915]
drm_atomic_check_only+0x554/0x910
drm_atomic_nonblocking_commit+0xe/0x50
drm_mode_atomic_ioctl+0x8c2/0xab0
drm_ioctl_kernel+0xac/0x140
Add new CONFIG_DRM_DEBUG_MODESET_LOCK to enable modeset lock debugging
with stack depot and trace.
[1] https://lore.kernel.org/r/20210924114741.15940-4-jani.nik...@intel.com
Cc: Daniel Vetter
Cc: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/Kconfig| 13
drivers/gpu/drm/drm_modeset_lock.c | 49 --
include/drm/drm_modeset_lock.h | 8 +
3 files changed, 68 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index b17e231ca6f7..7334975c788b 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -100,6 +100,19 @@ config DRM_DEBUG_DP_MST_TOPOLOGY_REFS
This has the potential to use a lot of memory and print some very
large kernel messages. If in doubt, say "N".
+config DRM_DEBUG_MODESET_LOCK
+ bool "Enable backtrace history for lock contention"
+ depends on STACKTRACE_SUPPORT
+ select STACKDEPOT
+ depends on EXPERT
+ help
+ Enable debug tracing of failures to gracefully handle drm modeset lock
+ contention. A history of each drm modeset lock path hitting -EDEADLK
+ will be saved until gracefully handled, and the backtrace will be
+ printed when attempting to lock a contended lock.
+
+ If in doubt, say "N".
+
config DRM_FBDEV_EMULATION
bool "Enable legacy fbdev support for your modesetting driver"
depends on DRM
diff --git a/drivers/gpu/drm/drm_modeset_lock.c
b/drivers/gpu/drm/drm_modeset_lock.c
index bf8a6e823a15..4d32b61fa1fd 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
/**
* DOC: kms locking
@@ -77,6 +78,45 @@
static DEFINE_WW_CLASS(crtc_ww_class);
+#if IS_ENABLED(CONFIG_DRM_DEBUG_MODESET_LOCK)
+static noinline depot_stack_handle_t __stack_depot_save(void)
+{
+ unsigned long entries[8];
+ unsigned int n;
+
+ n = stack_trace_save(entries, ARRAY_SIZE(entries), 1);
+
+ return stack_depot_save(entries, n, GFP_NOWAIT | __GFP_NOWARN);
+}
+
+static void __stack_depot_print(depot_stack_handle_t stack_depot)
+{
+ struct drm_printer p = drm_debug_printer("drm_modeset_lock");
+ unsigned long *entries;
+ unsigned int nr_entries;
+ char *buf;
+
+ buf = kmalloc(PAGE_SIZE, GFP_NOWAIT | __GFP_NOWARN);
+ if (!buf)
+ return;
+
+ nr_entries = stack_depot_fetch(stack_depot, );
+ stack_trace_snprint(buf, PAGE_SIZE, entries, nr_entries, 2);
+
+ drm_printf(, "attempting to lock a contended lock without
backoff:\n%s", buf);
+
+ kfree(buf);
+}
+#else /* CONFIG_DRM_DEBUG_MODESET_LOCK */
+static depot_stack_handle_t __stack_depot_save(void)
+{
+ return 0;
+}
+static void __stack_depot_print(depot_stack_handle_t stack_depot)
+{
+}
+#endif /* CONFIG_DRM_DEBUG_MODESET_LOCK */
+
/**
* drm_modeset_lock_all - take all modeset locks
* @dev: DRM device
@@ -225,7 +265,9 @@ EXPORT_SYMBOL(drm_modeset_acquire_fini);
*/
void drm_modeset_drop_locks(struct drm_modeset_acquire_ctx *ctx)
{
- WARN_ON(ctx->contended);
+ if (WARN_ON(ctx->contended))
+ __stack_depot_print(ctx->stack_depot);
+
while (!list_empty(>locked)) {
struct drm_modeset_lock *lock;
@@ -243,7 +285,8 @@ static inline int modeset_lock(struct drm_modeset_lock
*lock,
{
int ret;
- WARN_ON(ctx->contended);
+ if (WARN_ON(ctx->contended))
+ __stack_depot_print(ctx->stack_depot);
if (ctx->trylock_only) {
lockdep_assert_held(>ww_ctx);
@@ -274,6 +317,7 @@ static inline int modeset_lock(struct drm_modeset_lock
*lock,
ret = 0;
} else if (ret == -EDEADLK) {
ctx->contended = lock;
+ ctx->stack_depot =
[PATCH] dt-bindings: Drop more redundant 'maxItems'
Another round of removing redundant minItems/maxItems from new schema in the recent merge window. If a property has an 'items' list, then a 'minItems' or 'maxItems' with the same size as the list is redundant and can be dropped. Note that is DT schema specific behavior and not standard json-schema behavior. The tooling will fixup the final schema adding any unspecified minItems/maxItems. Cc: "David S. Miller" Cc: Jakub Kicinski Cc: Evgeniy Polyakov Cc: Marek Vasut Cc: Joakim Zhang Cc: Daniel Mack Cc: dri-devel@lists.freedesktop.org Cc: net...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Signed-off-by: Rob Herring --- .../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml| 2 -- Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml| 1 - Documentation/devicetree/bindings/w1/w1-gpio.yaml | 1 - 3 files changed, 4 deletions(-) diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml index 07b20383cbca..b446d0f0f1b4 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml @@ -50,7 +50,6 @@ properties: data-lanes: description: array of physical DSI data lane indexes. minItems: 1 -maxItems: 4 items: - const: 1 - const: 2 @@ -71,7 +70,6 @@ properties: data-lanes: description: array of physical DSI data lane indexes. minItems: 1 -maxItems: 4 items: - const: 1 - const: 2 diff --git a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml index 5629b2e4ccf8..ee4afe361fac 100644 --- a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml +++ b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml @@ -34,7 +34,6 @@ properties: clocks: minItems: 3 -maxItems: 5 items: - description: MAC host clock - description: MAC apb clock diff --git a/Documentation/devicetree/bindings/w1/w1-gpio.yaml b/Documentation/devicetree/bindings/w1/w1-gpio.yaml index 7ba1c2fd4722..8eef2380161b 100644 --- a/Documentation/devicetree/bindings/w1/w1-gpio.yaml +++ b/Documentation/devicetree/bindings/w1/w1-gpio.yaml @@ -15,7 +15,6 @@ properties: gpios: minItems: 1 -maxItems: 2 items: - description: Data I/O pin - description: Enable pin for an external pull-up resistor -- 2.30.2
[PATCH][next] nouveau/svm: Use kvcalloc() instead of kvzalloc()
Use 2-factor argument form kvcalloc() instead of kvzalloc(). Link: https://github.com/KSPP/linux/issues/162 Signed-off-by: Gustavo A. R. Silva --- drivers/gpu/drm/nouveau/nouveau_svm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c b/drivers/gpu/drm/nouveau/nouveau_svm.c index b0c3422cb01f..1a896a24288a 100644 --- a/drivers/gpu/drm/nouveau/nouveau_svm.c +++ b/drivers/gpu/drm/nouveau/nouveau_svm.c @@ -992,7 +992,7 @@ nouveau_svm_fault_buffer_ctor(struct nouveau_svm *svm, s32 oclass, int id) if (ret) return ret; - buffer->fault = kvzalloc(sizeof(*buffer->fault) * buffer->entries, GFP_KERNEL); + buffer->fault = kvcalloc(sizeof(*buffer->fault), buffer->entries, GFP_KERNEL); if (!buffer->fault) return -ENOMEM; -- 2.27.0
Re: [Intel-gfx] [PATCH 23/27] drm/i915/guc: Implement no mid batch preemption for multi-lrc
On 8/20/2021 15:44, Matthew Brost wrote:
For some users of multi-lrc, e.g. split frame, it isn't safe to preempt
mid BB. To safely enable preemption at the BB boundary, a handshake
between to parent and child is needed. This is implemented via custom
emit_bb_start & emit_fini_breadcrumb functions and enabled via by
via by -> by
default if a context is configured by set parallel extension.
I tend to agree with Tvrtko that this should probably be an opt in
change. Is there a flags word passed in when creating the context?
Also, it's not just a change in pre-emption behaviour but a change in
synchronisation too, right? Previously, if you had a whole bunch of back
to back submissions then one child could run ahead of another and/or the
parent. After this change, there is a forced regroup at the end of each
batch. So while one could end sooner/later than the others, they can't
ever get an entire batch (or more) ahead or behind. Or was that
synchronisation already in there through other means anyway?
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 2 +-
drivers/gpu/drm/i915/gt/intel_context_types.h | 3 +
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 2 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 283 +-
4 files changed, 287 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 5615be32879c..2de62649e275 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -561,7 +561,7 @@ void intel_context_bind_parent_child(struct intel_context
*parent,
GEM_BUG_ON(intel_context_is_child(child));
GEM_BUG_ON(intel_context_is_parent(child));
- parent->guc_number_children++;
+ child->guc_child_index = parent->guc_number_children++;
list_add_tail(>guc_child_link,
>guc_child_list);
child->parent = parent;
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 713d85b0b364..727f91e7f7c2 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -246,6 +246,9 @@ struct intel_context {
/** @guc_number_children: number of children if parent */
u8 guc_number_children;
+ /** @guc_child_index: index into guc_child_list if child */
+ u8 guc_child_index;
+
/**
* @parent_page: page in context used by parent for work queue,
* work queue descriptor
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index 6cd26dc060d1..9f61cfa5566a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -188,7 +188,7 @@ struct guc_process_desc {
u32 wq_status;
u32 engine_presence;
u32 priority;
- u32 reserved[30];
+ u32 reserved[36];
What is this extra space for? All the extra storage is grabbed from
after the end of this structure, isn't it?
} __packed;
#define CONTEXT_REGISTRATION_FLAG_KMD BIT(0)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 91330525330d..1a18f99bf12a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -11,6 +11,7 @@
#include "gt/intel_context.h"
#include "gt/intel_engine_pm.h"
#include "gt/intel_engine_heartbeat.h"
+#include "gt/intel_gpu_commands.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_irq.h"
#include "gt/intel_gt_pm.h"
@@ -366,10 +367,14 @@ static struct i915_priolist *to_priolist(struct rb_node
*rb)
/*
* When using multi-lrc submission an extra page in the context state is
- * reserved for the process descriptor and work queue.
+ * reserved for the process descriptor, work queue, and preempt BB boundary
+ * handshake between the parent + childlren contexts.
*
* The layout of this page is below:
* 0 guc_process_desc
+ * + sizeof(struct guc_process_desc) child go
+ * + CACHELINE_BYTES child join ...
+ * + CACHELINE_BYTES ...
Would be better written as '[num_children]' instead of '...' to make it
clear it is a per child array.
Also, maybe create a struct for this to get rid of the magic '+1's and
'BYTES / sizeof' constructs in the functions below.
* ...unused
* PAGE_SIZE / 2 work queue start
* ...work queue
@@ -1785,6 +1790,30 @@ static int deregister_context(struct intel_context *ce,
u32 guc_id, bool loop)
return __guc_action_deregister_context(guc, guc_id, loop);
}
+static inline void
Re: [PATCH v4 0/8] Implement generic cc_platform_has() helper function
On Tue, Sep 28, 2021 at 02:01:57PM -0700, Kuppuswamy, Sathyanarayanan wrote: > Yes. But, since the check is related to TDX, I just want to confirm whether > you are fine with naming the function as intel_*(). Why is this such a big of a deal?! There's amd_cc_platform_has() and intel_cc_platform_has() will be the corresponding Intel version. > Since this patch is going to have dependency on TDX code, I will include > this patch in TDX patch set. Ok. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
[PATCH v3 4/4] drm/rockchip: dsi: Disable PLL clock on bind error
Fix some error handling here noticed in review of other changes.
Fixes: 2d4f7bdafd70 ("drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge
driver")
Signed-off-by: Brian Norris
Reported-by: Chen-Yu Tsai
Reviewed-by: Chen-Yu Tsai
---
Changes in v3:
- Add Fixes, Reviewed-by
Changes in v2:
- New
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 8ea852880d1c..59c3d8ef6bf9 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -945,7 +945,7 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
ret = clk_prepare_enable(dsi->grf_clk);
if (ret) {
DRM_DEV_ERROR(dsi->dev, "Failed to enable grf_clk: %d\n", ret);
- goto out_pm_runtime;
+ goto out_pll_clk;
}
dw_mipi_dsi_rockchip_config(dsi);
@@ -957,19 +957,21 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
ret = rockchip_dsi_drm_create_encoder(dsi, drm_dev);
if (ret) {
DRM_DEV_ERROR(dev, "Failed to create drm encoder\n");
- goto out_pm_runtime;
+ goto out_pll_clk;
}
ret = dw_mipi_dsi_bind(dsi->dmd, >encoder);
if (ret) {
DRM_DEV_ERROR(dev, "Failed to bind: %d\n", ret);
- goto out_pm_runtime;
+ goto out_pll_clk;
}
dsi->dsi_bound = true;
return 0;
+out_pll_clk:
+ clk_disable_unprepare(dsi->pllref_clk);
out_pm_runtime:
pm_runtime_put(dsi->dev);
if (dsi->slave)
--
2.33.0.685.g46640cef36-goog
[PATCH v3 3/4] drm/rockchip: dsi: Fix unbalanced clock on probe error
Our probe() function never enabled this clock, so we shouldn't disable
it if we fail to probe the bridge.
Noted by inspection.
Fixes: 2d4f7bdafd70 ("drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge
driver")
Signed-off-by: Brian Norris
Reviewed-by: Chen-Yu Tsai
---
(no changes since v1)
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 21c67343cc6c..8ea852880d1c 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -1434,14 +1434,10 @@ static int dw_mipi_dsi_rockchip_probe(struct
platform_device *pdev)
if (ret != -EPROBE_DEFER)
DRM_DEV_ERROR(dev,
"Failed to probe dw_mipi_dsi: %d\n", ret);
- goto err_clkdisable;
+ return ret;
}
return 0;
-
-err_clkdisable:
- clk_disable_unprepare(dsi->pllref_clk);
- return ret;
}
static int dw_mipi_dsi_rockchip_remove(struct platform_device *pdev)
--
2.33.0.685.g46640cef36-goog
[PATCH v3 1/4] drm/rockchip: dsi: Hold pm-runtime across bind/unbind
In commit 43c2de1002d2, we moved most HW configuration to bind(), but we
didn't move the runtime PM management. Therefore, depending on initial
boot state, runtime-PM workqueue delays, and other timing factors, we
may disable our power domain in between the hardware configuration
(bind()) and when we enable the display. This can cause us to lose
hardware state and fail to configure our display. For example:
dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO
panel-innolux-p079zca ff96.mipi.0: failed to write command 0
or:
dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO
panel-kingdisplay-kd097d04 ff96.mipi.0: failed write init cmds: -110
We should match the runtime PM to the lifetime of the bind()/unbind()
cycle.
Tested on Acer Chrometab 10 (RK3399 Gru-Scarlet), with panel drivers
built either as modules or built-in.
Side notes: it seems one is more likely to see this problem when the
panel driver is built into the kernel. I've also seen this problem
bisect down to commits that simply changed Kconfig dependencies, because
it changed the order in which driver init functions were compiled into
the kernel, and therefore the ordering and timing of built-in device
probe.
Fixes: 43c2de1002d2 ("drm/rockchip: dsi: move all lane config except LCDC mux
to bind()")
Link:
https://lore.kernel.org/linux-rockchip/9aedfb528600ecf871885f7293ca4207c84d16c1.ca...@gmail.com/
Reported-by:
Cc:
Signed-off-by: Brian Norris
Tested-by: Nícolas F. R. A. Prado
---
(no changes since v2)
Changes in v2:
- Clean up pm-runtime state in error cases.
- Correct git hash for Fixes.
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 37 ++-
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index a2262bee5aa4..45676b23c019 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -773,10 +773,6 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
*encoder)
if (mux < 0)
return;
- pm_runtime_get_sync(dsi->dev);
- if (dsi->slave)
- pm_runtime_get_sync(dsi->slave->dev);
-
/*
* For the RK3399, the clk of grf must be enabled before writing grf
* register. And for RK3288 or other soc, this grf_clk must be NULL,
@@ -795,20 +791,10 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
*encoder)
clk_disable_unprepare(dsi->grf_clk);
}
-static void dw_mipi_dsi_encoder_disable(struct drm_encoder *encoder)
-{
- struct dw_mipi_dsi_rockchip *dsi = to_dsi(encoder);
-
- if (dsi->slave)
- pm_runtime_put(dsi->slave->dev);
- pm_runtime_put(dsi->dev);
-}
-
static const struct drm_encoder_helper_funcs
dw_mipi_dsi_encoder_helper_funcs = {
.atomic_check = dw_mipi_dsi_encoder_atomic_check,
.enable = dw_mipi_dsi_encoder_enable,
- .disable = dw_mipi_dsi_encoder_disable,
};
static int rockchip_dsi_drm_create_encoder(struct dw_mipi_dsi_rockchip *dsi,
@@ -938,10 +924,14 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
put_device(second);
}
+ pm_runtime_get_sync(dsi->dev);
+ if (dsi->slave)
+ pm_runtime_get_sync(dsi->slave->dev);
+
ret = clk_prepare_enable(dsi->pllref_clk);
if (ret) {
DRM_DEV_ERROR(dev, "Failed to enable pllref_clk: %d\n", ret);
- return ret;
+ goto out_pm_runtime;
}
/*
@@ -953,7 +943,7 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
ret = clk_prepare_enable(dsi->grf_clk);
if (ret) {
DRM_DEV_ERROR(dsi->dev, "Failed to enable grf_clk: %d\n", ret);
- return ret;
+ goto out_pm_runtime;
}
dw_mipi_dsi_rockchip_config(dsi);
@@ -965,16 +955,23 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
ret = rockchip_dsi_drm_create_encoder(dsi, drm_dev);
if (ret) {
DRM_DEV_ERROR(dev, "Failed to create drm encoder\n");
- return ret;
+ goto out_pm_runtime;
}
ret = dw_mipi_dsi_bind(dsi->dmd, >encoder);
if (ret) {
DRM_DEV_ERROR(dev, "Failed to bind: %d\n", ret);
- return ret;
+ goto out_pm_runtime;
}
return 0;
+
+out_pm_runtime:
+ pm_runtime_put(dsi->dev);
+ if (dsi->slave)
+ pm_runtime_put(dsi->slave->dev);
+
+ return ret;
}
static void dw_mipi_dsi_rockchip_unbind(struct device *dev,
@@ -989,6 +986,10 @@ static void dw_mipi_dsi_rockchip_unbind(struct device *dev,
dw_mipi_dsi_unbind(dsi->dmd);
clk_disable_unprepare(dsi->pllref_clk);
+
+ pm_runtime_put(dsi->dev);
+ if (dsi->slave)
+
[PATCH v3 2/4] drm/rockchip: dsi: Reconfigure hardware on resume()
Since commit 43c2de1002d2, we perform most HW configuration in the
bind() function. This configuration may be lost on suspend/resume, so we
need to call it again. That may lead to errors like this after system
suspend/resume:
dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO
panel-kingdisplay-kd097d04 ff96.mipi.0: failed write init cmds: -110
Tested on Acer Chromebook Tab 10 (RK3399 Gru-Scarlet).
Note that early mailing list versions of this driver borrowed Rockchip's
downstream/BSP solution, to do HW configuration in mode_set() (which
*is* called at the appropriate pre-enable() times), but that was
discarded along the way. I've avoided that still, because mode_set()
documentation doesn't suggest this kind of purpose as far as I can tell.
Fixes: 43c2de1002d2 ("drm/rockchip: dsi: move all lane config except LCDC mux
to bind()")
Cc:
Signed-off-by: Brian Norris
---
Changes in v3:
- New patch, to fix related PM issue discovered after patch 1
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 37 +++
1 file changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 45676b23c019..21c67343cc6c 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -268,6 +268,8 @@ struct dw_mipi_dsi_rockchip {
struct dw_mipi_dsi *dmd;
const struct rockchip_dw_dsi_chip_data *cdata;
struct dw_mipi_dsi_plat_data pdata;
+
+ bool dsi_bound;
};
struct dphy_pll_parameter_map {
@@ -964,6 +966,8 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
goto out_pm_runtime;
}
+ dsi->dsi_bound = true;
+
return 0;
out_pm_runtime:
@@ -983,6 +987,8 @@ static void dw_mipi_dsi_rockchip_unbind(struct device *dev,
if (dsi->is_slave)
return;
+ dsi->dsi_bound = false;
+
dw_mipi_dsi_unbind(dsi->dmd);
clk_disable_unprepare(dsi->pllref_clk);
@@ -1277,6 +1283,36 @@ static const struct phy_ops dw_mipi_dsi_dphy_ops = {
.exit = dw_mipi_dsi_dphy_exit,
};
+static int __maybe_unused dw_mipi_dsi_rockchip_resume(struct device *dev)
+{
+ struct dw_mipi_dsi_rockchip *dsi = dev_get_drvdata(dev);
+ int ret;
+
+ /*
+* Re-configure DSI state, if we were previously initialized. We need
+* to do this before rockchip_drm_drv tries to re-enable() any panels.
+*/
+ if (dsi->dsi_bound) {
+ ret = clk_prepare_enable(dsi->grf_clk);
+ if (ret) {
+ DRM_DEV_ERROR(dsi->dev, "Failed to enable grf_clk:
%d\n", ret);
+ return ret;
+ }
+
+ dw_mipi_dsi_rockchip_config(dsi);
+ if (dsi->slave)
+ dw_mipi_dsi_rockchip_config(dsi->slave);
+
+ clk_disable_unprepare(dsi->grf_clk);
+ }
+
+ return 0;
+}
+
+static const struct dev_pm_ops dw_mipi_dsi_rockchip_pm_ops = {
+ SET_LATE_SYSTEM_SLEEP_PM_OPS(NULL, dw_mipi_dsi_rockchip_resume)
+};
+
static int dw_mipi_dsi_rockchip_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
@@ -1594,6 +1630,7 @@ struct platform_driver dw_mipi_dsi_rockchip_driver = {
.remove = dw_mipi_dsi_rockchip_remove,
.driver = {
.of_match_table = dw_mipi_dsi_rockchip_dt_ids,
+ .pm = _mipi_dsi_rockchip_pm_ops,
.name = "dw-mipi-dsi-rockchip",
},
};
--
2.33.0.685.g46640cef36-goog
[PATCH v3 0/4] Fix Rockchip MIPI DSI display init timeouts
The Rockchip DSI driver has had a number of bugs over time and has
usually only worked by chance. A number of users have noticed that
things regressed with commit 43c2de1002d2 ("drm/rockchip: dsi: move all
lane config except LCDC mux to bind()"), although it was fixing several
real issues of its own that had been present forever in the upstream
driver (but notably, not in the downstream/BSP driver).
Patch 1 and 2 are the most important fixes here. See their description
for more info.
While I'm at it, fix a few error handling and cleanup issues too.
Changes in v3:
- New patch, to fix related PM issue discovered after patch 1
Changes in v2:
- Clean up pm-runtime state in error cases.
- Correct git hash for Fixes.
Brian Norris (4):
drm/rockchip: dsi: Hold pm-runtime across bind/unbind
drm/rockchip: dsi: Reconfigure hardware on resume()
drm/rockchip: dsi: Fix unbalanced clock on probe error
drm/rockchip: dsi: Disable PLL clock on bind error
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 82 +--
1 file changed, 59 insertions(+), 23 deletions(-)
--
2.33.0.685.g46640cef36-goog
Re: [Freedreno] [PATCH v2 13/13] drm/msm: Implement HDCP 1.x using the new drm HDCP helpers
On 2021-09-28 11:02, Sean Paul wrote:
On Tue, Sep 21, 2021 at 07:25:41PM -0700, abhin...@codeaurora.org
wrote:
On 2021-09-15 13:38, Sean Paul wrote:
> From: Sean Paul
>
> This patch adds HDCP 1.x support to msm DP connectors using the new HDCP
> helpers.
>
> Cc: Stephen Boyd
> Signed-off-by: Sean Paul
> Link:
>
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-15-s...@poorly.run
> #v1
>
> Changes in v2:
> -Squash [1] into this patch with the following changes (Stephen)
> -Update the sc7180 dtsi file
> -Remove resource names and just use index (Stephen)
>
> [1]
>
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-14-s...@poorly.run
> ---
/snip
> diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
> index 904535eda0c4..98731fd262d6 100644
> --- a/drivers/gpu/drm/msm/Makefile
> +++ b/drivers/gpu/drm/msm/Makefile
> @@ -109,6 +109,7 @@ msm-$(CONFIG_DRM_MSM_DP)+= dp/dp_aux.o \
>dp/dp_ctrl.o \
>dp/dp_display.o \
>dp/dp_drm.o \
> + dp/dp_hdcp.o \
>dp/dp_hpd.o \
>dp/dp_link.o \
>dp/dp_panel.o \
> diff --git a/drivers/gpu/drm/msm/dp/dp_debug.c
> b/drivers/gpu/drm/msm/dp/dp_debug.c
> index 2f6247e80e9d..de16fca8782a 100644
> --- a/drivers/gpu/drm/msm/dp/dp_debug.c
> +++ b/drivers/gpu/drm/msm/dp/dp_debug.c
/snip
> +static ssize_t dp_hdcp_key_write(struct file *file, const char __user
> *ubuf,
> + size_t len, loff_t *offp)
> +{
> + char *input_buffer;
> + int ret = 0;
> + struct dp_debug_private *debug = file->private_data;
> + struct drm_device *dev;
> +
> + dev = debug->drm_dev;
> +
> + if (len != (DRM_HDCP_KSV_LEN + DP_HDCP_NUM_KEYS * DP_HDCP_KEY_LEN))
> + return -EINVAL;
> +
> + if (!debug->hdcp)
> + return -ENOENT;
> +
> + input_buffer = memdup_user_nul(ubuf, len);
> + if (IS_ERR(input_buffer))
> + return PTR_ERR(input_buffer);
> +
> + ret = dp_hdcp_ingest_key(debug->hdcp, input_buffer, len);
> +
> + kfree(input_buffer);
> + if (ret < 0) {
> + DRM_ERROR("Could not ingest HDCP key, ret=%d\n", ret);
> + return ret;
> + }
> +
> + *offp += len;
> + return len;
> +}
It seems like the HDCP keys written using debugfs, just for my
understanding,
are you storing this in some secure partition and the usermode reads
from it
and writes them here?
We have not sorted out the userspace side of HDCP enablement yet, so it
remains
to be seen whether the keys will be injected via debugfs/firmware
file/property.
/snip
> +static int dp_connector_atomic_check(struct drm_connector *connector,
> + struct drm_atomic_state *state)
> +{
> + struct drm_connector_state *conn_state;
> + struct dp_connector_state *dp_state;
> +
> + conn_state = drm_atomic_get_new_connector_state(state, connector);
> + dp_state = to_dp_connector_state(conn_state);
> +
> + dp_state->hdcp_transition = drm_hdcp_atomic_check(connector, state);
I have a general question related to the transition flag and overall
tying
the HDCP
enable and authentication to the commit.
So lets say there is a case where the driver needs to disable HDCP. It
could
be due
to link integrity failure OR some other error condition which usermode
is
not aware of.
In that case, we will set this hdcp_transition to true but in the next
commit we will
actually do the authentication. What if usermode doesnt issue a new
frame?
This question arises because currently the link intergrity check is
done
using SW polling
in the previous patchset. But as I had commented there, this occurs in
HW
for us.
I dont see that isr itself in this patchset. So wanted to understand
if
thats part of this
approach to still tie it with commit.
So if we go with the HW polling based approach which is the preferred
method, we need to
untie this from the commit.
In the case of error, the worker will detect it and try to
re-authenticate. If
the re-authentication is successful, userspace will continue to be
unaware and
everything will keep working. If re-authentication is unsuccessful, the
worker
will update the property value and issue a uevent to userspace. So HDCP
enablement is only tied to commits when the property value is changing
as a
result of userspace.
Regarding SW vs HW link checks, I don't think there's any difference in
efficacy
between them. If HW can be relied on to issue an interrupt in failure
cases, a
follow-up set allowing for this seems like a great idea.
Thanks for the explanation. Yes, from our experience it has been pretty
reliable to
issue signal integrity failures. We already had the isr based approach
downstream
and would prefer to keep it that way based on our experience of it
firing reliably.
We can still keep the SW polling code but it should come into effect
only if HW polling
is not supported / preferred.
> +
> + return 0;
> +}
/snip
> +static int dp_hdcp_load_keys(struct drm_connector *connector)
> +{
> + struct dp_hdcp
Re: [Freedreno] [PATCH v2 04/13] drm/hdcp: Expand HDCP helper library for enable/disable/check
Hi Sean
On 2021-09-28 10:33, Sean Paul wrote:
On Tue, Sep 21, 2021 at 04:34:59PM -0700, abhin...@codeaurora.org
wrote:
On 2021-09-15 13:38, Sean Paul wrote:
> From: Sean Paul
>
> This patch expands upon the HDCP helper library to manage HDCP
> enable, disable, and check.
>
> Previous to this patch, the majority of the state management and sink
> interaction is tucked inside the Intel driver with the understanding
> that once a new platform supported HDCP we could make good decisions
> about what should be centralized. With the addition of HDCP support
> for Qualcomm, it's time to migrate the protocol-specific bits of HDCP
> authentication, key exchange, and link checks to the HDCP helper.
>
> In terms of functionality, this migration is 1:1 with the Intel driver,
> however things are laid out a bit differently than with intel_hdcp.c,
> which is why this is a separate patch from the i915 transition to the
> helper. On i915, the "shim" vtable is used to account for HDMI vs. DP
> vs. DP-MST differences whereas the helper library uses a LUT to
> account for the register offsets and a remote read function to route
> the messages. On i915, storing the sink information in the source is
> done inline whereas now we use the new drm_hdcp_helper_funcs vtable
> to store and fetch information to/from source hw. Finally, instead of
> calling enable/disable directly from the driver, we'll leave that
> decision to the helper and by calling drm_hdcp_helper_atomic_commit()
> from the driver. All told, this will centralize the protocol and state
> handling in the helper, ensuring we collect all of our bugs^Wlogic
> in one place.
>
> Signed-off-by: Sean Paul
> Link:
>
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-5-s...@poorly.run
> #v1
>
> Changes in v2:
> -Fixed set-but-unused variable identified by 0-day
> ---
> drivers/gpu/drm/drm_hdcp.c | 1103
> include/drm/drm_hdcp.h | 191 +++
> 2 files changed, 1294 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
> index 742313ce8f6f..47c6e6923a76 100644
> --- a/drivers/gpu/drm/drm_hdcp.c
> +++ b/drivers/gpu/drm/drm_hdcp.c
/snip
> +static void drm_hdcp_helper_check_work(struct work_struct *work)
> +{
> + struct drm_hdcp_helper_data *data =
> container_of(to_delayed_work(work),
> + struct
drm_hdcp_helper_data,
> + check_work);
> + unsigned long check_link_interval;
> +
Does this SW polling for Ri' mismatch need to be done even if the HW
is
capable of doing it
on its own?
MSM HDCP 1x HW can periodically check Ri' mismatches and issue an
interrupt
if there is a mismatch.
In that case this SW polling is not needed. So maybe check if the HW
supports polling and if so
skip this SW polling?
One could certainly change this to be HW driven. There is also an
interrupt on
Intel for DP links which [re]schedules link check in the interrupt
handler,
something similar could be done for msm. Note that even on these Intel
links
which support the CP interrupt, the worker still runs on the normal
cadence. I
haven't considered relying solely on the interrupt since I want to be
sure we
didn't miss anything.
Sean
I think we should have the support for HW polling added. From our
experience,
it has been pretty reliable for us and has a pretty consistent cadence
in alignment
with the spec. I dont quite understand why we should have both in
chipsets capable
of HW polling and am bit surprised if SW polling will catch something
which HW
polling and the subsequent interrupt has missed.
> + mutex_lock(>mutex);
> + if (data->value != DRM_MODE_CONTENT_PROTECTION_ENABLED)
> + goto out_data_mutex;
> +
> + drm_hdcp_helper_driver_lock(data);
> +
> + if (data->enabled_type == DRM_MODE_HDCP_CONTENT_TYPE1) {
> + if (drm_hdcp_hdcp2_check_link(data))
> + goto out;
> + check_link_interval = DRM_HDCP2_CHECK_PERIOD_MS;
> + } else {
> + if (drm_hdcp_hdcp1_check_link(data))
> + goto out;
> + check_link_interval = DRM_HDCP_CHECK_PERIOD_MS;
> + }
> + schedule_delayed_work(>check_work, check_link_interval);
> +
> +out:
> + drm_hdcp_helper_driver_unlock(data);
> +out_data_mutex:
> + mutex_unlock(>mutex);
> +}
/snip
Re: [Freedreno] [PATCH v2 00/13] drm/hdcp: Pull HDCP auth/exchange/check into helpers
On 2021-09-28 11:06, Sean Paul wrote: On Tue, Sep 21, 2021 at 07:30:29PM -0700, abhin...@codeaurora.org wrote: Hi Sean On 2021-09-15 13:38, Sean Paul wrote: > From: Sean Paul > > Hello again, > This is the second version of the HDCP helper patchset. See version 1 > here: https://patchwork.freedesktop.org/series/94623/ > > In this second version, I've fixed up the oopsies exposed by 0-day and > yamllint and incorporated early review feedback from the dt/dts reviews. > > Please take a look, > > Sean One question overall on the series: 1) Regarding validation, did you run any secure video to check the transitions? Yep, the transitions look good, no visual artifacts. Unplug/replug/suspend/resume all seem to be behaving as expected. 2) Is running HDCP 1x compliance also part of the validation efforts? If Qualcomm has the ability to run validation, I'd be very keen to get some help in that regard. Thanks for letting us know. To assist with (2) we will have to work with you on some logistics. Will sync up on IRC further on how to go about this. Sean Thanks Abhinav > > Sean Paul (13): > drm/hdcp: Add drm_hdcp_atomic_check() > drm/hdcp: Avoid changing crtc state in hdcp atomic check > drm/hdcp: Update property value on content type and user changes > drm/hdcp: Expand HDCP helper library for enable/disable/check > drm/i915/hdcp: Consolidate HDCP setup/state cache > drm/i915/hdcp: Retain hdcp_capable return codes > drm/i915/hdcp: Use HDCP helpers for i915 > drm/msm/dpu_kms: Re-order dpu includes > drm/msm/dpu: Remove useless checks in dpu_encoder > drm/msm/dpu: Remove encoder->enable() hack > drm/msm/dp: Re-order dp_audio_put in deinit_sub_modules > dt-bindings: msm/dp: Add bindings for HDCP registers > drm/msm: Implement HDCP 1.x using the new drm HDCP helpers > > .../bindings/display/msm/dp-controller.yaml |7 +- > arch/arm64/boot/dts/qcom/sc7180.dtsi |4 +- > drivers/gpu/drm/drm_hdcp.c| 1197 - > drivers/gpu/drm/i915/display/intel_atomic.c |7 +- > drivers/gpu/drm/i915/display/intel_ddi.c | 29 +- > .../drm/i915/display/intel_display_debugfs.c | 11 +- > .../drm/i915/display/intel_display_types.h| 58 +- > drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 345 ++--- > drivers/gpu/drm/i915/display/intel_dp_mst.c | 17 +- > drivers/gpu/drm/i915/display/intel_hdcp.c | 1011 +++--- > drivers/gpu/drm/i915/display/intel_hdcp.h | 35 +- > drivers/gpu/drm/i915/display/intel_hdmi.c | 256 ++-- > drivers/gpu/drm/msm/Makefile |1 + > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 17 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 30 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h |2 - > drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h |4 - > drivers/gpu/drm/msm/dp/dp_debug.c | 49 +- > drivers/gpu/drm/msm/dp/dp_debug.h |6 +- > drivers/gpu/drm/msm/dp/dp_display.c | 47 +- > drivers/gpu/drm/msm/dp/dp_display.h |5 + > drivers/gpu/drm/msm/dp/dp_drm.c | 68 +- > drivers/gpu/drm/msm/dp/dp_drm.h |5 + > drivers/gpu/drm/msm/dp/dp_hdcp.c | 433 ++ > drivers/gpu/drm/msm/dp/dp_hdcp.h | 27 + > drivers/gpu/drm/msm/dp/dp_parser.c| 22 +- > drivers/gpu/drm/msm/dp/dp_parser.h|4 + > drivers/gpu/drm/msm/dp/dp_reg.h | 44 +- > drivers/gpu/drm/msm/msm_atomic.c | 15 + > include/drm/drm_hdcp.h| 194 +++ > 30 files changed, 2561 insertions(+), 1389 deletions(-) > create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.c > create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.h
Re: [PATCH v6 2/2] habanalabs: add support for dma-buf exporter
On Tue, Sep 28, 2021 at 8:36 PM Jason Gunthorpe wrote:
>
> On Sun, Sep 12, 2021 at 07:53:09PM +0300, Oded Gabbay wrote:
> > From: Tomer Tayar
> >
> > Implement the calls to the dma-buf kernel api to create a dma-buf
> > object backed by FD.
> >
> > We block the option to mmap the DMA-BUF object because we don't support
> > DIRECT_IO and implicit P2P.
>
> This statement doesn't make sense, you can mmap your dmabuf if you
> like. All dmabuf mmaps are supposed to set the special bit/etc to
> exclude them from get_user_pages() anyhow - and since this is BAR
> memory not struct page memory this driver would be doing it anyhow.
>
But we block mmap the dmabuf fd from user-space.
If you try to do it, you will get MAP_FAILED.
That's because we don't supply a function to the mmap callback in dmabuf.
We did that per Christian's advice. It is in one of the long email
threads on previous versions of this patch.
> > We check the p2p distance using pci_p2pdma_distance_many() and refusing
> > to map dmabuf in case the distance doesn't allow p2p.
>
> Does this actually allow the p2p transfer for your intended use cases?
>
It depends on the system. If we are working bare-metal, then yes, it allows.
If inside a VM, then no. The virtualized root complex is not
white-listed and the kernel can't know the distance.
But I remember you asked me to add this check, in v3 of the review IIRC.
I don't mind removing this check if you don't object.
> > diff --git a/drivers/misc/habanalabs/common/memory.c
> > b/drivers/misc/habanalabs/common/memory.c
> > index 33986933aa9e..8cf5437c0390 100644
> > +++ b/drivers/misc/habanalabs/common/memory.c
> > @@ -1,7 +1,7 @@
> > // SPDX-License-Identifier: GPL-2.0
> >
> > /*
> > - * Copyright 2016-2019 HabanaLabs, Ltd.
> > + * Copyright 2016-2021 HabanaLabs, Ltd.
> > * All Rights Reserved.
> > */
> >
> > @@ -11,11 +11,13 @@
> >
> > #include
> > #include
> > +#include
> >
> > #define HL_MMU_DEBUG 0
> >
> > /* use small pages for supporting non-pow2 (32M/40M/48M) DRAM phys page
> > sizes */
> > -#define DRAM_POOL_PAGE_SIZE SZ_8M
> > +#define DRAM_POOL_PAGE_SIZE SZ_8M
> > +
>
> ??
ok, I 'll remove
>
> > /*
> > * The va ranges in context object contain a list with the available
> > chunks of
> > @@ -347,6 +349,13 @@ static int free_device_memory(struct hl_ctx *ctx,
> > struct hl_mem_in *args)
> > return -EINVAL;
> > }
> >
> > + if (phys_pg_pack->exporting_cnt) {
> > + dev_err(hdev->dev,
> > + "handle %u is exported, cannot free\n",
> > handle);
> > + spin_unlock(>idr_lock);
>
> Don't write to the kernel log from user space triggered actions
at all ?
It's the first time I hear about this limitation...
How do you tell the user it has done something wrong ?
I agree it might be better to rate limit it, but why not give the
information to the user ?
>
> > +static int alloc_sgt_from_device_pages(struct hl_device *hdev,
> > + struct sg_table **sgt, u64 *pages,
> > + u64 npages, u64 page_size,
> > + struct device *dev,
> > + enum dma_data_direction dir)
>
> Why doesn't this return a sg_table * and an ERR_PTR?
Basically I modeled this function after amdgpu_vram_mgr_alloc_sgt()
And in that function they also return int and pass the sg_table as **
If it's critical I can change.
>
> > +{
> > + u64 chunk_size, bar_address, dma_max_seg_size;
> > + struct asic_fixed_properties *prop;
> > + int rc, i, j, nents, cur_page;
> > + struct scatterlist *sg;
> > +
> > + prop = >asic_prop;
> > +
> > + dma_max_seg_size = dma_get_max_seg_size(dev);
>
> > +
> > + /* We would like to align the max segment size to PAGE_SIZE, so the
> > + * SGL will contain aligned addresses that can be easily mapped to
> > + * an MMU
> > + */
> > + dma_max_seg_size = ALIGN_DOWN(dma_max_seg_size, PAGE_SIZE);
> > + if (dma_max_seg_size < PAGE_SIZE) {
> > + dev_err_ratelimited(hdev->dev,
> > + "dma_max_seg_size %llu can't be smaller than
> > PAGE_SIZE\n",
> > + dma_max_seg_size);
> > + return -EINVAL;
> > + }
> > +
> > + *sgt = kzalloc(sizeof(**sgt), GFP_KERNEL);
> > + if (!*sgt)
> > + return -ENOMEM;
> > +
> > + /* If the size of each page is larger than the dma max segment size,
> > + * then we can't combine pages and the number of entries in the SGL
> > + * will just be the
> > + * *
> > + */
> > + if (page_size > dma_max_seg_size)
> > + nents = npages * DIV_ROUND_UP_ULL(page_size,
> > dma_max_seg_size);
> > + else
> > + /* Get number of non-contiguous chunks */
> > + for (i = 1, nents = 1, chunk_size = page_size ; i < npages ;
> >
Re: [PATCH v2 3/3] drm/rockchip: dsi: Disable PLL clock on bind error
On Mon, Sep 27, 2021 at 9:16 PM Chen-Yu Tsai wrote:
>
> On Tue, Sep 28, 2021 at 2:00 AM Brian Norris wrote:
> >
> > Fix some error handling here noticed in review of other changes.
> >
> > Reported-by: Chen-Yu Tsai
> > Signed-off-by: Brian Norris
>
> Fixes: 2d4f7bdafd70 ("drm/rockchip: dsi: migrate to use dw-mipi-dsi
> bridge driver")
>
> Otherwise,
>
> Reviewed-by: Chen-Yu Tsai
I'll add these tags, thanks.
> Additionally, I would move patch 2 and this patch before the first patch,
> as these two fix a commit introduced in v5.0, while the first patch fixes
> something introduced in v5.14. This would make automatic backporting cleaner.
Personally, I prioritize putting user-visible fixes first, and more
cosmetic things (like error handling that we ~never hit) later. Also,
the buggy commit was already backported to all still-supported stable
releases where it was relevant (i.e., 5.4+), so if these get
backported, they all should.
Regards,
Brian
[1] 43c2de1002d2 drm/rockchip: dsi: move all lane config except LCDC
mux to bind()
Re: [PATCH 2/3] drm/dp, drm/i915: Add support for VESA backlights using PWM for brightness control
On Tue, 2021-09-28 at 13:00 -0700, Doug Anderson wrote:
> Hi,
>
>
> I'm not sure I understand the comment above. You say "enabled/disabled
> via PWM" and that doesn't make sense w/ my mental model. Normally I
> think of a PWM allowing you to adjust the brightness and there being a
> separate GPIO that's in charge of enable/disable. To some extent you
Oops - you're completely right, it is a GPIO pin and I got myself
confused since in i915 I'm the chipset-specific callbacks for turning
the panel on are intertwined with the PWM callbacks.
> could think of a PWM as being "disabled" when its duty cycle is 0%,
> but usually there's separate "enable" logic that really has nothing to
> do with the PWM itself.
>
> In general, it seems like the options are:
>
> 1. DPCD controls PWM and the "enable" logic.
>
> 2. DPCD controls PWM but requires an external "enable" GPIO.
>
> 3. We require an external PWM but DPCD controls the "enable" logic.
>
> Maybe you need a second "capability" to describe whether the client of
> your code knows how to control an enable GPIO? ...or perhaps better
> you don't need a capability and you can just assume that if the client
> needs to set an "enable" GPIO that it will do so. That would match how
> things work today. AKA:
>
> a) Client calls the AUX backlight code to "enable"
>
> b) AUX backlight code will set the "enable" bit if supported.
>
> c) Client will set the "enable" GPIO if it knows about one.
>
> Presumably only one of b) or c) will actually do something. If neither
> does something then this panel simply isn't compatible with this
> board.
I will definitely take note from this explanation and rewrite some of
the helper docs I'm updating to reflect this, thank you!
Being that I think panel drivers are basically the only other user of
this driver, if you think this is the way to go I'm OK with this. My
original reasoning for having a cap for this was worrying about the ARM
drivers handling this, along with potentially changing backlight
behavior in nouveau. I'm realizing now though that those are probably
problems for nouveau and not the helper, and I could probably avoid
hitting any issues by just adding some additional DPCD checks for GPIO
enabling/PWM passthrough in nouveau itself.
So I'll drop the cap in the next respin of this
>
>
> > +/**
> > + * drm_edp_backlight_supported() - Check an eDP DPCD for VESA backlight
> > support
> > + * @aux: The AUX channel, only used for debug logging
> > + * @edp_dpcd: The DPCD to check
> > + * @caps: The backlight capabilities this driver supports
> > + *
> > + * Returns: %True if @edp_dpcd indicates that VESA backlight controls are
> > supported, %false
> > + * otherwise
> > + */
> > +bool drm_edp_backlight_supported(struct drm_dp_aux *aux,
> > + const u8
> > edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE],
> > + enum drm_edp_backlight_driver_caps caps)
> > +{
> > + if (!(edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP))
> > + return false;
> > +
> > + if (!(caps & DRM_EDP_BACKLIGHT_DRIVER_CAP_PWM) &&
> > + (!(edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) ||
> > + !(edp_dpcd[2] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))) {
>
> Elsewhere you match DP_EDP_BACKLIGHT_AUX_ENABLE_CAP against
> edp_dpcd[1]. Here you match against [2]. Are you sure that's correct?
absolutely not! thank you for catching this
>
>
> > /*
> > * DisplayPort AUX channel
> > */
> > @@ -2200,7 +2182,11 @@ drm_dp_has_quirk(const struct drm_dp_desc *desc,
> > enum drm_dp_quirk quirk)
> > * @pwm_freq_pre_divider: The PWM frequency pre-divider value being used
> > for this backlight, if any
> > * @max: The maximum backlight level that may be set
> > * @lsb_reg_used: Do we also write values to the
> > DP_EDP_BACKLIGHT_BRIGHTNESS_LSB register?
> > - * @aux_enable: Does the panel support the AUX enable cap?
> > + * @aux_enable: Does the panel support the AUX enable cap? Always %false
> > when the driver doesn't
> > + * support %DRM_EDP_BACKLIGHT_DRIVER_CAP_PWM
>
> Why is aux_enable always false if it doesn't support
> DRM_EDP_BACKLIGHT_DRIVER_CAP_PWM? It doesn't seem like the code
> enforces this and I'm not sure why it would. Am I confused?
This was mainly just to keep the behavior identical for drivers that
didn't support controlling backlights like this, but re: the response I
wrote up above I think we can just totally drop the caps.
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH v4 0/8] Implement generic cc_platform_has() helper function
On 9/28/21 1:58 PM, Borislav Petkov wrote: On Tue, Sep 28, 2021 at 01:48:46PM -0700, Kuppuswamy, Sathyanarayanan wrote: Just read it. If you want to use cpuid_has_tdx_guest() directly in cc_platform_has(), then you want to rename intel_cc_platform_has() to tdx_cc_platform_has()? Why? You simply do: if (cpuid_has_tdx_guest()) intel_cc_platform_has(...); and lemme paste from that mail: " ...you should use cpuid_has_tdx_guest() instead but cache its result so that you don't call CPUID each time the kernel executes cc_platform_has()." Makes sense? Yes. But, since the check is related to TDX, I just want to confirm whether you are fine with naming the function as intel_*(). Since this patch is going to have dependency on TDX code, I will include this patch in TDX patch set. -- Sathyanarayanan Kuppuswamy Linux Kernel Developer
Re: [PATCH v4 0/8] Implement generic cc_platform_has() helper function
On Tue, Sep 28, 2021 at 01:48:46PM -0700, Kuppuswamy, Sathyanarayanan wrote: > Just read it. If you want to use cpuid_has_tdx_guest() directly in > cc_platform_has(), then you want to rename intel_cc_platform_has() to > tdx_cc_platform_has()? Why? You simply do: if (cpuid_has_tdx_guest()) intel_cc_platform_has(...); and lemme paste from that mail: " ...you should use cpuid_has_tdx_guest() instead but cache its result so that you don't call CPUID each time the kernel executes cc_platform_has()." Makes sense? -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH v2 2/2] drm: rcar-du: Add R-Car DSI driver
Hi,
Sorry, I missed this email.
W dniu 23.09.2021 o 00:32, Laurent Pinchart pisze:
> Hi Andrzej,
>
> On Wed, Sep 22, 2021 at 04:29:39AM +0300, Laurent Pinchart wrote:
>> On Tue, Sep 21, 2021 at 09:42:11PM +0200, Andrzej Hajda wrote:
>>> W dniu 23.06.2021 o 15:56, Laurent Pinchart pisze:
From: LUU HOAI
The driver supports the MIPI DSI/CSI-2 TX encoder found in the R-Car V3U
SoC. It currently supports DSI mode only.
Signed-off-by: LUU HOAI
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Tested-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/Kconfig | 6 +
drivers/gpu/drm/rcar-du/Makefile | 1 +
drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 827 +++
drivers/gpu/drm/rcar-du/rcar_mipi_dsi_regs.h | 172
4 files changed, 1006 insertions(+)
create mode 100644 drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_mipi_dsi_regs.h
...
+
+ ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0, ,
+>next_bridge);
>>> You are looking for sink but DSI host is not yet registered, thus DSI
>>> child devices not yet created/bound, so in case of DSI-controlled sinks
>>> it will be always error.
>> Correct, it will not work for a sink that is controlled through DSI.
>> We've tested this with a sink controlled through I2C, as that's all we
>> have on the development board. That won't be very future-proof of
>> course.
>>
>>> Please look at pending documentation patch[1] for more in-depth explanation.
>>>
>>> [1]:
>>> https://protect2.fireeye.com/v1/url?k=ccc70571-935c3c5e-ccc68e3e-0cc47a31cdf8-cd122187fddf557d=1=311a381f-74cc-4b35-a344-362bc742c941=https%3A%2F%2Flkml.org%2Flkml%2F2021%2F9%2F10%2F165
>> I'll review that series.
> To clarify your point, do you consider this a blocker for merging this
> series, or something that can be addressed on top ?
The best would be to fix it before merge - the rule of thumb is that bad
patterns spread quite fast :)
If there is good reason to postpone the fix, please send it ASAP.
Regards
Andrzej
>
+ if (ret) {
+ dev_err_probe(dsi->dev, ret, "could not find next bridge\n");
+ return ret;
+ }
+
+ if (!dsi->next_bridge) {
+ dsi->next_bridge = devm_drm_panel_bridge_add(dsi->dev, panel);
+ if (IS_ERR(dsi->next_bridge)) {
+ dev_err(dsi->dev, "failed to create panel bridge\n");
+ return PTR_ERR(dsi->next_bridge);
+ }
+ }
+
+ /* Initialize the DSI host. */
+ dsi->host.dev = dsi->dev;
+ dsi->host.ops = _mipi_dsi_host_ops;
+ ret = mipi_dsi_host_register(>host);
+ if (ret < 0)
+ return ret;
+
+ /* Initialize the DRM bridge. */
+ dsi->bridge.funcs = _mipi_dsi_bridge_ops;
+ dsi->bridge.of_node = dsi->dev->of_node;
+ drm_bridge_add(>bridge);
+
+ return 0;
+}
+
+static int rcar_mipi_dsi_remove(struct platform_device *pdev)
+{
+ struct rcar_mipi_dsi *dsi = platform_get_drvdata(pdev);
+
+ drm_bridge_remove(>bridge);
+
+ mipi_dsi_host_unregister(>host);
+
+ return 0;
+}
+
+static const struct of_device_id rcar_mipi_dsi_of_table[] = {
+ { .compatible = "renesas,r8a779a0-dsi-csi2-tx" },
+ { }
+};
+
+MODULE_DEVICE_TABLE(of, rcar_mipi_dsi_of_table);
+
+static struct platform_driver rcar_mipi_dsi_platform_driver = {
+ .probe = rcar_mipi_dsi_probe,
+ .remove = rcar_mipi_dsi_remove,
+ .driver = {
+ .name = "rcar-mipi-dsi",
+ .of_match_table = rcar_mipi_dsi_of_table,
+ },
+};
+
+module_platform_driver(rcar_mipi_dsi_platform_driver);
+
+MODULE_DESCRIPTION("Renesas R-Car MIPI DSI Encoder Driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi_regs.h
b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi_regs.h
new file mode 100644
index ..0e7a9274749f
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi_regs.h
@@ -0,0 +1,172 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * rcar_mipi_dsi_regs.h -- R-Car MIPI DSI Interface Registers
Definitions
+ *
+ * Copyright (C) 2020 Renesas Electronics Corporation
+ */
+
+#ifndef __RCAR_MIPI_DSI_REGS_H__
+#define __RCAR_MIPI_DSI_REGS_H__
+
+#define LINKSR0x010
+#define LINKSR_LPBUSY (1 << 1)
+#define LINKSR_HSBUSY (1 << 0)
+
+/*
+ * Video Mode Register
+ */
+#define TXVMSETR 0x180
+#define TXVMSETR_SYNSEQ_PULSES
Re: [PATCH v4 0/8] Implement generic cc_platform_has() helper function
On 9/28/21 1:31 PM, Borislav Petkov wrote: On Tue, Sep 28, 2021 at 12:19:49PM -0700, Kuppuswamy, Sathyanarayanan wrote: Intel CC support patch is not included in this series. You want me to address the issue raised by Joerg before merging it? Did you not see my email to you today: https://lkml.kernel.org/r/yvl4zughfsh1q...@zn.tnic Just read it. If you want to use cpuid_has_tdx_guest() directly in cc_platform_has(), then you want to rename intel_cc_platform_has() to tdx_cc_platform_has()? ? -- Sathyanarayanan Kuppuswamy Linux Kernel Developer
Re: [Intel-gfx] [PATCH 22/27] drm/i915/guc: Add basic GuC multi-lrc selftest
On 8/20/2021 15:44, Matthew Brost wrote:
Add very basic (single submission) multi-lrc selftest.
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 1 +
.../drm/i915/gt/uc/selftest_guc_multi_lrc.c | 180 ++
.../drm/i915/selftests/i915_live_selftests.h | 1 +
3 files changed, 182 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 2554d0eb4afd..91330525330d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -3924,4 +3924,5 @@ bool intel_guc_virtual_engine_has_heartbeat(const struct
intel_engine_cs *ve)
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftest_guc.c"
+#include "selftest_guc_multi_lrc.c"
#endif
diff --git a/drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c
b/drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c
new file mode 100644
index ..dacfc5dfadd6
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright �� 2019 Intel Corporation
+ */
+
+#include "selftests/igt_spinner.h"
+#include "selftests/igt_reset.h"
+#include "selftests/intel_scheduler_helpers.h"
+#include "gt/intel_engine_heartbeat.h"
+#include "gem/selftests/mock_context.h"
+
+static void logical_sort(struct intel_engine_cs **engines, int num_engines)
+{
+ struct intel_engine_cs *sorted[MAX_ENGINE_INSTANCE + 1];
+ int i, j;
+
+ for (i = 0; i < num_engines; ++i)
+ for (j = 0; j < MAX_ENGINE_INSTANCE + 1; ++j) {
+ if (engines[j]->logical_mask & BIT(i)) {
+ sorted[i] = engines[j];
+ break;
+ }
+ }
+
+ memcpy(*engines, *sorted,
+ sizeof(struct intel_engine_cs *) * num_engines);
+}
+
+static struct intel_context *
+multi_lrc_create_parent(struct intel_gt *gt, u8 class,
+ unsigned long flags)
+{
+ struct intel_engine_cs *siblings[MAX_ENGINE_INSTANCE + 1];
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ int i = 0;
+
+ for_each_engine(engine, gt, id) {
+ if (engine->class != class)
+ continue;
+
+ siblings[i++] = engine;
+ }
+
+ if (i <= 1)
+ return ERR_PTR(0);
+
+ logical_sort(siblings, i);
+
+ return intel_engine_create_parallel(siblings, 1, i);
+}
+
+static void multi_lrc_context_unpin(struct intel_context *ce)
+{
+ struct intel_context *child;
+
+ GEM_BUG_ON(!intel_context_is_parent(ce));
+
+ for_each_child(ce, child)
+ intel_context_unpin(child);
+ intel_context_unpin(ce);
+}
+
+static void multi_lrc_context_put(struct intel_context *ce)
+{
+ GEM_BUG_ON(!intel_context_is_parent(ce));
+
+ /*
+* Only the parent gets the creation ref put in the uAPI, the parent
+* itself is responsible for creation ref put on the children.
+*/
+ intel_context_put(ce);
+}
+
+static struct i915_request *
+multi_lrc_nop_request(struct intel_context *ce)
+{
+ struct intel_context *child;
+ struct i915_request *rq, *child_rq;
+ int i = 0;
+
+ GEM_BUG_ON(!intel_context_is_parent(ce));
+
+ rq = intel_context_create_request(ce);
+ if (IS_ERR(rq))
+ return rq;
+
+ i915_request_get(rq);
+ i915_request_add(rq);
+
+ for_each_child(ce, child) {
+ child_rq = intel_context_create_request(child);
+ if (IS_ERR(child_rq))
+ goto child_error;
+
+ if (++i == ce->guc_number_children)
+ set_bit(I915_FENCE_FLAG_SUBMIT_PARALLEL,
+ _rq->fence.flags);
+ i915_request_add(child_rq);
+ }
+
+ return rq;
+
+child_error:
+ i915_request_put(rq);
+
+ return ERR_PTR(-ENOMEM);
+}
+
+static int __intel_guc_multi_lrc_basic(struct intel_gt *gt, unsigned int class)
+{
+ struct intel_context *parent;
+ struct i915_request *rq;
+ int ret;
+
+ parent = multi_lrc_create_parent(gt, class, 0);
+ if (IS_ERR(parent)) {
+ pr_err("Failed creating contexts: %ld", PTR_ERR(parent));
+ return PTR_ERR(parent);
+ } else if (!parent) {
+ pr_debug("Not enough engines in class: %d",
+VIDEO_DECODE_CLASS);
Should be 'class'.
With that fixed:
Reviewed-by: John Harrison
+ return 0;
+ }
+
+ rq = multi_lrc_nop_request(parent);
+ if (IS_ERR(rq)) {
+ ret = PTR_ERR(rq);
+ pr_err("Failed creating requests: %d", ret);
+ goto out;
+
RE: [PATCH] drm/kmb: Remove set_test_mode_src_osc_freq_target_{hi,low}_bits()
Thanks for the patch. Looks good.
Acked-by: Anitha Chrisanthus
> -Original Message-
> From: Nathan Chancellor
> Sent: Tuesday, September 28, 2021 12:24 PM
> To: Chrisanthus, Anitha ; Dea, Edmund J
>
> Cc: Geert Uytterhoeven ; Nick Desaulniers
> ; dri-devel@lists.freedesktop.org; linux-
> ker...@vger.kernel.org; l...@lists.linux.dev; Nathan Chancellor
> ; lkp
> Subject: [PATCH] drm/kmb: Remove
> set_test_mode_src_osc_freq_target_{hi,low}_bits()
>
> clang with W=1 warns:
>
> drivers/gpu/drm/kmb/kmb_dsi.c:812:2: error: unused function
> 'set_test_mode_src_osc_freq_target_low_bits' [-Werror,-Wunused-function]
> set_test_mode_src_osc_freq_target_low_bits(struct kmb_dsi *kmb_dsi,
> ^
> drivers/gpu/drm/kmb/kmb_dsi.c:824:2: error: unused function
> 'set_test_mode_src_osc_freq_target_hi_bits' [-Werror,-Wunused-function]
> set_test_mode_src_osc_freq_target_hi_bits(struct kmb_dsi *kmb_dsi,
> ^
> 2 errors generated.
>
> Remove them, as they have been unused since the driver's introduction in
> commit 98521f4d4b4c ("drm/kmb: Mipi DSI part of the display driver").
>
> Reported-by: kernel test robot
> Signed-off-by: Nathan Chancellor
> ---
> drivers/gpu/drm/kmb/kmb_dsi.c | 28
> 1 file changed, 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/kmb/kmb_dsi.c
> b/drivers/gpu/drm/kmb/kmb_dsi.c
> index 1793cd31b117..ae24c5fc35a5 100644
> --- a/drivers/gpu/drm/kmb/kmb_dsi.c
> +++ b/drivers/gpu/drm/kmb/kmb_dsi.c
> @@ -808,34 +808,6 @@ static void test_mode_send(struct kmb_dsi
> *kmb_dsi, u32 dphy_no,
> }
> }
>
> -static inline void
> - set_test_mode_src_osc_freq_target_low_bits(struct kmb_dsi
> *kmb_dsi,
> -u32 dphy_no,
> -u32 freq)
> -{
> - /* Typical rise/fall time=166, refer Table 1207 databook,
> - * sr_osc_freq_target[7:0]
> - */
> - test_mode_send(kmb_dsi, dphy_no,
> TEST_CODE_SLEW_RATE_DDL_CYCLES,
> -(freq & 0x7f));
> -}
> -
> -static inline void
> - set_test_mode_src_osc_freq_target_hi_bits(struct kmb_dsi *kmb_dsi,
> - u32 dphy_no,
> - u32 freq)
> -{
> - u32 data;
> -
> - /* Flag this as high nibble */
> - data = ((freq >> 6) & 0x1f) | (1 << 7);
> -
> - /* Typical rise/fall time=166, refer Table 1207 databook,
> - * sr_osc_freq_target[11:7]
> - */
> - test_mode_send(kmb_dsi, dphy_no,
> TEST_CODE_SLEW_RATE_DDL_CYCLES, data);
> -}
> -
> static void mipi_tx_get_vco_params(struct vco_params *vco)
> {
> int i;
>
> base-commit: 93ee1a2c0f08345ab17c51198f725d4c95984f4c
> --
> 2.33.0.591.gddb1055343
Re: [PATCH] drm/msm/dp: only signal audio when disconnected detected at dp_pm_resume
Quoting Kuogee Hsieh (2021-09-28 09:11:12)
> Only signal audio when disconnected detected at dp_pm_resume since
> connected status will be signaled to audio at next plugin handler.
Please add more details. This says what the patch does but it would be
better if it included why it is important. Does it fix something?
There's a fixes tag so it must fix something. Is it bad to signal audio
plug change on resume when it hasn't actually changed from last time?
Why is that bad? What if the cable is unplugged and then plugged in
before resume? Does audio still get signalled in that case?
>
> Fixes: 078867ce04ed ("drm/msm/dp: signal audio plugged change at
> dp_pm_resume")
> Signed-off-by: Kuogee Hsieh
> ---
> drivers/gpu/drm/msm/dp/dp_display.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index 0e543a03..6f13008 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -1356,14 +1356,14 @@ static int dp_pm_resume(struct device *dev)
> * can not declared display is connected unless
> * HDMI cable is plugged in and sink_count of
> * dongle become 1
> +* also only signal audio when disconnected
> */
> - if (dp->link->sink_count)
> + if (dp->link->sink_count) {
> dp->dp_display.is_connected = true;
> - else
> + } else {
> dp->dp_display.is_connected = false;
> -
> - dp_display_handle_plugged_change(g_dp_display,
> - dp->dp_display.is_connected);
> + dp_display_handle_plugged_change(g_dp_display, false);
> + }
[PATCH v3] drm/amd/display: Only define DP 2.0 symbols if not already defined
[Why]
For some reason we're defining DP 2.0 definitions inside our
driver. Now that patches to introduce relevant definitions
are slated to be merged into drm-next this is causing conflicts.
In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:33:
In file included from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:70:
In file included from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu_mode.h:36:
./include/drm/drm_dp_helper.h:1322:9: error:
'DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER' macro redefined
[-Werror,-Wmacro-redefined]
^
./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: note: previous
definition is here
^
1 error generated.
[How]
Guard all display driver defines with #ifndef for now. Once we pull
in the new definitions into amd-staging-drm-next we will follow
up and drop definitions from our driver and provide follow-up
header updates for any addition DP 2.0 definitions required
by our driver.
We also ensure drm_dp_helper.h is included before dc_dp_types.h.
v3: Ensure drm_dp_helper.h is included before dc_dp_types.h
v2: Add one missing endif
Signed-off-by: Harry Wentland
Reviewed-by: Fangzhi Zuo
---
drivers/gpu/drm/amd/display/dc/dc_dp_types.h | 54 ++--
drivers/gpu/drm/amd/display/dc/os_types.h| 1 +
2 files changed, 50 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
index a5e798b5da79..9de86ff5ef1b 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
@@ -860,28 +860,72 @@ struct psr_caps {
};
#if defined(CONFIG_DRM_AMD_DC_DCN)
+#ifndef DP_MAIN_LINK_CHANNEL_CODING_CAP
#define DP_MAIN_LINK_CHANNEL_CODING_CAP0x006
+#endif
+#ifndef DP_SINK_VIDEO_FALLBACK_FORMATS
#define DP_SINK_VIDEO_FALLBACK_FORMATS 0x020
+#endif
+#ifndef DP_FEC_CAPABILITY_1
#define DP_FEC_CAPABILITY_10x091
+#endif
+#ifndef DP_DFP_CAPABILITY_EXTENSION_SUPPORT
#define DP_DFP_CAPABILITY_EXTENSION_SUPPORT0x0A3
+#endif
+#ifndef DP_DSC_CONFIGURATION
#define DP_DSC_CONFIGURATION 0x161
+#endif
+#ifndef DP_PHY_SQUARE_PATTERN
#define DP_PHY_SQUARE_PATTERN 0x249
+#endif
+#ifndef DP_128b_132b_SUPPORTED_LINK_RATES
#define DP_128b_132b_SUPPORTED_LINK_RATES 0x2215
+#endif
+#ifndef DP_128b_132b_TRAINING_AUX_RD_INTERVAL
#define DP_128b_132b_TRAINING_AUX_RD_INTERVAL 0x2216
+#endif
+#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_7_0
#define DP_TEST_264BIT_CUSTOM_PATTERN_7_0 0X2230
+#endif
+#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_263_256
#define DP_TEST_264BIT_CUSTOM_PATTERN_263_256 0X2250
+#endif
+#ifndef DP_DSC_SUPPORT_AND_DECODER_COUNT
#define DP_DSC_SUPPORT_AND_DECODER_COUNT 0x2260
+#endif
+#ifndef DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0
#define DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0 0x2270
-# define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK (1 << 0)
-# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK (0b111 << 1)
-# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT1
-# define DP_DSC_DECODER_COUNT_MASK (0b111 << 5)
-# define DP_DSC_DECODER_COUNT_SHIFT5
+#endif
+#ifndef DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK
+#define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK (1 << 0)
+#endif
+#ifndef DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK
+#define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK (0b111 << 1)
+#endif
+#ifndef DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT
+#define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT 1
+#endif
+#ifndef DP_DSC_DECODER_COUNT_MASK
+#define DP_DSC_DECODER_COUNT_MASK (0b111 << 5)
+#endif
+#ifndef DP_DSC_DECODER_COUNT_SHIFT
+#define DP_DSC_DECODER_COUNT_SHIFT 5
+#endif
+#ifndef DP_MAIN_LINK_CHANNEL_CODING_SET
#define DP_MAIN_LINK_CHANNEL_CODING_SET0x108
+#endif
+#ifndef DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER
#define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+#endif
+#ifndef DP_PHY_REPEATER_128b_132b_RATES
#define DP_PHY_REPEATER_128b_132b_RATES0xF0007
+#endif
+#ifndef DP_128b_132b_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1
#define DP_128b_132b_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER10xF0022
+#endif
+#ifndef DP_INTRA_HOP_AUX_REPLY_INDICATION
#define DP_INTRA_HOP_AUX_REPLY_INDICATION (1 << 3)
+#endif
/* TODO - Use DRM header to replace above once available */
union dp_main_line_channel_coding_cap {
diff --git a/drivers/gpu/drm/amd/display/dc/os_types.h
b/drivers/gpu/drm/amd/display/dc/os_types.h
index f50cae252de4..34efb708ea12 100644
--- a/drivers/gpu/drm/amd/display/dc/os_types.h
+++ b/drivers/gpu/drm/amd/display/dc/os_types.h
@@ -35,6 +35,7 @@
#include
#include
+#include
#include "cgs_common.h"
--
2.33.0
Re: [PATCH v4 0/8] Implement generic cc_platform_has() helper function
On Tue, Sep 28, 2021 at 12:19:49PM -0700, Kuppuswamy, Sathyanarayanan wrote: > Intel CC support patch is not included in this series. You want me > to address the issue raised by Joerg before merging it? Did you not see my email to you today: https://lkml.kernel.org/r/yvl4zughfsh1q...@zn.tnic ? -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH 2/3] drm/dp, drm/i915: Add support for VESA backlights using PWM for brightness control
Hi,
On Mon, Sep 27, 2021 at 1:12 PM Lyude Paul wrote:
>
> @@ -3305,11 +3313,10 @@ EXPORT_SYMBOL(drm_edp_backlight_enable);
> * @bl: Backlight capability info from drm_edp_backlight_init()
> *
> * This function handles disabling DPCD backlight controls on a panel over
> AUX. Note that some
> - * panels have backlights that are enabled/disabled by other means, despite
> having their brightness
> - * values controlled through DPCD. On such panels
> _edp_backlight_info.aux_enable will be set to
> - * %false, this function will become a no-op (and we will skip updating
> - * %DP_EDP_DISPLAY_CONTROL_REGISTER), and the driver must take care to
> perform it's own
> - * implementation specific step for disabling the backlight.
> + * panels have backlights that are enabled/disabled via PWM. On such panels
> + * _edp_backlight_info.aux_enable will be set to %false, this function
> will become a no-op (and
> + * we will skip updating %DP_EDP_DISPLAY_CONTROL_REGISTER), and the driver
> must handle disabling the
> + * backlight via PWM.
I'm not sure I understand the comment above. You say "enabled/disabled
via PWM" and that doesn't make sense w/ my mental model. Normally I
think of a PWM allowing you to adjust the brightness and there being a
separate GPIO that's in charge of enable/disable. To some extent you
could think of a PWM as being "disabled" when its duty cycle is 0%,
but usually there's separate "enable" logic that really has nothing to
do with the PWM itself.
In general, it seems like the options are:
1. DPCD controls PWM and the "enable" logic.
2. DPCD controls PWM but requires an external "enable" GPIO.
3. We require an external PWM but DPCD controls the "enable" logic.
Maybe you need a second "capability" to describe whether the client of
your code knows how to control an enable GPIO? ...or perhaps better
you don't need a capability and you can just assume that if the client
needs to set an "enable" GPIO that it will do so. That would match how
things work today. AKA:
a) Client calls the AUX backlight code to "enable"
b) AUX backlight code will set the "enable" bit if supported.
c) Client will set the "enable" GPIO if it knows about one.
Presumably only one of b) or c) will actually do something. If neither
does something then this panel simply isn't compatible with this
board.
> +/**
> + * drm_edp_backlight_supported() - Check an eDP DPCD for VESA backlight
> support
> + * @aux: The AUX channel, only used for debug logging
> + * @edp_dpcd: The DPCD to check
> + * @caps: The backlight capabilities this driver supports
> + *
> + * Returns: %True if @edp_dpcd indicates that VESA backlight controls are
> supported, %false
> + * otherwise
> + */
> +bool drm_edp_backlight_supported(struct drm_dp_aux *aux,
> +const u8 edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE],
> +enum drm_edp_backlight_driver_caps caps)
> +{
> + if (!(edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP))
> + return false;
> +
> + if (!(caps & DRM_EDP_BACKLIGHT_DRIVER_CAP_PWM) &&
> + (!(edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) ||
> +!(edp_dpcd[2] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))) {
Elsewhere you match DP_EDP_BACKLIGHT_AUX_ENABLE_CAP against
edp_dpcd[1]. Here you match against [2]. Are you sure that's correct?
> /*
> * DisplayPort AUX channel
> */
> @@ -2200,7 +2182,11 @@ drm_dp_has_quirk(const struct drm_dp_desc *desc, enum
> drm_dp_quirk quirk)
> * @pwm_freq_pre_divider: The PWM frequency pre-divider value being used for
> this backlight, if any
> * @max: The maximum backlight level that may be set
> * @lsb_reg_used: Do we also write values to the
> DP_EDP_BACKLIGHT_BRIGHTNESS_LSB register?
> - * @aux_enable: Does the panel support the AUX enable cap?
> + * @aux_enable: Does the panel support the AUX enable cap? Always %false
> when the driver doesn't
> + * support %DRM_EDP_BACKLIGHT_DRIVER_CAP_PWM
Why is aux_enable always false if it doesn't support
DRM_EDP_BACKLIGHT_DRIVER_CAP_PWM? It doesn't seem like the code
enforces this and I'm not sure why it would. Am I confused?
[PATCH] drm/kmb: Remove set_test_mode_src_osc_freq_target_{hi, low}_bits()
clang with W=1 warns:
drivers/gpu/drm/kmb/kmb_dsi.c:812:2: error: unused function
'set_test_mode_src_osc_freq_target_low_bits' [-Werror,-Wunused-function]
set_test_mode_src_osc_freq_target_low_bits(struct kmb_dsi *kmb_dsi,
^
drivers/gpu/drm/kmb/kmb_dsi.c:824:2: error: unused function
'set_test_mode_src_osc_freq_target_hi_bits' [-Werror,-Wunused-function]
set_test_mode_src_osc_freq_target_hi_bits(struct kmb_dsi *kmb_dsi,
^
2 errors generated.
Remove them, as they have been unused since the driver's introduction in
commit 98521f4d4b4c ("drm/kmb: Mipi DSI part of the display driver").
Reported-by: kernel test robot
Signed-off-by: Nathan Chancellor
---
drivers/gpu/drm/kmb/kmb_dsi.c | 28
1 file changed, 28 deletions(-)
diff --git a/drivers/gpu/drm/kmb/kmb_dsi.c b/drivers/gpu/drm/kmb/kmb_dsi.c
index 1793cd31b117..ae24c5fc35a5 100644
--- a/drivers/gpu/drm/kmb/kmb_dsi.c
+++ b/drivers/gpu/drm/kmb/kmb_dsi.c
@@ -808,34 +808,6 @@ static void test_mode_send(struct kmb_dsi *kmb_dsi, u32
dphy_no,
}
}
-static inline void
- set_test_mode_src_osc_freq_target_low_bits(struct kmb_dsi *kmb_dsi,
- u32 dphy_no,
- u32 freq)
-{
- /* Typical rise/fall time=166, refer Table 1207 databook,
-* sr_osc_freq_target[7:0]
-*/
- test_mode_send(kmb_dsi, dphy_no, TEST_CODE_SLEW_RATE_DDL_CYCLES,
- (freq & 0x7f));
-}
-
-static inline void
- set_test_mode_src_osc_freq_target_hi_bits(struct kmb_dsi *kmb_dsi,
- u32 dphy_no,
- u32 freq)
-{
- u32 data;
-
- /* Flag this as high nibble */
- data = ((freq >> 6) & 0x1f) | (1 << 7);
-
- /* Typical rise/fall time=166, refer Table 1207 databook,
-* sr_osc_freq_target[11:7]
-*/
- test_mode_send(kmb_dsi, dphy_no, TEST_CODE_SLEW_RATE_DDL_CYCLES, data);
-}
-
static void mipi_tx_get_vco_params(struct vco_params *vco)
{
int i;
base-commit: 93ee1a2c0f08345ab17c51198f725d4c95984f4c
--
2.33.0.591.gddb1055343
Re: [PATCH v4 0/8] Implement generic cc_platform_has() helper function
On 9/28/21 12:10 PM, Borislav Petkov wrote: From: Borislav Petkov Hi all, here's v4 of the cc_platform_has() patchset with feedback incorporated. I'm going to route this through tip if there are no objections. Intel CC support patch is not included in this series. You want me to address the issue raised by Joerg before merging it? Thx. Tom Lendacky (8): x86/ioremap: Selectively build arch override encryption functions arch/cc: Introduce a function to check for confidential computing features x86/sev: Add an x86 version of cc_platform_has() powerpc/pseries/svm: Add a powerpc version of cc_platform_has() x86/sme: Replace occurrences of sme_active() with cc_platform_has() x86/sev: Replace occurrences of sev_active() with cc_platform_has() x86/sev: Replace occurrences of sev_es_active() with cc_platform_has() treewide: Replace the use of mem_encrypt_active() with cc_platform_has() arch/Kconfig | 3 + arch/powerpc/include/asm/mem_encrypt.h | 5 -- arch/powerpc/platforms/pseries/Kconfig | 1 + arch/powerpc/platforms/pseries/Makefile | 2 + arch/powerpc/platforms/pseries/cc_platform.c | 26 ++ arch/powerpc/platforms/pseries/svm.c | 5 +- arch/s390/include/asm/mem_encrypt.h | 2 - arch/x86/Kconfig | 1 + arch/x86/include/asm/io.h| 8 ++ arch/x86/include/asm/kexec.h | 2 +- arch/x86/include/asm/mem_encrypt.h | 12 +-- arch/x86/kernel/Makefile | 6 ++ arch/x86/kernel/cc_platform.c| 69 +++ arch/x86/kernel/crash_dump_64.c | 4 +- arch/x86/kernel/head64.c | 9 +- arch/x86/kernel/kvm.c| 3 +- arch/x86/kernel/kvmclock.c | 4 +- arch/x86/kernel/machine_kexec_64.c | 19 +++-- arch/x86/kernel/pci-swiotlb.c| 9 +- arch/x86/kernel/relocate_kernel_64.S | 2 +- arch/x86/kernel/sev.c| 6 +- arch/x86/kvm/svm/svm.c | 3 +- arch/x86/mm/ioremap.c| 18 ++-- arch/x86/mm/mem_encrypt.c| 55 arch/x86/mm/mem_encrypt_identity.c | 9 +- arch/x86/mm/pat/set_memory.c | 3 +- arch/x86/platform/efi/efi_64.c | 9 +- arch/x86/realmode/init.c | 8 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 +- drivers/gpu/drm/drm_cache.c | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 6 +- drivers/iommu/amd/init.c | 7 +- drivers/iommu/amd/iommu.c| 3 +- drivers/iommu/amd/iommu_v2.c | 3 +- drivers/iommu/iommu.c| 3 +- fs/proc/vmcore.c | 6 +- include/linux/cc_platform.h | 88 include/linux/mem_encrypt.h | 4 - kernel/dma/swiotlb.c | 4 +- 40 files changed, 310 insertions(+), 129 deletions(-) create mode 100644 arch/powerpc/platforms/pseries/cc_platform.c create mode 100644 arch/x86/kernel/cc_platform.c create mode 100644 include/linux/cc_platform.h -- Sathyanarayanan Kuppuswamy Linux Kernel Developer
Re: [PATCH v6 1/2] habanalabs: define uAPI to export FD for DMA-BUF
On Tue, Sep 28, 2021 at 8:13 PM Jason Gunthorpe wrote:
>
> On Sun, Sep 12, 2021 at 07:53:08PM +0300, Oded Gabbay wrote:
> > /* HL_MEM_OP_* */
> > __u32 op;
> > - /* HL_MEM_* flags */
> > + /* HL_MEM_* flags.
> > + * For the HL_MEM_OP_EXPORT_DMABUF_FD opcode, this field holds the
> > + * DMA-BUF file/FD flags.
> > + */
> > __u32 flags;
> > /* Context ID - Currently not in use */
> > __u32 ctx_id;
> > @@ -1072,6 +1091,13 @@ struct hl_mem_out {
> >
> > __u32 pad;
> > };
> > +
> > + /* Returned in HL_MEM_OP_EXPORT_DMABUF_FD. Represents the
> > + * DMA-BUF object that was created to describe a memory
> > + * allocation on the device's memory space. The FD should be
> > + * passed to the importer driver
> > + */
> > + __u64 fd;
>
> fd's should be a s32 type in a fixed width uapi.
Yep, will correct this.
>
> I usually expect to see the uapi changes inside the commit that
> consumes them, splitting the patch like this seems strange but
> harmless.
I'll remember that when I send the RDMA patches down the road :)
Thanks,
Oded
>
> Jason
[PATCH 7/8] x86/sev: Replace occurrences of sev_es_active() with cc_platform_has()
From: Tom Lendacky
Replace uses of sev_es_active() with the more generic cc_platform_has()
using CC_ATTR_GUEST_STATE_ENCRYPT. If future support is added for other
memory encyrption techonologies, the use of CC_ATTR_GUEST_STATE_ENCRYPT
can be updated, as required.
Signed-off-by: Tom Lendacky
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/mem_encrypt.h | 2 --
arch/x86/kernel/sev.c | 6 +++---
arch/x86/mm/mem_encrypt.c | 24 +++-
arch/x86/realmode/init.c | 3 +--
4 files changed, 7 insertions(+), 28 deletions(-)
diff --git a/arch/x86/include/asm/mem_encrypt.h
b/arch/x86/include/asm/mem_encrypt.h
index a5a58ccd1ee3..da14ede311aa 100644
--- a/arch/x86/include/asm/mem_encrypt.h
+++ b/arch/x86/include/asm/mem_encrypt.h
@@ -51,7 +51,6 @@ void __init mem_encrypt_free_decrypted_mem(void);
void __init mem_encrypt_init(void);
void __init sev_es_init_vc_handling(void);
-bool sev_es_active(void);
#define __bss_decrypted __section(".bss..decrypted")
@@ -74,7 +73,6 @@ static inline void __init sme_encrypt_kernel(struct
boot_params *bp) { }
static inline void __init sme_enable(struct boot_params *bp) { }
static inline void sev_es_init_vc_handling(void) { }
-static inline bool sev_es_active(void) { return false; }
static inline int __init
early_set_memory_decrypted(unsigned long vaddr, unsigned long size) { return
0; }
diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
index a6895e440bc3..53a6837d354b 100644
--- a/arch/x86/kernel/sev.c
+++ b/arch/x86/kernel/sev.c
@@ -11,7 +11,7 @@
#include /* For show_regs() */
#include
-#include
+#include
#include
#include
#include
@@ -615,7 +615,7 @@ int __init sev_es_efi_map_ghcbs(pgd_t *pgd)
int cpu;
u64 pfn;
- if (!sev_es_active())
+ if (!cc_platform_has(CC_ATTR_GUEST_STATE_ENCRYPT))
return 0;
pflags = _PAGE_NX | _PAGE_RW;
@@ -774,7 +774,7 @@ void __init sev_es_init_vc_handling(void)
BUILD_BUG_ON(offsetof(struct sev_es_runtime_data, ghcb_page) %
PAGE_SIZE);
- if (!sev_es_active())
+ if (!cc_platform_has(CC_ATTR_GUEST_STATE_ENCRYPT))
return;
if (!sev_es_check_cpu_features())
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index 932007a6913b..2d04c39bea1d 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -361,25 +361,6 @@ int __init early_set_memory_encrypted(unsigned long vaddr,
unsigned long size)
return early_set_memory_enc_dec(vaddr, size, true);
}
-/*
- * SME and SEV are very similar but they are not the same, so there are
- * times that the kernel will need to distinguish between SME and SEV. The
- * cc_platform_has() function is used for this. When a distinction isn't
- * needed, the CC_ATTR_MEM_ENCRYPT attribute can be used.
- *
- * The trampoline code is a good example for this requirement. Before
- * paging is activated, SME will access all memory as decrypted, but SEV
- * will access all memory as encrypted. So, when APs are being brought
- * up under SME the trampoline area cannot be encrypted, whereas under SEV
- * the trampoline area must be encrypted.
- */
-
-/* Needs to be called from non-instrumentable code */
-bool noinstr sev_es_active(void)
-{
- return sev_status & MSR_AMD64_SEV_ES_ENABLED;
-}
-
/* Override for DMA direct allocation check - ARCH_HAS_FORCE_DMA_UNENCRYPTED */
bool force_dma_unencrypted(struct device *dev)
{
@@ -449,7 +430,7 @@ static void print_mem_encrypt_feature_info(void)
pr_cont(" SEV");
/* Encrypted Register State */
- if (sev_es_active())
+ if (cc_platform_has(CC_ATTR_GUEST_STATE_ENCRYPT))
pr_cont(" SEV-ES");
pr_cont("\n");
@@ -468,7 +449,8 @@ void __init mem_encrypt_init(void)
* With SEV, we need to unroll the rep string I/O instructions,
* but SEV-ES supports them through the #VC handler.
*/
- if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) && !sev_es_active())
+ if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
+ !cc_platform_has(CC_ATTR_GUEST_STATE_ENCRYPT))
static_branch_enable(_enable_key);
print_mem_encrypt_feature_info();
diff --git a/arch/x86/realmode/init.c b/arch/x86/realmode/init.c
index c878c5ee5a4c..4a3da7592b99 100644
--- a/arch/x86/realmode/init.c
+++ b/arch/x86/realmode/init.c
@@ -2,7 +2,6 @@
#include
#include
#include
-#include
#include
#include
@@ -48,7 +47,7 @@ static void sme_sev_setup_real_mode(struct trampoline_header
*th)
if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT))
th->flags |= TH_FLAGS_SME_ACTIVE;
- if (sev_es_active()) {
+ if (cc_platform_has(CC_ATTR_GUEST_STATE_ENCRYPT)) {
/*
* Skip the call to verify_cpu() in secondary_startup_64 as it
* will cause #VC exceptions when the AP can't handle them yet.
[PATCH 6/8] x86/sev: Replace occurrences of sev_active() with cc_platform_has()
From: Tom Lendacky
Replace uses of sev_active() with the more generic cc_platform_has()
using CC_ATTR_GUEST_MEM_ENCRYPT. If future support is added for other
memory encryption technologies, the use of CC_ATTR_GUEST_MEM_ENCRYPT
can be updated, as required.
Signed-off-by: Tom Lendacky
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/mem_encrypt.h | 2 --
arch/x86/kernel/crash_dump_64.c| 4 +++-
arch/x86/kernel/kvm.c | 3 ++-
arch/x86/kernel/kvmclock.c | 4 ++--
arch/x86/kernel/machine_kexec_64.c | 4 ++--
arch/x86/kvm/svm/svm.c | 3 ++-
arch/x86/mm/ioremap.c | 6 +++---
arch/x86/mm/mem_encrypt.c | 21 -
arch/x86/platform/efi/efi_64.c | 9 +
9 files changed, 27 insertions(+), 29 deletions(-)
diff --git a/arch/x86/include/asm/mem_encrypt.h
b/arch/x86/include/asm/mem_encrypt.h
index 63c5b99ccae5..a5a58ccd1ee3 100644
--- a/arch/x86/include/asm/mem_encrypt.h
+++ b/arch/x86/include/asm/mem_encrypt.h
@@ -51,7 +51,6 @@ void __init mem_encrypt_free_decrypted_mem(void);
void __init mem_encrypt_init(void);
void __init sev_es_init_vc_handling(void);
-bool sev_active(void);
bool sev_es_active(void);
#define __bss_decrypted __section(".bss..decrypted")
@@ -75,7 +74,6 @@ static inline void __init sme_encrypt_kernel(struct
boot_params *bp) { }
static inline void __init sme_enable(struct boot_params *bp) { }
static inline void sev_es_init_vc_handling(void) { }
-static inline bool sev_active(void) { return false; }
static inline bool sev_es_active(void) { return false; }
static inline int __init
diff --git a/arch/x86/kernel/crash_dump_64.c b/arch/x86/kernel/crash_dump_64.c
index 045e82e8945b..a7f617a3981d 100644
--- a/arch/x86/kernel/crash_dump_64.c
+++ b/arch/x86/kernel/crash_dump_64.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
static ssize_t __copy_oldmem_page(unsigned long pfn, char *buf, size_t csize,
unsigned long offset, int userbuf,
@@ -73,5 +74,6 @@ ssize_t copy_oldmem_page_encrypted(unsigned long pfn, char
*buf, size_t csize,
ssize_t elfcorehdr_read(char *buf, size_t count, u64 *ppos)
{
- return read_from_oldmem(buf, count, ppos, 0, sev_active());
+ return read_from_oldmem(buf, count, ppos, 0,
+ cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT));
}
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index b656456c3a94..8863d1941f1b 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -418,7 +419,7 @@ static void __init sev_map_percpu_data(void)
{
int cpu;
- if (!sev_active())
+ if (!cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
return;
for_each_possible_cpu(cpu) {
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index ad273e5861c1..fc3930c5db1b 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -16,9 +16,9 @@
#include
#include
#include
+#include
#include
-#include
#include
#include
@@ -232,7 +232,7 @@ static void __init kvmclock_init_mem(void)
* hvclock is shared between the guest and the hypervisor, must
* be mapped decrypted.
*/
- if (sev_active()) {
+ if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) {
r = set_memory_decrypted((unsigned long) hvclock_mem,
1UL << order);
if (r) {
diff --git a/arch/x86/kernel/machine_kexec_64.c
b/arch/x86/kernel/machine_kexec_64.c
index 7040c0fa921c..f5da4a18070a 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -167,7 +167,7 @@ static int init_transition_pgtable(struct kimage *image,
pgd_t *pgd)
}
pte = pte_offset_kernel(pmd, vaddr);
- if (sev_active())
+ if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
prot = PAGE_KERNEL_EXEC;
set_pte(pte, pfn_pte(paddr >> PAGE_SHIFT, prot));
@@ -207,7 +207,7 @@ static int init_pgtable(struct kimage *image, unsigned long
start_pgtable)
level4p = (pgd_t *)__va(start_pgtable);
clear_page(level4p);
- if (sev_active()) {
+ if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) {
info.page_flag |= _PAGE_ENC;
info.kernpg_flag |= _PAGE_ENC;
}
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 05e8d4d27969..a2f78a8cfdaa 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -455,7 +456,7 @@ static int has_svm(void)
return 0;
}
- if (sev_active()) {
+ if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) {
pr_info("KVM is unsupported when running as an SEV guest\n");
[PATCH 5/8] x86/sme: Replace occurrences of sme_active() with cc_platform_has()
From: Tom Lendacky
Replace uses of sme_active() with the more generic cc_platform_has()
using CC_ATTR_HOST_MEM_ENCRYPT. If future support is added for other
memory encryption technologies, the use of CC_ATTR_HOST_MEM_ENCRYPT
can be updated, as required.
This also replaces two usages of sev_active() that are really geared
towards detecting if SME is active.
Signed-off-by: Tom Lendacky
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/kexec.h | 2 +-
arch/x86/include/asm/mem_encrypt.h | 2 --
arch/x86/kernel/machine_kexec_64.c | 15 ---
arch/x86/kernel/pci-swiotlb.c| 9 -
arch/x86/kernel/relocate_kernel_64.S | 2 +-
arch/x86/mm/ioremap.c| 6 +++---
arch/x86/mm/mem_encrypt.c| 13 -
arch/x86/mm/mem_encrypt_identity.c | 9 -
arch/x86/realmode/init.c | 5 +++--
drivers/iommu/amd/init.c | 7 ---
10 files changed, 36 insertions(+), 34 deletions(-)
diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
index 0a6e34b07017..11b7c06e2828 100644
--- a/arch/x86/include/asm/kexec.h
+++ b/arch/x86/include/asm/kexec.h
@@ -129,7 +129,7 @@ relocate_kernel(unsigned long indirection_page,
unsigned long page_list,
unsigned long start_address,
unsigned int preserve_context,
- unsigned int sme_active);
+ unsigned int host_mem_enc_active);
#endif
#define ARCH_HAS_KIMAGE_ARCH
diff --git a/arch/x86/include/asm/mem_encrypt.h
b/arch/x86/include/asm/mem_encrypt.h
index 3fb9f5ebefa4..63c5b99ccae5 100644
--- a/arch/x86/include/asm/mem_encrypt.h
+++ b/arch/x86/include/asm/mem_encrypt.h
@@ -51,7 +51,6 @@ void __init mem_encrypt_free_decrypted_mem(void);
void __init mem_encrypt_init(void);
void __init sev_es_init_vc_handling(void);
-bool sme_active(void);
bool sev_active(void);
bool sev_es_active(void);
@@ -76,7 +75,6 @@ static inline void __init sme_encrypt_kernel(struct
boot_params *bp) { }
static inline void __init sme_enable(struct boot_params *bp) { }
static inline void sev_es_init_vc_handling(void) { }
-static inline bool sme_active(void) { return false; }
static inline bool sev_active(void) { return false; }
static inline bool sev_es_active(void) { return false; }
diff --git a/arch/x86/kernel/machine_kexec_64.c
b/arch/x86/kernel/machine_kexec_64.c
index 131f30fdcfbd..7040c0fa921c 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -358,7 +359,7 @@ void machine_kexec(struct kimage *image)
(unsigned long)page_list,
image->start,
image->preserve_context,
- sme_active());
+
cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT));
#ifdef CONFIG_KEXEC_JUMP
if (image->preserve_context)
@@ -569,12 +570,12 @@ void arch_kexec_unprotect_crashkres(void)
*/
int arch_kexec_post_alloc_pages(void *vaddr, unsigned int pages, gfp_t gfp)
{
- if (sev_active())
+ if (!cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT))
return 0;
/*
-* If SME is active we need to be sure that kexec pages are
-* not encrypted because when we boot to the new kernel the
+* If host memory encryption is active we need to be sure that kexec
+* pages are not encrypted because when we boot to the new kernel the
* pages won't be accessed encrypted (initially).
*/
return set_memory_decrypted((unsigned long)vaddr, pages);
@@ -582,12 +583,12 @@ int arch_kexec_post_alloc_pages(void *vaddr, unsigned int
pages, gfp_t gfp)
void arch_kexec_pre_free_pages(void *vaddr, unsigned int pages)
{
- if (sev_active())
+ if (!cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT))
return;
/*
-* If SME is active we need to reset the pages back to being
-* an encrypted mapping before freeing them.
+* If host memory encryption is active we need to reset the pages back
+* to being an encrypted mapping before freeing them.
*/
set_memory_encrypted((unsigned long)vaddr, pages);
}
diff --git a/arch/x86/kernel/pci-swiotlb.c b/arch/x86/kernel/pci-swiotlb.c
index c2cfa5e7c152..814ab46a0dad 100644
--- a/arch/x86/kernel/pci-swiotlb.c
+++ b/arch/x86/kernel/pci-swiotlb.c
@@ -6,7 +6,7 @@
#include
#include
#include
-#include
+#include
#include
#include
@@ -45,11 +45,10 @@ int __init pci_swiotlb_detect_4gb(void)
swiotlb = 1;
/*
-* If SME is active then swiotlb will be set to 1 so that bounce
-* buffers are allocated and used for devices that do not support
-* the addressing range required for the encryption mask.
+*
[PATCH 8/8] treewide: Replace the use of mem_encrypt_active() with cc_platform_has()
From: Tom Lendacky
Replace uses of mem_encrypt_active() with calls to cc_platform_has() with
the CC_ATTR_MEM_ENCRYPT attribute.
Remove the implementation of mem_encrypt_active() across all arches.
For s390, since the default implementation of the cc_platform_has()
matches the s390 implementation of mem_encrypt_active(), cc_platform_has()
does not need to be implemented in s390 (the config option
ARCH_HAS_CC_PLATFORM is not set).
Signed-off-by: Tom Lendacky
Signed-off-by: Borislav Petkov
---
arch/powerpc/include/asm/mem_encrypt.h | 5 -
arch/powerpc/platforms/pseries/svm.c| 5 +++--
arch/s390/include/asm/mem_encrypt.h | 2 --
arch/x86/include/asm/mem_encrypt.h | 5 -
arch/x86/kernel/head64.c| 9 +++--
arch/x86/mm/ioremap.c | 4 ++--
arch/x86/mm/mem_encrypt.c | 2 +-
arch/x86/mm/pat/set_memory.c| 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 +++-
drivers/gpu/drm/drm_cache.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 6 +++---
drivers/iommu/amd/iommu.c | 3 ++-
drivers/iommu/amd/iommu_v2.c| 3 ++-
drivers/iommu/iommu.c | 3 ++-
fs/proc/vmcore.c| 6 +++---
include/linux/mem_encrypt.h | 4
kernel/dma/swiotlb.c| 4 ++--
18 files changed, 36 insertions(+), 40 deletions(-)
diff --git a/arch/powerpc/include/asm/mem_encrypt.h
b/arch/powerpc/include/asm/mem_encrypt.h
index ba9dab07c1be..2f26b8fc8d29 100644
--- a/arch/powerpc/include/asm/mem_encrypt.h
+++ b/arch/powerpc/include/asm/mem_encrypt.h
@@ -10,11 +10,6 @@
#include
-static inline bool mem_encrypt_active(void)
-{
- return is_secure_guest();
-}
-
static inline bool force_dma_unencrypted(struct device *dev)
{
return is_secure_guest();
diff --git a/arch/powerpc/platforms/pseries/svm.c
b/arch/powerpc/platforms/pseries/svm.c
index 87f001b4c4e4..c083ecbbae4d 100644
--- a/arch/powerpc/platforms/pseries/svm.c
+++ b/arch/powerpc/platforms/pseries/svm.c
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
#include
#include
@@ -63,7 +64,7 @@ void __init svm_swiotlb_init(void)
int set_memory_encrypted(unsigned long addr, int numpages)
{
- if (!mem_encrypt_active())
+ if (!cc_platform_has(CC_ATTR_MEM_ENCRYPT))
return 0;
if (!PAGE_ALIGNED(addr))
@@ -76,7 +77,7 @@ int set_memory_encrypted(unsigned long addr, int numpages)
int set_memory_decrypted(unsigned long addr, int numpages)
{
- if (!mem_encrypt_active())
+ if (!cc_platform_has(CC_ATTR_MEM_ENCRYPT))
return 0;
if (!PAGE_ALIGNED(addr))
diff --git a/arch/s390/include/asm/mem_encrypt.h
b/arch/s390/include/asm/mem_encrypt.h
index 2542cbf7e2d1..08a8b96606d7 100644
--- a/arch/s390/include/asm/mem_encrypt.h
+++ b/arch/s390/include/asm/mem_encrypt.h
@@ -4,8 +4,6 @@
#ifndef __ASSEMBLY__
-static inline bool mem_encrypt_active(void) { return false; }
-
int set_memory_encrypted(unsigned long addr, int numpages);
int set_memory_decrypted(unsigned long addr, int numpages);
diff --git a/arch/x86/include/asm/mem_encrypt.h
b/arch/x86/include/asm/mem_encrypt.h
index da14ede311aa..2d4f5c17d79c 100644
--- a/arch/x86/include/asm/mem_encrypt.h
+++ b/arch/x86/include/asm/mem_encrypt.h
@@ -96,11 +96,6 @@ static inline void mem_encrypt_free_decrypted_mem(void) { }
extern char __start_bss_decrypted[], __end_bss_decrypted[],
__start_bss_decrypted_unused[];
-static inline bool mem_encrypt_active(void)
-{
- return sme_me_mask;
-}
-
static inline u64 sme_get_me_mask(void)
{
return sme_me_mask;
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index de01903c3735..fc5371a7e9d1 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -19,7 +19,7 @@
#include
#include
#include
-#include
+#include
#include
#include
@@ -284,8 +284,13 @@ unsigned long __head __startup_64(unsigned long physaddr,
* The bss section will be memset to zero later in the initialization so
* there is no need to zero it after changing the memory encryption
* attribute.
+*
+* This is early code, use an open coded check for SME instead of
+* using cc_platform_has(). This eliminates worries about removing
+* instrumentation or checking boot_cpu_data in the cc_platform_has()
+* function.
*/
- if (mem_encrypt_active()) {
+ if (sme_get_me_mask()) {
vaddr = (unsigned long)__start_bss_decrypted;
vaddr_end = (unsigned long)__end_bss_decrypted;
for (; vaddr < vaddr_end; vaddr += PMD_SIZE) {
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index b59a5cbc6bc5..026031b3b782 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -694,7 +694,7 @@ static bool __init
[PATCH 4/8] powerpc/pseries/svm: Add a powerpc version of cc_platform_has()
From: Tom Lendacky
Introduce a powerpc version of the cc_platform_has() function. This will
be used to replace the powerpc mem_encrypt_active() implementation, so
the implementation will initially only support the CC_ATTR_MEM_ENCRYPT
attribute.
Signed-off-by: Tom Lendacky
Signed-off-by: Borislav Petkov
Acked-by: Michael Ellerman
---
arch/powerpc/platforms/pseries/Kconfig | 1 +
arch/powerpc/platforms/pseries/Makefile | 2 ++
arch/powerpc/platforms/pseries/cc_platform.c | 26
3 files changed, 29 insertions(+)
create mode 100644 arch/powerpc/platforms/pseries/cc_platform.c
diff --git a/arch/powerpc/platforms/pseries/Kconfig
b/arch/powerpc/platforms/pseries/Kconfig
index 5e037df2a3a1..2e57391e0778 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -159,6 +159,7 @@ config PPC_SVM
select SWIOTLB
select ARCH_HAS_MEM_ENCRYPT
select ARCH_HAS_FORCE_DMA_UNENCRYPTED
+ select ARCH_HAS_CC_PLATFORM
help
There are certain POWER platforms which support secure guests using
the Protected Execution Facility, with the help of an Ultravisor
diff --git a/arch/powerpc/platforms/pseries/Makefile
b/arch/powerpc/platforms/pseries/Makefile
index 4cda0ef87be0..41d8aee98da4 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -31,3 +31,5 @@ obj-$(CONFIG_FA_DUMP) += rtas-fadump.o
obj-$(CONFIG_SUSPEND) += suspend.o
obj-$(CONFIG_PPC_VAS) += vas.o
+
+obj-$(CONFIG_ARCH_HAS_CC_PLATFORM) += cc_platform.o
diff --git a/arch/powerpc/platforms/pseries/cc_platform.c
b/arch/powerpc/platforms/pseries/cc_platform.c
new file mode 100644
index ..e8021af83a19
--- /dev/null
+++ b/arch/powerpc/platforms/pseries/cc_platform.c
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Confidential Computing Platform Capability checks
+ *
+ * Copyright (C) 2021 Advanced Micro Devices, Inc.
+ *
+ * Author: Tom Lendacky
+ */
+
+#include
+#include
+
+#include
+#include
+
+bool cc_platform_has(enum cc_attr attr)
+{
+ switch (attr) {
+ case CC_ATTR_MEM_ENCRYPT:
+ return is_secure_guest();
+
+ default:
+ return false;
+ }
+}
+EXPORT_SYMBOL_GPL(cc_platform_has);
--
2.29.2
[PATCH 3/8] x86/sev: Add an x86 version of cc_platform_has()
From: Tom Lendacky
Introduce an x86 version of the cc_platform_has() function. This will be
used to replace vendor specific calls like sme_active(), sev_active(),
etc.
Signed-off-by: Tom Lendacky
Signed-off-by: Borislav Petkov
---
arch/x86/Kconfig | 1 +
arch/x86/include/asm/mem_encrypt.h | 1 +
arch/x86/kernel/Makefile | 6 +++
arch/x86/kernel/cc_platform.c | 69 ++
arch/x86/mm/mem_encrypt.c | 1 +
5 files changed, 78 insertions(+)
create mode 100644 arch/x86/kernel/cc_platform.c
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index ab83c22d274e..9f190ec4f953 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1518,6 +1518,7 @@ config AMD_MEM_ENCRYPT
select ARCH_HAS_FORCE_DMA_UNENCRYPTED
select INSTRUCTION_DECODER
select ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
+ select ARCH_HAS_CC_PLATFORM
help
Say yes to enable support for the encryption of system memory.
This requires an AMD processor that supports Secure Memory
diff --git a/arch/x86/include/asm/mem_encrypt.h
b/arch/x86/include/asm/mem_encrypt.h
index 9c80c68d75b5..3fb9f5ebefa4 100644
--- a/arch/x86/include/asm/mem_encrypt.h
+++ b/arch/x86/include/asm/mem_encrypt.h
@@ -13,6 +13,7 @@
#ifndef __ASSEMBLY__
#include
+#include
#include
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 8f4e8fa6ed75..2ff3e600f426 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -21,6 +21,7 @@ CFLAGS_REMOVE_ftrace.o = -pg
CFLAGS_REMOVE_early_printk.o = -pg
CFLAGS_REMOVE_head64.o = -pg
CFLAGS_REMOVE_sev.o = -pg
+CFLAGS_REMOVE_cc_platform.o = -pg
endif
KASAN_SANITIZE_head$(BITS).o := n
@@ -29,6 +30,7 @@ KASAN_SANITIZE_dumpstack_$(BITS).o:= n
KASAN_SANITIZE_stacktrace.o:= n
KASAN_SANITIZE_paravirt.o := n
KASAN_SANITIZE_sev.o := n
+KASAN_SANITIZE_cc_platform.o := n
# With some compiler versions the generated code results in boot hangs, caused
# by several compilation units. To be safe, disable all instrumentation.
@@ -47,6 +49,7 @@ endif
KCOV_INSTRUMENT:= n
CFLAGS_head$(BITS).o += -fno-stack-protector
+CFLAGS_cc_platform.o += -fno-stack-protector
CFLAGS_irq.o := -I $(srctree)/$(src)/../include/asm/trace
@@ -147,6 +150,9 @@ obj-$(CONFIG_UNWINDER_FRAME_POINTER)+=
unwind_frame.o
obj-$(CONFIG_UNWINDER_GUESS) += unwind_guess.o
obj-$(CONFIG_AMD_MEM_ENCRYPT) += sev.o
+
+obj-$(CONFIG_ARCH_HAS_CC_PLATFORM) += cc_platform.o
+
###
# 64 bit specific files
ifeq ($(CONFIG_X86_64),y)
diff --git a/arch/x86/kernel/cc_platform.c b/arch/x86/kernel/cc_platform.c
new file mode 100644
index ..03bb2f343ddb
--- /dev/null
+++ b/arch/x86/kernel/cc_platform.c
@@ -0,0 +1,69 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Confidential Computing Platform Capability checks
+ *
+ * Copyright (C) 2021 Advanced Micro Devices, Inc.
+ *
+ * Author: Tom Lendacky
+ */
+
+#include
+#include
+#include
+
+#include
+
+static bool __maybe_unused intel_cc_platform_has(enum cc_attr attr)
+{
+#ifdef CONFIG_INTEL_TDX_GUEST
+ return false;
+#else
+ return false;
+#endif
+}
+
+/*
+ * SME and SEV are very similar but they are not the same, so there are
+ * times that the kernel will need to distinguish between SME and SEV. The
+ * cc_platform_has() function is used for this. When a distinction isn't
+ * needed, the CC_ATTR_MEM_ENCRYPT attribute can be used.
+ *
+ * The trampoline code is a good example for this requirement. Before
+ * paging is activated, SME will access all memory as decrypted, but SEV
+ * will access all memory as encrypted. So, when APs are being brought
+ * up under SME the trampoline area cannot be encrypted, whereas under SEV
+ * the trampoline area must be encrypted.
+ */
+static bool amd_cc_platform_has(enum cc_attr attr)
+{
+#ifdef CONFIG_AMD_MEM_ENCRYPT
+ switch (attr) {
+ case CC_ATTR_MEM_ENCRYPT:
+ return sme_me_mask;
+
+ case CC_ATTR_HOST_MEM_ENCRYPT:
+ return sme_me_mask && !(sev_status & MSR_AMD64_SEV_ENABLED);
+
+ case CC_ATTR_GUEST_MEM_ENCRYPT:
+ return sev_status & MSR_AMD64_SEV_ENABLED;
+
+ case CC_ATTR_GUEST_STATE_ENCRYPT:
+ return sev_status & MSR_AMD64_SEV_ES_ENABLED;
+
+ default:
+ return false;
+ }
+#else
+ return false;
+#endif
+}
+
+
+bool cc_platform_has(enum cc_attr attr)
+{
+ if (sme_me_mask)
+ return amd_cc_platform_has(attr);
+
+ return false;
+}
+EXPORT_SYMBOL_GPL(cc_platform_has);
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index ff08dc463634..e29b1418d00c 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -20,6 +20,7
[PATCH 1/8] x86/ioremap: Selectively build arch override encryption functions
From: Tom Lendacky
In preparation for other uses of the cc_platform_has() function
besides AMD's memory encryption support, selectively build the
AMD memory encryption architecture override functions only when
CONFIG_AMD_MEM_ENCRYPT=y. These functions are:
- early_memremap_pgprot_adjust()
- arch_memremap_can_ram_remap()
Additionally, routines that are only invoked by these architecture
override functions can also be conditionally built. These functions are:
- memremap_should_map_decrypted()
- memremap_is_efi_data()
- memremap_is_setup_data()
- early_memremap_is_setup_data()
And finally, phys_mem_access_encrypted() is conditionally built as well,
but requires a static inline version of it when CONFIG_AMD_MEM_ENCRYPT is
not set.
Signed-off-by: Tom Lendacky
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/io.h | 8
arch/x86/mm/ioremap.c | 2 +-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 841a5d104afa..5c6a4af0b911 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -391,6 +391,7 @@ extern void arch_io_free_memtype_wc(resource_size_t start,
resource_size_t size)
#define arch_io_reserve_memtype_wc arch_io_reserve_memtype_wc
#endif
+#ifdef CONFIG_AMD_MEM_ENCRYPT
extern bool arch_memremap_can_ram_remap(resource_size_t offset,
unsigned long size,
unsigned long flags);
@@ -398,6 +399,13 @@ extern bool arch_memremap_can_ram_remap(resource_size_t
offset,
extern bool phys_mem_access_encrypted(unsigned long phys_addr,
unsigned long size);
+#else
+static inline bool phys_mem_access_encrypted(unsigned long phys_addr,
+unsigned long size)
+{
+ return true;
+}
+#endif
/**
* iosubmit_cmds512 - copy data to single MMIO location, in 512-bit units
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 60ade7dd71bd..ccff76cedd8f 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -508,6 +508,7 @@ void unxlate_dev_mem_ptr(phys_addr_t phys, void *addr)
memunmap((void *)((unsigned long)addr & PAGE_MASK));
}
+#ifdef CONFIG_AMD_MEM_ENCRYPT
/*
* Examine the physical address to determine if it is an area of memory
* that should be mapped decrypted. If the memory is not part of the
@@ -746,7 +747,6 @@ bool phys_mem_access_encrypted(unsigned long phys_addr,
unsigned long size)
return arch_memremap_can_ram_remap(phys_addr, size, 0);
}
-#ifdef CONFIG_AMD_MEM_ENCRYPT
/* Remap memory with encryption */
void __init *early_memremap_encrypted(resource_size_t phys_addr,
unsigned long size)
--
2.29.2
[PATCH v4 0/8] Implement generic cc_platform_has() helper function
From: Borislav Petkov Hi all, here's v4 of the cc_platform_has() patchset with feedback incorporated. I'm going to route this through tip if there are no objections. Thx. Tom Lendacky (8): x86/ioremap: Selectively build arch override encryption functions arch/cc: Introduce a function to check for confidential computing features x86/sev: Add an x86 version of cc_platform_has() powerpc/pseries/svm: Add a powerpc version of cc_platform_has() x86/sme: Replace occurrences of sme_active() with cc_platform_has() x86/sev: Replace occurrences of sev_active() with cc_platform_has() x86/sev: Replace occurrences of sev_es_active() with cc_platform_has() treewide: Replace the use of mem_encrypt_active() with cc_platform_has() arch/Kconfig | 3 + arch/powerpc/include/asm/mem_encrypt.h | 5 -- arch/powerpc/platforms/pseries/Kconfig | 1 + arch/powerpc/platforms/pseries/Makefile | 2 + arch/powerpc/platforms/pseries/cc_platform.c | 26 ++ arch/powerpc/platforms/pseries/svm.c | 5 +- arch/s390/include/asm/mem_encrypt.h | 2 - arch/x86/Kconfig | 1 + arch/x86/include/asm/io.h| 8 ++ arch/x86/include/asm/kexec.h | 2 +- arch/x86/include/asm/mem_encrypt.h | 12 +-- arch/x86/kernel/Makefile | 6 ++ arch/x86/kernel/cc_platform.c| 69 +++ arch/x86/kernel/crash_dump_64.c | 4 +- arch/x86/kernel/head64.c | 9 +- arch/x86/kernel/kvm.c| 3 +- arch/x86/kernel/kvmclock.c | 4 +- arch/x86/kernel/machine_kexec_64.c | 19 +++-- arch/x86/kernel/pci-swiotlb.c| 9 +- arch/x86/kernel/relocate_kernel_64.S | 2 +- arch/x86/kernel/sev.c| 6 +- arch/x86/kvm/svm/svm.c | 3 +- arch/x86/mm/ioremap.c| 18 ++-- arch/x86/mm/mem_encrypt.c| 55 arch/x86/mm/mem_encrypt_identity.c | 9 +- arch/x86/mm/pat/set_memory.c | 3 +- arch/x86/platform/efi/efi_64.c | 9 +- arch/x86/realmode/init.c | 8 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 +- drivers/gpu/drm/drm_cache.c | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 6 +- drivers/iommu/amd/init.c | 7 +- drivers/iommu/amd/iommu.c| 3 +- drivers/iommu/amd/iommu_v2.c | 3 +- drivers/iommu/iommu.c| 3 +- fs/proc/vmcore.c | 6 +- include/linux/cc_platform.h | 88 include/linux/mem_encrypt.h | 4 - kernel/dma/swiotlb.c | 4 +- 40 files changed, 310 insertions(+), 129 deletions(-) create mode 100644 arch/powerpc/platforms/pseries/cc_platform.c create mode 100644 arch/x86/kernel/cc_platform.c create mode 100644 include/linux/cc_platform.h -- 2.29.2
[PATCH 2/8] arch/cc: Introduce a function to check for confidential computing features
From: Tom Lendacky
In preparation for other confidential computing technologies, introduce
a generic helper function, cc_platform_has(), that can be used to
check for specific active confidential computing attributes, like
memory encryption. This is intended to eliminate having to add multiple
technology-specific checks to the code (e.g. if (sev_active() ||
tdx_active() || ... ).
[ bp: s/_CC_PLATFORM_H/_LINUX_CC_PLATFORM_H/g ]
Co-developed-by: Andi Kleen
Signed-off-by: Andi Kleen
Co-developed-by: Kuppuswamy Sathyanarayanan
Signed-off-by: Kuppuswamy Sathyanarayanan
Signed-off-by: Tom Lendacky
Signed-off-by: Borislav Petkov
---
arch/Kconfig| 3 ++
include/linux/cc_platform.h | 88 +
2 files changed, 91 insertions(+)
create mode 100644 include/linux/cc_platform.h
diff --git a/arch/Kconfig b/arch/Kconfig
index 8df1c7102643..d1e69d6e8498 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1234,6 +1234,9 @@ config RELR
config ARCH_HAS_MEM_ENCRYPT
bool
+config ARCH_HAS_CC_PLATFORM
+ bool
+
config HAVE_SPARSE_SYSCALL_NR
bool
help
diff --git a/include/linux/cc_platform.h b/include/linux/cc_platform.h
new file mode 100644
index ..a075b70b9a70
--- /dev/null
+++ b/include/linux/cc_platform.h
@@ -0,0 +1,88 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Confidential Computing Platform Capability checks
+ *
+ * Copyright (C) 2021 Advanced Micro Devices, Inc.
+ *
+ * Author: Tom Lendacky
+ */
+
+#ifndef _LINUX_CC_PLATFORM_H
+#define _LINUX_CC_PLATFORM_H
+
+#include
+#include
+
+/**
+ * enum cc_attr - Confidential computing attributes
+ *
+ * These attributes represent confidential computing features that are
+ * currently active.
+ */
+enum cc_attr {
+ /**
+* @CC_ATTR_MEM_ENCRYPT: Memory encryption is active
+*
+* The platform/OS is running with active memory encryption. This
+* includes running either as a bare-metal system or a hypervisor
+* and actively using memory encryption or as a guest/virtual machine
+* and actively using memory encryption.
+*
+* Examples include SME, SEV and SEV-ES.
+*/
+ CC_ATTR_MEM_ENCRYPT,
+
+ /**
+* @CC_ATTR_HOST_MEM_ENCRYPT: Host memory encryption is active
+*
+* The platform/OS is running as a bare-metal system or a hypervisor
+* and actively using memory encryption.
+*
+* Examples include SME.
+*/
+ CC_ATTR_HOST_MEM_ENCRYPT,
+
+ /**
+* @CC_ATTR_GUEST_MEM_ENCRYPT: Guest memory encryption is active
+*
+* The platform/OS is running as a guest/virtual machine and actively
+* using memory encryption.
+*
+* Examples include SEV and SEV-ES.
+*/
+ CC_ATTR_GUEST_MEM_ENCRYPT,
+
+ /**
+* @CC_ATTR_GUEST_STATE_ENCRYPT: Guest state encryption is active
+*
+* The platform/OS is running as a guest/virtual machine and actively
+* using memory encryption and register state encryption.
+*
+* Examples include SEV-ES.
+*/
+ CC_ATTR_GUEST_STATE_ENCRYPT,
+};
+
+#ifdef CONFIG_ARCH_HAS_CC_PLATFORM
+
+/**
+ * cc_platform_has() - Checks if the specified cc_attr attribute is active
+ * @attr: Confidential computing attribute to check
+ *
+ * The cc_platform_has() function will return an indicator as to whether the
+ * specified Confidential Computing attribute is currently active.
+ *
+ * Context: Any context
+ * Return:
+ * * TRUE - Specified Confidential Computing attribute is active
+ * * FALSE - Specified Confidential Computing attribute is not active
+ */
+bool cc_platform_has(enum cc_attr attr);
+
+#else /* !CONFIG_ARCH_HAS_CC_PLATFORM */
+
+static inline bool cc_platform_has(enum cc_attr attr) { return false; }
+
+#endif /* CONFIG_ARCH_HAS_CC_PLATFORM */
+
+#endif /* _LINUX_CC_PLATFORM_H */
--
2.29.2
Re: [PATCH] drm/bridge: Add stubs for devm_drm_of_get_bridge when OF is disabled
On 9/28/21 11:13 AM, Maxime Ripard wrote:
If CONFIG_OF is disabled, devm_drm_of_get_bridge won't be compiled in
and drivers using that function will fail to build.
Add an inline stub so that we can still build-test those cases.
Reported-by: Randy Dunlap
Signed-off-by: Maxime Ripard
Acked-by: Randy Dunlap # build-tested
Thanks.
---
include/drm/drm_bridge.h | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 9cdbd209388e..1648ce265cba 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -911,9 +911,20 @@ struct drm_bridge *devm_drm_panel_bridge_add(struct device
*dev,
struct drm_bridge *devm_drm_panel_bridge_add_typed(struct device *dev,
struct drm_panel *panel,
u32 connector_type);
+struct drm_connector *drm_panel_bridge_connector(struct drm_bridge *bridge);
+#endif
+
+#if defined(CONFIG_OF) && defined(CONFIG_DRM_PANEL_BRIDGE)
struct drm_bridge *devm_drm_of_get_bridge(struct device *dev, struct
device_node *node,
u32 port, u32 endpoint);
-struct drm_connector *drm_panel_bridge_connector(struct drm_bridge *bridge);
+#else
+static inline struct drm_bridge *devm_drm_of_get_bridge(struct device *dev,
+ struct device_node
*node,
+ u32 port,
+ u32 endpoint)
+{
+ return ERR_PTR(-ENODEV);
+}
#endif
#endif
--
~Randy
[PATCH] drm/bridge: Add stubs for devm_drm_of_get_bridge when OF is disabled
If CONFIG_OF is disabled, devm_drm_of_get_bridge won't be compiled in
and drivers using that function will fail to build.
Add an inline stub so that we can still build-test those cases.
Reported-by: Randy Dunlap
Signed-off-by: Maxime Ripard
---
include/drm/drm_bridge.h | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 9cdbd209388e..1648ce265cba 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -911,9 +911,20 @@ struct drm_bridge *devm_drm_panel_bridge_add(struct device
*dev,
struct drm_bridge *devm_drm_panel_bridge_add_typed(struct device *dev,
struct drm_panel *panel,
u32 connector_type);
+struct drm_connector *drm_panel_bridge_connector(struct drm_bridge *bridge);
+#endif
+
+#if defined(CONFIG_OF) && defined(CONFIG_DRM_PANEL_BRIDGE)
struct drm_bridge *devm_drm_of_get_bridge(struct device *dev, struct
device_node *node,
u32 port, u32 endpoint);
-struct drm_connector *drm_panel_bridge_connector(struct drm_bridge *bridge);
+#else
+static inline struct drm_bridge *devm_drm_of_get_bridge(struct device *dev,
+ struct device_node
*node,
+ u32 port,
+ u32 endpoint)
+{
+ return ERR_PTR(-ENODEV);
+}
#endif
#endif
--
2.31.1
Re: [Freedreno] [PATCH v2 00/13] drm/hdcp: Pull HDCP auth/exchange/check into helpers
On Tue, Sep 21, 2021 at 07:30:29PM -0700, abhin...@codeaurora.org wrote: > Hi Sean > > On 2021-09-15 13:38, Sean Paul wrote: > > From: Sean Paul > > > > Hello again, > > This is the second version of the HDCP helper patchset. See version 1 > > here: https://patchwork.freedesktop.org/series/94623/ > > > > In this second version, I've fixed up the oopsies exposed by 0-day and > > yamllint and incorporated early review feedback from the dt/dts reviews. > > > > Please take a look, > > > > Sean > > One question overall on the series: > > 1) Regarding validation, did you run any secure video to check the > transitions? Yep, the transitions look good, no visual artifacts. Unplug/replug/suspend/resume all seem to be behaving as expected. > 2) Is running HDCP 1x compliance also part of the validation efforts? If Qualcomm has the ability to run validation, I'd be very keen to get some help in that regard. Sean > > Thanks > > Abhinav > > > > > Sean Paul (13): > > drm/hdcp: Add drm_hdcp_atomic_check() > > drm/hdcp: Avoid changing crtc state in hdcp atomic check > > drm/hdcp: Update property value on content type and user changes > > drm/hdcp: Expand HDCP helper library for enable/disable/check > > drm/i915/hdcp: Consolidate HDCP setup/state cache > > drm/i915/hdcp: Retain hdcp_capable return codes > > drm/i915/hdcp: Use HDCP helpers for i915 > > drm/msm/dpu_kms: Re-order dpu includes > > drm/msm/dpu: Remove useless checks in dpu_encoder > > drm/msm/dpu: Remove encoder->enable() hack > > drm/msm/dp: Re-order dp_audio_put in deinit_sub_modules > > dt-bindings: msm/dp: Add bindings for HDCP registers > > drm/msm: Implement HDCP 1.x using the new drm HDCP helpers > > > > .../bindings/display/msm/dp-controller.yaml |7 +- > > arch/arm64/boot/dts/qcom/sc7180.dtsi |4 +- > > drivers/gpu/drm/drm_hdcp.c| 1197 - > > drivers/gpu/drm/i915/display/intel_atomic.c |7 +- > > drivers/gpu/drm/i915/display/intel_ddi.c | 29 +- > > .../drm/i915/display/intel_display_debugfs.c | 11 +- > > .../drm/i915/display/intel_display_types.h| 58 +- > > drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 345 ++--- > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 17 +- > > drivers/gpu/drm/i915/display/intel_hdcp.c | 1011 +++--- > > drivers/gpu/drm/i915/display/intel_hdcp.h | 35 +- > > drivers/gpu/drm/i915/display/intel_hdmi.c | 256 ++-- > > drivers/gpu/drm/msm/Makefile |1 + > > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 17 +- > > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 30 +- > > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h |2 - > > drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h |4 - > > drivers/gpu/drm/msm/dp/dp_debug.c | 49 +- > > drivers/gpu/drm/msm/dp/dp_debug.h |6 +- > > drivers/gpu/drm/msm/dp/dp_display.c | 47 +- > > drivers/gpu/drm/msm/dp/dp_display.h |5 + > > drivers/gpu/drm/msm/dp/dp_drm.c | 68 +- > > drivers/gpu/drm/msm/dp/dp_drm.h |5 + > > drivers/gpu/drm/msm/dp/dp_hdcp.c | 433 ++ > > drivers/gpu/drm/msm/dp/dp_hdcp.h | 27 + > > drivers/gpu/drm/msm/dp/dp_parser.c| 22 +- > > drivers/gpu/drm/msm/dp/dp_parser.h|4 + > > drivers/gpu/drm/msm/dp/dp_reg.h | 44 +- > > drivers/gpu/drm/msm/msm_atomic.c | 15 + > > include/drm/drm_hdcp.h| 194 +++ > > 30 files changed, 2561 insertions(+), 1389 deletions(-) > > create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.c > > create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.h -- Sean Paul, Software Engineer, Google / Chromium OS
Re: [Freedreno] [PATCH v2 13/13] drm/msm: Implement HDCP 1.x using the new drm HDCP helpers
On Tue, Sep 21, 2021 at 07:25:41PM -0700, abhin...@codeaurora.org wrote:
> On 2021-09-15 13:38, Sean Paul wrote:
> > From: Sean Paul
> >
> > This patch adds HDCP 1.x support to msm DP connectors using the new HDCP
> > helpers.
> >
> > Cc: Stephen Boyd
> > Signed-off-by: Sean Paul
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-15-s...@poorly.run
> > #v1
> >
> > Changes in v2:
> > -Squash [1] into this patch with the following changes (Stephen)
> > -Update the sc7180 dtsi file
> > -Remove resource names and just use index (Stephen)
> >
>
>
> > [1]
> > https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-14-s...@poorly.run
> > ---
/snip
> > diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
> > index 904535eda0c4..98731fd262d6 100644
> > --- a/drivers/gpu/drm/msm/Makefile
> > +++ b/drivers/gpu/drm/msm/Makefile
> > @@ -109,6 +109,7 @@ msm-$(CONFIG_DRM_MSM_DP)+= dp/dp_aux.o \
> > dp/dp_ctrl.o \
> > dp/dp_display.o \
> > dp/dp_drm.o \
> > + dp/dp_hdcp.o \
> > dp/dp_hpd.o \
> > dp/dp_link.o \
> > dp/dp_panel.o \
> > diff --git a/drivers/gpu/drm/msm/dp/dp_debug.c
> > b/drivers/gpu/drm/msm/dp/dp_debug.c
> > index 2f6247e80e9d..de16fca8782a 100644
> > --- a/drivers/gpu/drm/msm/dp/dp_debug.c
> > +++ b/drivers/gpu/drm/msm/dp/dp_debug.c
/snip
> > +static ssize_t dp_hdcp_key_write(struct file *file, const char __user
> > *ubuf,
> > +size_t len, loff_t *offp)
> > +{
> > + char *input_buffer;
> > + int ret = 0;
> > + struct dp_debug_private *debug = file->private_data;
> > + struct drm_device *dev;
> > +
> > + dev = debug->drm_dev;
> > +
> > + if (len != (DRM_HDCP_KSV_LEN + DP_HDCP_NUM_KEYS * DP_HDCP_KEY_LEN))
> > + return -EINVAL;
> > +
> > + if (!debug->hdcp)
> > + return -ENOENT;
> > +
> > + input_buffer = memdup_user_nul(ubuf, len);
> > + if (IS_ERR(input_buffer))
> > + return PTR_ERR(input_buffer);
> > +
> > + ret = dp_hdcp_ingest_key(debug->hdcp, input_buffer, len);
> > +
> > + kfree(input_buffer);
> > + if (ret < 0) {
> > + DRM_ERROR("Could not ingest HDCP key, ret=%d\n", ret);
> > + return ret;
> > + }
> > +
> > + *offp += len;
> > + return len;
> > +}
>
> It seems like the HDCP keys written using debugfs, just for my
> understanding,
> are you storing this in some secure partition and the usermode reads from it
> and writes them here?
>
We have not sorted out the userspace side of HDCP enablement yet, so it remains
to be seen whether the keys will be injected via debugfs/firmware file/property.
/snip
> > +static int dp_connector_atomic_check(struct drm_connector *connector,
> > +struct drm_atomic_state *state)
> > +{
> > + struct drm_connector_state *conn_state;
> > + struct dp_connector_state *dp_state;
> > +
> > + conn_state = drm_atomic_get_new_connector_state(state, connector);
> > + dp_state = to_dp_connector_state(conn_state);
> > +
> > + dp_state->hdcp_transition = drm_hdcp_atomic_check(connector, state);
>
> I have a general question related to the transition flag and overall tying
> the HDCP
> enable and authentication to the commit.
> So lets say there is a case where the driver needs to disable HDCP. It could
> be due
> to link integrity failure OR some other error condition which usermode is
> not aware of.
> In that case, we will set this hdcp_transition to true but in the next
> commit we will
> actually do the authentication. What if usermode doesnt issue a new frame?
> This question arises because currently the link intergrity check is done
> using SW polling
> in the previous patchset. But as I had commented there, this occurs in HW
> for us.
> I dont see that isr itself in this patchset. So wanted to understand if
> thats part of this
> approach to still tie it with commit.
>
> So if we go with the HW polling based approach which is the preferred
> method, we need to
> untie this from the commit.
>
In the case of error, the worker will detect it and try to re-authenticate. If
the re-authentication is successful, userspace will continue to be unaware and
everything will keep working. If re-authentication is unsuccessful, the worker
will update the property value and issue a uevent to userspace. So HDCP
enablement is only tied to commits when the property value is changing as a
result of userspace.
Regarding SW vs HW link checks, I don't think there's any difference in efficacy
between them. If HW can be relied on to issue an interrupt in failure cases, a
follow-up set allowing for this seems like a great idea.
> > +
> > + return 0;
> > +}
/snip
> > +static int dp_hdcp_load_keys(struct drm_connector *connector)
> > +{
> > + struct dp_hdcp *hdcp = dp_display_connector_to_hdcp(connector);
> > + struct dp_hdcp_key *key;
> > + int i, ret = 0;
> > +
> > + mutex_lock(>key_lock);
> > +
> > + key = hdcp->key;
> > +
> > +
RE: [PATCH v2] drm/amd/display: Only define DP 2.0 symbols if not already defined
[AMD Official Use Only]
> -Original Message-
> From: Harry Wentland
> Sent: September 28, 2021 1:08 PM
> To: Deucher, Alexander ; amd-
> g...@lists.freedesktop.org; Zuo, Jerry
> Cc: jani.nik...@intel.com; Li, Sun peng (Leo) ;
> nat...@kernel.org; intel-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; ville.syrj...@linux.intel.com;
> manasi.d.nav...@intel.com; Koenig, Christian ;
> Pan, Xinhui ; s...@canb.auug.org.au; linux-
> n...@vger.kernel.org; airl...@gmail.com; daniel.vet...@ffwll.ch; Wentland,
> Harry
> Subject: [PATCH v2] drm/amd/display: Only define DP 2.0 symbols if not
> already defined
>
> [Why]
> For some reason we're defining DP 2.0 definitions inside our driver. Now that
> patches to introduce relevant definitions are slated to be merged into drm-
> next this is causing conflicts.
>
> In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:33:
> In file included
> from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:70:
> In file included
> from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu_mode.h:36:
> ./include/drm/drm_dp_helper.h:1322:9: error:
> 'DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER' macro redefined [-
> Werror,-Wmacro-redefined]
> ^
> ./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: note:
> previous definition is here
> ^
> 1 error generated.
>
> v2: Add one missing endif
>
> [How]
> Guard all display driver defines with #ifndef for now. Once we pull in the new
> definitions into amd-staging-drm-next we will follow up and drop definitions
> from our driver and provide follow-up header updates for any addition DP
> 2.0 definitions required by our driver.
>
> Signed-off-by: Harry Wentland
Reviewed-by: Fangzhi Zuo
> ---
> drivers/gpu/drm/amd/display/dc/dc_dp_types.h | 54
> ++--
> 1 file changed, 49 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
> b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
> index a5e798b5da79..9de86ff5ef1b 100644
> --- a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
> +++ b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
> @@ -860,28 +860,72 @@ struct psr_caps {
> };
>
> #if defined(CONFIG_DRM_AMD_DC_DCN)
> +#ifndef DP_MAIN_LINK_CHANNEL_CODING_CAP
> #define DP_MAIN_LINK_CHANNEL_CODING_CAP 0x006
> +#endif
> +#ifndef DP_SINK_VIDEO_FALLBACK_FORMATS
> #define DP_SINK_VIDEO_FALLBACK_FORMATS 0x020
> +#endif
> +#ifndef DP_FEC_CAPABILITY_1
> #define DP_FEC_CAPABILITY_1 0x091
> +#endif
> +#ifndef DP_DFP_CAPABILITY_EXTENSION_SUPPORT
> #define DP_DFP_CAPABILITY_EXTENSION_SUPPORT 0x0A3
> +#endif
> +#ifndef DP_DSC_CONFIGURATION
> #define DP_DSC_CONFIGURATION 0x161
> +#endif
> +#ifndef DP_PHY_SQUARE_PATTERN
> #define DP_PHY_SQUARE_PATTERN0x249
> +#endif
> +#ifndef DP_128b_132b_SUPPORTED_LINK_RATES
> #define DP_128b_132b_SUPPORTED_LINK_RATES0x2215
> +#endif
> +#ifndef DP_128b_132b_TRAINING_AUX_RD_INTERVAL
> #define DP_128b_132b_TRAINING_AUX_RD_INTERVAL
> 0x2216
> +#endif
> +#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_7_0
> #define DP_TEST_264BIT_CUSTOM_PATTERN_7_00X2230
> +#endif
> +#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_263_256
> #define DP_TEST_264BIT_CUSTOM_PATTERN_263_256
> 0X2250
> +#endif
> +#ifndef DP_DSC_SUPPORT_AND_DECODER_COUNT
> #define DP_DSC_SUPPORT_AND_DECODER_COUNT 0x2260
> +#endif
> +#ifndef DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0
> #define DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0
> 0x2270
> -# define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK (1 <<
> 0)
> -# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK
> (0b111 << 1)
> -# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT 1
> -# define DP_DSC_DECODER_COUNT_MASK (0b111 << 5)
> -# define DP_DSC_DECODER_COUNT_SHIFT 5
> +#endif
> +#ifndef DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK
> +#define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK(1 <<
> 0)
> +#endif
> +#ifndef DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK
> +#define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK
> (0b111 << 1)
> +#endif
> +#ifndef DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT
> +#define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT 1
> +#endif
> +#ifndef DP_DSC_DECODER_COUNT_MASK
> +#define DP_DSC_DECODER_COUNT_MASK(0b111 << 5)
> +#endif
> +#ifndef DP_DSC_DECODER_COUNT_SHIFT
> +#define DP_DSC_DECODER_COUNT_SHIFT 5
> +#endif
> +#ifndef DP_MAIN_LINK_CHANNEL_CODING_SET
> #define DP_MAIN_LINK_CHANNEL_CODING_SET 0x108
> +#endif
> +#ifndef DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER
> #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
> +#endif
> +#ifndef DP_PHY_REPEATER_128b_132b_RATES
> #define DP_PHY_REPEATER_128b_132b_RATES
> 0xF0007
> +#endif
> +#ifndef DP_128b_132b_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1
> #define
Re: [PATCH v6 2/2] habanalabs: add support for dma-buf exporter
On Sun, Sep 12, 2021 at 07:53:09PM +0300, Oded Gabbay wrote:
> From: Tomer Tayar
>
> Implement the calls to the dma-buf kernel api to create a dma-buf
> object backed by FD.
>
> We block the option to mmap the DMA-BUF object because we don't support
> DIRECT_IO and implicit P2P.
This statement doesn't make sense, you can mmap your dmabuf if you
like. All dmabuf mmaps are supposed to set the special bit/etc to
exclude them from get_user_pages() anyhow - and since this is BAR
memory not struct page memory this driver would be doing it anyhow.
> We check the p2p distance using pci_p2pdma_distance_many() and refusing
> to map dmabuf in case the distance doesn't allow p2p.
Does this actually allow the p2p transfer for your intended use cases?
> diff --git a/drivers/misc/habanalabs/common/memory.c
> b/drivers/misc/habanalabs/common/memory.c
> index 33986933aa9e..8cf5437c0390 100644
> +++ b/drivers/misc/habanalabs/common/memory.c
> @@ -1,7 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0
>
> /*
> - * Copyright 2016-2019 HabanaLabs, Ltd.
> + * Copyright 2016-2021 HabanaLabs, Ltd.
> * All Rights Reserved.
> */
>
> @@ -11,11 +11,13 @@
>
> #include
> #include
> +#include
>
> #define HL_MMU_DEBUG 0
>
> /* use small pages for supporting non-pow2 (32M/40M/48M) DRAM phys page
> sizes */
> -#define DRAM_POOL_PAGE_SIZE SZ_8M
> +#define DRAM_POOL_PAGE_SIZE SZ_8M
> +
??
> /*
> * The va ranges in context object contain a list with the available chunks
> of
> @@ -347,6 +349,13 @@ static int free_device_memory(struct hl_ctx *ctx, struct
> hl_mem_in *args)
> return -EINVAL;
> }
>
> + if (phys_pg_pack->exporting_cnt) {
> + dev_err(hdev->dev,
> + "handle %u is exported, cannot free\n", handle);
> + spin_unlock(>idr_lock);
Don't write to the kernel log from user space triggered actions
> +static int alloc_sgt_from_device_pages(struct hl_device *hdev,
> + struct sg_table **sgt, u64 *pages,
> + u64 npages, u64 page_size,
> + struct device *dev,
> + enum dma_data_direction dir)
Why doesn't this return a sg_table * and an ERR_PTR?
> +{
> + u64 chunk_size, bar_address, dma_max_seg_size;
> + struct asic_fixed_properties *prop;
> + int rc, i, j, nents, cur_page;
> + struct scatterlist *sg;
> +
> + prop = >asic_prop;
> +
> + dma_max_seg_size = dma_get_max_seg_size(dev);
> +
> + /* We would like to align the max segment size to PAGE_SIZE, so the
> + * SGL will contain aligned addresses that can be easily mapped to
> + * an MMU
> + */
> + dma_max_seg_size = ALIGN_DOWN(dma_max_seg_size, PAGE_SIZE);
> + if (dma_max_seg_size < PAGE_SIZE) {
> + dev_err_ratelimited(hdev->dev,
> + "dma_max_seg_size %llu can't be smaller than
> PAGE_SIZE\n",
> + dma_max_seg_size);
> + return -EINVAL;
> + }
> +
> + *sgt = kzalloc(sizeof(**sgt), GFP_KERNEL);
> + if (!*sgt)
> + return -ENOMEM;
> +
> + /* If the size of each page is larger than the dma max segment size,
> + * then we can't combine pages and the number of entries in the SGL
> + * will just be the
> + * *
> + */
> + if (page_size > dma_max_seg_size)
> + nents = npages * DIV_ROUND_UP_ULL(page_size, dma_max_seg_size);
> + else
> + /* Get number of non-contiguous chunks */
> + for (i = 1, nents = 1, chunk_size = page_size ; i < npages ;
> i++) {
> + if (pages[i - 1] + page_size != pages[i] ||
> + chunk_size + page_size >
> dma_max_seg_size) {
> + nents++;
> + chunk_size = page_size;
> + continue;
> + }
> +
> + chunk_size += page_size;
> + }
> +
> + rc = sg_alloc_table(*sgt, nents, GFP_KERNEL | __GFP_ZERO);
> + if (rc)
> + goto error_free;
> +
> + /* Because we are not going to include a CPU list we want to have some
> + * chance that other users will detect this by setting the orig_nents
> + * to 0 and using only nents (length of DMA list) when going over the
> + * sgl
> + */
> + (*sgt)->orig_nents = 0;
Maybe do this at the end so you'd have to undo it on the error path?
> + cur_page = 0;
> +
> + if (page_size > dma_max_seg_size) {
> + u64 size_left, cur_device_address = 0;
> +
> + size_left = page_size;
> +
> + /* Need to split each page into the number of chunks of
> + * dma_max_seg_size
> + */
> + for_each_sgtable_dma_sg((*sgt), sg, i) {
> +
Re: [Freedreno] [PATCH v2 04/13] drm/hdcp: Expand HDCP helper library for enable/disable/check
On Tue, Sep 21, 2021 at 04:34:59PM -0700, abhin...@codeaurora.org wrote:
> On 2021-09-15 13:38, Sean Paul wrote:
> > From: Sean Paul
> >
> > This patch expands upon the HDCP helper library to manage HDCP
> > enable, disable, and check.
> >
> > Previous to this patch, the majority of the state management and sink
> > interaction is tucked inside the Intel driver with the understanding
> > that once a new platform supported HDCP we could make good decisions
> > about what should be centralized. With the addition of HDCP support
> > for Qualcomm, it's time to migrate the protocol-specific bits of HDCP
> > authentication, key exchange, and link checks to the HDCP helper.
> >
> > In terms of functionality, this migration is 1:1 with the Intel driver,
> > however things are laid out a bit differently than with intel_hdcp.c,
> > which is why this is a separate patch from the i915 transition to the
> > helper. On i915, the "shim" vtable is used to account for HDMI vs. DP
> > vs. DP-MST differences whereas the helper library uses a LUT to
> > account for the register offsets and a remote read function to route
> > the messages. On i915, storing the sink information in the source is
> > done inline whereas now we use the new drm_hdcp_helper_funcs vtable
> > to store and fetch information to/from source hw. Finally, instead of
> > calling enable/disable directly from the driver, we'll leave that
> > decision to the helper and by calling drm_hdcp_helper_atomic_commit()
> > from the driver. All told, this will centralize the protocol and state
> > handling in the helper, ensuring we collect all of our bugs^Wlogic
> > in one place.
> >
> > Signed-off-by: Sean Paul
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-5-s...@poorly.run
> > #v1
> >
> > Changes in v2:
> > -Fixed set-but-unused variable identified by 0-day
> > ---
> > drivers/gpu/drm/drm_hdcp.c | 1103
> > include/drm/drm_hdcp.h | 191 +++
> > 2 files changed, 1294 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
> > index 742313ce8f6f..47c6e6923a76 100644
> > --- a/drivers/gpu/drm/drm_hdcp.c
> > +++ b/drivers/gpu/drm/drm_hdcp.c
/snip
> > +static void drm_hdcp_helper_check_work(struct work_struct *work)
> > +{
> > + struct drm_hdcp_helper_data *data =
> > container_of(to_delayed_work(work),
> > +struct
> > drm_hdcp_helper_data,
> > +check_work);
> > + unsigned long check_link_interval;
> > +
>
> Does this SW polling for Ri' mismatch need to be done even if the HW is
> capable of doing it
> on its own?
> MSM HDCP 1x HW can periodically check Ri' mismatches and issue an interrupt
> if there is a mismatch.
> In that case this SW polling is not needed. So maybe check if the HW
> supports polling and if so
> skip this SW polling?
>
One could certainly change this to be HW driven. There is also an interrupt on
Intel for DP links which [re]schedules link check in the interrupt handler,
something similar could be done for msm. Note that even on these Intel links
which support the CP interrupt, the worker still runs on the normal cadence. I
haven't considered relying solely on the interrupt since I want to be sure we
didn't miss anything.
Sean
> > + mutex_lock(>mutex);
> > + if (data->value != DRM_MODE_CONTENT_PROTECTION_ENABLED)
> > + goto out_data_mutex;
> > +
> > + drm_hdcp_helper_driver_lock(data);
> > +
> > + if (data->enabled_type == DRM_MODE_HDCP_CONTENT_TYPE1) {
> > + if (drm_hdcp_hdcp2_check_link(data))
> > + goto out;
> > + check_link_interval = DRM_HDCP2_CHECK_PERIOD_MS;
> > + } else {
> > + if (drm_hdcp_hdcp1_check_link(data))
> > + goto out;
> > + check_link_interval = DRM_HDCP_CHECK_PERIOD_MS;
> > + }
> > + schedule_delayed_work(>check_work, check_link_interval);
> > +
> > +out:
> > + drm_hdcp_helper_driver_unlock(data);
> > +out_data_mutex:
> > + mutex_unlock(>mutex);
> > +}
/snip
--
Sean Paul, Software Engineer, Google / Chromium OS
Re: [PATCH v2 3/5] drm/msm/dp: Support up to 3 DP controllers
On 2021-08-27 10:14, Bjorn Andersson wrote:
On Fri 27 Aug 00:20 CDT 2021, Stephen Boyd wrote:
Quoting Bjorn Andersson (2021-08-25 16:42:31)
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
> index 2c7de43f655a..4a6132c18e57 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -78,6 +78,8 @@ struct dp_display_private {
> char *name;
> int irq;
>
> + int id;
> +
> /* state variables */
> bool core_initialized;
> bool hpd_irq_on;
> @@ -115,8 +117,19 @@ struct dp_display_private {
> struct dp_audio *audio;
> };
>
> +
> +struct msm_dp_config {
> + phys_addr_t io_start[3];
Can this be made into another struct, like msm_dp_desc, that also
indicates what type of DP connector it is, i.e. eDP vs DP? That would
help me understand in modetest and /sys/class/drm what sort of
connector
is probing. dp_drm_connector_init() would need to pass the type of
connector appropriately. Right now, eDP connectors still show up as DP
instead of eDP in sysfs.
I like it, will spin a v3 with this.
Regards,
Bjorn
Hi Bjorn,
Have you spin off V3 yet?
When you expect your patches related to DP be up streamed?
Thanks,
kuogee
> + size_t num_dp;
> +};
> +
> +static const struct msm_dp_config sc7180_dp_cfg = {
> + .io_start = { 0x0ae9 },
> + .num_dp = 1,
> +};
> +
> static const struct of_device_id dp_dt_match[] = {
> - {.compatible = "qcom,sc7180-dp"},
> + { .compatible = "qcom,sc7180-dp", .data = _dp_cfg },
> {}
> };
>
Re: [PATCH v6 1/2] habanalabs: define uAPI to export FD for DMA-BUF
On Sun, Sep 12, 2021 at 07:53:08PM +0300, Oded Gabbay wrote:
> /* HL_MEM_OP_* */
> __u32 op;
> - /* HL_MEM_* flags */
> + /* HL_MEM_* flags.
> + * For the HL_MEM_OP_EXPORT_DMABUF_FD opcode, this field holds the
> + * DMA-BUF file/FD flags.
> + */
> __u32 flags;
> /* Context ID - Currently not in use */
> __u32 ctx_id;
> @@ -1072,6 +1091,13 @@ struct hl_mem_out {
>
> __u32 pad;
> };
> +
> + /* Returned in HL_MEM_OP_EXPORT_DMABUF_FD. Represents the
> + * DMA-BUF object that was created to describe a memory
> + * allocation on the device's memory space. The FD should be
> + * passed to the importer driver
> + */
> + __u64 fd;
fd's should be a s32 type in a fixed width uapi.
I usually expect to see the uapi changes inside the commit that
consumes them, splitting the patch like this seems strange but
harmless.
Jason
[PATCH v2] drm/amd/display: Only define DP 2.0 symbols if not already defined
[Why]
For some reason we're defining DP 2.0 definitions inside our
driver. Now that patches to introduce relevant definitions
are slated to be merged into drm-next this is causing conflicts.
In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:33:
In file included from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:70:
In file included from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu_mode.h:36:
./include/drm/drm_dp_helper.h:1322:9: error:
'DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER' macro redefined
[-Werror,-Wmacro-redefined]
^
./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: note: previous
definition is here
^
1 error generated.
v2: Add one missing endif
[How]
Guard all display driver defines with #ifndef for now. Once we pull
in the new definitions into amd-staging-drm-next we will follow
up and drop definitions from our driver and provide follow-up
header updates for any addition DP 2.0 definitions required
by our driver.
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/amd/display/dc/dc_dp_types.h | 54 ++--
1 file changed, 49 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
index a5e798b5da79..9de86ff5ef1b 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
@@ -860,28 +860,72 @@ struct psr_caps {
};
#if defined(CONFIG_DRM_AMD_DC_DCN)
+#ifndef DP_MAIN_LINK_CHANNEL_CODING_CAP
#define DP_MAIN_LINK_CHANNEL_CODING_CAP0x006
+#endif
+#ifndef DP_SINK_VIDEO_FALLBACK_FORMATS
#define DP_SINK_VIDEO_FALLBACK_FORMATS 0x020
+#endif
+#ifndef DP_FEC_CAPABILITY_1
#define DP_FEC_CAPABILITY_10x091
+#endif
+#ifndef DP_DFP_CAPABILITY_EXTENSION_SUPPORT
#define DP_DFP_CAPABILITY_EXTENSION_SUPPORT0x0A3
+#endif
+#ifndef DP_DSC_CONFIGURATION
#define DP_DSC_CONFIGURATION 0x161
+#endif
+#ifndef DP_PHY_SQUARE_PATTERN
#define DP_PHY_SQUARE_PATTERN 0x249
+#endif
+#ifndef DP_128b_132b_SUPPORTED_LINK_RATES
#define DP_128b_132b_SUPPORTED_LINK_RATES 0x2215
+#endif
+#ifndef DP_128b_132b_TRAINING_AUX_RD_INTERVAL
#define DP_128b_132b_TRAINING_AUX_RD_INTERVAL 0x2216
+#endif
+#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_7_0
#define DP_TEST_264BIT_CUSTOM_PATTERN_7_0 0X2230
+#endif
+#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_263_256
#define DP_TEST_264BIT_CUSTOM_PATTERN_263_256 0X2250
+#endif
+#ifndef DP_DSC_SUPPORT_AND_DECODER_COUNT
#define DP_DSC_SUPPORT_AND_DECODER_COUNT 0x2260
+#endif
+#ifndef DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0
#define DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0 0x2270
-# define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK (1 << 0)
-# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK (0b111 << 1)
-# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT1
-# define DP_DSC_DECODER_COUNT_MASK (0b111 << 5)
-# define DP_DSC_DECODER_COUNT_SHIFT5
+#endif
+#ifndef DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK
+#define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK (1 << 0)
+#endif
+#ifndef DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK
+#define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK (0b111 << 1)
+#endif
+#ifndef DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT
+#define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT 1
+#endif
+#ifndef DP_DSC_DECODER_COUNT_MASK
+#define DP_DSC_DECODER_COUNT_MASK (0b111 << 5)
+#endif
+#ifndef DP_DSC_DECODER_COUNT_SHIFT
+#define DP_DSC_DECODER_COUNT_SHIFT 5
+#endif
+#ifndef DP_MAIN_LINK_CHANNEL_CODING_SET
#define DP_MAIN_LINK_CHANNEL_CODING_SET0x108
+#endif
+#ifndef DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER
#define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+#endif
+#ifndef DP_PHY_REPEATER_128b_132b_RATES
#define DP_PHY_REPEATER_128b_132b_RATES0xF0007
+#endif
+#ifndef DP_128b_132b_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1
#define DP_128b_132b_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER10xF0022
+#endif
+#ifndef DP_INTRA_HOP_AUX_REPLY_INDICATION
#define DP_INTRA_HOP_AUX_REPLY_INDICATION (1 << 3)
+#endif
/* TODO - Use DRM header to replace above once available */
union dp_main_line_channel_coding_cap {
--
2.33.0
Re: [PATCH v5 2/2] drm/bridge: ti-sn65dsi86: Implement the pwm_chip
On Sat 25 Sep 16:25 CDT 2021, Uwe Kleine-K?nig wrote:
> Hello Bjorn,
>
> On Fri, Sep 24, 2021 at 05:04:41PM -0500, Bjorn Andersson wrote:
> > On Fri 24 Sep 02:54 CDT 2021, Uwe Kleine-K?nig wrote:
> > > > +static int ti_sn65dsi86_read_u16(struct ti_sn65dsi86 *pdata,
> > > > +unsigned int reg, u16 *val)
> > > > +{
> > > > + unsigned int tmp;
> > > > + int ret;
> > > > +
> > > > + ret = regmap_read(pdata->regmap, reg, );
> > > > + if (ret)
> > > > + return ret;
> > > > + *val = tmp;
> > > > +
> > > > + ret = regmap_read(pdata->regmap, reg + 1, );
> > > > + if (ret)
> > > > + return ret;
> > > > + *val |= tmp << 8;
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > static void ti_sn65dsi86_write_u16(struct ti_sn65dsi86 *pdata,
> > > >unsigned int reg, u16 val)
> > > > {
> > > > - regmap_write(pdata->regmap, reg, val & 0xFF);
> > > > - regmap_write(pdata->regmap, reg + 1, val >> 8);
> > > > + u8 buf[2] = { val & 0xff, val >> 8 };
> > > > +
> > > > + regmap_bulk_write(pdata->regmap, reg, , ARRAY_SIZE(buf));
> > >
> > > Given that ti_sn65dsi86_write_u16 uses regmap_bulk_write I wonder why
> > > ti_sn65dsi86_read_u16 doesn't use regmap_bulk_read.
> >
> > Seems reasonable to make that use the bulk interface as well and this
> > would look better in its own patch.
>
> Not sure I understand you here. My position here would be to introduce
> these two functions with a consistent behaviour. If both use bulk or
> both don't use it (and you introduce it later in a separate patch)
> doesn't matter to me.
>
We're in agreement :)
> > > > static u32 ti_sn_bridge_get_dsi_freq(struct ti_sn65dsi86 *pdata)
> > > > @@ -253,6 +298,12 @@ static void ti_sn_bridge_set_refclk_freq(struct
> > > > ti_sn65dsi86 *pdata)
> > > >
> > > > regmap_update_bits(pdata->regmap, SN_DPPLL_SRC_REG,
> > > > REFCLK_FREQ_MASK,
> > > >REFCLK_FREQ(i));
> > > > +
> > > > + /*
> > > > +* The PWM refclk is based on the value written to
> > > > SN_DPPLL_SRC_REG,
> > > > +* regardless of its actual sourcing.
> > > > +*/
> > > > + pdata->pwm_refclk_freq = ti_sn_bridge_refclk_lut[i];
> > > > }
> > > >
> > > > static void ti_sn65dsi86_enable_comms(struct ti_sn65dsi86 *pdata)
> > > > @@ -1259,9 +1310,283 @@ static struct auxiliary_driver
> > > > ti_sn_bridge_driver = {
> > > > };
> > > >
> > > > /*
> > > > -
> > > > - * GPIO Controller
> > > > + * PWM Controller
> > > > + */
> > > > +#if defined(CONFIG_PWM)
> > > > +static int ti_sn_pwm_pin_request(struct ti_sn65dsi86 *pdata)
> > > > +{
> > > > + return atomic_xchg(>pwm_pin_busy, 1) ? -EBUSY : 0;
> > > > +}
> > > > +
> > > > +static void ti_sn_pwm_pin_release(struct ti_sn65dsi86 *pdata)
> > > > +{
> > > > + atomic_set(>pwm_pin_busy, 0);
> > > > +}
> > > > +
> > > > +static struct ti_sn65dsi86 *pwm_chip_to_ti_sn_bridge(struct pwm_chip
> > > > *chip)
> > > > +{
> > > > + return container_of(chip, struct ti_sn65dsi86, pchip);
> > > > +}
> > > > +
> > > > +static int ti_sn_pwm_request(struct pwm_chip *chip, struct pwm_device
> > > > *pwm)
> > > > +{
> > > > + struct ti_sn65dsi86 *pdata = pwm_chip_to_ti_sn_bridge(chip);
> > > > +
> > > > + return ti_sn_pwm_pin_request(pdata);
> > > > +}
> > > > +
> > > > +static void ti_sn_pwm_free(struct pwm_chip *chip, struct pwm_device
> > > > *pwm)
> > > > +{
> > > > + struct ti_sn65dsi86 *pdata = pwm_chip_to_ti_sn_bridge(chip);
> > > > +
> > > > + ti_sn_pwm_pin_release(pdata);
> > > > +}
> > > > +
> > > > +/*
> > > > + * Limitations:
> > > > + * - The PWM signal is not driven when the chip is powered down, or in
> > > > its
> > > > + * reset state and the driver does not implement the "suspend state"
> > > > + * described in the documentation. In order to save power,
> > > > state->enabled is
> > > > + * interpreted as denoting if the signal is expected to be valid,
> > > > and is used
> > > > + * to determine if the chip needs to be kept powered.
> > > > + * - Changing both period and duty_cycle is not done atomically,
> > > > neither is the
> > > > + * multi-byte register updates, so the output might briefly be
> > > > undefined
> > > > + * during update.
> > > > */
> > > > +static int ti_sn_pwm_apply(struct pwm_chip *chip, struct pwm_device
> > > > *pwm,
> > > > + const struct pwm_state *state)
> > > > +{
> > > > + struct ti_sn65dsi86 *pdata = pwm_chip_to_ti_sn_bridge(chip);
> > > > + unsigned int pwm_en_inv;
> > > > + unsigned int backlight;
> > > > + unsigned int pre_div;
> > > > + unsigned int scale;
> > > > + u64 period_max;
> > > > + u64 period;
> > > > + int ret;
> > > > +
> > > > +
Re: [PATCH] drm/msm/dpu: Remove some nonsense
On 28/09/2021 19:28, Rob Clark wrote:
From: Rob Clark
These aren't used. And if we add use for them later, we should probably
do something a bit more structured than string parsing.
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 6 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 8
2 files changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index b131fd376192..e32dbb06aad1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -958,12 +958,6 @@ static const struct dpu_perf_cfg sdm845_perf_data = {
.min_core_ib = 240,
.min_llcc_ib = 80,
.min_dram_ib = 80,
- .core_ib_ff = "6.0",
- .core_clk_ff = "1.0",
- .comp_ratio_rt =
- "NV12/5/1/1.23 AB24/5/1/1.23 XB24/5/1/1.23",
- .comp_ratio_nrt =
- "NV12/5/1/1.25 AB24/5/1/1.25 XB24/5/1/1.25",
.undersized_prefill_lines = 2,
.xtra_prefill_lines = 2,
.dest_scale_prefill_lines = 3,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index d2a945a27cfa..4ade44bbd37e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -676,10 +676,6 @@ struct dpu_perf_cdp_cfg {
* @min_core_ibminimum mnoc ib vote in kbps
* @min_llcc_ibminimum llcc ib vote in kbps
* @min_dram_ibminimum dram ib vote in kbps
- * @core_ib_ff core instantaneous bandwidth fudge factor
- * @core_clk_ffcore clock fudge factor
- * @comp_ratio_rt string of 0 or more of ///
- * @comp_ratio_nrt string of 0 or more of ///
* @undersized_prefill_lines undersized prefill in lines
* @xtra_prefill_lines extra prefill latency in lines
* @dest_scale_prefill_lines destination scaler latency in lines
@@ -702,10 +698,6 @@ struct dpu_perf_cfg {
u32 min_core_ib;
u32 min_llcc_ib;
u32 min_dram_ib;
- const char *core_ib_ff;
- const char *core_clk_ff;
- const char *comp_ratio_rt;
- const char *comp_ratio_nrt;
u32 undersized_prefill_lines;
u32 xtra_prefill_lines;
u32 dest_scale_prefill_lines;
--
With best wishes
Dmitry
Re: [PATCH 1/3] drm/bridge: Add a function to abstract away panels
W dniu 23.09.2021 o 02:29, Laurent Pinchart pisze:
> Hi Maxime,
>
> Thank you for the patch.
>
> I know this has already been merged, but I have a question.
>
> On Fri, Sep 10, 2021 at 03:09:39PM +0200, Maxime Ripard wrote:
>> Display drivers so far need to have a lot of boilerplate to first
>> retrieve either the panel or bridge that they are connected to using
>> drm_of_find_panel_or_bridge(), and then either deal with each with ad-hoc
>> functions or create a drm panel bridge through drm_panel_bridge_add.
>>
>> In order to reduce the boilerplate and hopefully create a path of least
>> resistance towards using the DRM panel bridge layer, let's create the
>> function devm_drm_of_get_next to reduce that boilerplate.
>>
>> Signed-off-by: Maxime Ripard
>> ---
>> drivers/gpu/drm/drm_bridge.c | 42
>> drivers/gpu/drm/drm_of.c | 3 +++
>> include/drm/drm_bridge.h | 2 ++
>> 3 files changed, 43 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>> index a8ed66751c2d..10ddca4638b0 100644
>> --- a/drivers/gpu/drm/drm_bridge.c
>> +++ b/drivers/gpu/drm/drm_bridge.c
>> @@ -28,6 +28,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>>
>> #include "drm_crtc_internal.h"
>> @@ -51,10 +52,8 @@
>>*
>>* Display drivers are responsible for linking encoders with the first
>> bridge
>>* in the chains. This is done by acquiring the appropriate bridge with
>> - * of_drm_find_bridge() or drm_of_find_panel_or_bridge(), or creating it
>> for a
>> - * panel with drm_panel_bridge_add_typed() (or the managed version
>> - * devm_drm_panel_bridge_add_typed()). Once acquired, the bridge shall be
>> - * attached to the encoder with a call to drm_bridge_attach().
>> + * devm_drm_of_get_bridge(). Once acquired, the bridge shall be attached to
>> the
>> + * encoder with a call to drm_bridge_attach().
>>*
>>* Bridges are responsible for linking themselves with the next bridge in
>> the
>>* chain, if any. This is done the same way as for encoders, with the call
>> to
>> @@ -1233,6 +1232,41 @@ struct drm_bridge *of_drm_find_bridge(struct
>> device_node *np)
>> return NULL;
>> }
>> EXPORT_SYMBOL(of_drm_find_bridge);
>> +
>> +/**
>> + * devm_drm_of_get_bridge - Return next bridge in the chain
>> + * @dev: device to tie the bridge lifetime to
>> + * @np: device tree node containing encoder output ports
>> + * @port: port in the device tree node
>> + * @endpoint: endpoint in the device tree node
>> + *
>> + * Given a DT node's port and endpoint number, finds the connected node
>> + * and returns the associated bridge if any, or creates and returns a
>> + * drm panel bridge instance if a panel is connected.
>> + *
>> + * Returns a pointer to the bridge if successful, or an error pointer
>> + * otherwise.
>> + */
>> +struct drm_bridge *devm_drm_of_get_bridge(struct device *dev,
>> + struct device_node *np,
>> + unsigned int port,
>> + unsigned int endpoint)
>> +{
>> +struct drm_bridge *bridge;
>> +struct drm_panel *panel;
>> +int ret;
>> +
>> +ret = drm_of_find_panel_or_bridge(np, port, endpoint,
>> + , );
>> +if (ret)
>> +return ERR_PTR(ret);
>> +
>> +if (panel)
>> +bridge = devm_drm_panel_bridge_add(dev, panel);
>> +
>> +return bridge;
> I really like the idea, I've wanted to do something like this for a long
> time. I however wonder if this is the best approach, or if we could get
> the panel core to register the bridge itself. The part that bothers me
> here is the assymetry in the lifetime of the bridges, the returned
> pointer is either looked up or allocated.
When drm_panel_bridge was proposed 1st time I suggested that instead of
it we should just merge panels with bridges (maybe with new name, my
favorite is drm_sink), but I was outvoted :)
Apparently with this patch we go to the same direction: since panels
will be accessed only via drm_panel_bridge they will become actually
bridges :) Somebody could then clean-up the whole intermediate code.
Regards
Andrzej
>
> Bridge lifetime is such a mess that it may not make a big difference,
> but eventually we'll have to address that problem globally.
>
>> +}
>> +EXPORT_SYMBOL(devm_drm_of_get_bridge);
>> #endif
>>
>> MODULE_AUTHOR("Ajay Kumar ");
>> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
>> index 997b8827fed2..37c34146eea8 100644
>> --- a/drivers/gpu/drm/drm_of.c
>> +++ b/drivers/gpu/drm/drm_of.c
>> @@ -231,6 +231,9 @@ EXPORT_SYMBOL_GPL(drm_of_encoder_active_endpoint);
>>* return either the associated struct drm_panel or drm_bridge device.
>> Either
>>* @panel or @bridge must not be NULL.
>>*
>> + * This function is deprecated and should not be used in new drivers.
[PATCH] drm/msm/dpu: Remove some nonsense
From: Rob Clark
These aren't used. And if we add use for them later, we should probably
do something a bit more structured than string parsing.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 6 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 8
2 files changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index b131fd376192..e32dbb06aad1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -958,12 +958,6 @@ static const struct dpu_perf_cfg sdm845_perf_data = {
.min_core_ib = 240,
.min_llcc_ib = 80,
.min_dram_ib = 80,
- .core_ib_ff = "6.0",
- .core_clk_ff = "1.0",
- .comp_ratio_rt =
- "NV12/5/1/1.23 AB24/5/1/1.23 XB24/5/1/1.23",
- .comp_ratio_nrt =
- "NV12/5/1/1.25 AB24/5/1/1.25 XB24/5/1/1.25",
.undersized_prefill_lines = 2,
.xtra_prefill_lines = 2,
.dest_scale_prefill_lines = 3,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index d2a945a27cfa..4ade44bbd37e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -676,10 +676,6 @@ struct dpu_perf_cdp_cfg {
* @min_core_ibminimum mnoc ib vote in kbps
* @min_llcc_ibminimum llcc ib vote in kbps
* @min_dram_ibminimum dram ib vote in kbps
- * @core_ib_ff core instantaneous bandwidth fudge factor
- * @core_clk_ffcore clock fudge factor
- * @comp_ratio_rt string of 0 or more of ///
- * @comp_ratio_nrt string of 0 or more of ///
* @undersized_prefill_lines undersized prefill in lines
* @xtra_prefill_lines extra prefill latency in lines
* @dest_scale_prefill_lines destination scaler latency in lines
@@ -702,10 +698,6 @@ struct dpu_perf_cfg {
u32 min_core_ib;
u32 min_llcc_ib;
u32 min_dram_ib;
- const char *core_ib_ff;
- const char *core_clk_ff;
- const char *comp_ratio_rt;
- const char *comp_ratio_nrt;
u32 undersized_prefill_lines;
u32 xtra_prefill_lines;
u32 dest_scale_prefill_lines;
--
2.31.1
[PATCH] drm/msm/dp: only signal audio when disconnected detected at dp_pm_resume
Only signal audio when disconnected detected at dp_pm_resume since
connected status will be signaled to audio at next plugin handler.
Fixes: 078867ce04ed ("drm/msm/dp: signal audio plugged change at dp_pm_resume")
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 0e543a03..6f13008 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1356,14 +1356,14 @@ static int dp_pm_resume(struct device *dev)
* can not declared display is connected unless
* HDMI cable is plugged in and sink_count of
* dongle become 1
+* also only signal audio when disconnected
*/
- if (dp->link->sink_count)
+ if (dp->link->sink_count) {
dp->dp_display.is_connected = true;
- else
+ } else {
dp->dp_display.is_connected = false;
-
- dp_display_handle_plugged_change(g_dp_display,
- dp->dp_display.is_connected);
+ dp_display_handle_plugged_change(g_dp_display, false);
+ }
DRM_DEBUG_DP("After, sink_count=%d is_connected=%d core_inited=%d
power_on=%d\n",
dp->link->sink_count, dp->dp_display.is_connected,
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: linux-next: Tree for Sep 28 [drivers/gpu/drm/vc4/vc4.ko]
On 9/28/21 12:23 AM, Stephen Rothwell wrote: Hi all, Changes since 20210927: on x86_64: ERROR: modpost: "devm_drm_of_get_bridge" [drivers/gpu/drm/vc4/vc4.ko] undefined! Full randconfig file is attached. -- ~Randy config-r5051.gz Description: application/gzip
Re: [Freedreno] [PATCH] drm/msm: Switch ordering of runpm put vs devfreq_idle
On Tue, Sep 28, 2021 at 7:52 AM Akhil P Oommen wrote:
>
> On 9/27/2021 8:59 PM, Rob Clark wrote:
> > From: Rob Clark
> >
> > I've seen a few crashes like:
> >
> > Internal error: synchronous external abort: 9610 [#1] PREEMPT SMP
> > Modules linked in: snd_seq_dummy snd_seq snd_seq_device bridge stp llc
> > tun nf_nat_tftp nf_conntrack_tftp nf_nat_ftp nf_conntrack_ftp esp6 ah6
> > ip6t_REJECT ip6t_ipv6header vhost_vsock vhost
> > vmw_vsock_virtio_transport_common vsock rfcomm algif_hash algif_skcipher
> > af_alg uinput veth xt_cgroup xt_MASQUERADE venus_enc venus_dec
> > videobuf2_dma_contig qcom_spmi_adc5 qcom_spmi_adc_tm5 hci_uart
> > qcom_vadc_common cros_ec_typec qcom_spmi_temp_alarm typec btqca
> > snd_soc_rt5682_i2c snd_soc_rt5682 snd_soc_sc7180 bluetooth
> > snd_soc_qcom_common snd_soc_rl6231 ecdh_generic ecc venus_core v4l2_mem2mem
> > snd_soc_lpass_sc7180 snd_soc_lpass_hdmi snd_soc_lpass_cpu
> > snd_soc_lpass_platform snd_soc_max98357a ip6table_nat fuse iio_trig_sysfs
> > cros_ec_lid_angle cros_ec_sensors cros_ec_sensors_core
> > industrialio_triggered_buffer kfifo_buf cros_ec_sensorhub lzo_rle
> > ath10k_snoc lzo_compress ath10k_core ath zram mac80211 cfg80211
> > ax88179_178a usbnet mii uvcvideo videobuf2_vmalloc joydev
> > CPU: 3 PID: 212 Comm: A618-worker Tainted: G W
> > 5.4.139-16300-g88d8e1285982 #1
> > Hardware name: Google Pompom (rev1) with LTE (DT)
> > pstate: 60c9 (nZCv daif +PAN +UAO)
> > pc : a6xx_gmu_set_oob+0x114/0x200
> > lr : a6xx_gmu_set_oob+0x10c/0x200
> > sp : ffc011b7bc20
> > x29: ffc011b7bc20 x28: ffdad27c5000
> > x27: 0001 x26: ffdad1521044
> > x25: ffbef7498338 x24: 0018
> > x23: 0002 x22: 00014648
> > x21: 033732fe638b x20: 8000
> > x19: ffbef7433bc8 x18: 4000
> > x17: 00243508d982 x16: b67e
> > x15: 90d4 x14: 0024
> > x13: 0024 x12: 00017521
> > x11: 0b48 x10: 00326a48
> > x9 : 1a130d33f6371600 x8 : ffc011e54648
> > x7 : 614948e5003c x6 : ffbe3cd17e60
> > x5 : 0040 x4 : 0004
> > x3 : x2 : ffbef7488000
> > x1 : ffbef7488000 x0 :
> > Call trace:
> > a6xx_gmu_set_oob+0x114/0x200
> > a6xx_gmu_set_freq+0xe0/0x1fc
> > msm_devfreq_target+0x80/0x13c
> > msm_devfreq_idle+0x54/0x94
> > retire_submit+0x170/0x254
> > retire_submits+0xa4/0xdc
> > retire_worker+0x1c/0x28
> > kthread_worker_fn+0xf4/0x1bc
> > kthread+0x140/0x158
> > ret_from_fork+0x10/0x18
> > Code: 52800c81 9415bbe5 f9400a68 8b160108 (b9400108)
> > ---[ end trace 16b871df2482cd61 ]---
> > Kernel panic - not syncing: Fatal exception
> > SMP: stopping secondary CPUs
> > Kernel Offset: 0x1ac140 from 0xffc01000
> > PHYS_OFFSET: 0xffc28000
> > CPU features: 0x88102e,2a80aa38
> > Memory Limit: none
> >
> > Which smells a lot like touching hw after power collapse. I'm not
> > *entirely* sure how it could have taken 66ms (the autosuspend delay)
> > before we get to a6xx_gmu_set_oob(), but to be safe we should move
> > the pm_runtime_put_autosuspend() after msm_devfreq_idle().
> https://elixir.bootlin.com/linux/v5.15-rc1/source/drivers/gpu/drm/msm/adreno/a6xx_gmu.c#L132
> We have this check in the gmu freq set path which should avoid this
> scenario. I might be a bit pedantic here, but I feel that the original
> code is more accurate. We should immediately mark last busy and put
> runtime_pm refcount.
The problem is that get_if_in_use(gmu->dev) doesn't prevent the _gpu_
device from suspending and racing down the _set_oob()/_clear_oob()
path in parallel with set_freq().. I think that (plus the potential
for either of those paths to race with get_timestamp()) is related to
the gmu OOB crashes I'm seeing from the field.
A better plan is probably something along the lines of [1].. maybe
re-worked a bit if it is not acceptable to start using c99. Which
we'll also need if we wanted to defer slightly clamping to idle. (Or
if we had IFPC working we could just drop the whole freq change on
idle<->active transitions ;-))
[1] https://patchwork.freedesktop.org/patch/455928/?series=95119=1
>
> -Akhil.
>
> >
> > Fixes: 9bc95570175a ("drm/msm: Devfreq tuning")
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/msm/msm_gpu.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> > index d1a16642ecd5..2b2bbe7499e6 100644
> > --- a/drivers/gpu/drm/msm/msm_gpu.c
> > +++ b/drivers/gpu/drm/msm/msm_gpu.c
> > @@ -667,9 +667,6 @@ static void retire_submit(struct msm_gpu *gpu, struct
> > msm_ringbuffer *ring,
> >
> >
[Bug 214029] [bisected] [amdgpu] Several memory leaks in amdgpu and ttm
https://bugzilla.kernel.org/show_bug.cgi?id=214029 --- Comment #16 from Erhard F. (erhar...@mailbox.org) --- Created attachment 299007 --> https://bugzilla.kernel.org/attachment.cgi?id=299007=edit final bisect.log -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 214029] [bisected] [amdgpu] Several memory leaks in amdgpu and ttm
https://bugzilla.kernel.org/show_bug.cgi?id=214029 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added CC||christian.koe...@amd.com --- Comment #15 from Erhard F. (erhar...@mailbox.org) --- I got around skipping commits by cherry-picking 9551158069ba8fcc893798d42dc4f978b62ef60f (kfence: make compatible with kmemleak) and finally was able to complete the bisect. The offending commit was: # git bisect good d02117f8efaa5fbc37437df1ae955a147a2a424a is the first bad commit commit d02117f8efaa5fbc37437df1ae955a147a2a424a Author: Christian König Date: Sat Apr 17 19:09:30 2021 +0200 drm/ttm: remove special handling for non GEM drivers vmwgfx is the only driver actually using this. Move the handling into the driver instead. Signed-off-by: Christian König Acked-by: Huang Rui Reviewed-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20210419092853.1605-1-christian.koe...@amd.com drivers/gpu/drm/ttm/ttm_bo.c | 11 --- drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 10 ++ include/drm/ttm/ttm_bo_api.h | 19 --- 3 files changed, 10 insertions(+), 30 deletions(-) -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v3] drm/dp: Add Additional DP2 Headers
On 2021-09-27 15:23, Fangzhi Zuo wrote: > Include FEC, DSC, Link Training related headers. > > Change since v2 > - Align with the spec for DP_DSC_SUPPORT_AND_DSC_DECODER_COUNT > > Signed-off-by: Fangzhi Zuo Reviewed-by: Harry Wentland Harry > --- > This patch is based on top of the other DP2.0 work in > "drm/dp: add LTTPR DP 2.0 DPCD addresses" > --- > include/drm/drm_dp_helper.h | 20 > 1 file changed, 20 insertions(+) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index 1d5b3dbb6e56..a1df35aa6e68 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -453,6 +453,7 @@ struct drm_panel; > # define DP_FEC_UNCORR_BLK_ERROR_COUNT_CAP (1 << 1) > # define DP_FEC_CORR_BLK_ERROR_COUNT_CAP(1 << 2) > # define DP_FEC_BIT_ERROR_COUNT_CAP (1 << 3) > +#define DP_FEC_CAPABILITY_1 0x091 /* 2.0 */ > > /* DP-HDMI2.1 PCON DSC ENCODER SUPPORT */ > #define DP_PCON_DSC_ENCODER_CAP_SIZE0xC /* 0x9E - 0x92 */ > @@ -537,6 +538,9 @@ struct drm_panel; > #define DP_DSC_BRANCH_OVERALL_THROUGHPUT_1 0x0a1 > #define DP_DSC_BRANCH_MAX_LINE_WIDTH0x0a2 > > +/* DFP Capability Extension */ > +#define DP_DFP_CAPABILITY_EXTENSION_SUPPORT 0x0a3 /* 2.0 */ > + > /* Link Configuration */ > #define DP_LINK_BW_SET 0x100 > # define DP_LINK_RATE_TABLE 0x00/* eDP 1.4 */ > @@ -688,6 +692,7 @@ struct drm_panel; > > #define DP_DSC_ENABLE 0x160 /* DP 1.4 */ > # define DP_DECOMPRESSION_EN(1 << 0) > +#define DP_DSC_CONFIGURATION 0x161 /* DP 2.0 */ > > #define DP_PSR_EN_CFG0x170 /* XXX 1.2? */ > # define DP_PSR_ENABLE BIT(0) > @@ -743,6 +748,7 @@ struct drm_panel; > # define DP_RECEIVE_PORT_0_STATUS(1 << 0) > # define DP_RECEIVE_PORT_1_STATUS(1 << 1) > # define DP_STREAM_REGENERATION_STATUS (1 << 2) /* 2.0 */ > +# define DP_INTRA_HOP_AUX_REPLY_INDICATION (1 << 3) /* 2.0 */ > > #define DP_ADJUST_REQUEST_LANE0_10x206 > #define DP_ADJUST_REQUEST_LANE2_30x207 > @@ -865,6 +871,8 @@ struct drm_panel; > # define DP_PHY_TEST_PATTERN_80BIT_CUSTOM 0x4 > # define DP_PHY_TEST_PATTERN_CP2520 0x5 > > +#define DP_PHY_SQUARE_PATTERN0x249 > + > #define DP_TEST_HBR2_SCRAMBLER_RESET0x24A > #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250 > #define DP_TEST_80BIT_CUSTOM_PATTERN_15_8 0x251 > @@ -1109,6 +1117,18 @@ struct drm_panel; > #define DP_128B132B_TRAINING_AUX_RD_INTERVAL 0x2216 /* 2.0 */ > # define DP_128B132B_TRAINING_AUX_RD_INTERVAL_MASK 0x7f > > +#define DP_TEST_264BIT_CUSTOM_PATTERN_7_00x2230 > +#define DP_TEST_264BIT_CUSTOM_PATTERN_263_2560x2250 > + > +/* DSC Extended Capability Branch Total DSC Resources */ > +#define DP_DSC_SUPPORT_AND_DSC_DECODER_COUNT 0x2260 /* 2.0 */ > +# define DP_DSC_DECODER_COUNT_MASK (0b111 << 5) > +# define DP_DSC_DECODER_COUNT_SHIFT 5 > +#define DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0 0x2270 /* 2.0 */ > +# define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK (1 << 0) > +# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK (0b111 << 1) > +# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT 1 > + > /* Protocol Converter Extension */ > /* HDMI CEC tunneling over AUX DP 1.3 section 5.3.3.3.1 DPCD 1.4+ */ > #define DP_CEC_TUNNELING_CAPABILITY0x3000 >
Re: refactor the i915 GVT support
On Tue, Sep 28, 2021 at 02:35:06PM +, Wang, Zhi A wrote: > Yes. I was thinking of the possibility of putting off some work later so > that we don't need to make a lot of changes. GVT-g needs to take a > snapshot of GPU registers as the initial virtual states for other vGPUs, > which requires the initialization happens at a certain early time of > initialization of i915. I was thinking maybe we can take other patches > from Christoph like "de-virtualize*" except this one because currently > we have to maintain a TEST-ONLY patch on our tree to prevent i915 built > as kernel module. How about just capture these registers in the main module/device and not try so hard to isolate it to the gvt stuff? Jason
Re: refactor the i915 GVT support
On 9/28/21 2:00 PM, Luis Chamberlain wrote:
> On Tue, Sep 28, 2021 at 07:41:00AM +, Wang, Zhi A wrote:
>> Hey guys:
>>
>> After some investigation, I found the root cause this problem ("i915"
>> module loading will be stuck with Christoph's refactor patches), which
>> can be reproduced by building both i915 and kvmgt as kernel module and
>> the loading i915.
> Thanks for looking into this!
>
>> The root cause is: in Linux kernel loading, before a kernel module
>> loading is finished, its symbols can not be reached by other module when
>> resolving the symbols (even they can be found in /proc/kallsyms).
>> Because the status of the kernel module is MODULE_STATE_COMING and
>> resolve_symbol() from another kernel module will check this and return a
>> -EBUSY.
> Well, it would seem that way but...
>
>> In this case, before i915 loading is finished, the requested module
>> "kvmgt" cannot reach the symbols in module i915. Thus it kept waiting
>> and left message like below in the dmesg:
>>
>> [ 644.152021] kvmgt: gave up waiting for init of module i915.
>> [ 644.152039] kvmgt: Unknown symbol i915_gem_object_set_to_cpu_domain
>> (err -16)
>> [ 674.871409] kvmgt: gave up waiting for init of module i915.
>> [ 674.871427] kvmgt: Unknown symbol intel_ring_begin (err -16)
>> [ 705.590586] kvmgt: gave up waiting for init of module i915.
>> [ 705.590604] kvmgt: Unknown symbol i915_vma_move_to_active (err -16)
>> [ 736.310230] kvmgt: gave up waiting for init of module i915.
>> [ 736.310248] kvmgt: Unknown symbol shmem_unpin_map (err -16)
>> ...
>>
>> The error message is from execution path below:
>>
>> kernel/module.c:
>>
>> [i915 module loading] ->
>> request_module("kvmgt")->[modprobe]->init_module("kvmgt")->load_module()->simplify_symbols()->resolve_symbol_wait():
>>
>> static const struct kernel_symbol *
>> resolve_symbol_wait(struct module *mod,
>> const struct load_info *info,
>> const char *name)
>> {
>> const struct kernel_symbol *ksym;
>> char owner[MODULE_NAME_LEN];
>>
>> if (wait_event_interruptible_timeout(module_wq,
>> !IS_ERR(ksym = resolve_symbol(mod, info, name, owner))
>> || PTR_ERR(ksym) != -EBUSY,
>> 30 * HZ) <= 0) {
>> pr_warn("%s: gave up waiting for init of module %s.\n",
>> mod->name, owner);
>>
>> }
> Commit 9bea7f23952d5 ("module: fix bne2 "gave up waiting for init of
> module libcrc32c") is worth reviewing. It dealt with a similar issue,
> and in particular it addressed the issue with -EBUSY being returned
> by ref_module().
>
> And so, in theory that case should be dealt with in resolve_symbol_wait()
> already. And so can you try this just to verify something:
>
> diff --git a/kernel/module.c b/kernel/module.c
> index 40ec9a030eec..98f87cbb37de 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -1459,7 +1459,7 @@ resolve_symbol_wait(struct module *mod,
> if (wait_event_interruptible_timeout(module_wq,
> !IS_ERR(ksym = resolve_symbol(mod, info, name, owner))
> || PTR_ERR(ksym) != -EBUSY,
> - 30 * HZ) <= 0) {
> + 160 * HZ) <= 0) {
> pr_warn("%s: gave up waiting for init of module %s.\n",
> mod->name, owner);
> }
>
Hi Luis:
Thanks so much for the reply and patch.:)
I am afraid that this patch wouldn't work in this case as the
request_module("kvmgt") happens in the init_module of i915. Before the
initialization path is finished in i915, the i915 symbols are not
available to be referenced. Unfortunately, It's matter of sequence, not
of delay. :(
>> code:
>> https://github.com/intel/gvt-linux/blob/bd950a66c7919d7121d2530f30984351534a96dc/kernel/module.c#L1452
>>
>> In resolve_symbol_wait(), it calls resolve_symbol() to resolve the
>> symbols in "i915". In resolve_symbol() -> ref_module() ->
>> strong_try_module_get(), it will check the status of the module which
>> owns the symbol.
>>
>> static inline int strong_try_module_get(struct module *mod)
>> {
>> BUG_ON(mod && mod->state == MODULE_STATE_UNFORMED);
>> if (mod && mod->state == MODULE_STATE_COMING)
>> return -EBUSY;
>> if (try_module_get(mod))
>> return 0;
>> else
>> return -ENOENT;
>> }
>>
>> code:https://github.com/intel/gvt-linux/blob/bd950a66c7919d7121d2530f30984351534a96dc/kernel/module.c#L318
>>
>> But unfortunately, this execution path begins in i915 module loading, at
>> this time, the status of kernel module "i915" is MODULE_STATE_COMING
>> until loading of "kvmgt" is finished. Thus a -EBUSY is always returned
>> when kernel is trying to resolve symbols for "kvmgt".
>>
>>
>> This patch below might need re-work:
> If the above test patch still fails, well.. that might be telling of
> another issue which is perhaps difficult to see at first glance. If
>
[PATCH] [SUBMITTED 20210721] fbdev: simplefb: fix Kconfig dependencies
From: Arnd Bergmann
Configurations with both CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM=m
are allowed by Kconfig because the 'depends on !DRM_SIMPLEDRM' dependency
does not disallow FB_SIMPLE as long as SIMPLEDRM is not built-in. This
can however result in a build failure when cfb_fillrect() etc are then
also in loadable modules:
x86_64-linux-ld: drivers/video/fbdev/simplefb.o:(.rodata+0x1f8): undefined
reference to `cfb_fillrect'
x86_64-linux-ld: drivers/video/fbdev/simplefb.o:(.rodata+0x200): undefined
reference to `cfb_copyarea'
x86_64-linux-ld: drivers/video/fbdev/simplefb.o:(.rodata+0x208): undefined
reference to `cfb_imageblit'
To work around this, change FB_SIMPLE to be a 'tristate' symbol,
which still allows both to be =m together, but not one of them to
be =y if the other one is =m. If a distro kernel picks this
configuration, it can be determined by local policy which of
the two modules gets loaded. The 'of_chosen' export is needed
as this is the first loadable module referencing it.
Alternatively, the Kconfig dependency could be changed to
'depends on DRM_SIMPLEDRM=n', which would forbid the configuration
with both drivers.
Fixes: 11e8f5fd223b ("drm: Add simpledrm driver")
Acked-by: Rob Herring # for drivers/of/
Link: https://lore.kernel.org/all/20210721151839.2484245-1-a...@kernel.org/
Signed-off-by: Arnd Bergmann
---
drivers/of/base.c | 1 +
drivers/video/fbdev/Kconfig | 5 +++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index f720c0d246f2..0ac17256258d 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -36,6 +36,7 @@ LIST_HEAD(aliases_lookup);
struct device_node *of_root;
EXPORT_SYMBOL(of_root);
struct device_node *of_chosen;
+EXPORT_SYMBOL(of_chosen);
struct device_node *of_aliases;
struct device_node *of_stdout;
static const char *of_stdout_options;
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index b26b79dfcac9..6ed5e608dd04 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2193,8 +2193,9 @@ config FB_HYPERV
This framebuffer driver supports Microsoft Hyper-V Synthetic Video.
config FB_SIMPLE
- bool "Simple framebuffer support"
- depends on (FB = y) && !DRM_SIMPLEDRM
+ tristate "Simple framebuffer support"
+ depends on FB
+ depends on !DRM_SIMPLEDRM
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
--
2.29.2
Re: [PATCH] drm/msm: Switch ordering of runpm put vs devfreq_idle
On 9/27/2021 8:59 PM, Rob Clark wrote:
From: Rob Clark
I've seen a few crashes like:
Internal error: synchronous external abort: 9610 [#1] PREEMPT SMP
Modules linked in: snd_seq_dummy snd_seq snd_seq_device bridge stp llc tun
nf_nat_tftp nf_conntrack_tftp nf_nat_ftp nf_conntrack_ftp esp6 ah6 ip6t_REJECT
ip6t_ipv6header vhost_vsock vhost vmw_vsock_virtio_transport_common vsock
rfcomm algif_hash algif_skcipher af_alg uinput veth xt_cgroup xt_MASQUERADE
venus_enc venus_dec videobuf2_dma_contig qcom_spmi_adc5 qcom_spmi_adc_tm5
hci_uart qcom_vadc_common cros_ec_typec qcom_spmi_temp_alarm typec btqca
snd_soc_rt5682_i2c snd_soc_rt5682 snd_soc_sc7180 bluetooth snd_soc_qcom_common
snd_soc_rl6231 ecdh_generic ecc venus_core v4l2_mem2mem snd_soc_lpass_sc7180
snd_soc_lpass_hdmi snd_soc_lpass_cpu snd_soc_lpass_platform snd_soc_max98357a
ip6table_nat fuse iio_trig_sysfs cros_ec_lid_angle cros_ec_sensors
cros_ec_sensors_core industrialio_triggered_buffer kfifo_buf cros_ec_sensorhub
lzo_rle ath10k_snoc lzo_compress ath10k_core ath zram mac80211 cfg80211
ax88179_178a usbnet mii uvcvideo videobuf2_vmalloc joydev
CPU: 3 PID: 212 Comm: A618-worker Tainted: G W 5.4.139-16300-g88d8e1285982
#1
Hardware name: Google Pompom (rev1) with LTE (DT)
pstate: 60c9 (nZCv daif +PAN +UAO)
pc : a6xx_gmu_set_oob+0x114/0x200
lr : a6xx_gmu_set_oob+0x10c/0x200
sp : ffc011b7bc20
x29: ffc011b7bc20 x28: ffdad27c5000
x27: 0001 x26: ffdad1521044
x25: ffbef7498338 x24: 0018
x23: 0002 x22: 00014648
x21: 033732fe638b x20: 8000
x19: ffbef7433bc8 x18: 4000
x17: 00243508d982 x16: b67e
x15: 90d4 x14: 0024
x13: 0024 x12: 00017521
x11: 0b48 x10: 00326a48
x9 : 1a130d33f6371600 x8 : ffc011e54648
x7 : 614948e5003c x6 : ffbe3cd17e60
x5 : 0040 x4 : 0004
x3 : x2 : ffbef7488000
x1 : ffbef7488000 x0 :
Call trace:
a6xx_gmu_set_oob+0x114/0x200
a6xx_gmu_set_freq+0xe0/0x1fc
msm_devfreq_target+0x80/0x13c
msm_devfreq_idle+0x54/0x94
retire_submit+0x170/0x254
retire_submits+0xa4/0xdc
retire_worker+0x1c/0x28
kthread_worker_fn+0xf4/0x1bc
kthread+0x140/0x158
ret_from_fork+0x10/0x18
Code: 52800c81 9415bbe5 f9400a68 8b160108 (b9400108)
---[ end trace 16b871df2482cd61 ]---
Kernel panic - not syncing: Fatal exception
SMP: stopping secondary CPUs
Kernel Offset: 0x1ac140 from 0xffc01000
PHYS_OFFSET: 0xffc28000
CPU features: 0x88102e,2a80aa38
Memory Limit: none
Which smells a lot like touching hw after power collapse. I'm not
*entirely* sure how it could have taken 66ms (the autosuspend delay)
before we get to a6xx_gmu_set_oob(), but to be safe we should move
the pm_runtime_put_autosuspend() after msm_devfreq_idle().
https://elixir.bootlin.com/linux/v5.15-rc1/source/drivers/gpu/drm/msm/adreno/a6xx_gmu.c#L132
We have this check in the gmu freq set path which should avoid this
scenario. I might be a bit pedantic here, but I feel that the original
code is more accurate. We should immediately mark last busy and put
runtime_pm refcount.
-Akhil.
Fixes: 9bc95570175a ("drm/msm: Devfreq tuning")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index d1a16642ecd5..2b2bbe7499e6 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -667,9 +667,6 @@ static void retire_submit(struct msm_gpu *gpu, struct
msm_ringbuffer *ring,
msm_submit_retire(submit);
- pm_runtime_mark_last_busy(>pdev->dev);
- pm_runtime_put_autosuspend(>pdev->dev);
-
spin_lock_irqsave(>submit_lock, flags);
list_del(>node);
spin_unlock_irqrestore(>submit_lock, flags);
@@ -683,6 +680,9 @@ static void retire_submit(struct msm_gpu *gpu, struct
msm_ringbuffer *ring,
mutex_unlock(>active_lock);
msm_gem_submit_put(submit);
+
+ pm_runtime_mark_last_busy(>pdev->dev);
+ pm_runtime_put_autosuspend(>pdev->dev);
}
static void retire_submits(struct msm_gpu *gpu)
Re: [PATCH v4 06/10] drm/ingenic: Add dw-hdmi driver for jz4780
Hi Nikolaus & Paul,
Le lun., sept. 27 2021 at 18:44:24 +0200, H. Nikolaus Schaller
a écrit :
From: Paul Boddie
A specialisation of the generic Synopsys HDMI driver is employed for
JZ4780
HDMI support. This requires a new driver, plus device tree and
configuration
modifications.
Signed-off-by: Paul Boddie
Signed-off-by: Ezequiel Garcia
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/Kconfig | 9 ++
drivers/gpu/drm/ingenic/Makefile | 1 +
drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c | 142
++
3 files changed, 152 insertions(+)
create mode 100644 drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
diff --git a/drivers/gpu/drm/ingenic/Kconfig
b/drivers/gpu/drm/ingenic/Kconfig
index 3b57f8be007c..4c7d311fbeff 100644
--- a/drivers/gpu/drm/ingenic/Kconfig
+++ b/drivers/gpu/drm/ingenic/Kconfig
@@ -25,4 +25,13 @@ config DRM_INGENIC_IPU
The Image Processing Unit (IPU) will appear as a second primary
plane.
+config DRM_INGENIC_DW_HDMI
+ bool "Ingenic specific support for Synopsys DW HDMI"
+ depends on MACH_JZ4780
+ select DRM_DW_HDMI
+ help
+ Choose this option to enable Synopsys DesignWare HDMI based
driver.
+ If you want to enable HDMI on Ingenic JZ4780 based SoC, you should
+ select this option..
+
endif
diff --git a/drivers/gpu/drm/ingenic/Makefile
b/drivers/gpu/drm/ingenic/Makefile
index d313326bdddb..3db9888a6c04 100644
--- a/drivers/gpu/drm/ingenic/Makefile
+++ b/drivers/gpu/drm/ingenic/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_DRM_INGENIC) += ingenic-drm.o
ingenic-drm-y = ingenic-drm-drv.o
ingenic-drm-$(CONFIG_DRM_INGENIC_IPU) += ingenic-ipu.o
+ingenic-drm-$(CONFIG_DRM_INGENIC_DW_HDMI) += ingenic-dw-hdmi.o
diff --git a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
new file mode 100644
index ..dd9c94ae842e
--- /dev/null
+++ b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
@@ -0,0 +1,142 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2011-2013 Freescale Semiconductor, Inc.
+ * Copyright (C) 2019, 2020 Paul Boddie
+ *
+ * Derived from dw_hdmi-imx.c with i.MX portions removed.
+ * Probe and remove operations derived from rcar_dw_hdmi.c.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static const struct dw_hdmi_mpll_config ingenic_mpll_cfg[] = {
+ { 4525, { { 0x01e0, 0x }, { 0x21e1, 0x }, { 0x41e2,
0x } } },
+ { 9250, { { 0x0140, 0x0005 }, { 0x2141, 0x0005 }, { 0x4142,
0x0005 } } },
+ { 14850, { { 0x00a0, 0x000a }, { 0x20a1, 0x000a }, { 0x40a2,
0x000a } } },
+ { 21600, { { 0x00a0, 0x000a }, { 0x2001, 0x000f }, { 0x4002,
0x000f } } },
+ { ~0UL, { { 0x, 0x }, { 0x, 0x }, { 0x,
0x } } }
+};
+
+static const struct dw_hdmi_curr_ctrl ingenic_cur_ctr[] = {
+ /*pixelclk bpp8bpp10 bpp12 */
+ { 5400, { 0x091c, 0x091c, 0x06dc } },
+ { 5840, { 0x091c, 0x06dc, 0x06dc } },
+ { 7200, { 0x06dc, 0x06dc, 0x091c } },
+ { 7425, { 0x06dc, 0x0b5c, 0x091c } },
+ { 11880, { 0x091c, 0x091c, 0x06dc } },
+ { 21600, { 0x06dc, 0x0b5c, 0x091c } },
+ { ~0UL, { 0x, 0x, 0x } },
+};
+
+/*
+ * Resistance term 133Ohm Cfg
+ * PREEMP config 0.00
+ * TX/CK level 10
+ */
+static const struct dw_hdmi_phy_config ingenic_phy_config[] = {
+ /*pixelclk symbol term vlev */
+ { 21600, 0x800d, 0x0005, 0x01ad},
+ { ~0UL, 0x, 0x, 0x}
+};
+
+static enum drm_mode_status
+ingenic_dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
+ const struct drm_display_info *info,
+ const struct drm_display_mode *mode)
+{
+ if (mode->clock < 13500)
+ return MODE_CLOCK_LOW;
+ /* FIXME: Hardware is capable of 270MHz, but setup data is missing.
*/
+ if (mode->clock > 216000)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+}
+
+static bool
+ingenic_dw_hdmi_mode_fixup(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC |
DRM_MODE_FLAG_PVSYNC);
+ adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC |
DRM_MODE_FLAG_NVSYNC);
Why do these flags need to be cleared? The LCDC can work with negative
v/h sync, does the HDMI core not work with that?
+
+ return true;
+}
+
+static const struct drm_bridge_timings ingenic_dw_hdmi_timings = {
+ .input_bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
That info should be provided in the EDID, is this really needed here?
Cheers,
-Paul
+};
+
+static struct dw_hdmi_plat_data ingenic_dw_hdmi_plat_data = {
+ .mpll_cfg = ingenic_mpll_cfg,
+ .cur_ctr= ingenic_cur_ctr,
+ .phy_config = ingenic_phy_config,
+ .mode_valid =
Re: refactor the i915 GVT support
On Tue, Sep 28, 2021 at 07:41:00AM +, Wang, Zhi A wrote:
> Hey guys:
>
> After some investigation, I found the root cause this problem ("i915"
> module loading will be stuck with Christoph's refactor patches), which
> can be reproduced by building both i915 and kvmgt as kernel module and
> the loading i915.
Thanks for looking into this!
> The root cause is: in Linux kernel loading, before a kernel module
> loading is finished, its symbols can not be reached by other module when
> resolving the symbols (even they can be found in /proc/kallsyms).
> Because the status of the kernel module is MODULE_STATE_COMING and
> resolve_symbol() from another kernel module will check this and return a
> -EBUSY.
Well, it would seem that way but...
> In this case, before i915 loading is finished, the requested module
> "kvmgt" cannot reach the symbols in module i915. Thus it kept waiting
> and left message like below in the dmesg:
>
> [ 644.152021] kvmgt: gave up waiting for init of module i915.
> [ 644.152039] kvmgt: Unknown symbol i915_gem_object_set_to_cpu_domain
> (err -16)
> [ 674.871409] kvmgt: gave up waiting for init of module i915.
> [ 674.871427] kvmgt: Unknown symbol intel_ring_begin (err -16)
> [ 705.590586] kvmgt: gave up waiting for init of module i915.
> [ 705.590604] kvmgt: Unknown symbol i915_vma_move_to_active (err -16)
> [ 736.310230] kvmgt: gave up waiting for init of module i915.
> [ 736.310248] kvmgt: Unknown symbol shmem_unpin_map (err -16)
> ...
>
> The error message is from execution path below:
>
> kernel/module.c:
>
> [i915 module loading] ->
> request_module("kvmgt")->[modprobe]->init_module("kvmgt")->load_module()->simplify_symbols()->resolve_symbol_wait():
>
> static const struct kernel_symbol *
> resolve_symbol_wait(struct module *mod,
> const struct load_info *info,
> const char *name)
> {
> const struct kernel_symbol *ksym;
> char owner[MODULE_NAME_LEN];
>
> if (wait_event_interruptible_timeout(module_wq,
> !IS_ERR(ksym = resolve_symbol(mod, info, name, owner))
> || PTR_ERR(ksym) != -EBUSY,
> 30 * HZ) <= 0) {
> pr_warn("%s: gave up waiting for init of module %s.\n",
> mod->name, owner);
>
> }
Commit 9bea7f23952d5 ("module: fix bne2 "gave up waiting for init of
module libcrc32c") is worth reviewing. It dealt with a similar issue,
and in particular it addressed the issue with -EBUSY being returned
by ref_module().
And so, in theory that case should be dealt with in resolve_symbol_wait()
already. And so can you try this just to verify something:
diff --git a/kernel/module.c b/kernel/module.c
index 40ec9a030eec..98f87cbb37de 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1459,7 +1459,7 @@ resolve_symbol_wait(struct module *mod,
if (wait_event_interruptible_timeout(module_wq,
!IS_ERR(ksym = resolve_symbol(mod, info, name, owner))
|| PTR_ERR(ksym) != -EBUSY,
-30 * HZ) <= 0) {
+160 * HZ) <= 0) {
pr_warn("%s: gave up waiting for init of module %s.\n",
mod->name, owner);
}
> code:
> https://github.com/intel/gvt-linux/blob/bd950a66c7919d7121d2530f30984351534a96dc/kernel/module.c#L1452
>
> In resolve_symbol_wait(), it calls resolve_symbol() to resolve the
> symbols in "i915". In resolve_symbol() -> ref_module() ->
> strong_try_module_get(), it will check the status of the module which
> owns the symbol.
>
> static inline int strong_try_module_get(struct module *mod)
> {
> BUG_ON(mod && mod->state == MODULE_STATE_UNFORMED);
> if (mod && mod->state == MODULE_STATE_COMING)
> return -EBUSY;
> if (try_module_get(mod))
> return 0;
> else
> return -ENOENT;
> }
>
> code:https://github.com/intel/gvt-linux/blob/bd950a66c7919d7121d2530f30984351534a96dc/kernel/module.c#L318
>
> But unfortunately, this execution path begins in i915 module loading, at
> this time, the status of kernel module "i915" is MODULE_STATE_COMING
> until loading of "kvmgt" is finished. Thus a -EBUSY is always returned
> when kernel is trying to resolve symbols for "kvmgt".
>
>
> This patch below might need re-work:
If the above test patch still fails, well.. that might be telling of
another issue which is perhaps difficult to see at first glance. If
resolve_symbol_wait() won't succeed until request_module("kvmgt")
completes and if this means having kvmgt's init routine complete, that
could end up in some longer chain or in the worst case a sort of
circular dependency which is only implicated by module loading. It'd be
really odd... but I cannot rule it out.
This is one reason I hinted that you should strive to not do much on a
module's init. If you can punt work off for later that's best.
Luis
>
> Author: Christoph Hellwig
>
Re: [PATCH v4 06/10] drm/ingenic: Add dw-hdmi driver for jz4780
Hi Neil,
> Am 28.09.2021 um 15:02 schrieb Neil Armstrong :
>
> On 27/09/2021 18:44, H. Nikolaus Schaller wrote:
>> From: Paul Boddie
>>
>> A specialisation of the generic Synopsys HDMI driver is employed for JZ4780
>> HDMI support. This requires a new driver, plus device tree and configuration
>> modifications.
>>
>> Signed-off-by: Paul Boddie
>> Signed-off-by: Ezequiel Garcia
>> Signed-off-by: H. Nikolaus Schaller
>> ---
>> drivers/gpu/drm/ingenic/Kconfig | 9 ++
>> drivers/gpu/drm/ingenic/Makefile | 1 +
>> drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c | 142 ++
>> 3 files changed, 152 insertions(+)
>> create mode 100644 drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
>>
>> diff --git a/drivers/gpu/drm/ingenic/Kconfig
>> b/drivers/gpu/drm/ingenic/Kconfig
>> index 3b57f8be007c..4c7d311fbeff 100644
>> --- a/drivers/gpu/drm/ingenic/Kconfig
>> +++ b/drivers/gpu/drm/ingenic/Kconfig
>> @@ -25,4 +25,13 @@ config DRM_INGENIC_IPU
>>
>>The Image Processing Unit (IPU) will appear as a second primary plane.
>>
>> +config DRM_INGENIC_DW_HDMI
>> +bool "Ingenic specific support for Synopsys DW HDMI"
>> +depends on MACH_JZ4780
>> +select DRM_DW_HDMI
>> +help
>> + Choose this option to enable Synopsys DesignWare HDMI based driver.
>> + If you want to enable HDMI on Ingenic JZ4780 based SoC, you should
>> + select this option..
>> +
>> endif
>> diff --git a/drivers/gpu/drm/ingenic/Makefile
>> b/drivers/gpu/drm/ingenic/Makefile
>> index d313326bdddb..3db9888a6c04 100644
>> --- a/drivers/gpu/drm/ingenic/Makefile
>> +++ b/drivers/gpu/drm/ingenic/Makefile
>> @@ -1,3 +1,4 @@
>> obj-$(CONFIG_DRM_INGENIC) += ingenic-drm.o
>> ingenic-drm-y = ingenic-drm-drv.o
>> ingenic-drm-$(CONFIG_DRM_INGENIC_IPU) += ingenic-ipu.o
>> +ingenic-drm-$(CONFIG_DRM_INGENIC_DW_HDMI) += ingenic-dw-hdmi.o
>> diff --git a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
>> b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
>> new file mode 100644
>> index ..dd9c94ae842e
>> --- /dev/null
>> +++ b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
>> @@ -0,0 +1,142 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/* Copyright (C) 2011-2013 Freescale Semiconductor, Inc.
>> + * Copyright (C) 2019, 2020 Paul Boddie
>> + *
>> + * Derived from dw_hdmi-imx.c with i.MX portions removed.
>> + * Probe and remove operations derived from rcar_dw_hdmi.c.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +static const struct dw_hdmi_mpll_config ingenic_mpll_cfg[] = {
>> +{ 4525, { { 0x01e0, 0x }, { 0x21e1, 0x }, { 0x41e2, 0x
>> } } },
>> +{ 9250, { { 0x0140, 0x0005 }, { 0x2141, 0x0005 }, { 0x4142, 0x0005
>> } } },
>> +{ 14850, { { 0x00a0, 0x000a }, { 0x20a1, 0x000a }, { 0x40a2, 0x000a
>> } } },
>> +{ 21600, { { 0x00a0, 0x000a }, { 0x2001, 0x000f }, { 0x4002, 0x000f
>> } } },
>> +{ ~0UL, { { 0x, 0x }, { 0x, 0x }, { 0x, 0x
>> } } }
>> +};
>> +
>> +static const struct dw_hdmi_curr_ctrl ingenic_cur_ctr[] = {
>> +/*pixelclk bpp8bpp10 bpp12 */
>> +{ 5400, { 0x091c, 0x091c, 0x06dc } },
>> +{ 5840, { 0x091c, 0x06dc, 0x06dc } },
>> +{ 7200, { 0x06dc, 0x06dc, 0x091c } },
>> +{ 7425, { 0x06dc, 0x0b5c, 0x091c } },
>> +{ 11880, { 0x091c, 0x091c, 0x06dc } },
>> +{ 21600, { 0x06dc, 0x0b5c, 0x091c } },
>> +{ ~0UL, { 0x, 0x, 0x } },
>> +};
>> +
>> +/*
>> + * Resistance term 133Ohm Cfg
>> + * PREEMP config 0.00
>> + * TX/CK level 10
>> + */
>> +static const struct dw_hdmi_phy_config ingenic_phy_config[] = {
>> +/*pixelclk symbol term vlev */
>> +{ 21600, 0x800d, 0x0005, 0x01ad},
>> +{ ~0UL, 0x, 0x, 0x}
>> +};
>> +
>> +static enum drm_mode_status
>> +ingenic_dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
>> + const struct drm_display_info *info,
>> + const struct drm_display_mode *mode)
>> +{
>> +if (mode->clock < 13500)
>> +return MODE_CLOCK_LOW;
>> +/* FIXME: Hardware is capable of 270MHz, but setup data is missing. */
>> +if (mode->clock > 216000)
>> +return MODE_CLOCK_HIGH;
>> +
>> +return MODE_OK;
>> +}
>> +
>> +static bool
>> +ingenic_dw_hdmi_mode_fixup(struct drm_bridge *bridge,
>> + const struct drm_display_mode *mode,
>> + struct drm_display_mode *adjusted_mode)
>> +{
>> +adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
>> +adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
>> +
>> +return true;
>> +}
>> +
>> +static const struct drm_bridge_timings ingenic_dw_hdmi_timings = {
>> +.input_bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
>> +};
>
> These should go in the intermediate encoder bridge callbacks Paul introduces
> in his patch at [1].
>
>
Re: [PATCH 2/2] [v2] qcom_scm: hide Kconfig symbol
On 9/28/21 2:50 AM, Arnd Bergmann wrote: From: Arnd Bergmann Now that SCM can be a loadable module, we have to add another dependency to avoid link failures when ipa or adreno-gpu are built-in: aarch64-linux-ld: drivers/net/ipa/ipa_main.o: in function `ipa_probe': ipa_main.c:(.text+0xfc4): undefined reference to `qcom_scm_is_available' ld.lld: error: undefined symbol: qcom_scm_is_available referenced by adreno_gpu.c gpu/drm/msm/adreno/adreno_gpu.o:(adreno_zap_shader_load) in archive drivers/built-in.a This can happen when CONFIG_ARCH_QCOM is disabled and we don't select QCOM_MDT_LOADER, but some other module selects QCOM_SCM. Ideally we'd use a similar dependency here to what we have for QCOM_RPROC_COMMON, but that causes dependency loops from other things selecting QCOM_SCM. This appears to be an endless problem, so try something different this time: - CONFIG_QCOM_SCM becomes a hidden symbol that nothing 'depends on' but that is simply selected by all of its users - All the stubs in include/linux/qcom_scm.h can go away - arm-smccc.h needs to provide a stub for __arm_smccc_smc() to allow compile-testing QCOM_SCM on all architectures. - To avoid a circular dependency chain involving RESET_CONTROLLER and PINCTRL_SUNXI, drop the 'select RESET_CONTROLLER' statement. According to my testing this still builds fine, and the QCOM platform selects this symbol already. Acked-by: Kalle Valo Signed-off-by: Arnd Bergmann --- Changes in v2: - drop the 'select RESET_CONTROLLER' line, rather than adding more of the same --- drivers/firmware/Kconfig| 5 +- drivers/gpu/drm/msm/Kconfig | 4 +- drivers/iommu/Kconfig | 2 +- drivers/media/platform/Kconfig | 2 +- drivers/mmc/host/Kconfig| 2 +- drivers/net/ipa/Kconfig | 1 + For drivers/net/ipa/Kconfig, looks good to me. Nice simplification. Acked-by: Alex Elder drivers/net/wireless/ath/ath10k/Kconfig | 2 +- drivers/pinctrl/qcom/Kconfig| 3 +- include/linux/arm-smccc.h | 10 include/linux/qcom_scm.h| 71 - 10 files changed, 20 insertions(+), 82 deletions(-) . . .
[PATCH v3 3/3] drm/msm/mdp5: Add configuration for MDP v1.16
From: Vladimir Lypak
MDP version v1.16 is almost identical to v1.15 with most significant
difference being presence of second DSI interface. MDP v1.16 is found on
SoCs such as MSM8x53, SDM450, SDM632 (All with Adreno 506).
Signed-off-by: Vladimir Lypak
Signed-off-by: Sireesh Kodali
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 89
1 file changed, 89 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
index 9741544ffc35..0d28c8ff4009 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
@@ -752,6 +752,94 @@ const struct mdp5_cfg_hw msm8x76_config = {
.max_clk = 36000,
};
+static const struct mdp5_cfg_hw msm8x53_config = {
+ .name = "msm8x53",
+ .mdp = {
+ .count = 1,
+ .caps = MDP_CAP_CDM |
+ MDP_CAP_SRC_SPLIT,
+ },
+ .ctl = {
+ .count = 3,
+ .base = { 0x01000, 0x01200, 0x01400 },
+ .flush_hw_mask = 0x,
+ },
+ .pipe_vig = {
+ .count = 1,
+ .base = { 0x04000 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SCALE |
+ MDP_PIPE_CAP_CSC|
+ MDP_PIPE_CAP_DECIMATION |
+ MDP_PIPE_CAP_SW_PIX_EXT |
+ 0,
+ },
+ .pipe_rgb = {
+ .count = 2,
+ .base = { 0x14000, 0x16000 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_DECIMATION |
+ MDP_PIPE_CAP_SW_PIX_EXT |
+ 0,
+ },
+ .pipe_dma = {
+ .count = 1,
+ .base = { 0x24000 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SW_PIX_EXT |
+ 0,
+ },
+ .pipe_cursor = {
+ .count = 1,
+ .base = { 0x34000 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SW_PIX_EXT |
+ MDP_PIPE_CAP_CURSOR |
+ 0,
+ },
+
+ .lm = {
+ .count = 3,
+ .base = { 0x44000, 0x45000 },
+ .instances = {
+ { .id = 0, .pp = 0, .dspp = 0,
+ .caps = MDP_LM_CAP_DISPLAY |
+ MDP_LM_CAP_PAIR },
+ { .id = 1, .pp = 1, .dspp = -1,
+ .caps = MDP_LM_CAP_DISPLAY },
+},
+ .nb_stages = 5,
+ .max_width = 2048,
+ .max_height = 0x,
+ },
+ .dspp = {
+ .count = 1,
+ .base = { 0x54000 },
+
+ },
+ .pp = {
+ .count = 2,
+ .base = { 0x7, 0x70800 },
+ },
+ .cdm = {
+ .count = 1,
+ .base = { 0x79200 },
+ },
+ .intf = {
+ .base = { 0x6a000, 0x6a800, 0x6b000 },
+ .connect = {
+ [0] = INTF_DISABLED,
+ [1] = INTF_DSI,
+ [2] = INTF_DSI,
+ },
+ },
+ .max_clk = 4,
+};
+
static const struct mdp5_cfg_hw msm8917_config = {
.name = "msm8917",
.mdp = {
@@ -1151,6 +1239,7 @@ static const struct mdp5_cfg_handler cfg_handlers_v1[] = {
{ .revision = 7, .config = { .hw = _config } },
{ .revision = 11, .config = { .hw = _config } },
{ .revision = 15, .config = { .hw = _config } },
+ { .revision = 16, .config = { .hw = _config } },
};
static const struct mdp5_cfg_handler cfg_handlers_v3[] = {
--
2.33.0
[PATCH v3 2/3] drm/msm/dsi: Add phy configuration for MSM8953
From: Vladimir Lypak
Add phy configuration for 14nm dsi phy found on MSM8953 SoC. Only
difference from existing configurations are io_start addresses.
Signed-off-by: Vladimir Lypak
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Sireesh Kodali
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 ++
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 1 +
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 21 +
3 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 8c65ef6968ca..9842e04b5858 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -627,6 +627,8 @@ static const struct of_device_id dsi_phy_dt_match[] = {
.data = _phy_14nm_cfgs },
{ .compatible = "qcom,dsi-phy-14nm-660",
.data = _phy_14nm_660_cfgs },
+ { .compatible = "qcom,dsi-phy-14nm-8953",
+ .data = _phy_14nm_8953_cfgs },
#endif
#ifdef CONFIG_DRM_MSM_DSI_10NM_PHY
{ .compatible = "qcom,dsi-phy-10nm",
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index b91303ada74f..4c8257581bfc 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -48,6 +48,7 @@ extern const struct msm_dsi_phy_cfg dsi_phy_20nm_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_8960_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_14nm_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_14nm_660_cfgs;
+extern const struct msm_dsi_phy_cfg dsi_phy_14nm_8953_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_10nm_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_10nm_8998_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_7nm_cfgs;
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
index d13552b2213b..9a6b1f0cbbaf 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
@@ -1065,3 +1065,24 @@ const struct msm_dsi_phy_cfg dsi_phy_14nm_660_cfgs = {
.io_start = { 0xc994400, 0xc996000 },
.num_dsi_phy = 2,
};
+
+const struct msm_dsi_phy_cfg dsi_phy_14nm_8953_cfgs = {
+ .has_phy_lane = true,
+ .reg_cfg = {
+ .num = 1,
+ .regs = {
+ {"vcca", 17000, 32},
+ },
+ },
+ .ops = {
+ .enable = dsi_14nm_phy_enable,
+ .disable = dsi_14nm_phy_disable,
+ .pll_init = dsi_pll_14nm_init,
+ .save_pll_state = dsi_14nm_pll_save_state,
+ .restore_pll_state = dsi_14nm_pll_restore_state,
+ },
+ .min_pll_rate = VCO_MIN_RATE,
+ .max_pll_rate = VCO_MAX_RATE,
+ .io_start = { 0x1a94400, 0x1a96400 },
+ .num_dsi_phy = 2,
+};
--
2.33.0
[PATCH v3 1/3] dt-bindings: msm: dsi: Add MSM8953 dsi phy
SoCs based on the MSM8953 platform use the 14nm DSI PHY driver Signed-off-by: Sireesh Kodali --- Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml index 064df50e21a5..81dbee4803c0 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml @@ -17,6 +17,7 @@ properties: enum: - qcom,dsi-phy-14nm - qcom,dsi-phy-14nm-660 + - qcom,dsi-phy-14nm-8953 reg: items: -- 2.33.0
[PATCH v3 0/3] MSM8953 MDP/DSI PHY enablement
This patch series adds support for the MDP and DSI PHY as found on the MSM8953 platform (APQ8053, SDM450, SDA450, SDM625, SDM626). All the SoCs on this platform use the adreno 506 GPU. Changes since v2: - Changed dt-bindings to use enum instead of oneOf Changes since v1: - Split the dsi phy doc changes into a separate commit - Add Reviewed-by tag to patch 2 Sireesh Kodali (1): dt-bindings: msm: dsi: Add MSM8953 dsi phy Vladimir Lypak (2): drm/msm/dsi: Add phy configuration for MSM8953 drm/msm/mdp5: Add configuration for MDP v1.16 .../bindings/display/msm/dsi-phy-14nm.yaml| 1 + drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 89 +++ drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 1 + drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c| 21 + 5 files changed, 114 insertions(+) -- 2.33.0
[Bug 212425] Kernel warning at drivers/gpu/drm/ttm/ttm_bo.c:517
https://bugzilla.kernel.org/show_bug.cgi?id=212425 Grzegorz Kowal (custos.men...@gmail.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v4 06/10] drm/ingenic: Add dw-hdmi driver for jz4780
On 27/09/2021 18:44, H. Nikolaus Schaller wrote:
> From: Paul Boddie
>
> A specialisation of the generic Synopsys HDMI driver is employed for JZ4780
> HDMI support. This requires a new driver, plus device tree and configuration
> modifications.
>
> Signed-off-by: Paul Boddie
> Signed-off-by: Ezequiel Garcia
> Signed-off-by: H. Nikolaus Schaller
> ---
> drivers/gpu/drm/ingenic/Kconfig | 9 ++
> drivers/gpu/drm/ingenic/Makefile | 1 +
> drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c | 142 ++
> 3 files changed, 152 insertions(+)
> create mode 100644 drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
>
> diff --git a/drivers/gpu/drm/ingenic/Kconfig b/drivers/gpu/drm/ingenic/Kconfig
> index 3b57f8be007c..4c7d311fbeff 100644
> --- a/drivers/gpu/drm/ingenic/Kconfig
> +++ b/drivers/gpu/drm/ingenic/Kconfig
> @@ -25,4 +25,13 @@ config DRM_INGENIC_IPU
>
> The Image Processing Unit (IPU) will appear as a second primary plane.
>
> +config DRM_INGENIC_DW_HDMI
> + bool "Ingenic specific support for Synopsys DW HDMI"
> + depends on MACH_JZ4780
> + select DRM_DW_HDMI
> + help
> + Choose this option to enable Synopsys DesignWare HDMI based driver.
> + If you want to enable HDMI on Ingenic JZ4780 based SoC, you should
> + select this option..
> +
> endif
> diff --git a/drivers/gpu/drm/ingenic/Makefile
> b/drivers/gpu/drm/ingenic/Makefile
> index d313326bdddb..3db9888a6c04 100644
> --- a/drivers/gpu/drm/ingenic/Makefile
> +++ b/drivers/gpu/drm/ingenic/Makefile
> @@ -1,3 +1,4 @@
> obj-$(CONFIG_DRM_INGENIC) += ingenic-drm.o
> ingenic-drm-y = ingenic-drm-drv.o
> ingenic-drm-$(CONFIG_DRM_INGENIC_IPU) += ingenic-ipu.o
> +ingenic-drm-$(CONFIG_DRM_INGENIC_DW_HDMI) += ingenic-dw-hdmi.o
> diff --git a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
> b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
> new file mode 100644
> index ..dd9c94ae842e
> --- /dev/null
> +++ b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
> @@ -0,0 +1,142 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (C) 2011-2013 Freescale Semiconductor, Inc.
> + * Copyright (C) 2019, 2020 Paul Boddie
> + *
> + * Derived from dw_hdmi-imx.c with i.MX portions removed.
> + * Probe and remove operations derived from rcar_dw_hdmi.c.
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +static const struct dw_hdmi_mpll_config ingenic_mpll_cfg[] = {
> + { 4525, { { 0x01e0, 0x }, { 0x21e1, 0x }, { 0x41e2, 0x
> } } },
> + { 9250, { { 0x0140, 0x0005 }, { 0x2141, 0x0005 }, { 0x4142, 0x0005
> } } },
> + { 14850, { { 0x00a0, 0x000a }, { 0x20a1, 0x000a }, { 0x40a2, 0x000a
> } } },
> + { 21600, { { 0x00a0, 0x000a }, { 0x2001, 0x000f }, { 0x4002, 0x000f
> } } },
> + { ~0UL, { { 0x, 0x }, { 0x, 0x }, { 0x, 0x
> } } }
> +};
> +
> +static const struct dw_hdmi_curr_ctrl ingenic_cur_ctr[] = {
> + /*pixelclk bpp8bpp10 bpp12 */
> + { 5400, { 0x091c, 0x091c, 0x06dc } },
> + { 5840, { 0x091c, 0x06dc, 0x06dc } },
> + { 7200, { 0x06dc, 0x06dc, 0x091c } },
> + { 7425, { 0x06dc, 0x0b5c, 0x091c } },
> + { 11880, { 0x091c, 0x091c, 0x06dc } },
> + { 21600, { 0x06dc, 0x0b5c, 0x091c } },
> + { ~0UL, { 0x, 0x, 0x } },
> +};
> +
> +/*
> + * Resistance term 133Ohm Cfg
> + * PREEMP config 0.00
> + * TX/CK level 10
> + */
> +static const struct dw_hdmi_phy_config ingenic_phy_config[] = {
> + /*pixelclk symbol term vlev */
> + { 21600, 0x800d, 0x0005, 0x01ad},
> + { ~0UL, 0x, 0x, 0x}
> +};
> +
> +static enum drm_mode_status
> +ingenic_dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
> +const struct drm_display_info *info,
> +const struct drm_display_mode *mode)
> +{
> + if (mode->clock < 13500)
> + return MODE_CLOCK_LOW;
> + /* FIXME: Hardware is capable of 270MHz, but setup data is missing. */
> + if (mode->clock > 216000)
> + return MODE_CLOCK_HIGH;
> +
> + return MODE_OK;
> +}
> +
> +static bool
> +ingenic_dw_hdmi_mode_fixup(struct drm_bridge *bridge,
> +const struct drm_display_mode *mode,
> +struct drm_display_mode *adjusted_mode)
> +{
> + adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
> + adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
> +
> + return true;
> +}
> +
> +static const struct drm_bridge_timings ingenic_dw_hdmi_timings = {
> + .input_bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
> +};
These should go in the intermediate encoder bridge callbacks Paul introduces in
his patch at [1].
With that patch 4 can be dropped.
[1] https://lore.kernel.org/r/2021092220.496871-7-p...@crapouillou.net
Neil
> +
> +static struct dw_hdmi_plat_data
Re: [PATCH v1 2/5] drm: mxsfb: Set proper default bus format when using a bridge
On 9/28/21 2:16 PM, Guido Günther wrote:
If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
returned. Fallback to a reasonable default (MEDIA_BUS_FMT_RGB888_1X24) in
that case.
This unbreaks e.g. using mxsfb with the nwl bridge and mipi panels.
Fixes: b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge if
present")
Reported-by: Martin Kepplinger
Signed-off-by: Guido Günther
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index d6abd2077114..f4be16f5c20b 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -369,6 +369,11 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc,
drm_atomic_get_new_bridge_state(state,
mxsfb->bridge);
bus_format = bridge_state->input_bus_cfg.format;
+ if (bus_format == MEDIA_BUS_FMT_FIXED) {
+ dev_warn_once(drm->dev,
+ "Bridge does not provide bus format. Please
fix.");
Fix what ? Oh ... the bridge driver ?
Maybe such a hint should be in the warning message. And it might be
useful to explain how to fix that bridge driver, or at least provide
some reference to an example (like this nwl patch series).
+ bus_format = MEDIA_BUS_FMT_RGB888_1X24;
The warning should also mention that the driver is falling back to this
mode.
Re: [PATCH] drm: mxsfb: Set proper default bus format when using a bridge
Hi,
On Tue, Sep 28, 2021 at 11:27:49AM +0200, Lucas Stach wrote:
> Am Dienstag, dem 28.09.2021 um 11:19 +0200 schrieb Guido Günther:
> > Hi,
> > On Tue, Sep 28, 2021 at 11:08:58AM +0200, Marek Vasut wrote:
> > > On 9/28/21 10:55 AM, Guido Günther wrote:
> > > > If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
> > > > returned. Fallback to a reasonable default (MEDIA_BUS_FMT_RGB888_1X24)
> > > > in
> > > > that case.
> > > >
> > > > This unbreaks e.g. using mxsfb with the nwl bridge and mipi panels.
> > > >
> > > > Fixes: b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest
> > > > bridge if present")
> > > >
> > > > Signed-off-by: Guido Günther
> > > > ---
> > > >
> > > > I'll look at what needs to be done in nwl separately but this also
> > > > unbreaks other bridge seupts that don't to format negotiation yet.
> > > >
> > > > drivers/gpu/drm/mxsfb/mxsfb_kms.c | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > > > b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > > > index af6c620adf6e..4ef94cf686b0 100644
> > > > --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > > > +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > > > @@ -369,6 +369,8 @@ static void mxsfb_crtc_atomic_enable(struct
> > > > drm_crtc *crtc,
> > > > drm_atomic_get_new_bridge_state(state,
> > > > mxsfb->bridge);
> > > > bus_format = bridge_state->input_bus_cfg.format;
> > > > + if (bus_format == MEDIA_BUS_FMT_FIXED)
> > > > + bus_format = MEDIA_BUS_FMT_RGB888_1X24;
> > >
> > > Shouldn't the NWL bridge return the correct format ?
> >
> > Yes it should and I'll send a separate patch for that but we currently
> > don't do anything meaningful at all if the bridge doesn't do format
> > negotiation and then fail setup in mxsfb_set_formats().
> >
> > I think we should at least preserve the status quo (as we do with the
> > non bridge case in b776b0f00f24 too).
> >
> > We could have a warning to spot drivers that don't do that yet and hence
> > the generic code returns MEDIA_BUS_FMT_FIXED.
> >
> That sounds sensible. Using a default format if we don't know what to
> do is going to be a unpleasant surprise for those with a display
> pipeline that doesn't work with the default format. So please add a
> dev_warn when we are doing this fallback.
>
> Also I would argue that the NWL fix is the patch that should go in the
> stable tree. This one should only be a additional safety net, so I
> would drop the Fixes tag.
Dropped and folded into the small series with other fixes needed to
get get the bus format propagated up from the panel.
Cheers,
-- Guido
>
> Regards,
> Lucas
>
[PATCH v1 2/5] drm: mxsfb: Set proper default bus format when using a bridge
If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
returned. Fallback to a reasonable default (MEDIA_BUS_FMT_RGB888_1X24) in
that case.
This unbreaks e.g. using mxsfb with the nwl bridge and mipi panels.
Fixes: b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge if
present")
Reported-by: Martin Kepplinger
Signed-off-by: Guido Günther
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index d6abd2077114..f4be16f5c20b 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -369,6 +369,11 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc,
drm_atomic_get_new_bridge_state(state,
mxsfb->bridge);
bus_format = bridge_state->input_bus_cfg.format;
+ if (bus_format == MEDIA_BUS_FMT_FIXED) {
+ dev_warn_once(drm->dev,
+ "Bridge does not provide bus format.
Please fix.");
+ bus_format = MEDIA_BUS_FMT_RGB888_1X24;
+ }
}
/* If there is no bridge, use bus format from connector */
--
2.33.0
[PATCH v1 3/5] drm/bridge: nwl-dsi: Add atomic_get_input_bus_fmts
Components further up in the chain might ask us for supported formats.
Without this MEDIA_BUS_FMT_FIXED is assumed which then breaks display
output with mxsfb since it can't determine a proper bus format.
We handle the bus formats that correspond to the DSI formats the bridge
can potentially output (see chapter 13.6 of the i.MX 8MQ reference
manual) - which matches what xsfb can input.
Fixes: b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge if
present")
Signed-off-by: Guido Günther
---
drivers/gpu/drm/bridge/nwl-dsi.c | 35
1 file changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index a251cc1f088f..27c80d36846b 100644
--- a/drivers/gpu/drm/bridge/nwl-dsi.c
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -1234,6 +1234,40 @@ static void nwl_dsi_bridge_detach(struct drm_bridge
*bridge)
drm_of_panel_bridge_remove(dsi->dev->of_node, 1, 0);
}
+static u32 *nwl_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
+struct drm_bridge_state
*bridge_state,
+struct drm_crtc_state
*crtc_state,
+struct drm_connector_state
*conn_state,
+u32 output_fmt,
+unsigned int *num_input_fmts)
+{
+ u32 *input_fmts, input_fmt;
+
+ *num_input_fmts = 0;
+
+ switch (output_fmt) {
+ /* If MEDIA_BUS_FMT_FIXED is tested, return default bus format */
+ case MEDIA_BUS_FMT_FIXED:
+ input_fmt = MEDIA_BUS_FMT_RGB888_1X24;
+ break;
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ case MEDIA_BUS_FMT_RGB666_1X18:
+ case MEDIA_BUS_FMT_RGB565_1X16:
+ input_fmt = output_fmt;
+ break;
+ default:
+ return NULL;
+ }
+
+ input_fmts = kcalloc(1, sizeof(*input_fmts), GFP_KERNEL);
+ if (!input_fmts)
+ return NULL;
+ input_fmts[0] = input_fmt;
+ *num_input_fmts = 1;
+
+ return input_fmts;
+}
+
static const struct drm_bridge_funcs nwl_dsi_bridge_funcs = {
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
@@ -1241,6 +1275,7 @@ static const struct drm_bridge_funcs nwl_dsi_bridge_funcs
= {
.atomic_check = nwl_dsi_bridge_atomic_check,
.atomic_enable = nwl_dsi_bridge_atomic_enable,
.atomic_disable = nwl_dsi_bridge_atomic_disable,
+ .atomic_get_input_bus_fmts = nwl_bridge_atomic_get_input_bus_fmts,
.mode_set = nwl_dsi_bridge_mode_set,
.mode_valid = nwl_dsi_bridge_mode_valid,
.attach = nwl_dsi_bridge_attach,
--
2.33.0
[PATCH v1 5/5] drm/panel: st7703: Add media bus format
This allows the DSI bridge to detect the correct bus format.
We currently only support MEDIA_BUS_FMT_RGB888_1X24.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
index a2c303e5732c..73f69c929a75 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
@@ -453,6 +453,10 @@ static int st7703_prepare(struct drm_panel *panel)
return ret;
}
+static const u32 mantix_bus_formats[] = {
+ MEDIA_BUS_FMT_RGB888_1X24,
+};
+
static int st7703_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
{
@@ -474,6 +478,10 @@ static int st7703_get_modes(struct drm_panel *panel,
connector->display_info.height_mm = mode->height_mm;
drm_mode_probed_add(connector, mode);
+ drm_display_info_set_bus_formats(>display_info,
+mantix_bus_formats,
+ARRAY_SIZE(mantix_bus_formats));
+
return 1;
}
--
2.33.0
[PATCH v1 4/5] drm/panel: mantix: Add media bus format
This allows the DSI bridge to detect the correct bus format.
We currently only support MEDIA_BUS_FMT_RGB888_1X24.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
index f0e9bce23c41..d6bcf1045255 100644
--- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -232,6 +233,10 @@ static const struct drm_display_mode default_mode_ys = {
.height_mm = 130,
};
+static const u32 mantix_bus_formats[] = {
+ MEDIA_BUS_FMT_RGB888_1X24,
+};
+
static int mantix_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
{
@@ -253,6 +258,10 @@ static int mantix_get_modes(struct drm_panel *panel,
connector->display_info.height_mm = mode->height_mm;
drm_mode_probed_add(connector, mode);
+ drm_display_info_set_bus_formats(>display_info,
+mantix_bus_formats,
+ARRAY_SIZE(mantix_bus_formats));
+
return 1;
}
--
2.33.0
