Re: [PATCH 13/28] drm/mediatek: add connection from RDMA0 to DSI3
Hi, Stu:
Two inline comment.
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add the connection from RDMA0 to DSI3
>
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index c08aed8dae44..fed1b5704355 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -83,6 +83,7 @@
> #define GAMMA_MOUT_EN_RDMA1 0x1
> #define RDMA0_MOUT_DPI0 0x2
> #define RDMA0_MOUT_DSI2 0x4
> +#define RDMA0_MOUT_DSI3 0x5
Usually, each bit of a mout register represent a output enable. Is this
value 0x5 is a correct value?
> #define RDMA1_MOUT_DPI0 0x2
> #define DPI0_SEL_IN_RDMA10x1
> #define COLOR1_SEL_IN_OVL1 0x1
> @@ -164,6 +165,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id
> cur,
> } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI2) {
> *addr = DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN;
> value = RDMA0_MOUT_DSI2;
> + } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI3) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN;
> + value = RDMA0_MOUT_DSI3;
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> value = RDMA1_MOUT_DPI0;
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index fe6fdc021fc7..22f4c72fa785 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -228,7 +228,7 @@ static const struct mtk_ddp_comp_match
> mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_DSI0]= { MTK_DSI,0, NULL },
> [DDP_COMPONENT_DSI1]= { MTK_DSI,1, NULL },
> [DDP_COMPONENT_DSI2]= { MTK_DSI,2, NULL },
> - [DDP_COMPONENT_DSI2]= { MTK_DSI,3, NULL },
> + [DDP_COMPONENT_DSI3]= { MTK_DSI,3, NULL },
I think this is not related to this patch.
Regards,
CK
> [DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, _gamma },
> [DDP_COMPONENT_OD0] = { MTK_DISP_OD,0, _od },
> [DDP_COMPONENT_OD1] = { MTK_DISP_OD,1, _od },
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/28] drm/mediatek: add connection from RDMA0 to DSI2
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add the connection from RDMA0 to DSI2
>
> Signed-off-by: Stu Hsieh
Reviewed-by: CK Hu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index d7953f2f6a36..c08aed8dae44 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -82,6 +82,7 @@
> #define OVL1_MOUT_EN_COLOR1 0x1
> #define GAMMA_MOUT_EN_RDMA1 0x1
> #define RDMA0_MOUT_DPI0 0x2
> +#define RDMA0_MOUT_DSI2 0x4
> #define RDMA1_MOUT_DPI0 0x2
> #define DPI0_SEL_IN_RDMA10x1
> #define COLOR1_SEL_IN_OVL1 0x1
> @@ -160,6 +161,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id
> cur,
> } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI0) {
> *addr = DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN;
> value = RDMA0_MOUT_DPI0;
> + } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI2) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN;
> + value = RDMA0_MOUT_DSI2;
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> value = RDMA1_MOUT_DPI0;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/28] drm/mediatek: add connection from RDMA0 to DPI0
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add the connection from RDMA0 to DPI0
>
> Signed-off-by: Stu Hsieh
Reviewed-by: CK Hu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 8bfc0debd2c2..d7953f2f6a36 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -29,6 +29,7 @@
> #define DISP_REG_CONFIG_DISP_COLOR0_SEL_IN 0x084
> #define DISP_REG_CONFIG_DISP_COLOR1_SEL_IN 0x088
> #define DISP_REG_CONFIG_DPI_SEL_IN 0x0ac
> +#define DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN 0x0c4
> #define DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN 0x0c8
> #define DISP_REG_CONFIG_MMSYS_CG_CON00x100
>
> @@ -80,6 +81,7 @@
> #define COLOR0_SEL_IN_OVL0 0x1
> #define OVL1_MOUT_EN_COLOR1 0x1
> #define GAMMA_MOUT_EN_RDMA1 0x1
> +#define RDMA0_MOUT_DPI0 0x2
> #define RDMA1_MOUT_DPI0 0x2
> #define DPI0_SEL_IN_RDMA10x1
> #define COLOR1_SEL_IN_OVL1 0x1
> @@ -155,6 +157,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id
> cur,
> } else if (cur == DDP_COMPONENT_OD1 && next == DDP_COMPONENT_RDMA1) {
> *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
> value = OD1_MOUT_EN_RDMA1;
> + } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI0) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN;
> + value = RDMA0_MOUT_DPI0;
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> value = RDMA1_MOUT_DPI0;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/28] drm/mediatek: add component DSI3
Hi, Stu:
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add the component DSI3
>
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 192f7374d988..fe6fdc021fc7 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -228,6 +228,7 @@ static const struct mtk_ddp_comp_match
> mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_DSI0]= { MTK_DSI,0, NULL },
> [DDP_COMPONENT_DSI1]= { MTK_DSI,1, NULL },
> [DDP_COMPONENT_DSI2]= { MTK_DSI,2, NULL },
> + [DDP_COMPONENT_DSI2]= { MTK_DSI,3, NULL },
DDP_COMPONENT_DSI3
Regards,
CK
> [DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, _gamma },
> [DDP_COMPONENT_OD0] = { MTK_DISP_OD,0, _od },
> [DDP_COMPONENT_OD1] = { MTK_DISP_OD,1, _od },
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 8d152b337f15..7413ffeb3c9d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -51,6 +51,7 @@ enum mtk_ddp_comp_id {
> DDP_COMPONENT_DSI0,
> DDP_COMPONENT_DSI1,
> DDP_COMPONENT_DSI2,
> + DDP_COMPONENT_DSI3,
> DDP_COMPONENT_GAMMA,
> DDP_COMPONENT_OD0,
> DDP_COMPONENT_OD1,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/28] drm/mediatek: add component DSI2
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add the component DSI2
>
> Signed-off-by: Stu Hsieh
Reviewed-by: CK Hu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 4f9d81025d69..192f7374d988 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -227,6 +227,7 @@ static const struct mtk_ddp_comp_match
> mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_DPI1]= { MTK_DPI,1, NULL },
> [DDP_COMPONENT_DSI0]= { MTK_DSI,0, NULL },
> [DDP_COMPONENT_DSI1]= { MTK_DSI,1, NULL },
> + [DDP_COMPONENT_DSI2]= { MTK_DSI,2, NULL },
> [DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, _gamma },
> [DDP_COMPONENT_OD0] = { MTK_DISP_OD,0, _od },
> [DDP_COMPONENT_OD1] = { MTK_DISP_OD,1, _od },
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 54c99c169093..8d152b337f15 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -50,6 +50,7 @@ enum mtk_ddp_comp_id {
> DDP_COMPONENT_DPI1,
> DDP_COMPONENT_DSI0,
> DDP_COMPONENT_DSI1,
> + DDP_COMPONENT_DSI2,
> DDP_COMPONENT_GAMMA,
> DDP_COMPONENT_OD0,
> DDP_COMPONENT_OD1,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/28] drm/mediatek: add component DPI1
On Mon, 2018-06-11 at 11:25 +0800, Stu Hsieh wrote:
> This patch add the component DPI1
>
> Signed-off-by: Stu Hsieh
Reviewed-by: CK Hu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 86e8c9e5df41..4f9d81025d69 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -224,6 +224,7 @@ static const struct mtk_ddp_comp_match
> mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_COLOR0] = { MTK_DISP_COLOR, 0, NULL },
> [DDP_COMPONENT_COLOR1] = { MTK_DISP_COLOR, 1, NULL },
> [DDP_COMPONENT_DPI0]= { MTK_DPI,0, NULL },
> + [DDP_COMPONENT_DPI1]= { MTK_DPI,1, NULL },
> [DDP_COMPONENT_DSI0]= { MTK_DSI,0, NULL },
> [DDP_COMPONENT_DSI1]= { MTK_DSI,1, NULL },
> [DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, _gamma },
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index e00c2e798abd..54c99c169093 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -47,6 +47,7 @@ enum mtk_ddp_comp_id {
> DDP_COMPONENT_COLOR0,
> DDP_COMPONENT_COLOR1,
> DDP_COMPONENT_DPI0,
> + DDP_COMPONENT_DPI1,
> DDP_COMPONENT_DSI0,
> DDP_COMPONENT_DSI1,
> DDP_COMPONENT_GAMMA,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/28] drm/mediatek: add ddp component OD1
On Mon, 2018-06-11 at 11:25 +0800, Stu Hsieh wrote:
> This patch add the component OD1 and
> rename the OD to OD0
>
> Signed-off-by: Stu Hsieh
Reviewed-by: CK Hu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 ++--
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 3 ++-
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 3 ++-
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
> 4 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 7217665f4b5d..58e44349e315 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -114,7 +114,7 @@ static const unsigned int
> mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
> [DDP_COMPONENT_COLOR1] = MT8173_MUTEX_MOD_DISP_COLOR1,
> [DDP_COMPONENT_GAMMA] = MT8173_MUTEX_MOD_DISP_GAMMA,
> - [DDP_COMPONENT_OD] = MT8173_MUTEX_MOD_DISP_OD,
> + [DDP_COMPONENT_OD0] = MT8173_MUTEX_MOD_DISP_OD,
> [DDP_COMPONENT_OVL0] = MT8173_MUTEX_MOD_DISP_OVL0,
> [DDP_COMPONENT_OVL1] = MT8173_MUTEX_MOD_DISP_OVL1,
> [DDP_COMPONENT_PWM0] = MT8173_MUTEX_MOD_DISP_PWM0,
> @@ -139,7 +139,7 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id
> cur,
> } else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_RDMA0) {
> *addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
> value = OVL_MOUT_EN_RDMA;
> - } else if (cur == DDP_COMPONENT_OD && next == DDP_COMPONENT_RDMA0) {
> + } else if (cur == DDP_COMPONENT_OD0 && next == DDP_COMPONENT_RDMA0) {
> *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
> value = OD_MOUT_EN_RDMA0;
> } else if (cur == DDP_COMPONENT_UFOE && next == DDP_COMPONENT_DSI0) {
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 0919039805aa..87acf6be87f6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -227,7 +227,8 @@ static const struct mtk_ddp_comp_match
> mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_DSI0]= { MTK_DSI,0, NULL },
> [DDP_COMPONENT_DSI1]= { MTK_DSI,1, NULL },
> [DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, _gamma },
> - [DDP_COMPONENT_OD] = { MTK_DISP_OD,0, _od },
> + [DDP_COMPONENT_OD0] = { MTK_DISP_OD,0, _od },
> + [DDP_COMPONENT_OD1] = { MTK_DISP_OD,1, _od },
> [DDP_COMPONENT_OVL0]= { MTK_DISP_OVL, 0, NULL },
> [DDP_COMPONENT_OVL1]= { MTK_DISP_OVL, 1, NULL },
> [DDP_COMPONENT_PWM0]= { MTK_DISP_PWM, 0, NULL },
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index eee3c0cc2632..9b19fc4423f1 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -50,7 +50,8 @@ enum mtk_ddp_comp_id {
> DDP_COMPONENT_DSI0,
> DDP_COMPONENT_DSI1,
> DDP_COMPONENT_GAMMA,
> - DDP_COMPONENT_OD,
> + DDP_COMPONENT_OD0,
> + DDP_COMPONENT_OD1,
> DDP_COMPONENT_OVL0,
> DDP_COMPONENT_OVL1,
> DDP_COMPONENT_PWM0,
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index a415260f3d5f..08d5d0b47bfe 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -150,7 +150,7 @@ static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] =
> {
> DDP_COMPONENT_OVL0,
> DDP_COMPONENT_COLOR0,
> DDP_COMPONENT_AAL0,
> - DDP_COMPONENT_OD,
> + DDP_COMPONENT_OD0,
> DDP_COMPONENT_RDMA0,
> DDP_COMPONENT_UFOE,
> DDP_COMPONENT_DSI0,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199959] amdgpu, regression?: system freezes after resume
https://bugzilla.kernel.org/show_bug.cgi?id=199959 --- Comment #21 from Alexander Mezin (mezin.alexan...@gmail.com) --- Not sure if it'll help, but I've added more logging here: --- a/drivers/pci/setup-res.c +++ b/drivers/pci/setup-res.c @@ -436,6 +436,8 @@ int pci_resize_resource(struct pci_dev *dev, int resno, int size) if (ret) return ret; + pci_info(dev, "BAR %d: resized from %d to %d", resno, old, size); + res->end = res->start + pci_rebar_size_to_bytes(size) - 1; /* Check if the new config works by trying to assign everything. */ And suspend-resume with "re-resize" hack shows this: amdgpu :65:00.0: BAR 0: resized from 8 to 13 (this message appears in dmesg two times, first one on boot, second one during resume, exactly the same message in both cases) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/27] clk: sunxi-ng: r40: Allow setting parent rate to display related clocks
On Wed, Jun 13, 2018 at 4:00 AM, Jernej Skrabec wrote: > Display related peripherals need precise clocks to operate correctly. > > Allow DE2, TCONs and HDMI to set parent clock. > > Signed-off-by: Jernej Skrabec Reviewed-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/27] clk: sunxi-ng: r40: Add minimal rate for video PLLs
On Wed, Jun 13, 2018 at 4:00 AM, Jernej Skrabec wrote: > According to documentation and experience with other similar SoCs, video > PLLs don't work stable if their output frequency is set below 192 MHz. > > Because of that, set minimal rate to both R40 video PLLs to 192 MHz. > > Signed-off-by: Jernej Skrabec Reviewed-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199959] amdgpu, regression?: system freezes after resume
https://bugzilla.kernel.org/show_bug.cgi?id=199959 --- Comment #20 from Alexander Mezin (mezin.alexan...@gmail.com) --- Created attachment 276521 --> https://bugzilla.kernel.org/attachment.cgi?id=276521=edit lspci after resume with hack -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199959] amdgpu, regression?: system freezes after resume
https://bugzilla.kernel.org/show_bug.cgi?id=199959 --- Comment #19 from Alexander Mezin (mezin.alexan...@gmail.com) --- Created attachment 276519 --> https://bugzilla.kernel.org/attachment.cgi?id=276519=edit lspci after resume, no hack -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199959] amdgpu, regression?: system freezes after resume
https://bugzilla.kernel.org/show_bug.cgi?id=199959 --- Comment #18 from Alexander Mezin (mezin.alexan...@gmail.com) --- Created attachment 276517 --> https://bugzilla.kernel.org/attachment.cgi?id=276517=edit lspci before suspend -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199959] amdgpu, regression?: system freezes after resume
https://bugzilla.kernel.org/show_bug.cgi?id=199959 --- Comment #17 from Alexander Mezin (mezin.alexan...@gmail.com) --- setpci - exactly the same output in all 3 cases (verified with 'diff' to be sure): 0407 0001 fff1 00e0 00e2 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 198713] AMD DC crashes when computing clocks/detecting freesync
https://bugzilla.kernel.org/show_bug.cgi?id=198713 --- Comment #6 from Nicholas Johnson (nicholas.john...@outlook.com.au) --- If you are referring to my comment, mine was with 4.17 kernel (latest stable release). I was just commenting on this one (4.15) because it looks like the same bug, and I am highlighting that they still have not fixed it in 4.17. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: RE: [Intel-gfx] DRM Inquiry
Hi Jani, I like to understand how the DRM_DP_AUX_CHARDEV=y kick off. Regards,John On Monday, June 11, 2018, 7:36:51 PM GMT+8, Jani Nikula wrote: On Mon, 11 Jun 2018, John Sledge wrote: > Thanks for the help. I was able to manage your advice on the > drm_dp_aux_chardev. Though I still need to learn more about the DRM vs > kernel process flow. Like for example, upon changing/adding > DRM_DP_AUX_CHARDEV in kernel .config, How did DRM_DP_AUX_CHARDEV was > being invoke here? From the code, I notice character device will be > created under drm_dp_aux_register_devnode method. > For example I made two kernel 4.6 with DRM_DP_AUX_CHARDEV=y and > another kernel 4.6 with DRM_DP_AUX_CHARDEV=n. > So the steps was to build and install the kernel with > DRM_DP_AUX_CHARDEV=y. Once finish, I tried to reboot and verified the > /dev/drm_dp_aux_chardev* and it was there. > Now, I will change the .config DRM_DP_AUXCHARDEV=n then follow the > steps below to manual build the DRM module. I'm not really sure if I'm > correct on this one. Why are you disabling it again? Just enable the config, use the resulting kernel, and do the rest in userspace. > 1. rm /dev/drm_dp_aux_chardev* 2. make modules_prepare3. make > SUBDIRS=scripts/mod4. make SUBDIRS=drivers/gpu/drm modules5. cp > drivers/gpu/drm/i915/i915.ko > /lib/modules/4.6.0-94.11-default/kernel/drivers/gpu/drm6. ... I copy > all .ko under drm to the lib/modules/4.67. depmod8. modprobe > i9159. ... I also modprobe all modules10. reboot > The result was /dev/drm_dp_aux_chardev* was still there. My > expectation was it would disrepair or remove. Don't do this. I don't understand what you're trying to do. > Please have comments and advice. Please explain what you're trying to do to begin with. What's your end goal? BR, Jani. PS. Please prefer plain text instead of html on the list. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DPU PATCH 3/4] drm/msm/dpu: remove resource pool manager
resource pool manager utility was introduced to manage
rotator sessions. Removing the support as the rotator
feature doesn't exist.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 494 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 84 --
2 files changed, 578 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 9ca8325..426e2ad 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -98,476 +98,6 @@ static inline int _dpu_crtc_power_enable(struct dpu_crtc
*dpu_crtc, bool enable)
return 0;
}
-/**
- * _dpu_crtc_rp_to_crtc - get crtc from resource pool object
- * @rp: Pointer to resource pool
- * return: Pointer to drm crtc if success; null otherwise
- */
-static struct drm_crtc *_dpu_crtc_rp_to_crtc(struct dpu_crtc_respool *rp)
-{
- if (!rp)
- return NULL;
-
- return container_of(rp, struct dpu_crtc_state, rp)->base.crtc;
-}
-
-/**
- * _dpu_crtc_rp_reclaim - reclaim unused, or all if forced, resources in pool
- * @rp: Pointer to resource pool
- * @force: True to reclaim all resources; otherwise, reclaim only unused ones
- * return: None
- */
-static void _dpu_crtc_rp_reclaim(struct dpu_crtc_respool *rp, bool force)
-{
- struct dpu_crtc_res *res, *next;
- struct drm_crtc *crtc;
-
- crtc = _dpu_crtc_rp_to_crtc(rp);
- if (!crtc) {
- DPU_ERROR("invalid crtc\n");
- return;
- }
-
- DPU_DEBUG("crtc%d.%u %s\n", crtc->base.id, rp->sequence_id,
- force ? "destroy" : "free_unused");
-
- list_for_each_entry_safe(res, next, >res_list, list) {
- if (!force && !(res->flags & DPU_CRTC_RES_FLAG_FREE))
- continue;
- DPU_DEBUG("crtc%d.%u reclaim res:0x%x/0x%llx/%pK/%d\n",
- crtc->base.id, rp->sequence_id,
- res->type, res->tag, res->val,
- atomic_read(>refcount));
- list_del(>list);
- if (res->ops.put)
- res->ops.put(res->val);
- kfree(res);
- }
-}
-
-/**
- * _dpu_crtc_rp_free_unused - free unused resource in pool
- * @rp: Pointer to resource pool
- * return: none
- */
-static void _dpu_crtc_rp_free_unused(struct dpu_crtc_respool *rp)
-{
- mutex_lock(rp->rp_lock);
- _dpu_crtc_rp_reclaim(rp, false);
- mutex_unlock(rp->rp_lock);
-}
-
-/**
- * _dpu_crtc_rp_destroy - destroy resource pool
- * @rp: Pointer to resource pool
- * return: None
- */
-static void _dpu_crtc_rp_destroy(struct dpu_crtc_respool *rp)
-{
- mutex_lock(rp->rp_lock);
- list_del_init(>rp_list);
- _dpu_crtc_rp_reclaim(rp, true);
- mutex_unlock(rp->rp_lock);
-}
-
-/**
- * _dpu_crtc_hw_blk_get - get callback for hardware block
- * @val: Resource handle
- * @type: Resource type
- * @tag: Search tag for given resource
- * return: Resource handle
- */
-static void *_dpu_crtc_hw_blk_get(void *val, u32 type, u64 tag)
-{
- DPU_DEBUG("res:%d/0x%llx/%pK\n", type, tag, val);
- return dpu_hw_blk_get(val, type, tag);
-}
-
-/**
- * _dpu_crtc_hw_blk_put - put callback for hardware block
- * @val: Resource handle
- * return: None
- */
-static void _dpu_crtc_hw_blk_put(void *val)
-{
- DPU_DEBUG("res://%pK\n", val);
- dpu_hw_blk_put(val);
-}
-
-/**
- * _dpu_crtc_rp_duplicate - duplicate resource pool and reset reference count
- * @rp: Pointer to original resource pool
- * @dup_rp: Pointer to duplicated resource pool
- * return: None
- */
-static void _dpu_crtc_rp_duplicate(struct dpu_crtc_respool *rp,
- struct dpu_crtc_respool *dup_rp)
-{
- struct dpu_crtc_res *res, *dup_res;
- struct drm_crtc *crtc;
-
- if (!rp || !dup_rp || !rp->rp_head) {
- DPU_ERROR("invalid resource pool\n");
- return;
- }
-
- crtc = _dpu_crtc_rp_to_crtc(rp);
- if (!crtc) {
- DPU_ERROR("invalid crtc\n");
- return;
- }
-
- DPU_DEBUG("crtc%d.%u duplicate\n", crtc->base.id, rp->sequence_id);
-
- mutex_lock(rp->rp_lock);
- dup_rp->sequence_id = rp->sequence_id + 1;
- INIT_LIST_HEAD(_rp->res_list);
- dup_rp->ops = rp->ops;
- list_for_each_entry(res, >res_list, list) {
- dup_res = kzalloc(sizeof(struct dpu_crtc_res), GFP_KERNEL);
- if (!dup_res) {
- mutex_unlock(rp->rp_lock);
- return;
- }
- INIT_LIST_HEAD(_res->list);
- atomic_set(_res->refcount, 0);
- dup_res->type = res->type;
- dup_res->tag = res->tag;
- dup_res->val = res->val;
- dup_res->ops = res->ops;
- dup_res->flags = DPU_CRTC_RES_FLAG_FREE;
-
[DPU PATCH 2/4] drm/msm/dpu: remove scalar config definitions
cleans up left out scalar config definitions from headers
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h| 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 10 --
2 files changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index 39def93..099e58b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -194,7 +194,6 @@ struct dpu_crtc {
u32 num_mixers;
bool mixers_swapped;
struct dpu_crtc_mixer mixers[CRTC_DUAL_MIXERS];
- struct dpu_hw_scaler3_lut_cfg *scl3_lut_cfg;
struct drm_pending_vblank_event *event;
u32 vsync_count;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
index 42f1b22..71e8dd1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
@@ -148,16 +148,6 @@ struct dpu_hw_scaler3_cfg {
struct dpu_hw_scaler3_de_cfg de;
};
-struct dpu_hw_scaler3_lut_cfg {
- bool is_configured;
- u32 *dir_lut;
- size_t dir_len;
- u32 *cir_lut;
- size_t cir_len;
- u32 *sep_lut;
- size_t sep_len;
-};
-
/**
* struct dpu_drm_pix_ext_v1 - version 1 of pixel ext structure
* @num_ext_pxls_lr: Number of total horizontal pixels
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DPU PATCH 1/4] drm/msm/dpu: add atomic private object to dpu kms
Subclass drm private state for DPU for handling driver
specific data. Adds atomic private object and private object
lock to dpu kms. Provides helper function to retrieve DPU
private data from current atomic state.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 66 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 15
2 files changed, 81 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index fe614c0..a4ab783 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1076,6 +1076,10 @@ static void dpu_kms_destroy(struct msm_kms *kms)
dpu_kms = to_dpu_kms(kms);
_dpu_kms_hw_destroy(dpu_kms);
+
+ drm_atomic_private_obj_fini(_kms->priv_obj);
+ drm_modeset_lock_fini(_kms->priv_obj_lock);
+
}
static void dpu_kms_preclose(struct msm_kms *kms, struct drm_file *file)
@@ -1618,10 +1622,59 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
return rc;
}
+struct dpu_private_state *dpu_get_private_state(struct drm_atomic_state *state)
+{
+ struct msm_drm_private *priv = state->dev->dev_private;
+ struct dpu_kms *dpu_kms = to_dpu_kms(priv->kms);
+ struct drm_private_state *priv_state;
+ int rc = 0;
+
+ rc = drm_modeset_lock(_kms->priv_obj_lock, state->acquire_ctx);
+ if (rc)
+ return ERR_PTR(rc);
+
+ priv_state = drm_atomic_get_private_obj_state(state,
+ _kms->priv_obj);
+ if (!priv_state)
+ return NULL;
+
+ return to_dpu_private_state(priv_state);
+}
+
+static struct drm_private_state *
+dpu_private_obj_duplicate_state(struct drm_private_obj *obj)
+{
+ struct dpu_private_state *dpu_priv_state;
+
+ dpu_priv_state = kmemdup(obj->state,
+ sizeof(*dpu_priv_state), GFP_KERNEL);
+ if (!dpu_priv_state)
+ return NULL;
+
+ __drm_atomic_helper_private_obj_duplicate_state(obj,
+ _priv_state->base);
+
+ return _priv_state->base;
+}
+
+static void dpu_private_obj_destroy_state(struct drm_private_obj *obj,
+ struct drm_private_state *state)
+{
+ struct dpu_private_state *dpu_priv_state = to_dpu_private_state(state);
+
+ kfree(dpu_priv_state);
+}
+
+static const struct drm_private_state_funcs priv_obj_funcs = {
+ .atomic_duplicate_state = dpu_private_obj_duplicate_state,
+ .atomic_destroy_state = dpu_private_obj_destroy_state,
+};
+
struct msm_kms *dpu_kms_init(struct drm_device *dev)
{
struct msm_drm_private *priv;
struct dpu_kms *dpu_kms;
+ struct dpu_private_state *dpu_priv_state;
int irq;
if (!dev || !dev->dev_private) {
@@ -1639,6 +1692,19 @@ struct msm_kms *dpu_kms_init(struct drm_device *dev)
}
dpu_kms->base.irq = irq;
+ /* Initialize private obj's */
+ drm_modeset_lock_init(_kms->priv_obj_lock);
+
+ dpu_priv_state = kzalloc(sizeof(*dpu_priv_state), GFP_KERNEL);
+ if (!dpu_priv_state) {
+ DPU_ERROR("failed to allocate dpu priv obj\n");
+ return ERR_PTR(-ENOMEM);
+ }
+
+ drm_atomic_private_obj_init(_kms->priv_obj,
+ _priv_state->base,
+ _obj_funcs);
+
return _kms->base;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index 046e6f7..924d8967 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -190,6 +190,9 @@ struct dpu_kms {
struct dpu_hw_vbif *hw_vbif[VBIF_MAX];
struct dpu_hw_mdp *hw_mdp;
+ struct drm_modeset_lock priv_obj_lock;
+ struct drm_private_obj priv_obj;
+
bool has_danger_ctrl;
struct platform_device *pdev;
@@ -197,12 +200,24 @@ struct dpu_kms {
struct dss_module_power mp;
};
+struct dpu_private_state {
+ struct drm_private_state base;
+};
+
struct vsync_info {
u32 frame_count;
u32 line_count;
};
#define to_dpu_kms(x) container_of(x, struct dpu_kms, base)
+#define to_dpu_private_state(x) container_of(x, struct dpu_private_state, base)
+
+/**
+ * dpu_get_private_state - get dpu private state from atomic state
+ * @state: drm atomic state
+ * Return: pointer to dpu private state object
+ */
+struct dpu_private_state *dpu_get_private_state(struct drm_atomic_state
*state);
/**
* dpu_is_custom_client - whether or not to enable non-standard customizations
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DPU PATCH 4/4] drm/msm/dpu: use private obj to track hw resources
Switch to state based resource management. This patch
overhauls the resource manager and HW allocation methods by
maintaining the global resource pool and allocated hw
blocks in respective drm component states.
Global resource manager(RM) is tracked in private object.
Allocation strategy is switched from single point allocation
of HW resources for the display pipeline to per component
based allocation, where each drm component allocates HW
blocks mapped to it's domain and tracks them in their respective
state objects.
Fixes resource contention due to race conditions between
user space and display thread by reserving resources
only in atomic check.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 210 +++---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 59 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 223 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h| 4 -
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 9 +-
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 32 +-
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 86 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 19 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h| 8 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 805 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 149 ++--
11 files changed, 534 insertions(+), 1070 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 426e2ad..a484c06 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -47,6 +47,8 @@
#define RIGHT_MIXER 1
#define MISR_BUFF_SIZE 256
+#define MAX_VDISPLAY_SPLIT 1080
+
static inline struct dpu_kms *_dpu_crtc_get_kms(struct drm_crtc *crtc)
{
@@ -142,9 +144,9 @@ static void _dpu_crtc_program_lm_output_roi(struct drm_crtc
*crtc)
crtc_state = to_dpu_crtc_state(crtc->state);
lm_horiz_position = 0;
- for (lm_idx = 0; lm_idx < dpu_crtc->num_mixers; lm_idx++) {
+ for (lm_idx = 0; lm_idx < crtc_state->num_mixers; lm_idx++) {
const struct dpu_rect *lm_roi = _state->lm_bounds[lm_idx];
- struct dpu_hw_mixer *hw_lm = dpu_crtc->mixers[lm_idx].hw_lm;
+ struct dpu_hw_mixer *hw_lm = crtc_state->mixers[lm_idx].hw_lm;
struct dpu_hw_mixer_cfg cfg;
if (dpu_kms_rect_is_null(lm_roi))
@@ -182,7 +184,7 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc
*crtc,
return;
}
- ctl = mixer->hw_ctl;
+ ctl = mixer->lm_ctl;
lm = mixer->hw_lm;
stage_cfg = _crtc->stage_cfg;
cstate = to_dpu_crtc_state(crtc->state);
@@ -237,7 +239,7 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc
*crtc,
format->base.pixel_format, fb ? fb->modifier : 0);
/* blend config update */
- for (lm_idx = 0; lm_idx < dpu_crtc->num_mixers; lm_idx++) {
+ for (lm_idx = 0; lm_idx < cstate->num_mixers; lm_idx++) {
_dpu_crtc_setup_blend_cfg(mixer + lm_idx, pstate);
mixer[lm_idx].flush_mask |= flush_mask;
@@ -260,7 +262,7 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc
*crtc,
static void _dpu_crtc_blend_setup(struct drm_crtc *crtc)
{
struct dpu_crtc *dpu_crtc;
- struct dpu_crtc_state *dpu_crtc_state;
+ struct dpu_crtc_state *cstate;
struct dpu_crtc_mixer *mixer;
struct dpu_hw_ctl *ctl;
struct dpu_hw_mixer *lm;
@@ -271,26 +273,26 @@ static void _dpu_crtc_blend_setup(struct drm_crtc *crtc)
return;
dpu_crtc = to_dpu_crtc(crtc);
- dpu_crtc_state = to_dpu_crtc_state(crtc->state);
- mixer = dpu_crtc->mixers;
+ cstate = to_dpu_crtc_state(crtc->state);
+ mixer = cstate->mixers;
DPU_DEBUG("%s\n", dpu_crtc->name);
- if (dpu_crtc->num_mixers > CRTC_DUAL_MIXERS) {
- DPU_ERROR("invalid number mixers: %d\n", dpu_crtc->num_mixers);
+ if (cstate->num_mixers > CRTC_DUAL_MIXERS) {
+ DPU_ERROR("invalid number mixers: %d\n", cstate->num_mixers);
return;
}
- for (i = 0; i < dpu_crtc->num_mixers; i++) {
- if (!mixer[i].hw_lm || !mixer[i].hw_ctl) {
+ for (i = 0; i < cstate->num_mixers; i++) {
+ if (!mixer[i].hw_lm || !mixer[i].lm_ctl) {
DPU_ERROR("invalid lm or ctl assigned to mixer\n");
return;
}
mixer[i].mixer_op_mode = 0;
mixer[i].flush_mask = 0;
- if (mixer[i].hw_ctl->ops.clear_all_blendstages)
- mixer[i].hw_ctl->ops.clear_all_blendstages(
- mixer[i].hw_ctl);
+ if
[DPU PATCH 0/4] Atomic resource management
This patchset introduces drm private object in KMS to manage HW resource management. It modifies the resource manager by introducing API's to do per DRM object resource allocation/cleanups. The patchset is based on: https://patchwork.kernel.org/patch/10461375/ Jeykumar Sankaran (4): drm/msm/dpu: add atomic private object to dpu kms drm/msm/dpu: remove scalar config definitions drm/msm/dpu: remove resource pool manager drm/msm/dpu: use private obj to track hw resources drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 704 +++--- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 144 ++-- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 223 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h| 4 - drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 9 +- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 32 +- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 86 +-- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h| 10 - drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 85 ++- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h| 23 +- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 805 ++--- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 149 ++-- 12 files changed, 615 insertions(+), 1659 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DPU PATCH] drm/msm: remove support for seamless modes
Seamless modes are ones which do not require a display
to be turned OFF/ON between mode switches.
Remove support for seamless modes from DPU for now.
This will be added later based on additional requirements.
This change depends on the DPU custom property removal series:
- https://patchwork.freedesktop.org/series/44592/
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 31
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 106 +---
drivers/gpu/drm/msm/msm_kms.h | 44
include/uapi/drm/drm_mode.h | 1 -
4 files changed, 3 insertions(+), 179 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 4616a62..9ca8325 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -591,22 +591,6 @@ static void dpu_crtc_destroy(struct drm_crtc *crtc)
kfree(dpu_crtc);
}
-static bool dpu_crtc_mode_fixup(struct drm_crtc *crtc,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
-{
- DPU_DEBUG("\n");
-
- if ((msm_is_mode_seamless(adjusted_mode) ||
- msm_is_mode_seamless_vrr(adjusted_mode)) &&
- (!crtc->enabled)) {
- DPU_ERROR("crtc state prevents seamless transition\n");
- return false;
- }
-
- return true;
-}
-
static void _dpu_crtc_setup_blend_cfg(struct dpu_crtc_mixer *mixer,
struct dpu_plane_state *pstate)
{
@@ -1728,12 +1712,6 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
mode = >base.adjusted_mode;
priv = crtc->dev->dev_private;
- if (msm_is_mode_seamless(mode) || msm_is_mode_seamless_vrr(mode) ||
- msm_is_mode_seamless_dms(mode)) {
- DPU_DEBUG("Seamless mode is being applied, skip disable\n");
- return;
- }
-
DPU_DEBUG("crtc%d\n", crtc->base.id);
if (dpu_kms_is_suspend_state(crtc->dev))
@@ -1817,12 +1795,6 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
DPU_EVT32_VERBOSE(DRMID(crtc));
dpu_crtc = to_dpu_crtc(crtc);
- if (msm_is_mode_seamless(>state->adjusted_mode) ||
- msm_is_mode_seamless_vrr(>state->adjusted_mode)) {
- DPU_DEBUG("Skipping crtc enable, seamless mode\n");
- return;
- }
-
drm_for_each_encoder(encoder, crtc->dev) {
if (encoder->crtc != crtc)
continue;
@@ -1857,8 +1829,6 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
DPU_POWER_EVENT_PRE_DISABLE,
dpu_crtc_handle_power_event, crtc, dpu_crtc->name);
- if (msm_needs_vblank_pre_modeset(>state->adjusted_mode))
- drm_crtc_wait_one_vblank(crtc);
}
struct plane_state {
@@ -2497,7 +2467,6 @@ static void dpu_crtc_early_unregister(struct drm_crtc
*crtc)
};
static const struct drm_crtc_helper_funcs dpu_crtc_helper_funcs = {
- .mode_fixup = dpu_crtc_mode_fixup,
.disable = dpu_crtc_disable,
.atomic_enable = dpu_crtc_enable,
.atomic_check = dpu_crtc_atomic_check,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 7dd609c..11a1045 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -96,15 +96,6 @@
* IDLE is expected when IDLE_PC has run, and PRE_OFF did nothing.
* PRE_OFF is expected when PRE_STOP was executed during the ON state.
* Resource state should be in OFF at the end of the event.
- * @DPU_ENC_RC_EVENT_PRE_MODESET:
- * This event happens at NORMAL priority from a work item.
- * Event signals that there is a seamless mode switch is in prgoress. A
- * client needs to turn of only irq - leave clocks ON to reduce the mode
- * switch latency.
- * @DPU_ENC_RC_EVENT_POST_MODESET:
- * This event happens at NORMAL priority from a work item.
- * Event signals that seamless mode switch is complete and resources are
- * acquired. Clients wants to turn on the irq again.
* @DPU_ENC_RC_EVENT_ENTER_IDLE:
* This event happens at NORMAL priority from a work item.
* Event signals that there were no frame updates for IDLE_TIMEOUT time.
@@ -116,8 +107,6 @@ enum dpu_enc_rc_events {
DPU_ENC_RC_EVENT_FRAME_DONE,
DPU_ENC_RC_EVENT_PRE_STOP,
DPU_ENC_RC_EVENT_STOP,
- DPU_ENC_RC_EVENT_PRE_MODESET,
- DPU_ENC_RC_EVENT_POST_MODESET,
DPU_ENC_RC_EVENT_ENTER_IDLE
};
@@ -133,7 +122,6 @@ enum dpu_enc_rc_states {
DPU_ENC_RC_STATE_OFF,
DPU_ENC_RC_STATE_PRE_OFF,
DPU_ENC_RC_STATE_ON,
- DPU_ENC_RC_STATE_MODESET,
DPU_ENC_RC_STATE_IDLE
};
@@ -809,7 +797,6 @@ static int dpu_encoder_resource_control(struct drm_encoder
*drm_enc,
struct
Re: [PATCH 4/8] dt-bindings: display: rockchip: update DSI controller
On Mon, Jun 11, 2018 at 03:34:58PM +0200, Heiko Stuebner wrote: > From: Nickey Yang > > This patch update describe panel/port links, including > unit addresses in documentation of device tree bindings > for the rockchip DSI controller based on the Synopsys > DesignWare MIPI DSI host controller. > > Signed-off-by: Nickey Yang > Reviewed-by: Brian Norris > Signed-off-by: Heiko Stuebner > --- > .../display/rockchip/dw_mipi_dsi_rockchip.txt | 23 +-- > 1 file changed, 21 insertions(+), 2 deletions(-) Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: display: renesas: lvds: document R8A77980 bindings
On Tue, Jun 05, 2018 at 11:28:58PM +0300, Sergei Shtylyov wrote: > Document the R-Car V3H (R8A77980) SoC in the R-Car LVDS bindings. > > Signed-off-by: Sergei Shtylyov > > --- > Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt |1 + > 1 file changed, 1 insertion(+) Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199749] amdgpu on Ryzen 2400G freeze randomly
https://bugzilla.kernel.org/show_bug.cgi?id=199749 Andrey Grodzovsky (andrey.grodzov...@amd.com) changed: What|Removed |Added CC||andrey.grodzov...@amd.com --- Comment #1 from Andrey Grodzovsky (andrey.grodzov...@amd.com) --- Can you load kernel with grub command line amdgpu.vm_update_mode=3 to force CPU VM update mode and see if this makes the issue go away ? Andrey -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: display: renesas: du: document R8A77980 bindings
On Mon, Jun 04, 2018 at 10:04:59PM +0300, Sergei Shtylyov wrote: > Document the R-Car V3H (R8A77980) SoC in the R-Car DU bindings; the DU > hardware seems the same as in the R-Car V3M (R8A77970). > > Signed-off-by: Sergei Shtylyov > > --- > The patch is against the 'drm-next' branch of David Airlie's 'linux.git' repo. > > Documentation/devicetree/bindings/display/renesas,du.txt |2 ++ > 1 file changed, 2 insertions(+) Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200045] New: i2c-algo-bit: black screen on 'radeon' module probing
https://bugzilla.kernel.org/show_bug.cgi?id=200045
Bug ID: 200045
Summary: i2c-algo-bit: black screen on 'radeon' module probing
Product: Drivers
Version: 2.5
Kernel Version: 4.16
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
Assignee: drivers_video-...@kernel-bugs.osdl.org
Reporter: cerg2010cerg2...@mail.ru
Regression: No
Created attachment 276499
--> https://bugzilla.kernel.org/attachment.cgi?id=276499=edit
lspci -v
Hi,
After updating to the 4.16 kernel I started to get a black screen on boot,
without something useful in log. This bug also happens in latest version
(4.17.1). I'm using HP Pavilion dv6-3090er laptop with an exotic ATI/AMD
switchable graphics (radeon 4250 integrated/5650 discrete).
I bisected the issue down to commit 3e5f06bed72fe72166a6778f630241a893f67799
("i2c: algo-bit: init the bus to a known state") and reverting this fixes the
problem. Also loading radeon module with hw_i2c=1 gives me working display with
full brightness, and attempt to change it results in reboot.
Thanks.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: simple: Add support for Innolux G070Y2-L01
On Mon, Jun 04, 2018 at 01:16:48PM +0200, Christoph Fritz wrote: > This patch adds support for Innolux G070Y2-L01 7" WVGA (800x480) TFT LCD > panel. > > Signed-off-by: Christoph Fritz > --- > .../bindings/display/panel/innolux,g070y2-l01.txt | 12 +++ > drivers/gpu/drm/panel/panel-simple.c | 37 > -- > 2 files changed, 47 insertions(+), 2 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/panel/innolux,g070y2-l01.txt Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 198713] AMD DC crashes when computing clocks/detecting freesync
https://bugzilla.kernel.org/show_bug.cgi?id=198713 Andrey Grodzovsky (andrey.grodzov...@amd.com) changed: What|Removed |Added CC||andrey.grodzov...@amd.com --- Comment #5 from Andrey Grodzovsky (andrey.grodzov...@amd.com) --- It's not a crash but a warning over invalid reg fields access - here https://elixir.bootlin.com/linux/v4.15.1/source/drivers/gpu/drm/amd/display/dc/dm_services.h#L132 I see you are working with 4.15 kernel, can you take the latest stable from here - https://www.kernel.org/ and see if problem goes away ? For quicker response time you can try submitting tickets to Free Desktop Bugzilla - https://bugs.freedesktop.org/ Andrey -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 2/6] dt-bindings: display/ti: add k2g-dss bindings
On Thu, May 31, 2018 at 03:41:05PM +0300, Tomi Valkeinen wrote: > Add DT bindings for Texas Instruments K2G SoC Display Subsystem. The DSS > is quite simple, with a single plane and a single output. > > Signed-off-by: Tomi Valkeinen > Cc: devicet...@vger.kernel.org > --- > .../devicetree/bindings/display/ti/ti,k2g-dss.txt | 15 +++ > 1 file changed, 15 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/ti/ti,k2g-dss.txt Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199025] Suspend hangs. Never fully suspends and impossible to return to running state.
https://bugzilla.kernel.org/show_bug.cgi?id=199025 --- Comment #36 from Samuel Sieb (samuel-kb...@sieb.net) --- This is resolved for me with the 4.16 kernel after upgrading to F28. And the Fedora bug has been closed as well with someone else saying the same thing. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm: Print bad user modes
On 2018-06-11 03:34 PM, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Print out the modeline when we reject a bad user mode. Avoids having to
> guess why it was rejected.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/drm_atomic.c| 20 +---
> drivers/gpu/drm/drm_crtc.c | 4 +++-
> drivers/gpu/drm/drm_crtc_internal.h | 3 +++
> drivers/gpu/drm/drm_modes.c | 2 +-
> 4 files changed, 24 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index d7de83a6c1c2..5fe5e06062a9 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -400,10 +400,24 @@ int drm_atomic_set_mode_prop_for_crtc(struct
> drm_crtc_state *state,
> memset(>mode, 0, sizeof(state->mode));
>
> if (blob) {
> - if (blob->length != sizeof(struct drm_mode_modeinfo) ||
> - drm_mode_convert_umode(state->crtc->dev, >mode,
> -blob->data))
> + int ret;
> +
> + if (blob->length != sizeof(struct drm_mode_modeinfo)) {
> + DRM_DEBUG_ATOMIC("[CRTC:%d:%s] bad mode blob length:
> %zu\n",
> + crtc->base.id, crtc->name,
> + blob->length);
> + return -EINVAL;
> + }
> +
> + ret = drm_mode_convert_umode(crtc->dev,
> + >mode, blob->data);
> + if (ret) {
> + DRM_DEBUG_ATOMIC("[CRTC:%d:%s] invalid mode (ret=%d,
> status=%s):\n",
> + crtc->base.id, crtc->name,
> + ret,
> drm_get_mode_status_name(state->mode.status));
> + drm_mode_debug_printmodeline(>mode);
> return -EINVAL;
> + }
>
> state->mode_blob = drm_property_blob_get(blob);
> state->enable = true;
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 53828fc8d911..163d82ac7d76 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -649,7 +649,9 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
>
> ret = drm_mode_convert_umode(dev, mode, _req->mode);
> if (ret) {
> - DRM_DEBUG_KMS("Invalid mode\n");
> + DRM_DEBUG_KMS("Invalid mode (ret=%d, status=%s)\n",
> + ret,
> drm_get_mode_status_name(mode->status));
> + drm_mode_debug_printmodeline(mode);
> goto out;
> }
>
> diff --git a/drivers/gpu/drm/drm_crtc_internal.h
> b/drivers/gpu/drm/drm_crtc_internal.h
> index 5d307b23a4e6..34499800932a 100644
> --- a/drivers/gpu/drm/drm_crtc_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_internal.h
> @@ -56,6 +56,9 @@ int drm_mode_setcrtc(struct drm_device *dev,
> int drm_modeset_register_all(struct drm_device *dev);
> void drm_modeset_unregister_all(struct drm_device *dev);
>
> +/* drm_modes.c */
> +const char *drm_get_mode_status_name(enum drm_mode_status status);
> +
> /* IOCTLs */
> int drm_mode_getresources(struct drm_device *dev,
> void *data, struct drm_file *file_priv);
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index c78ca0e84ffd..7f552d5fa88e 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1257,7 +1257,7 @@ static const char * const drm_mode_status_names[] = {
>
> #undef MODE_STATUS
>
> -static const char *drm_get_mode_status_name(enum drm_mode_status status)
> +const char *drm_get_mode_status_name(enum drm_mode_status status)
> {
> int index = status + 3;
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106870] [Raven Ridge occasionally hangs] VM_L2_PROTECTION_FAULT_STATUS:0x00000000
https://bugs.freedesktop.org/show_bug.cgi?id=106870 --- Comment #2 from Luca --- I think they are the same bug but in the title it was mentioned it was occurring during boot and that is not my case although I have this problem at boot (https://bugs.freedesktop.org/show_bug.cgi?id=106225). I've updated the microcode to the latest version, llvm was already at version 6. It seems it happens again but more rarely, it happened now after 7 hours of uptime. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28771] [RADEON:KMS::R300C:R300G] waiting for vline forced always on
https://bugs.freedesktop.org/show_bug.cgi?id=28771 Bug 28771 depends on bug 42035, which changed state. Bug 42035 Summary: no way to turn off vline wait at runtime https://bugs.freedesktop.org/show_bug.cgi?id=42035 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 23017] Direct color dri windowed visual is causing causing full black screen
https://bugs.freedesktop.org/show_bug.cgi?id=23017 Adam Jackson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #13 from Adam Jackson --- Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases. -- You are receiving this mail because: You are on the CC list for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/atomic: Improve debug messages
On 2018-06-11 03:34 PM, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Print the id/name of the object we're dealing with. Makes it easier to
> figure out what's going on. Also toss in a few extra debug prints that
> might be useful.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/drm_atomic.c | 88
> ++--
> 1 file changed, 61 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index ee4b43b9404e..d7de83a6c1c2 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -339,6 +339,7 @@ static s32 __user *get_out_fence_for_crtc(struct
> drm_atomic_state *state,
> int drm_atomic_set_mode_for_crtc(struct drm_crtc_state *state,
>const struct drm_display_mode *mode)
> {
> + struct drm_crtc *crtc = state->crtc;
> struct drm_mode_modeinfo umode;
>
> /* Early return for no change. */
> @@ -359,13 +360,13 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state
> *state,
>
> drm_mode_copy(>mode, mode);
> state->enable = true;
> - DRM_DEBUG_ATOMIC("Set [MODE:%s] for CRTC state %p\n",
> - mode->name, state);
> + DRM_DEBUG_ATOMIC("Set [MODE:%s] for [CRTC:%d:%s] state %p\n",
> + mode->name, crtc->base.id, crtc->name, state);
> } else {
> memset(>mode, 0, sizeof(state->mode));
> state->enable = false;
> - DRM_DEBUG_ATOMIC("Set [NOMODE] for CRTC state %p\n",
> - state);
> + DRM_DEBUG_ATOMIC("Set [NOMODE] for [CRTC:%d:%s] state %p\n",
> + crtc->base.id, crtc->name, state);
> }
>
> return 0;
> @@ -388,6 +389,8 @@ EXPORT_SYMBOL(drm_atomic_set_mode_for_crtc);
> int drm_atomic_set_mode_prop_for_crtc(struct drm_crtc_state *state,
>struct drm_property_blob *blob)
> {
> + struct drm_crtc *crtc = state->crtc;
> +
> if (blob == state->mode_blob)
> return 0;
>
> @@ -404,12 +407,13 @@ int drm_atomic_set_mode_prop_for_crtc(struct
> drm_crtc_state *state,
>
> state->mode_blob = drm_property_blob_get(blob);
> state->enable = true;
> - DRM_DEBUG_ATOMIC("Set [MODE:%s] for CRTC state %p\n",
> - state->mode.name, state);
> + DRM_DEBUG_ATOMIC("Set [MODE:%s] for [CRTC:%d:%s] state %p\n",
> + state->mode.name, crtc->base.id, crtc->name,
> + state);
> } else {
> state->enable = false;
> - DRM_DEBUG_ATOMIC("Set [NOMODE] for CRTC state %p\n",
> - state);
> + DRM_DEBUG_ATOMIC("Set [NOMODE] for [CRTC:%d:%s] state %p\n",
> + crtc->base.id, crtc->name, state);
> }
>
> return 0;
> @@ -539,10 +543,14 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
> return -EFAULT;
>
> set_out_fence_for_crtc(state->state, crtc, fence_ptr);
> - } else if (crtc->funcs->atomic_set_property)
> + } else if (crtc->funcs->atomic_set_property) {
> return crtc->funcs->atomic_set_property(crtc, state, property,
> val);
> - else
> + } else {
> + DRM_DEBUG_ATOMIC("[CRTC:%d:%s] unknown property
> [PROP:%d:%s]]\n",
> + crtc->base.id, crtc->name,
> + property->base.id, property->name);
> return -EINVAL;
> + }
>
> return 0;
> }
> @@ -799,8 +807,11 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane,
> } else if (property == plane->alpha_property) {
> state->alpha = val;
> } else if (property == plane->rotation_property) {
> - if (!is_power_of_2(val & DRM_MODE_ROTATE_MASK))
> + if (!is_power_of_2(val & DRM_MODE_ROTATE_MASK)) {
> + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] bad rotation bitmask:
> 0x%llx\n",
> + plane->base.id, plane->name, val);
> return -EINVAL;
> + }
> state->rotation = val;
> } else if (property == plane->zpos_property) {
> state->zpos = val;
> @@ -812,6 +823,9 @@ static int drm_atomic_plane_set_property(struct drm_plane
> *plane,
> return plane->funcs->atomic_set_property(plane, state,
> property, val);
> } else {
> + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] unknown property
> [PROP:%d:%s]]\n",
> + plane->base.id, plane->name,
> + property->base.id, property->name);
> return -EINVAL;
> }
>
[Bug 106225] Kernel panic after modesetting (not on every boot) on ryzen 5 2400g
https://bugs.freedesktop.org/show_bug.cgi?id=106225 --- Comment #32 from Luca --- Happens to me too (kernel 4.17 ubuntu 18.04), especially the first boot of the day I always get black screen after modeset. I haven't tried with KASAN and can't get any log but I suspect is the same issue. Asrock ab350m pro4 - firmware 4.7 PSU seasonic s12ii ram 2x8 gb kingston hyperx fury 2666 CPU ryzen 2200g -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/msm: Remove pm_runtime operations from msm_iommu
On Mon, Jun 11, 2018 at 11:26 AM Jordan Crouse wrote:
>
> Now that the IOMMU is the master of it's own power we don't need to bring
> up the GPU to do IOMMU operations. This is good because bringing up a6xx
> requires the GMU so calling pm_runtime_get_sync() too early in the process
> gets us into some nasty circular dependency situations.
>
> Signed-off-by: Jordan Crouse
Reviewed-by: Kristian H. Kristensen
> ---
> drivers/gpu/drm/msm/msm_iommu.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
> index b23d33622f37..ccd93ac6a4d8 100644
> --- a/drivers/gpu/drm/msm/msm_iommu.c
> +++ b/drivers/gpu/drm/msm/msm_iommu.c
> @@ -40,9 +40,7 @@ static int msm_iommu_attach(struct msm_mmu *mmu, const char
> * const *names,
> struct msm_iommu *iommu = to_msm_iommu(mmu);
> int ret;
>
> - pm_runtime_get_sync(mmu->dev);
> ret = iommu_attach_device(iommu->domain, mmu->dev);
> - pm_runtime_put_sync(mmu->dev);
>
> return ret;
> }
> @@ -52,9 +50,7 @@ static void msm_iommu_detach(struct msm_mmu *mmu, const
> char * const *names,
> {
> struct msm_iommu *iommu = to_msm_iommu(mmu);
>
> - pm_runtime_get_sync(mmu->dev);
> iommu_detach_device(iommu->domain, mmu->dev);
> - pm_runtime_put_sync(mmu->dev);
> }
>
> static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova,
> @@ -63,9 +59,7 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova,
> struct msm_iommu *iommu = to_msm_iommu(mmu);
> size_t ret;
>
> -// pm_runtime_get_sync(mmu->dev);
> ret = iommu_map_sg(iommu->domain, iova, sgt->sgl, sgt->nents, prot);
> -// pm_runtime_put_sync(mmu->dev);
> WARN_ON(ret < 0);
>
> return (ret == len) ? 0 : -EINVAL;
> @@ -76,9 +70,7 @@ static int msm_iommu_unmap(struct msm_mmu *mmu, uint64_t
> iova,
> {
> struct msm_iommu *iommu = to_msm_iommu(mmu);
>
> - pm_runtime_get_sync(mmu->dev);
> iommu_unmap(iommu->domain, iova, len);
> - pm_runtime_put_sync(mmu->dev);
>
> return 0;
> }
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 18/21] udlfb: allow reallocating the framebuffer
On Mon, 4 Jun 2018, kbuild test robot wrote:
> Hi Mikulas,
>
> I love your patch! Perhaps something to improve:
>
> [auto build test WARNING on drm/drm-next]
> [also build test WARNING on v4.17-rc7 next-20180601]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Mikulas-Patocka/USB-DisplayLink-patches/20180603-233013
What is it really complaining about? That URL shows 404 Not Found and this
email has no warnings at all.
> base: git://people.freedesktop.org/~airlied/linux.git drm-next
> reproduce:
> # apt-get install sparse
> make ARCH=x86_64 allmodconfig
> make C=1 CF=-D__CHECK_ENDIAN__
>
>
> sparse warnings: (new ones prefixed by >>)
>
>
> vim +1198 drivers/video/fbdev/udlfb.c
>
> 1171
> 1172/*
> 1173 * Assumes >lock held by caller
> 1174 * Assumes no active clients have framebuffer open
> 1175 */
> 1176static int dlfb_realloc_framebuffer(struct dlfb_data *dlfb,
> struct fb_info *info, u32 new_len)
> 1177{
> 1178u32 old_len = info->fix.smem_len;
> > 1179unsigned char *old_fb = info->screen_base;
> 1180unsigned char *new_fb;
> 1181unsigned char *new_back = NULL;
> 1182
> 1183new_len = PAGE_ALIGN(new_len);
> 1184
> 1185if (new_len > old_len) {
> 1186/*
> 1187 * Alloc system memory for virtual framebuffer
> 1188 */
> 1189new_fb = vmalloc(new_len);
> 1190if (!new_fb) {
> 1191dev_err(info->dev, "Virtual framebuffer
> alloc failed\n");
> 1192return -ENOMEM;
> 1193}
> 1194memset(new_fb, 0xff, new_len);
> 1195
> 1196if (info->screen_base) {
> 1197memcpy(new_fb, old_fb, old_len);
> > 1198dlfb_deferred_vfree(dlfb,
> > info->screen_base);
> 1199}
> 1200
> 1201info->screen_base = new_fb;
> 1202info->fix.smem_len = new_len;
> 1203info->fix.smem_start = (unsigned long) new_fb;
> 1204info->flags = udlfb_info_flags;
> 1205
> 1206/*
> 1207 * Second framebuffer copy to mirror the
> framebuffer state
> 1208 * on the physical USB device. We can function
> without this.
> 1209 * But with imperfect damage info we may send
> pixels over USB
> 1210 * that were, in fact, unchanged - wasting
> limited USB bandwidth
> 1211 */
> 1212if (shadow)
> 1213new_back = vzalloc(new_len);
> 1214if (!new_back)
> 1215dev_info(info->dev,
> 1216 "No shadow/backing buffer
> allocated\n");
> 1217else {
> 1218dlfb_deferred_vfree(dlfb,
> dlfb->backing_buffer);
> 1219dlfb->backing_buffer = new_back;
> 1220}
> 1221}
> 1222return 0;
> 1223}
> 1224
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mxsfb: rename driver to mxsfb-drm
On Tue, Jun 12, 2018 at 11:35 AM, Stefan Agner wrote: > There are two drivers for the LCDIF/MXSFB peripheral. If the DRM > and fbdev are compiled in, the registration of the second driver > fails: > mxs-dma 3300.dma-apbh: initialized > mxsfb 3073.lcdif: 3073.lcdif supply lcd not found, using dummy > regulator > mxsfb 3073.lcdif: initialized > Error: Driver 'mxsfb' is already registered, aborting... > > Avoid driver name conflict with MXS fbdev driver by renaming the > more recently added DRM driver. > > Signed-off-by: Stefan Agner Yes, this driver name collision is annoying: Reviewed-by: Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/mxsfb: rename driver to mxsfb-drm
There are two drivers for the LCDIF/MXSFB peripheral. If the DRM
and fbdev are compiled in, the registration of the second driver
fails:
mxs-dma 3300.dma-apbh: initialized
mxsfb 3073.lcdif: 3073.lcdif supply lcd not found, using dummy
regulator
mxsfb 3073.lcdif: initialized
Error: Driver 'mxsfb' is already registered, aborting...
Avoid driver name conflict with MXS fbdev driver by renaming the
more recently added DRM driver.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 5cae8db9dcd4..db2935797428 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -424,7 +424,7 @@ static struct platform_driver mxsfb_platform_driver = {
.remove = mxsfb_remove,
.id_table = mxsfb_devtype,
.driver = {
- .name = "mxsfb",
+ .name = "mxsfb-drm",
.of_match_table = mxsfb_dt_ids,
},
};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/meson: Fix an un-handled error path in 'meson_drv_bind_master()'
On 11/06/2018 18:53, Christophe JAILLET wrote:
> If 'platform_get_resource_byname()' fails, we should release some resources
> before leaving, as already done in the other error handling path of the
> function.
>
> Fixes: acaa3f13b8dd ("drm/meson: Fix potential NULL dereference in
> meson_drv_bind_master()")
> Signed-off-by: Christophe JAILLET
> ---
> drivers/gpu/drm/meson/meson_drv.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_drv.c
> b/drivers/gpu/drm/meson/meson_drv.c
> index 32b1a6cdecfc..d3443125e661 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -197,8 +197,10 @@ static int meson_drv_bind_master(struct device *dev,
> bool has_components)
> priv->io_base = regs;
>
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "hhi");
> - if (!res)
> - return -EINVAL;
> + if (!res) {
> + ret = -EINVAL;
> + goto free_drm;
> + }
> /* Simply ioremap since it may be a shared register zone */
> regs = devm_ioremap(dev, res->start, resource_size(res));
> if (!regs) {
> @@ -215,8 +217,10 @@ static int meson_drv_bind_master(struct device *dev,
> bool has_components)
> }
>
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dmc");
> - if (!res)
> - return -EINVAL;
> + if (!res) {
> + ret = -EINVAL;
> + goto free_drm;
> + }
> /* Simply ioremap since it may be a shared register zone */
> regs = devm_ioremap(dev, res->start, resource_size(res));
> if (!regs) {
>
Acked-by: Neil Armstrong
I'll push it when rc1 is tagged.
Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99492] [intel_gpu_tools] intel_gpu_frequency's parsing of parameters broken
https://bugs.freedesktop.org/show_bug.cgi?id=99492 Jani Nikula changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99492] [intel_gpu_tools] intel_gpu_frequency's parsing of parameters broken
https://bugs.freedesktop.org/show_bug.cgi?id=99492 Jani Nikula changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Jani Nikula --- Fix pushed to igt: commit 95bfb2902473b9f4e644c3eb831fdf110d87ed4f Author: Jani Nikula Date: Tue Jun 12 17:02:11 2018 +0300 tools/intel_gpu_frequency: fix usage and examples -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99492] [intel_gpu_tools] intel_gpu_frequency's parsing of parameters broken
https://bugs.freedesktop.org/show_bug.cgi?id=99492
--- Comment #1 from Jani Nikula ---
(In reply to Andreas Reis from comment #0)
> At least in the case of -g, intel_gpu_frequency currently (1.16 & git) fails
> if there are parameters. With none it works.
>
> Eg, the example's -gmin,cur yields "invalid option -- 'n'" and -gcur
> "Selected unmodifiable frequency".
-g|--get suboptions have been removed in commit 20d6e0f41b3b
("tools/intel_gpu_frequency: remove use of getsubopt") but the quick usage
wasn't updated. Just use without suboptions.
Patch on the list to update the usage:
http://patchwork.freedesktop.org/patch/msgid/20180612140544.7231-1-jani.nik...@intel.com
> That and I couldn't compile until I disabled the assembler, I kept getting
> lex.o: In function `yylex':
>
> lex.c:(.text+0x3c8f): undefined reference to `yywrap'
Unrelated, please file a new bug if this persists with the current git.
Apologies for this staying below the radar for so long; I guess nobody thought
it was that important. :(
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 3/5] drm/mali-dp: Add writeback support for DP500.
Mali DP500 behaves differently from the rest of the Mali DP IP,
in that it does not have a one-shot mode and keeps writing the
content of the current frame to the provided memory area until
stopped. As a way of emulating the one-shot behaviour, we are
going to use the CVAL interrupt that is being raised at the
start of each frame, during prefetch phase, to act as End-of-Write
signal, but with a twist: we are going to disable the memory
write engine right after we're notified that it has been enabled,
using the knowledge that the bit controlling the enabling will
only be acted upon on the next vblank/prefetch.
CVAL interrupt will fire durint the next prefetch phase every time
the global CVAL bit gets set, so we need a state byte to track
the memory write enabling. We also need to pay attention during the
disabling of the memory write engine as that requires the CVAL bit
to be set in the control register, but we don't want to do that
during an atomic commit, as it will write into the hardware a partial
state.
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_drv.c | 16 --
drivers/gpu/drm/arm/malidp_drv.h | 4 ++
drivers/gpu/drm/arm/malidp_hw.c | 84 +--
drivers/gpu/drm/arm/malidp_hw.h | 5 +-
drivers/gpu/drm/arm/malidp_regs.h | 3 +-
5 files changed, 102 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 8d20faa198cf1..e262620ffed55 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -170,14 +170,15 @@ static int malidp_set_and_wait_config_valid(struct
drm_device *drm)
struct malidp_hw_device *hwdev = malidp->dev;
int ret;
- atomic_set(>config_valid, 0);
hwdev->hw->set_config_valid(hwdev);
/* don't wait for config_valid flag if we are in config mode */
- if (hwdev->hw->in_config_mode(hwdev))
+ if (hwdev->hw->in_config_mode(hwdev)) {
+ atomic_set(>config_valid, MALIDP_CONFIG_VALID_DONE);
return 0;
+ }
ret = wait_event_interruptible_timeout(malidp->wq,
- atomic_read(>config_valid) == 1,
+ atomic_read(>config_valid) ==
MALIDP_CONFIG_VALID_DONE,
msecs_to_jiffies(MALIDP_CONF_VALID_TIMEOUT));
return (ret > 0) ? 0 : -ETIMEDOUT;
@@ -216,12 +217,19 @@ static void malidp_atomic_commit_hw_done(struct
drm_atomic_state *state)
static void malidp_atomic_commit_tail(struct drm_atomic_state *state)
{
struct drm_device *drm = state->dev;
+ struct malidp_drm *malidp = drm->dev_private;
struct drm_crtc *crtc;
struct drm_crtc_state *old_crtc_state;
int i;
pm_runtime_get_sync(drm->dev);
+ /*
+* set config_valid to a special value to let IRQ handlers
+* know that we are updating registers
+*/
+ atomic_set(>config_valid, MALIDP_CONFIG_START);
+
drm_atomic_helper_commit_modeset_disables(drm, state);
for_each_old_crtc_in_state(state, crtc, old_crtc_state, i) {
@@ -589,7 +597,7 @@ static int malidp_bind(struct device *dev)
out_depth = (out_depth << 8) | (output_width[i] & 0xf);
malidp_hw_write(hwdev, out_depth, hwdev->hw->map.out_depth_base);
- atomic_set(>config_valid, 0);
+ atomic_set(>config_valid, MALIDP_CONFIG_VALID_INIT);
init_waitqueue_head(>wq);
ret = malidp_init(drm);
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index c70989b933874..e8c41cf1b5bd2 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -18,6 +18,10 @@
#include
#include "malidp_hw.h"
+#define MALIDP_CONFIG_VALID_INIT 0
+#define MALIDP_CONFIG_VALID_DONE 1
+#define MALIDP_CONFIG_START0xd0
+
struct malidp_drm {
struct malidp_hw_device *dev;
struct drm_crtc crtc;
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index dd3a15964c588..0524b75f85c6e 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -22,6 +22,13 @@
#include "malidp_drv.h"
#include "malidp_hw.h"
+enum {
+ MW_NOT_ENABLED = 0, /* SE writeback not enabled */
+ MW_ONESHOT, /* SE in one-shot mode for writeback */
+ MW_START, /* SE started writeback */
+ MW_STOP,/* SE finished writeback */
+};
+
static const struct malidp_format_id malidp500_de_formats[] = {
/*fourcc, layers supporting the format, internal id */
{ DRM_FORMAT_ARGB2101010, DE_VIDEO1 | DE_GRAPHICS1 | DE_GRAPHICS2, 0 },
@@ -368,6 +375,51 @@ static long malidp500_se_calc_mclk(struct malidp_hw_device
*hwdev,
return ret;
}
+static int malidp500_enable_memwrite(struct malidp_hw_device *hwdev,
+dma_addr_t *addrs, s32 *pitches,
+
[PATCH v8 5/5] drm: mali-dp: Add writeback connector
From: Brian Starkey
Mali-DP has a memory writeback engine which can be used to write the
composition result to a memory buffer. Expose this functionality as a
DRM writeback connector on supported hardware.
Changes since v1:
Daniel Vetter:
- Don't require a modeset when writeback routing changes
- Make writeback connector always disconnected
Changes since v2:
- Rebase onto new drm_writeback_connector
- Add reset callback, allocating subclassed state
Daniel Vetter:
- Squash out-fence support into this commit
Gustavo Padovan:
- Don't signal fence directly from driver (and drop malidp_mw_job)
Changes since v3:
- Modifications to fit with Mali-DP commit tail changes
Signed-off-by: Brian Starkey
[rebased and fixed conflicts]
Signed-off-by: Mihail Atanassov
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/Makefile | 1 +
drivers/gpu/drm/arm/malidp_crtc.c | 10 ++
drivers/gpu/drm/arm/malidp_drv.c | 19 ++-
drivers/gpu/drm/arm/malidp_drv.h | 3 +
drivers/gpu/drm/arm/malidp_hw.c | 5 +
drivers/gpu/drm/arm/malidp_mw.c | 250 ++
drivers/gpu/drm/arm/malidp_mw.h | 14 ++
drivers/gpu/drm/drm_atomic.c | 4 +
8 files changed, 301 insertions(+), 5 deletions(-)
create mode 100644 drivers/gpu/drm/arm/malidp_mw.c
create mode 100644 drivers/gpu/drm/arm/malidp_mw.h
diff --git a/drivers/gpu/drm/arm/Makefile b/drivers/gpu/drm/arm/Makefile
index bb8b158ff90d0..3bf31d1a4722c 100644
--- a/drivers/gpu/drm/arm/Makefile
+++ b/drivers/gpu/drm/arm/Makefile
@@ -1,4 +1,5 @@
hdlcd-y := hdlcd_drv.o hdlcd_crtc.o
obj-$(CONFIG_DRM_HDLCD)+= hdlcd.o
mali-dp-y := malidp_drv.o malidp_hw.o malidp_planes.o malidp_crtc.o
+mali-dp-y += malidp_mw.o
obj-$(CONFIG_DRM_MALI_DISPLAY) += mali-dp.o
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
b/drivers/gpu/drm/arm/malidp_crtc.c
index fcc62bc60f6a7..ef44202fb43f8 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -411,6 +411,16 @@ static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
}
}
+ /* If only the writeback routing has changed, we don't need a modeset */
+ if (state->connectors_changed) {
+ u32 old_mask = crtc->state->connector_mask;
+ u32 new_mask = state->connector_mask;
+
+ if ((old_mask ^ new_mask) ==
+ (1 << drm_connector_index(>mw_connector.base)))
+ state->connectors_changed = false;
+ }
+
ret = malidp_crtc_atomic_check_gamma(crtc, state);
ret = ret ? ret : malidp_crtc_atomic_check_ctm(crtc, state);
ret = ret ? ret : malidp_crtc_atomic_check_scaling(crtc, state);
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index e262620ffed55..fc264554c5035 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -31,6 +31,7 @@
#include
#include "malidp_drv.h"
+#include "malidp_mw.h"
#include "malidp_regs.h"
#include "malidp_hw.h"
@@ -238,7 +239,9 @@ static void malidp_atomic_commit_tail(struct
drm_atomic_state *state)
malidp_atomic_commit_se_config(crtc, old_crtc_state);
}
- drm_atomic_helper_commit_planes(drm, state, 0);
+ drm_atomic_helper_commit_planes(drm, state,
DRM_PLANE_COMMIT_ACTIVE_ONLY);
+
+ malidp_mw_atomic_commit(drm, state);
drm_atomic_helper_commit_modeset_enables(drm, state);
@@ -276,12 +279,18 @@ static int malidp_init(struct drm_device *drm)
drm->mode_config.helper_private = _mode_config_helpers;
ret = malidp_crtc_init(drm);
- if (ret) {
- drm_mode_config_cleanup(drm);
- return ret;
- }
+ if (ret)
+ goto crtc_fail;
+
+ ret = malidp_mw_connector_init(drm);
+ if (ret)
+ goto crtc_fail;
return 0;
+
+crtc_fail:
+ drm_mode_config_cleanup(drm);
+ return ret;
}
static void malidp_fini(struct drm_device *drm)
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index e8c41cf1b5bd2..5febd4b43e058 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -13,6 +13,8 @@
#ifndef __MALIDP_DRV_H__
#define __MALIDP_DRV_H__
+#include
+#include
#include
#include
#include
@@ -25,6 +27,7 @@
struct malidp_drm {
struct malidp_hw_device *dev;
struct drm_crtc crtc;
+ struct drm_writeback_connector mw_connector;
wait_queue_head_t wq;
struct drm_pending_vblank_event *event;
atomic_t config_valid;
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index df3649203e6a9..e0de7a35a0beb 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -21,6 +21,7 @@
#include "malidp_drv.h"
#include "malidp_hw.h"
+#include "malidp_mw.h"
enum {
MW_NOT_ENABLED = 0, /* SE writeback not enabled */
@@
[PATCH v8 4/5] drm/mali-dp: Add RGB writeback formats for DP500.
Annotate the pixel format matrix for DP500 with the memory-write flag
for formats that are supported by the SE memwrite engine.
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_hw.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 0524b75f85c6e..df3649203e6a9 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -31,12 +31,12 @@ enum {
static const struct malidp_format_id malidp500_de_formats[] = {
/*fourcc, layers supporting the format, internal id */
- { DRM_FORMAT_ARGB2101010, DE_VIDEO1 | DE_GRAPHICS1 | DE_GRAPHICS2, 0 },
- { DRM_FORMAT_ABGR2101010, DE_VIDEO1 | DE_GRAPHICS1 | DE_GRAPHICS2, 1 },
+ { DRM_FORMAT_ARGB2101010, DE_VIDEO1 | DE_GRAPHICS1 | DE_GRAPHICS2 |
SE_MEMWRITE, 0 },
+ { DRM_FORMAT_ABGR2101010, DE_VIDEO1 | DE_GRAPHICS1 | DE_GRAPHICS2 |
SE_MEMWRITE, 1 },
{ DRM_FORMAT_ARGB, DE_VIDEO1 | DE_GRAPHICS1 | DE_GRAPHICS2, 2 },
{ DRM_FORMAT_ABGR, DE_VIDEO1 | DE_GRAPHICS1 | DE_GRAPHICS2, 3 },
- { DRM_FORMAT_XRGB, DE_VIDEO1 | DE_GRAPHICS1 | DE_GRAPHICS2, 4 },
- { DRM_FORMAT_XBGR, DE_VIDEO1 | DE_GRAPHICS1 | DE_GRAPHICS2, 5 },
+ { DRM_FORMAT_XRGB, DE_VIDEO1 | DE_GRAPHICS1 | DE_GRAPHICS2 |
SE_MEMWRITE, 4 },
+ { DRM_FORMAT_XBGR, DE_VIDEO1 | DE_GRAPHICS1 | DE_GRAPHICS2 |
SE_MEMWRITE, 5 },
{ DRM_FORMAT_RGB888, DE_VIDEO1 | DE_GRAPHICS1 | DE_GRAPHICS2, 6 },
{ DRM_FORMAT_BGR888, DE_VIDEO1 | DE_GRAPHICS1 | DE_GRAPHICS2, 7 },
{ DRM_FORMAT_RGBA5551, DE_VIDEO1 | DE_GRAPHICS1 | DE_GRAPHICS2, 8 },
@@ -45,7 +45,7 @@ static const struct malidp_format_id malidp500_de_formats[] =
{
{ DRM_FORMAT_BGR565, DE_VIDEO1 | DE_GRAPHICS1 | DE_GRAPHICS2, 11 },
{ DRM_FORMAT_UYVY, DE_VIDEO1, 12 },
{ DRM_FORMAT_YUYV, DE_VIDEO1, 13 },
- { DRM_FORMAT_NV12, DE_VIDEO1, 14 },
+ { DRM_FORMAT_NV12, DE_VIDEO1 | SE_MEMWRITE, 14 },
{ DRM_FORMAT_YUV420, DE_VIDEO1, 15 },
};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 2/5] drm: mali-dp: Add RGB writeback formats for DP550/DP650
From: Brian Starkey
Add a layer bit for the SE memory-write, and add it to the pixel format
matrix for DP550/DP650.
Signed-off-by: Brian Starkey
[rebased and fixed conflicts]
Signed-off-by: Mihail Atanassov
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_hw.c | 22 +++---
drivers/gpu/drm/arm/malidp_hw.h | 1 +
2 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 7a48a0defd90a..dd3a15964c588 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -47,27 +47,27 @@ static const struct malidp_format_id malidp500_de_formats[]
= {
#define MALIDP_COMMON_FORMATS \
/*fourcc, layers supporting the format, internal id */ \
- { DRM_FORMAT_ARGB2101010, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2,
MALIDP_ID(0, 0) }, \
- { DRM_FORMAT_ABGR2101010, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2,
MALIDP_ID(0, 1) }, \
- { DRM_FORMAT_RGBA1010102, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2,
MALIDP_ID(0, 2) }, \
- { DRM_FORMAT_BGRA1010102, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2,
MALIDP_ID(0, 3) }, \
+ { DRM_FORMAT_ARGB2101010, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 |
SE_MEMWRITE, MALIDP_ID(0, 0) }, \
+ { DRM_FORMAT_ABGR2101010, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 |
SE_MEMWRITE, MALIDP_ID(0, 1) }, \
+ { DRM_FORMAT_RGBA1010102, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 |
SE_MEMWRITE, MALIDP_ID(0, 2) }, \
+ { DRM_FORMAT_BGRA1010102, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 |
SE_MEMWRITE, MALIDP_ID(0, 3) }, \
{ DRM_FORMAT_ARGB, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART,
MALIDP_ID(1, 0) }, \
{ DRM_FORMAT_ABGR, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART,
MALIDP_ID(1, 1) }, \
{ DRM_FORMAT_RGBA, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART,
MALIDP_ID(1, 2) }, \
{ DRM_FORMAT_BGRA, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART,
MALIDP_ID(1, 3) }, \
- { DRM_FORMAT_XRGB, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART,
MALIDP_ID(2, 0) }, \
- { DRM_FORMAT_XBGR, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART,
MALIDP_ID(2, 1) }, \
- { DRM_FORMAT_RGBX, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART,
MALIDP_ID(2, 2) }, \
- { DRM_FORMAT_BGRX, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART,
MALIDP_ID(2, 3) }, \
- { DRM_FORMAT_RGB888, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(3,
0) }, \
- { DRM_FORMAT_BGR888, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(3,
1) }, \
+ { DRM_FORMAT_XRGB, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART
| SE_MEMWRITE, MALIDP_ID(2, 0) }, \
+ { DRM_FORMAT_XBGR, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART
| SE_MEMWRITE, MALIDP_ID(2, 1) }, \
+ { DRM_FORMAT_RGBX, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART
| SE_MEMWRITE, MALIDP_ID(2, 2) }, \
+ { DRM_FORMAT_BGRX, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART
| SE_MEMWRITE, MALIDP_ID(2, 3) }, \
+ { DRM_FORMAT_RGB888, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 |
SE_MEMWRITE, MALIDP_ID(3, 0) }, \
+ { DRM_FORMAT_BGR888, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 |
SE_MEMWRITE, MALIDP_ID(3, 1) }, \
{ DRM_FORMAT_RGBA5551, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2,
MALIDP_ID(4, 0) }, \
{ DRM_FORMAT_ABGR1555, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2,
MALIDP_ID(4, 1) }, \
{ DRM_FORMAT_RGB565, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(4,
2) }, \
{ DRM_FORMAT_BGR565, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(4,
3) }, \
{ DRM_FORMAT_YUYV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 2) },\
{ DRM_FORMAT_UYVY, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 3) },\
- { DRM_FORMAT_NV12, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 6) },\
+ { DRM_FORMAT_NV12, DE_VIDEO1 | DE_VIDEO2 | SE_MEMWRITE, MALIDP_ID(5, 6)
}, \
{ DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }
static const struct malidp_format_id malidp550_de_formats[] = {
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index 72cc22f828360..a242e97cf6428 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -33,6 +33,7 @@ enum {
DE_GRAPHICS2 = BIT(2), /* used only in DP500 */
DE_VIDEO2 = BIT(3),
DE_SMART = BIT(4),
+ SE_MEMWRITE = BIT(5),
};
struct malidp_format_id {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 0/5] drm/mali-dp: Add support for memory writeback engine
Hi, Updating the Mali DP memory writeback engine support series to match the v10 generic writeback connector support posted here [1]. Changelog: - v8: Addressed feedback from Brian wrt the state tracking that we deploy for DP500 and the timing of the CVAL setting. Also added SPDX license identifiers for the newly added files. - v7: Added support for DP500 writeback. It behaves differently from the rest of the IP portfolio, but because customers are asking for it to be supported in mainline, we're adding it here. - v6: skipped, in order to align with latest generic series numbers. - v5: https://lists.freedesktop.org/archives/dri-devel/2017-May/141799.html Best regards, Liviu [1] https://lists.freedesktop.org/archives/dri-devel/2018-June/179753.html Brian Starkey (2): drm: mali-dp: Add RGB writeback formats for DP550/DP650 drm: mali-dp: Add writeback connector Liviu Dudau (3): drm: mali-dp: Add support for writeback on DP550/DP650 drm/mali-dp: Add writeback support for DP500. drm/mali-dp: Add RGB writeback formats for DP500. drivers/gpu/drm/arm/Makefile | 1 + drivers/gpu/drm/arm/malidp_crtc.c | 10 ++ drivers/gpu/drm/arm/malidp_drv.c | 35 +++-- drivers/gpu/drm/arm/malidp_drv.h | 7 + drivers/gpu/drm/arm/malidp_hw.c | 176 ++--- drivers/gpu/drm/arm/malidp_hw.h | 21 +++ drivers/gpu/drm/arm/malidp_mw.c | 250 ++ drivers/gpu/drm/arm/malidp_mw.h | 14 ++ drivers/gpu/drm/arm/malidp_regs.h | 18 ++- drivers/gpu/drm/drm_atomic.c | 4 + 10 files changed, 504 insertions(+), 32 deletions(-) create mode 100644 drivers/gpu/drm/arm/malidp_mw.c create mode 100644 drivers/gpu/drm/arm/malidp_mw.h -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 1/5] drm: mali-dp: Add support for writeback on DP550/DP650
Mali-DP display processors are able to write the composition result to a
memory buffer via the SE.
Add entry points in the HAL for enabling/disabling this feature, and
implement support for it on DP650 and DP550. DP500 acts differently and
so is omitted from this change.
Changes since v3:
- Fix missing vsync interrupt for DP550
Signed-off-by: Liviu Dudau
Signed-off-by: Brian Starkey
[rebased and fixed conflicts]
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/arm/malidp_hw.c | 55 +--
drivers/gpu/drm/arm/malidp_hw.h | 17 ++
drivers/gpu/drm/arm/malidp_regs.h | 15 +
3 files changed, 85 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index d789b46dc8173..7a48a0defd90a 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -588,6 +588,49 @@ static long malidp550_se_calc_mclk(struct malidp_hw_device
*hwdev,
return ret;
}
+static int malidp550_enable_memwrite(struct malidp_hw_device *hwdev,
+dma_addr_t *addrs, s32 *pitches,
+int num_planes, u16 w, u16 h, u32 fmt_id)
+{
+ u32 base = MALIDP550_SE_MEMWRITE_BASE;
+ u32 de_base = malidp_get_block_base(hwdev, MALIDP_DE_BLOCK);
+
+ /* enable the scaling engine block */
+ malidp_hw_setbits(hwdev, MALIDP_SCALE_ENGINE_EN, de_base +
MALIDP_DE_DISPLAY_FUNC);
+
+ malidp_hw_write(hwdev, fmt_id, base + MALIDP_MW_FORMAT);
+ switch (num_planes) {
+ case 2:
+ malidp_hw_write(hwdev, lower_32_bits(addrs[1]), base +
MALIDP_MW_P2_PTR_LOW);
+ malidp_hw_write(hwdev, upper_32_bits(addrs[1]), base +
MALIDP_MW_P2_PTR_HIGH);
+ malidp_hw_write(hwdev, pitches[1], base + MALIDP_MW_P2_STRIDE);
+ /* fall through */
+ case 1:
+ malidp_hw_write(hwdev, lower_32_bits(addrs[0]), base +
MALIDP_MW_P1_PTR_LOW);
+ malidp_hw_write(hwdev, upper_32_bits(addrs[0]), base +
MALIDP_MW_P1_PTR_HIGH);
+ malidp_hw_write(hwdev, pitches[0], base + MALIDP_MW_P1_STRIDE);
+ break;
+ default:
+ WARN(1, "Invalid number of planes");
+ }
+
+ malidp_hw_write(hwdev, MALIDP_DE_H_ACTIVE(w) | MALIDP_DE_V_ACTIVE(h),
+ MALIDP550_SE_MEMWRITE_OUT_SIZE);
+ malidp_hw_setbits(hwdev, MALIDP550_SE_MEMWRITE_ONESHOT |
MALIDP_SE_MEMWRITE_EN,
+ MALIDP550_SE_CONTROL);
+
+ return 0;
+}
+
+static void malidp550_disable_memwrite(struct malidp_hw_device *hwdev)
+{
+ u32 base = malidp_get_block_base(hwdev, MALIDP_DE_BLOCK);
+
+ malidp_hw_clearbits(hwdev, MALIDP550_SE_MEMWRITE_ONESHOT |
MALIDP_SE_MEMWRITE_EN,
+ MALIDP550_SE_CONTROL);
+ malidp_hw_clearbits(hwdev, MALIDP_SCALE_ENGINE_EN, base +
MALIDP_DE_DISPLAY_FUNC);
+}
+
static int malidp650_query_hw(struct malidp_hw_device *hwdev)
{
u32 conf = malidp_hw_read(hwdev, MALIDP550_CONFIG_ID);
@@ -673,9 +716,11 @@ const struct malidp_hw malidp_device[MALIDP_MAX_DEVICES] =
{
.se_irq_map = {
.irq_mask = MALIDP550_SE_IRQ_EOW |
MALIDP550_SE_IRQ_AXI_ERR,
+ .vsync_irq = MALIDP550_SE_IRQ_EOW,
},
.dc_irq_map = {
- .irq_mask = MALIDP550_DC_IRQ_CONF_VALID,
+ .irq_mask = MALIDP550_DC_IRQ_CONF_VALID |
+ MALIDP550_DC_IRQ_SE,
.vsync_irq = MALIDP550_DC_IRQ_CONF_VALID,
},
.pixel_formats = malidp550_de_formats,
@@ -691,6 +736,8 @@ const struct malidp_hw malidp_device[MALIDP_MAX_DEVICES] = {
.rotmem_required = malidp550_rotmem_required,
.se_set_scaling_coeffs = malidp550_se_set_scaling_coeffs,
.se_calc_mclk = malidp550_se_calc_mclk,
+ .enable_memwrite = malidp550_enable_memwrite,
+ .disable_memwrite = malidp550_disable_memwrite,
.features = 0,
},
[MALIDP_650] = {
@@ -711,9 +758,11 @@ const struct malidp_hw malidp_device[MALIDP_MAX_DEVICES] =
{
.se_irq_map = {
.irq_mask = MALIDP550_SE_IRQ_EOW |
MALIDP550_SE_IRQ_AXI_ERR,
+ .vsync_irq = MALIDP550_SE_IRQ_EOW,
},
.dc_irq_map = {
- .irq_mask = MALIDP550_DC_IRQ_CONF_VALID,
+ .irq_mask = MALIDP550_DC_IRQ_CONF_VALID |
+ MALIDP550_DC_IRQ_SE,
.vsync_irq =
[Bug 106892] GPU hang with radeon glx driver
https://bugs.freedesktop.org/show_bug.cgi?id=106892 --- Comment #3 from Simon --- ok also crashing with 1024x768@60Hz, so seems the resolution and frequency dont really matter for that bug, sry for the confusion. ^^ Anyway how do I disable these annoying EDID message spam in dmesg? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 3/3] drm: writeback: Add client capability for exposing writeback connectors
Due to the fact that writeback connectors behave in a special way
in DRM (they always report being disconnected) we might confuse some
userspace. Add a client capability for writeback connectors that will
filter them out for clients that don't understand the capability.
Changelog:
- only accept the capability if the client has already set the
DRM_CLIENT_CAP_ATOMIC one.
Cc: Sean Paul
Cc: Brian Starkey
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/drm_ioctl.c | 7 +++
drivers/gpu/drm/drm_mode_config.c | 5 +
include/drm/drm_file.h| 7 +++
include/uapi/drm/drm.h| 9 +
4 files changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 0d4cfb232576f..fe49fb0356b5a 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -334,6 +334,13 @@ drm_setclientcap(struct drm_device *dev, void *data,
struct drm_file *file_priv)
return -EINVAL;
file_priv->aspect_ratio_allowed = req->value;
break;
+ case DRM_CLIENT_CAP_WRITEBACK_CONNECTORS:
+ if (!file_priv->atomic)
+ return -EINVAL;
+ if (req->value > 1)
+ return -EINVAL;
+ file_priv->writeback_connectors = req->value;
+ break;
default:
return -EINVAL;
}
diff --git a/drivers/gpu/drm/drm_mode_config.c
b/drivers/gpu/drm/drm_mode_config.c
index e5c653357024d..21e353bd3948e 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -145,6 +145,11 @@ int drm_mode_getresources(struct drm_device *dev, void
*data,
count = 0;
connector_id = u64_to_user_ptr(card_res->connector_id_ptr);
drm_for_each_connector_iter(connector, _iter) {
+ /* only expose writeback connectors if userspace understands
them */
+ if (!file_priv->writeback_connectors &&
+ (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK))
+ continue;
+
if (drm_lease_held(file_priv, connector->base.id)) {
if (count < card_res->count_connectors &&
put_user(connector->base.id, connector_id + count))
{
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 027ac16da3d15..26485acc51d79 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -192,6 +192,13 @@ struct drm_file {
*/
unsigned aspect_ratio_allowed:1;
+ /**
+* @writeback_connectors:
+*
+* True if client understands writeback connectors
+*/
+ unsigned writeback_connectors:1;
+
/**
* @is_master:
*
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 9c660e1688abe..300f336633f28 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -687,6 +687,15 @@ struct drm_get_cap {
*/
#define DRM_CLIENT_CAP_ASPECT_RATIO4
+/**
+ * DRM_CLIENT_CAP_WRITEBACK_CONNECTORS
+ *
+ * If set to 1, the DRM core will expose special connectors to be used for
+ * writing back to memory the scene setup in the commit. Depends on client
+ * also supporting DRM_CLIENT_CAP_ATOMIC
+ */
+#define DRM_CLIENT_CAP_WRITEBACK_CONNECTORS5
+
/** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
struct drm_set_client_cap {
__u64 capability;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 2/3] drm: writeback: Add out-fences for writeback connectors
From: Brian Starkey
Add the WRITEBACK_OUT_FENCE_PTR property to writeback connectors, to
enable userspace to get a fence which will signal once the writeback is
complete. It is not allowed to request an out-fence without a
framebuffer attached to the connector.
A timeline is added to drm_writeback_connector for use by the writeback
out-fences.
In the case of a commit failure or DRM_MODE_ATOMIC_TEST_ONLY, the fence
is set to -1.
Changes from v2:
- Rebase onto Gustavo Padovan's v9 explicit sync series
- Change out_fence_ptr type to s32 __user *
- Set *out_fence_ptr to -1 in drm_atomic_connector_set_property
- Store fence in drm_writeback_job
Gustavo Padovan:
- Move out_fence_ptr out of connector_state
- Signal fence from drm_writeback_signal_completion instead of
in driver directly
Changes from v3:
- Rebase onto commit 7e9081c5aac7 ("drm/fence: fix memory overwrite
when setting out_fence fd") (change out_fence_ptr to s32 __user *,
for real this time.)
- Update documentation around WRITEBACK_OUT_FENCE_PTR
Signed-off-by: Brian Starkey
[rebased and fixed conflicts]
Signed-off-by: Mihail Atanassov
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/drm_atomic.c| 99 ++---
drivers/gpu/drm/drm_writeback.c | 109 +++-
include/drm/drm_atomic.h| 8 +++
include/drm/drm_connector.h | 8 +--
include/drm/drm_mode_config.h | 8 +++
include/drm/drm_writeback.h | 41 +++-
6 files changed, 257 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index f2400c77fe3f3..db3cb47da31b6 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -326,6 +326,35 @@ static s32 __user *get_out_fence_for_crtc(struct
drm_atomic_state *state,
return fence_ptr;
}
+static int set_out_fence_for_connector(struct drm_atomic_state *state,
+ struct drm_connector *connector,
+ s32 __user *fence_ptr)
+{
+ unsigned int index = drm_connector_index(connector);
+
+ if (!fence_ptr)
+ return 0;
+
+ if (put_user(-1, fence_ptr))
+ return -EFAULT;
+
+ state->connectors[index].out_fence_ptr = fence_ptr;
+
+ return 0;
+}
+
+static s32 __user *get_out_fence_for_connector(struct drm_atomic_state *state,
+ struct drm_connector *connector)
+{
+ unsigned int index = drm_connector_index(connector);
+ s32 __user *fence_ptr;
+
+ fence_ptr = state->connectors[index].out_fence_ptr;
+ state->connectors[index].out_fence_ptr = NULL;
+
+ return fence_ptr;
+}
+
/**
* drm_atomic_set_mode_for_crtc - set mode for CRTC
* @state: the CRTC whose incoming state to update
@@ -713,6 +742,12 @@ static int drm_atomic_connector_check(struct drm_connector
*connector,
return -EINVAL;
}
+ if (writeback_job->out_fence && !writeback_job->fb) {
+ DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] requesting out-fence
without framebuffer\n",
+connector->base.id, connector->name);
+ return -EINVAL;
+ }
+
return 0;
}
@@ -1332,6 +1367,11 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
if (fb)
drm_framebuffer_put(fb);
return ret;
+ } else if (property == config->writeback_out_fence_ptr_property) {
+ s32 __user *fence_ptr = u64_to_user_ptr(val);
+
+ return set_out_fence_for_connector(state->state, connector,
+ fence_ptr);
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -1416,6 +1456,8 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
*val = 0;
+ } else if (property == config->writeback_out_fence_ptr_property) {
+ *val = 0;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
@@ -2285,7 +2327,7 @@ static int setup_out_fence(struct drm_out_fence_state
*fence_state,
return 0;
}
-static int prepare_crtc_signaling(struct drm_device *dev,
+static int prepare_signaling(struct drm_device *dev,
struct drm_atomic_state *state,
struct drm_mode_atomic *arg,
struct drm_file *file_priv,
@@ -2294,6 +2336,8 @@ static int prepare_crtc_signaling(struct drm_device *dev,
[PATCH v10 1/3] drm: Add writeback connector type
From: Brian Starkey Writeback connectors represent writeback engines which can write the CRTC output to a memory framebuffer. Add a writeback connector type and related support functions. Drivers should initialize a writeback connector with drm_writeback_connector_init() which takes care of setting up all the writeback-specific details on top of the normal functionality of drm_connector_init(). Writeback connectors have a WRITEBACK_FB_ID property, used to set the output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the supported writeback formats to userspace. When a framebuffer is attached to a writeback connector with the WRITEBACK_FB_ID property, it is used only once (for the commit in which it was included), and userspace can never read back the value of WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is attached to a CRTC. Changes since v1: - Added drm_writeback.c + documentation - Added helper to initialize writeback connector in one go - Added core checks - Squashed into a single commit - Dropped the client cap - Writeback framebuffers are no longer persistent Changes since v2: Daniel Vetter: - Subclass drm_connector to drm_writeback_connector - Relax check to allow CRTC to be set without an FB - Add some writeback_ prefixes - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary Gustavo Padovan: - Add drm_writeback_job to handle writeback signalling centrally Changes since v3: - Rebased - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS Chances since v4: - Embed a drm_encoder inside the drm_writeback_connector to reduce the amount of boilerplate code required from the drivers that are using it. Changes since v5: - Added Rob Clark's atomic_commit() vfunc to connector helper funcs, so that writeback jobs are committed from atomic helpers - Updated create_writeback_properties() signature to return an error code rather than a boolean false for failure. - Free writeback job with the connector state rather than when doing the cleanup_work() Changes since v7: - fix extraneous use of out_fence that is only introduced in a subsequent patch. Changes since v8: - whitespace changes pull from subsequent patch Changes since v9: - Revert the v6 changes that free the writeback job in the connector state cleanup and return to doing it in the cleanup_work() function Signed-off-by: Brian Starkey [rebased and fixed conflicts] Signed-off-by: Mihail Atanassov [rebased and added atomic_commit() vfunc for writeback jobs] Signed-off-by: Rob Clark Signed-off-by: Liviu Dudau --- Documentation/gpu/drm-kms.rst| 9 + drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_atomic.c | 124 drivers/gpu/drm/drm_atomic_helper.c | 25 +++ drivers/gpu/drm/drm_connector.c | 4 +- drivers/gpu/drm/drm_writeback.c | 245 +++ include/drm/drm_atomic.h | 3 + include/drm/drm_connector.h | 13 ++ include/drm/drm_mode_config.h| 15 ++ include/drm/drm_modeset_helper_vtables.h | 11 + include/drm/drm_writeback.h | 91 + include/uapi/drm/drm_mode.h | 1 + 12 files changed, 541 insertions(+), 2 deletions(-) create mode 100644 drivers/gpu/drm/drm_writeback.c create mode 100644 include/drm/drm_writeback.h diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 1dffd1ac4cd44..809d403087f95 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -373,6 +373,15 @@ Connector Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_connector.c :export: +Writeback Connectors + + +.. kernel-doc:: drivers/gpu/drm/drm_writeback.c + :doc: overview + +.. kernel-doc:: drivers/gpu/drm/drm_writeback.c + :export: + Encoder Abstraction === diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index ef9f3dab287fd..69c13517ea3a6 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -18,7 +18,7 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \ drm_encoder.o drm_mode_object.o drm_property.o \ drm_plane.o drm_color_mgmt.o drm_print.o \ drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \ - drm_syncobj.o drm_lease.o + drm_syncobj.o drm_lease.o drm_writeback.o drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o drm-$(CONFIG_DRM_VM) += drm_vm.o diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 895741e9cd7db..f2400c77fe3f3 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -30,6 +30,7 @@ #include #include #include +#include #include #include "drm_crtc_internal.h" @@ -676,6 +677,45 @@ static void drm_atomic_crtc_print_state(struct drm_printer *p, crtc->funcs->atomic_print_state(p, state); } +/**
[PATCH v10 0/3] drm: Introduce writeback connectors
Hi,
This is v10 of the writeback connector series. Compared to v9 I've
reverted to the v6 way of cleaning up the writeback job in the cleanup_work()
function, where we also drop the reference to the job's framebuffer. I was
trying to come up with a reference counted implementation for the job, but
Sean Paul pointed out to Brian that it seems to be safe to free work_struct
structures in the workqueue callback, so we are going back to the original
implementation.
While doing that, I've also updated the patcheset to use the latest
drm_framebuffer_{put,get,assign} functions for managing the framebuffer
reference that the wriback job holds.
I will ask Gustavo to pull this series into drm-misc if there are no further
comments.
Best regards,
Liviu
Brian Starkey (2):
drm: Add writeback connector type
drm: writeback: Add out-fences for writeback connectors
Liviu Dudau (1):
drm: writeback: Add client capability for exposing writeback
connectors
Documentation/gpu/drm-kms.rst| 9 +
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_atomic.c | 223 ++-
drivers/gpu/drm/drm_atomic_helper.c | 25 ++
drivers/gpu/drm/drm_connector.c | 4 +-
drivers/gpu/drm/drm_ioctl.c | 7 +
drivers/gpu/drm/drm_mode_config.c| 5 +
drivers/gpu/drm/drm_writeback.c | 350 +++
include/drm/drm_atomic.h | 11 +
include/drm/drm_connector.h | 13 +
include/drm/drm_file.h | 7 +
include/drm/drm_mode_config.h| 23 ++
include/drm/drm_modeset_helper_vtables.h | 11 +
include/drm/drm_writeback.h | 130 +
include/uapi/drm/drm.h | 9 +
include/uapi/drm/drm_mode.h | 1 +
16 files changed, 819 insertions(+), 11 deletions(-)
create mode 100644 drivers/gpu/drm/drm_writeback.c
create mode 100644 include/drm/drm_writeback.h
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 9/9] xen/gntdev: Implement dma-buf import functionality
From: Oleksandr Andrushchenko
1. Import a dma-buf with the file descriptor provided and export
granted references to the pages of that dma-buf into the array
of grant references.
2. Add API to close all references to an imported buffer, so it can be
released by the owner. This is only valid for buffers created with
IOCTL_GNTDEV_DMABUF_IMP_TO_REFS.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/gntdev-dmabuf.c | 240 +++-
1 file changed, 238 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index 84cba67c6ad7..4d250eb8babc 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -17,6 +17,15 @@
#include "gntdev-common.h"
#include "gntdev-dmabuf.h"
+#ifndef GRANT_INVALID_REF
+/*
+ * Note on usage of grant reference 0 as invalid grant reference:
+ * grant reference 0 is valid, but never exposed to a driver,
+ * because of the fact it is already in use/reserved by the PV console.
+ */
+#define GRANT_INVALID_REF 0
+#endif
+
struct gntdev_dmabuf {
struct gntdev_dmabuf_priv *priv;
struct dma_buf *dmabuf;
@@ -31,6 +40,14 @@ struct gntdev_dmabuf {
struct gntdev_priv *priv;
struct gntdev_grant_map *map;
} exp;
+ struct {
+ /* Granted references of the imported buffer. */
+ grant_ref_t *refs;
+ /* Scatter-gather table of the imported buffer. */
+ struct sg_table *sgt;
+ /* dma-buf attachment of the imported buffer. */
+ struct dma_buf_attachment *attach;
+ } imp;
} u;
/* Number of pages this buffer has. */
@@ -55,6 +72,8 @@ struct gntdev_dmabuf_priv {
struct list_head exp_list;
/* List of wait objects. */
struct list_head exp_wait_list;
+ /* List of imported DMA buffers. */
+ struct list_head imp_list;
/* This is the lock which protects dma_buf_xxx lists. */
struct mutex lock;
};
@@ -500,21 +519,237 @@ int gntdev_dmabuf_exp_from_refs(struct gntdev_priv
*priv, int flags,
/* DMA buffer import support. */
+static int
+dmabuf_imp_grant_foreign_access(struct page **pages, u32 *refs,
+ int count, int domid)
+{
+ grant_ref_t priv_gref_head;
+ int i, ret;
+
+ ret = gnttab_alloc_grant_references(count, _gref_head);
+ if (ret < 0) {
+ pr_debug("Cannot allocate grant references, ret %d\n", ret);
+ return ret;
+ }
+
+ for (i = 0; i < count; i++) {
+ int cur_ref;
+
+ cur_ref = gnttab_claim_grant_reference(_gref_head);
+ if (cur_ref < 0) {
+ ret = cur_ref;
+ pr_debug("Cannot claim grant reference, ret %d\n", ret);
+ goto out;
+ }
+
+ gnttab_grant_foreign_access_ref(cur_ref, domid,
+ xen_page_to_gfn(pages[i]), 0);
+ refs[i] = cur_ref;
+ }
+
+ return 0;
+
+out:
+ gnttab_free_grant_references(priv_gref_head);
+ return ret;
+}
+
+static void dmabuf_imp_end_foreign_access(u32 *refs, int count)
+{
+ int i;
+
+ for (i = 0; i < count; i++)
+ if (refs[i] != GRANT_INVALID_REF)
+ gnttab_end_foreign_access(refs[i], 0, 0UL);
+}
+
+static void dmabuf_imp_free_storage(struct gntdev_dmabuf *gntdev_dmabuf)
+{
+ kfree(gntdev_dmabuf->pages);
+ kfree(gntdev_dmabuf->u.imp.refs);
+ kfree(gntdev_dmabuf);
+}
+
+static struct gntdev_dmabuf *dmabuf_imp_alloc_storage(int count)
+{
+ struct gntdev_dmabuf *gntdev_dmabuf;
+ int i;
+
+ gntdev_dmabuf = kzalloc(sizeof(*gntdev_dmabuf), GFP_KERNEL);
+ if (!gntdev_dmabuf)
+ goto fail;
+
+ gntdev_dmabuf->u.imp.refs = kcalloc(count,
+
sizeof(gntdev_dmabuf->u.imp.refs[0]),
+ GFP_KERNEL);
+ if (!gntdev_dmabuf->u.imp.refs)
+ goto fail;
+
+ gntdev_dmabuf->pages = kcalloc(count,
+ sizeof(gntdev_dmabuf->pages[0]),
+ GFP_KERNEL);
+ if (!gntdev_dmabuf->pages)
+ goto fail;
+
+ gntdev_dmabuf->nr_pages = count;
+
+ for (i = 0; i < count; i++)
+ gntdev_dmabuf->u.imp.refs[i] = GRANT_INVALID_REF;
+
+ return gntdev_dmabuf;
+
+fail:
+ dmabuf_imp_free_storage(gntdev_dmabuf);
+ return ERR_PTR(-ENOMEM);
+}
+
struct gntdev_dmabuf *
gntdev_dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *priv, struct device *dev,
int fd, int count, int domid)
{
- return ERR_PTR(-ENOMEM);
+ struct
[PATCH v3 8/9] xen/gntdev: Implement dma-buf export functionality
From: Oleksandr Andrushchenko
1. Create a dma-buf from grant references provided by the foreign
domain. By default dma-buf is backed by system memory pages, but
by providing GNTDEV_DMA_FLAG_XXX flags it can also be created
as a DMA write-combine/coherent buffer, e.g. allocated with
corresponding dma_alloc_xxx API.
Export the resulting buffer as a new dma-buf.
2. Implement waiting for the dma-buf to be released: block until the
dma-buf with the file descriptor provided is released.
If within the time-out provided the buffer is not released then
-ETIMEDOUT error is returned. If the buffer with the file descriptor
does not exist or has already been released, then -ENOENT is
returned. For valid file descriptors this must not be treated as
error.
3. Make gntdev's common code and structures available to dma-buf.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/gntdev-common.h | 4 +
drivers/xen/gntdev-dmabuf.c | 470 +++-
drivers/xen/gntdev.c| 10 +
3 files changed, 482 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/gntdev-common.h b/drivers/xen/gntdev-common.h
index a3408fd39b07..72f80dbce861 100644
--- a/drivers/xen/gntdev-common.h
+++ b/drivers/xen/gntdev-common.h
@@ -89,4 +89,8 @@ bool gntdev_account_mapped_pages(int count);
int gntdev_map_grant_pages(struct gntdev_grant_map *map);
+#ifdef CONFIG_XEN_GNTDEV_DMABUF
+void gntdev_remove_map(struct gntdev_priv *priv, struct gntdev_grant_map *map);
+#endif
+
#endif
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index dc57c6a25525..84cba67c6ad7 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -3,13 +3,53 @@
/*
* Xen dma-buf functionality for gntdev.
*
+ * DMA buffer implementation is based on drivers/gpu/drm/drm_prime.c.
+ *
* Copyright (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
*/
+#include
#include
+#include
+#include
+
+#include "gntdev-common.h"
#include "gntdev-dmabuf.h"
+struct gntdev_dmabuf {
+ struct gntdev_dmabuf_priv *priv;
+ struct dma_buf *dmabuf;
+ struct list_head next;
+ int fd;
+
+ union {
+ struct {
+ /* Exported buffers are reference counted. */
+ struct kref refcount;
+
+ struct gntdev_priv *priv;
+ struct gntdev_grant_map *map;
+ } exp;
+ } u;
+
+ /* Number of pages this buffer has. */
+ int nr_pages;
+ /* Pages of this buffer. */
+ struct page **pages;
+};
+
+struct gntdev_dmabuf_wait_obj {
+ struct list_head next;
+ struct gntdev_dmabuf *gntdev_dmabuf;
+ struct completion completion;
+};
+
+struct gntdev_dmabuf_attachment {
+ struct sg_table *sgt;
+ enum dma_data_direction dir;
+};
+
struct gntdev_dmabuf_priv {
/* List of exported DMA buffers. */
struct list_head exp_list;
@@ -23,17 +63,439 @@ struct gntdev_dmabuf_priv {
/* Implementation of wait for exported DMA buffer to be released. */
+static void dmabuf_exp_release(struct kref *kref);
+
+static struct gntdev_dmabuf_wait_obj *
+dmabuf_exp_wait_obj_new(struct gntdev_dmabuf_priv *priv,
+ struct gntdev_dmabuf *gntdev_dmabuf)
+{
+ struct gntdev_dmabuf_wait_obj *obj;
+
+ obj = kzalloc(sizeof(*obj), GFP_KERNEL);
+ if (!obj)
+ return ERR_PTR(-ENOMEM);
+
+ init_completion(>completion);
+ obj->gntdev_dmabuf = gntdev_dmabuf;
+
+ mutex_lock(>lock);
+ list_add(>next, >exp_wait_list);
+ /* Put our reference and wait for gntdev_dmabuf's release to fire. */
+ kref_put(_dmabuf->u.exp.refcount, dmabuf_exp_release);
+ mutex_unlock(>lock);
+ return obj;
+}
+
+static void dmabuf_exp_wait_obj_free(struct gntdev_dmabuf_priv *priv,
+struct gntdev_dmabuf_wait_obj *obj)
+{
+ struct gntdev_dmabuf_wait_obj *cur_obj, *q;
+
+ mutex_lock(>lock);
+ list_for_each_entry_safe(cur_obj, q, >exp_wait_list, next)
+ if (cur_obj == obj) {
+ list_del(>next);
+ kfree(obj);
+ break;
+ }
+ mutex_unlock(>lock);
+}
+
+static int dmabuf_exp_wait_obj_wait(struct gntdev_dmabuf_wait_obj *obj,
+ u32 wait_to_ms)
+{
+ if (wait_for_completion_timeout(>completion,
+ msecs_to_jiffies(wait_to_ms)) <= 0)
+ return -ETIMEDOUT;
+
+ return 0;
+}
+
+static void dmabuf_exp_wait_obj_signal(struct gntdev_dmabuf_priv *priv,
+ struct gntdev_dmabuf *gntdev_dmabuf)
+{
+ struct gntdev_dmabuf_wait_obj *obj, *q;
+
+ list_for_each_entry_safe(obj, q, >exp_wait_list, next)
+ if (obj->gntdev_dmabuf == gntdev_dmabuf) {
+ pr_debug("Found
[PATCH v3 6/9] xen/gntdev: Make private routines/structures accessible
From: Oleksandr Andrushchenko
This is in preparation for adding support of DMA buffer
functionality: make map/unmap related code and structures, used
privately by gntdev, ready for dma-buf extension, which will re-use
these. Rename corresponding structures as those become non-private
to gntdev now.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/gntdev-common.h | 86 +++
drivers/xen/gntdev.c| 132
2 files changed, 128 insertions(+), 90 deletions(-)
create mode 100644 drivers/xen/gntdev-common.h
diff --git a/drivers/xen/gntdev-common.h b/drivers/xen/gntdev-common.h
new file mode 100644
index ..7a9845a6bee9
--- /dev/null
+++ b/drivers/xen/gntdev-common.h
@@ -0,0 +1,86 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+/*
+ * Common functionality of grant device.
+ *
+ * Copyright (c) 2006-2007, D G Murray.
+ * (c) 2009 Gerd Hoffmann
+ * (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
+ */
+
+#ifndef _GNTDEV_COMMON_H
+#define _GNTDEV_COMMON_H
+
+#include
+#include
+#include
+#include
+
+struct gntdev_priv {
+ /* maps with visible offsets in the file descriptor */
+ struct list_head maps;
+ /* maps that are not visible; will be freed on munmap.
+* Only populated if populate_freeable_maps == 1 */
+ struct list_head freeable_maps;
+ /* lock protects maps and freeable_maps */
+ struct mutex lock;
+ struct mm_struct *mm;
+ struct mmu_notifier mn;
+
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ /* Device for which DMA memory is allocated. */
+ struct device *dma_dev;
+#endif
+};
+
+struct gntdev_unmap_notify {
+ int flags;
+ /* Address relative to the start of the gntdev_grant_map */
+ int addr;
+ int event;
+};
+
+struct gntdev_grant_map {
+ struct list_head next;
+ struct vm_area_struct *vma;
+ int index;
+ int count;
+ int flags;
+ refcount_t users;
+ struct gntdev_unmap_notify notify;
+ struct ioctl_gntdev_grant_ref *grants;
+ struct gnttab_map_grant_ref *map_ops;
+ struct gnttab_unmap_grant_ref *unmap_ops;
+ struct gnttab_map_grant_ref *kmap_ops;
+ struct gnttab_unmap_grant_ref *kunmap_ops;
+ struct page **pages;
+ unsigned long pages_vm_start;
+
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ /*
+* If dmabuf_vaddr is not NULL then this mapping is backed by DMA
+* capable memory.
+*/
+
+ struct device *dma_dev;
+ /* Flags used to create this DMA buffer: GNTDEV_DMA_FLAG_XXX. */
+ int dma_flags;
+ void *dma_vaddr;
+ dma_addr_t dma_bus_addr;
+ /* Needed to avoid allocation in gnttab_dma_free_pages(). */
+ xen_pfn_t *frames;
+#endif
+};
+
+struct gntdev_grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count,
+ int dma_flags);
+
+void gntdev_add_map(struct gntdev_priv *priv, struct gntdev_grant_map *add);
+
+void gntdev_put_map(struct gntdev_priv *priv, struct gntdev_grant_map *map);
+
+bool gntdev_account_mapped_pages(int count);
+
+int gntdev_map_grant_pages(struct gntdev_grant_map *map);
+
+#endif
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index d6b79ad1cd6f..a09db23e9663 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -6,6 +6,7 @@
*
* Copyright (c) 2006-2007, D G Murray.
* (c) 2009 Gerd Hoffmann
+ * (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ -26,10 +27,6 @@
#include
#include
#include
-#include
-#include
-#include
-#include
#include
#include
#include
@@ -50,6 +47,8 @@
#include
#include
+#include "gntdev-common.h"
+
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Derek G. Murray , "
"Gerd Hoffmann ");
@@ -65,73 +64,23 @@ static atomic_t pages_mapped = ATOMIC_INIT(0);
static int use_ptemod;
#define populate_freeable_maps use_ptemod
-struct gntdev_priv {
- /* maps with visible offsets in the file descriptor */
- struct list_head maps;
- /* maps that are not visible; will be freed on munmap.
-* Only populated if populate_freeable_maps == 1 */
- struct list_head freeable_maps;
- /* lock protects maps and freeable_maps */
- struct mutex lock;
- struct mm_struct *mm;
- struct mmu_notifier mn;
-
-#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
- /* Device for which DMA memory is allocated. */
- struct device *dma_dev;
-#endif
-};
-
-struct unmap_notify {
- int flags;
- /* Address relative to the start of the grant_map */
- int addr;
- int event;
-};
-
-struct grant_map {
- struct list_head next;
- struct vm_area_struct *vma;
- int index;
- int count;
- int flags;
- refcount_t users;
[PATCH v3 7/9] xen/gntdev: Add initial support for dma-buf UAPI
From: Oleksandr Andrushchenko
Add UAPI and IOCTLs for dma-buf grant device driver extension:
the extension allows userspace processes and kernel modules to
use Xen backed dma-buf implementation. With this extension grant
references to the pages of an imported dma-buf can be exported
for other domain use and grant references coming from a foreign
domain can be converted into a local dma-buf for local export.
Implement basic initialization and stubs for Xen DMA buffers'
support.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/Kconfig | 10 +++
drivers/xen/Makefile| 1 +
drivers/xen/gntdev-common.h | 6 ++
drivers/xen/gntdev-dmabuf.c | 72
drivers/xen/gntdev-dmabuf.h | 39 +++
drivers/xen/gntdev.c| 132
include/uapi/xen/gntdev.h | 91 +
7 files changed, 351 insertions(+)
create mode 100644 drivers/xen/gntdev-dmabuf.c
create mode 100644 drivers/xen/gntdev-dmabuf.h
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 39536ddfbce4..52d64e4b6b81 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -152,6 +152,16 @@ config XEN_GNTDEV
help
Allows userspace processes to use grants.
+config XEN_GNTDEV_DMABUF
+ bool "Add support for dma-buf grant access device driver extension"
+ depends on XEN_GNTDEV && XEN_GRANT_DMA_ALLOC && DMA_SHARED_BUFFER
+ help
+ Allows userspace processes and kernel modules to use Xen backed
+ dma-buf implementation. With this extension grant references to
+ the pages of an imported dma-buf can be exported for other domain
+ use and grant references coming from a foreign domain can be
+ converted into a local dma-buf for local export.
+
config XEN_GRANT_DEV_ALLOC
tristate "User-space grant reference allocator driver"
depends on XEN
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 3c87b0c3aca6..33afb7b2b227 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -41,5 +41,6 @@ obj-$(CONFIG_XEN_PVCALLS_BACKEND) += pvcalls-back.o
obj-$(CONFIG_XEN_PVCALLS_FRONTEND) += pvcalls-front.o
xen-evtchn-y := evtchn.o
xen-gntdev-y := gntdev.o
+xen-gntdev-$(CONFIG_XEN_GNTDEV_DMABUF) += gntdev-dmabuf.o
xen-gntalloc-y := gntalloc.o
xen-privcmd-y := privcmd.o
diff --git a/drivers/xen/gntdev-common.h b/drivers/xen/gntdev-common.h
index 7a9845a6bee9..a3408fd39b07 100644
--- a/drivers/xen/gntdev-common.h
+++ b/drivers/xen/gntdev-common.h
@@ -16,6 +16,8 @@
#include
#include
+struct gntdev_dmabuf_priv;
+
struct gntdev_priv {
/* maps with visible offsets in the file descriptor */
struct list_head maps;
@@ -31,6 +33,10 @@ struct gntdev_priv {
/* Device for which DMA memory is allocated. */
struct device *dma_dev;
#endif
+
+#ifdef CONFIG_XEN_GNTDEV_DMABUF
+ struct gntdev_dmabuf_priv *dmabuf_priv;
+#endif
};
struct gntdev_unmap_notify {
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
new file mode 100644
index ..dc57c6a25525
--- /dev/null
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Xen dma-buf functionality for gntdev.
+ *
+ * Copyright (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
+ */
+
+#include
+
+#include "gntdev-dmabuf.h"
+
+struct gntdev_dmabuf_priv {
+ /* List of exported DMA buffers. */
+ struct list_head exp_list;
+ /* List of wait objects. */
+ struct list_head exp_wait_list;
+ /* This is the lock which protects dma_buf_xxx lists. */
+ struct mutex lock;
+};
+
+/* DMA buffer export support. */
+
+/* Implementation of wait for exported DMA buffer to be released. */
+
+int gntdev_dmabuf_exp_wait_released(struct gntdev_dmabuf_priv *priv, int fd,
+ int wait_to_ms)
+{
+ return -EINVAL;
+}
+
+int gntdev_dmabuf_exp_from_refs(struct gntdev_priv *priv, int flags,
+ int count, u32 domid, u32 *refs, u32 *fd)
+{
+ *fd = -1;
+ return -EINVAL;
+}
+
+/* DMA buffer import support. */
+
+struct gntdev_dmabuf *
+gntdev_dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *priv, struct device *dev,
+ int fd, int count, int domid)
+{
+ return ERR_PTR(-ENOMEM);
+}
+
+u32 *gntdev_dmabuf_imp_get_refs(struct gntdev_dmabuf *gntdev_dmabuf)
+{
+ return NULL;
+}
+
+int gntdev_dmabuf_imp_release(struct gntdev_dmabuf_priv *priv, u32 fd)
+{
+ return -EINVAL;
+}
+
+struct gntdev_dmabuf_priv *gntdev_dmabuf_init(void)
+{
+ struct gntdev_dmabuf_priv *priv;
+
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return ERR_PTR(-ENOMEM);
+
+ return priv;
+}
+
+void gntdev_dmabuf_fini(struct gntdev_dmabuf_priv *priv)
+{
+
[PATCH v3 0/9] xen: dma-buf support for grant device
From: Oleksandr Andrushchenko This work is in response to my previous attempt to introduce Xen/DRM zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based frontends/backends. There is also an existing hyper_dmabuf approach available [3] which, if reworked to utilize the proposed solution, can greatly benefit as well. RFC for this series was published and discussed [9], comments addressed. The original rationale behind this work was to enable zero-copying use-cases while working with Xen para-virtual display driver [4]: when using Xen PV DRM frontend driver then on backend side one will need to do copying of display buffers' contents (filled by the frontend's user-space) into buffers allocated at the backend side. Taking into account the size of display buffers and frames per second it may result in unneeded huge data bus occupation and performance loss. The helper driver [4] allows implementing zero-copying use-cases when using Xen para-virtualized frontend display driver by implementing a DRM/KMS helper driver running on backend's side. It utilizes PRIME buffers API (implemented on top of Linux dma-buf) to share frontend's buffers with physical device drivers on backend's side: - a dumb buffer created on backend's side can be shared with the Xen PV frontend driver, so it directly writes into backend's domain memory (into the buffer exported from DRM/KMS driver of a physical display device) - a dumb buffer allocated by the frontend can be imported into physical device DRM/KMS driver, thus allowing to achieve no copying as well Finally, it was discussed and decided ([1], [5]) that it is worth implementing such use-cases via extension of the existing Xen gntdev driver instead of introducing new DRM specific driver. Please note, that the support of dma-buf is Linux only, as dma-buf is a Linux only thing. Now to the proposed solution. The changes to the existing Xen drivers in the Linux kernel fall into 2 categories: 1. DMA-able memory buffer allocation and increasing/decreasing memory reservation of the pages of such a buffer. This is required if we are about to share dma-buf with the hardware that does require those to be allocated with dma_alloc_xxx API. (It is still possible to allocate a dma-buf from any system memory, e.g. system pages). 2. Extension of the gntdev driver to enable it to import/export dma-buf’s. The first six patches are in preparation for Xen dma-buf support, but I consider those usable regardless of the dma-buf use-case, e.g. other frontend/backend kernel modules may also benefit from these for better code reuse: 0001-xen-grant-table-Export-gnttab_-alloc-free-_pages-as-.patch 0002-xen-grant-table-Make-set-clear-page-private-code-sha.patch 0003-xen-balloon-Share-common-memory-reservation-routines.patch 0004-xen-grant-table-Allow-allocating-buffers-suitable-fo.patch 0005-xen-gntdev-Allow-mappings-for-DMA-buffers.patch 0006-xen-gntdev-Make-private-routines-structures-accessib.patch The next three patches are Xen implementation of dma-buf as part of the grant device: 0007-xen-gntdev-Add-initial-support-for-dma-buf-UAPI.patch 0008-xen-gntdev-Implement-dma-buf-export-functionality.patch 0009-xen-gntdev-Implement-dma-buf-import-functionality.patch The corresponding libxengnttab changes are available at [6]. All the above was tested with display backend [7] and its accompanying helper library [8] on Renesas ARM64 based board. Basic balloon tests on x86. *To all the communities*: I would like to ask you to review the proposed solution and give feedback on it, so I can improve and send final patches for review (this is still work in progress, but enough to start discussing the implementation). Thank you in advance, Oleksandr Andrushchenko [1] https://lists.freedesktop.org/archives/dri-devel/2018-April/173163.html [2] https://elixir.bootlin.com/linux/v4.17-rc5/source/Documentation/driver-api/dma-buf.rst [3] https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg01202.html [4] https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/xen [5] https://patchwork.kernel.org/patch/10279681/ [6] https://github.com/andr2000/xen/tree/xen_dma_buf_v1 [7] https://github.com/andr2000/displ_be/tree/xen_dma_buf_v1 [8] https://github.com/andr2000/libxenbe/tree/xen_dma_buf_v1 [9] https://lkml.org/lkml/2018/5/17/215 Changes since v2: * - fixed missed break in dmabuf_exp_wait_obj_signal - re-worked debug and error messages, be less verbose - removed patch for making gntdev functions available to other drivers - removed WARN_ON's in dma-buf code - moved all dma-buf related code into gntdev-dmabuf - introduced gntdev-common.h with common structures and function prototypes - added additional checks for number of grants in IOCTLs - gnttab patch cleanup - made xenmem_reservation_scrub_page defined in the header as inline - fixed __pfn_to_mfn use to pfn_to_bfn - no changes to patches 1-2 Changes
[PATCH v3 1/9] xen/grant-table: Export gnttab_{alloc|free}_pages as GPL
From: Oleksandr Andrushchenko
Only gnttab_{alloc|free}_pages are exported as EXPORT_SYMBOL
while all the rest are exported as EXPORT_SYMBOL_GPL, thus
effectively making it not possible for non-GPL driver modules
to use grant table module. Export gnttab_{alloc|free}_pages as
EXPORT_SYMBOL_GPL so all the exports are aligned.
Signed-off-by: Oleksandr Andrushchenko
Reviewed-by: Juergen Gross
---
drivers/xen/grant-table.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 27be107d6480..ba36ff3e4903 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -799,7 +799,7 @@ int gnttab_alloc_pages(int nr_pages, struct page **pages)
return 0;
}
-EXPORT_SYMBOL(gnttab_alloc_pages);
+EXPORT_SYMBOL_GPL(gnttab_alloc_pages);
/**
* gnttab_free_pages - free pages allocated by gnttab_alloc_pages()
@@ -820,7 +820,7 @@ void gnttab_free_pages(int nr_pages, struct page **pages)
}
free_xenballooned_pages(nr_pages, pages);
}
-EXPORT_SYMBOL(gnttab_free_pages);
+EXPORT_SYMBOL_GPL(gnttab_free_pages);
/* Handling of paged out grant targets (GNTST_eagain) */
#define MAX_DELAY 256
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/9] xen/grant-table: Make set/clear page private code shared
From: Oleksandr Andrushchenko
Make set/clear page private code shared and accessible to
other kernel modules which can re-use these instead of open-coding.
Signed-off-by: Oleksandr Andrushchenko
Reviewed-by: Boris Ostrovsky
---
drivers/xen/grant-table.c | 54 +--
include/xen/grant_table.h | 3 +++
2 files changed, 38 insertions(+), 19 deletions(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index ba36ff3e4903..dbb48a89e987 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -769,29 +769,18 @@ void gnttab_free_auto_xlat_frames(void)
}
EXPORT_SYMBOL_GPL(gnttab_free_auto_xlat_frames);
-/**
- * gnttab_alloc_pages - alloc pages suitable for grant mapping into
- * @nr_pages: number of pages to alloc
- * @pages: returns the pages
- */
-int gnttab_alloc_pages(int nr_pages, struct page **pages)
+int gnttab_pages_set_private(int nr_pages, struct page **pages)
{
int i;
- int ret;
-
- ret = alloc_xenballooned_pages(nr_pages, pages);
- if (ret < 0)
- return ret;
for (i = 0; i < nr_pages; i++) {
#if BITS_PER_LONG < 64
struct xen_page_foreign *foreign;
foreign = kzalloc(sizeof(*foreign), GFP_KERNEL);
- if (!foreign) {
- gnttab_free_pages(nr_pages, pages);
+ if (!foreign)
return -ENOMEM;
- }
+
set_page_private(pages[i], (unsigned long)foreign);
#endif
SetPagePrivate(pages[i]);
@@ -799,14 +788,30 @@ int gnttab_alloc_pages(int nr_pages, struct page **pages)
return 0;
}
-EXPORT_SYMBOL_GPL(gnttab_alloc_pages);
+EXPORT_SYMBOL_GPL(gnttab_pages_set_private);
/**
- * gnttab_free_pages - free pages allocated by gnttab_alloc_pages()
- * @nr_pages; number of pages to free
- * @pages: the pages
+ * gnttab_alloc_pages - alloc pages suitable for grant mapping into
+ * @nr_pages: number of pages to alloc
+ * @pages: returns the pages
*/
-void gnttab_free_pages(int nr_pages, struct page **pages)
+int gnttab_alloc_pages(int nr_pages, struct page **pages)
+{
+ int ret;
+
+ ret = alloc_xenballooned_pages(nr_pages, pages);
+ if (ret < 0)
+ return ret;
+
+ ret = gnttab_pages_set_private(nr_pages, pages);
+ if (ret < 0)
+ gnttab_free_pages(nr_pages, pages);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(gnttab_alloc_pages);
+
+void gnttab_pages_clear_private(int nr_pages, struct page **pages)
{
int i;
@@ -818,6 +823,17 @@ void gnttab_free_pages(int nr_pages, struct page **pages)
ClearPagePrivate(pages[i]);
}
}
+}
+EXPORT_SYMBOL_GPL(gnttab_pages_clear_private);
+
+/**
+ * gnttab_free_pages - free pages allocated by gnttab_alloc_pages()
+ * @nr_pages; number of pages to free
+ * @pages: the pages
+ */
+void gnttab_free_pages(int nr_pages, struct page **pages)
+{
+ gnttab_pages_clear_private(nr_pages, pages);
free_xenballooned_pages(nr_pages, pages);
}
EXPORT_SYMBOL_GPL(gnttab_free_pages);
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 2e37741f6b8d..de03f2542bb7 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -198,6 +198,9 @@ void gnttab_free_auto_xlat_frames(void);
int gnttab_alloc_pages(int nr_pages, struct page **pages);
void gnttab_free_pages(int nr_pages, struct page **pages);
+int gnttab_pages_set_private(int nr_pages, struct page **pages);
+void gnttab_pages_clear_private(int nr_pages, struct page **pages);
+
int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
struct gnttab_map_grant_ref *kmap_ops,
struct page **pages, unsigned int count);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/9] xen/grant-table: Allow allocating buffers suitable for DMA
From: Oleksandr Andrushchenko
Extend grant table module API to allow allocating buffers that can
be used for DMA operations and mapping foreign grant references
on top of those.
The resulting buffer is similar to the one allocated by the balloon
driver in terms that proper memory reservation is made
({increase|decrease}_reservation and VA mappings updated if needed).
This is useful for sharing foreign buffers with HW drivers which
cannot work with scattered buffers provided by the balloon driver,
but require DMAable memory instead.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/Kconfig | 13 ++
drivers/xen/grant-table.c | 97 +++
include/xen/grant_table.h | 18
3 files changed, 128 insertions(+)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index e5d0c28372ea..39536ddfbce4 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -161,6 +161,19 @@ config XEN_GRANT_DEV_ALLOC
to other domains. This can be used to implement frontend drivers
or as part of an inter-domain shared memory channel.
+config XEN_GRANT_DMA_ALLOC
+ bool "Allow allocating DMA capable buffers with grant reference module"
+ depends on XEN && HAS_DMA
+ help
+ Extends grant table module API to allow allocating DMA capable
+ buffers and mapping foreign grant references on top of it.
+ The resulting buffer is similar to one allocated by the balloon
+ driver in terms that proper memory reservation is made
+ ({increase|decrease}_reservation and VA mappings updated if needed).
+ This is useful for sharing foreign buffers with HW drivers which
+ cannot work with scattered buffers provided by the balloon driver,
+ but require DMAable memory instead.
+
config SWIOTLB_XEN
def_bool y
select SWIOTLB
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index dbb48a89e987..26ed498b5e6d 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -45,6 +45,9 @@
#include
#include
#include
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+#include
+#endif
#include
#include
@@ -57,6 +60,7 @@
#ifdef CONFIG_X86
#include
#endif
+#include
#include
#include
@@ -838,6 +842,99 @@ void gnttab_free_pages(int nr_pages, struct page **pages)
}
EXPORT_SYMBOL_GPL(gnttab_free_pages);
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+/**
+ * gnttab_dma_alloc_pages - alloc DMAable pages suitable for grant mapping into
+ * @args: arguments to the function
+ */
+int gnttab_dma_alloc_pages(struct gnttab_dma_alloc_args *args)
+{
+ unsigned long pfn, start_pfn;
+ size_t size;
+ int i, ret;
+
+ size = args->nr_pages << PAGE_SHIFT;
+ if (args->coherent)
+ args->vaddr = dma_alloc_coherent(args->dev, size,
+>dev_bus_addr,
+GFP_KERNEL | __GFP_NOWARN);
+ else
+ args->vaddr = dma_alloc_wc(args->dev, size,
+ >dev_bus_addr,
+ GFP_KERNEL | __GFP_NOWARN);
+ if (!args->vaddr) {
+ pr_debug("Failed to allocate DMA buffer of size %zu\n", size);
+ return -ENOMEM;
+ }
+
+ start_pfn = __phys_to_pfn(args->dev_bus_addr);
+ for (pfn = start_pfn, i = 0; pfn < start_pfn + args->nr_pages;
+ pfn++, i++) {
+ struct page *page = pfn_to_page(pfn);
+
+ args->pages[i] = page;
+ args->frames[i] = xen_page_to_gfn(page);
+ xenmem_reservation_scrub_page(page);
+ }
+
+ xenmem_reservation_va_mapping_reset(args->nr_pages, args->pages);
+
+ ret = xenmem_reservation_decrease(args->nr_pages, args->frames);
+ if (ret != args->nr_pages) {
+ pr_debug("Failed to decrease reservation for DMA buffer\n");
+ ret = -EFAULT;
+ goto fail;
+ }
+
+ ret = gnttab_pages_set_private(args->nr_pages, args->pages);
+ if (ret < 0)
+ goto fail;
+
+ return 0;
+
+fail:
+ gnttab_dma_free_pages(args);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(gnttab_dma_alloc_pages);
+
+/**
+ * gnttab_dma_free_pages - free DMAable pages
+ * @args: arguments to the function
+ */
+int gnttab_dma_free_pages(struct gnttab_dma_alloc_args *args)
+{
+ size_t size;
+ int i, ret;
+
+ gnttab_pages_clear_private(args->nr_pages, args->pages);
+
+ for (i = 0; i < args->nr_pages; i++)
+ args->frames[i] = page_to_xen_pfn(args->pages[i]);
+
+ ret = xenmem_reservation_increase(args->nr_pages, args->frames);
+ if (ret != args->nr_pages) {
+ pr_debug("Failed to decrease reservation for DMA buffer\n");
+ ret = -EFAULT;
+ } else {
+ ret = 0;
+ }
+
+
[PATCH v3 5/9] xen/gntdev: Allow mappings for DMA buffers
From: Oleksandr Andrushchenko
Allow mappings for DMA backed buffers if grant table module
supports such: this extends grant device to not only map buffers
made of balloon pages, but also from buffers allocated with
dma_alloc_xxx.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/gntdev.c | 99 ++-
include/uapi/xen/gntdev.h | 15 ++
2 files changed, 112 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index bd56653b9bbc..d6b79ad1cd6f 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -37,6 +37,9 @@
#include
#include
#include
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+#include
+#endif
#include
#include
@@ -72,6 +75,11 @@ struct gntdev_priv {
struct mutex lock;
struct mm_struct *mm;
struct mmu_notifier mn;
+
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ /* Device for which DMA memory is allocated. */
+ struct device *dma_dev;
+#endif
};
struct unmap_notify {
@@ -96,10 +104,27 @@ struct grant_map {
struct gnttab_unmap_grant_ref *kunmap_ops;
struct page **pages;
unsigned long pages_vm_start;
+
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ /*
+* If dmabuf_vaddr is not NULL then this mapping is backed by DMA
+* capable memory.
+*/
+
+ struct device *dma_dev;
+ /* Flags used to create this DMA buffer: GNTDEV_DMA_FLAG_XXX. */
+ int dma_flags;
+ void *dma_vaddr;
+ dma_addr_t dma_bus_addr;
+ /* Needed to avoid allocation in gnttab_dma_free_pages(). */
+ xen_pfn_t *frames;
+#endif
};
static int unmap_grant_pages(struct grant_map *map, int offset, int pages);
+static struct miscdevice gntdev_miscdev;
+
/* -- */
static void gntdev_print_maps(struct gntdev_priv *priv,
@@ -121,8 +146,27 @@ static void gntdev_free_map(struct grant_map *map)
if (map == NULL)
return;
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ if (map->dma_vaddr) {
+ struct gnttab_dma_alloc_args args;
+
+ args.dev = map->dma_dev;
+ args.coherent = map->dma_flags & GNTDEV_DMA_FLAG_COHERENT;
+ args.nr_pages = map->count;
+ args.pages = map->pages;
+ args.frames = map->frames;
+ args.vaddr = map->dma_vaddr;
+ args.dev_bus_addr = map->dma_bus_addr;
+
+ gnttab_dma_free_pages();
+ } else
+#endif
if (map->pages)
gnttab_free_pages(map->count, map->pages);
+
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ kfree(map->frames);
+#endif
kfree(map->pages);
kfree(map->grants);
kfree(map->map_ops);
@@ -132,7 +176,8 @@ static void gntdev_free_map(struct grant_map *map)
kfree(map);
}
-static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count)
+static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count,
+ int dma_flags)
{
struct grant_map *add;
int i;
@@ -155,6 +200,37 @@ static struct grant_map *gntdev_alloc_map(struct
gntdev_priv *priv, int count)
NULL == add->pages)
goto err;
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ add->dma_flags = dma_flags;
+
+ /*
+* Check if this mapping is requested to be backed
+* by a DMA buffer.
+*/
+ if (dma_flags & (GNTDEV_DMA_FLAG_WC | GNTDEV_DMA_FLAG_COHERENT)) {
+ struct gnttab_dma_alloc_args args;
+
+ add->frames = kcalloc(count, sizeof(add->frames[0]),
+ GFP_KERNEL);
+ if (!add->frames)
+ goto err;
+
+ /* Remember the device, so we can free DMA memory. */
+ add->dma_dev = priv->dma_dev;
+
+ args.dev = priv->dma_dev;
+ args.coherent = dma_flags & GNTDEV_DMA_FLAG_COHERENT;
+ args.nr_pages = count;
+ args.pages = add->pages;
+ args.frames = add->frames;
+
+ if (gnttab_dma_alloc_pages())
+ goto err;
+
+ add->dma_vaddr = args.vaddr;
+ add->dma_bus_addr = args.dev_bus_addr;
+ } else
+#endif
if (gnttab_alloc_pages(count, add->pages))
goto err;
@@ -325,6 +401,14 @@ static int map_grant_pages(struct grant_map *map)
map->unmap_ops[i].handle = map->map_ops[i].handle;
if (use_ptemod)
map->kunmap_ops[i].handle = map->kmap_ops[i].handle;
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ else if (map->dma_vaddr) {
+ unsigned long mfn;
+
+ mfn = pfn_to_bfn(page_to_pfn(map->pages[i]));
+ map->unmap_ops[i].dev_bus_addr = __pfn_to_phys(mfn);
+ }
+#endif
}
[PATCH v3 3/9] xen/balloon: Share common memory reservation routines
From: Oleksandr Andrushchenko
Memory {increase|decrease}_reservation and VA mappings update/reset
code used in balloon driver can be made common, so other drivers can
also re-use the same functionality without open-coding.
Create a dedicated file for the shared code and export corresponding
symbols for other kernel modules.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/Makefile | 1 +
drivers/xen/balloon.c | 71 ++---
drivers/xen/mem-reservation.c | 112 ++
include/xen/mem-reservation.h | 64 +++
4 files changed, 183 insertions(+), 65 deletions(-)
create mode 100644 drivers/xen/mem-reservation.c
create mode 100644 include/xen/mem-reservation.h
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 451e833f5931..3c87b0c3aca6 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o
obj-$(CONFIG_X86) += fallback.o
obj-y += grant-table.o features.o balloon.o manage.o preempt.o time.o
+obj-y += mem-reservation.o
obj-y += events/
obj-y += xenbus/
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 065f0b607373..bdbce4257b65 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -71,6 +71,7 @@
#include
#include
#include
+#include
static int xen_hotplug_unpopulated;
@@ -157,13 +158,6 @@ static DECLARE_DELAYED_WORK(balloon_worker,
balloon_process);
#define GFP_BALLOON \
(GFP_HIGHUSER | __GFP_NOWARN | __GFP_NORETRY | __GFP_NOMEMALLOC)
-static void scrub_page(struct page *page)
-{
-#ifdef CONFIG_XEN_SCRUB_PAGES
- clear_highpage(page);
-#endif
-}
-
/* balloon_append: add the given page to the balloon. */
static void __balloon_append(struct page *page)
{
@@ -463,11 +457,6 @@ static enum bp_state increase_reservation(unsigned long
nr_pages)
int rc;
unsigned long i;
struct page *page;
- struct xen_memory_reservation reservation = {
- .address_bits = 0,
- .extent_order = EXTENT_ORDER,
- .domid= DOMID_SELF
- };
if (nr_pages > ARRAY_SIZE(frame_list))
nr_pages = ARRAY_SIZE(frame_list);
@@ -486,9 +475,7 @@ static enum bp_state increase_reservation(unsigned long
nr_pages)
page = balloon_next_page(page);
}
- set_xen_guest_handle(reservation.extent_start, frame_list);
- reservation.nr_extents = nr_pages;
- rc = HYPERVISOR_memory_op(XENMEM_populate_physmap, );
+ rc = xenmem_reservation_increase(nr_pages, frame_list);
if (rc <= 0)
return BP_EAGAIN;
@@ -496,29 +483,7 @@ static enum bp_state increase_reservation(unsigned long
nr_pages)
page = balloon_retrieve(false);
BUG_ON(page == NULL);
-#ifdef CONFIG_XEN_HAVE_PVMMU
- /*
-* We don't support PV MMU when Linux and Xen is using
-* different page granularity.
-*/
- BUILD_BUG_ON(XEN_PAGE_SIZE != PAGE_SIZE);
-
- if (!xen_feature(XENFEAT_auto_translated_physmap)) {
- unsigned long pfn = page_to_pfn(page);
-
- set_phys_to_machine(pfn, frame_list[i]);
-
- /* Link back into the page tables if not highmem. */
- if (!PageHighMem(page)) {
- int ret;
- ret = HYPERVISOR_update_va_mapping(
- (unsigned long)__va(pfn <<
PAGE_SHIFT),
- mfn_pte(frame_list[i],
PAGE_KERNEL),
- 0);
- BUG_ON(ret);
- }
- }
-#endif
+ xenmem_reservation_va_mapping_update(1, , _list[i]);
/* Relinquish the page back to the allocator. */
free_reserved_page(page);
@@ -535,11 +500,6 @@ static enum bp_state decrease_reservation(unsigned long
nr_pages, gfp_t gfp)
unsigned long i;
struct page *page, *tmp;
int ret;
- struct xen_memory_reservation reservation = {
- .address_bits = 0,
- .extent_order = EXTENT_ORDER,
- .domid= DOMID_SELF
- };
LIST_HEAD(pages);
if (nr_pages > ARRAY_SIZE(frame_list))
@@ -553,7 +513,7 @@ static enum bp_state decrease_reservation(unsigned long
nr_pages, gfp_t gfp)
break;
}
adjust_managed_page_count(page, -1);
- scrub_page(page);
+ xenmem_reservation_scrub_page(page);
list_add(>lru, );
}
@@ -575,25 +535,8 @@ static enum bp_state decrease_reservation(unsigned long
nr_pages, gfp_t gfp)
/*
[PATCH v4 2/2] drm/rockchip: vop: fix irq disabled after vop driver probed
From: Sandy Huang
The vop irq is shared between vop and iommu and irq probing in the
iommu driver moved to the probe function recently. This can in some
cases lead to a stall if the irq is triggered while the vop driver
still has it disabled, but the vop irq handler gets called.
But there is no real need to disable the irq, as the vop can simply
also track its enabled state and ignore irqs in that case.
For this we can simply check the power-domain state of the vop,
similar to how the iommu driver does it.
So remove the enable/disable handling and add appropriate condition
to the irq handler.
changes in v2:
- move to just check the power-domain state
- add clock handling
changes in v3:
- clarify comment to speak of runtime-pm not power-domain
changes in v4:
- address Marc's comments (clk-enable WARN_ON and style improvement)
Fixes: d0b912bd4c23 ("iommu/rockchip: Request irqs in rk_iommu_probe()")
Cc: sta...@vger.kernel.org
Signed-off-by: Sandy Huang
Signed-off-by: Heiko Stuebner
Tested-by: Ezequiel Garcia
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 25 ++---
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 9a1f272e41c7..d105e984cf09 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -573,8 +573,6 @@ static int vop_enable(struct drm_crtc *crtc)
spin_unlock(>reg_lock);
- enable_irq(vop->irq);
-
drm_crtc_vblank_on(crtc);
return 0;
@@ -618,8 +616,6 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
vop_dsp_hold_valid_irq_disable(vop);
- disable_irq(vop->irq);
-
vop->is_enabled = false;
/*
@@ -1195,6 +1191,18 @@ static irqreturn_t vop_isr(int irq, void *data)
uint32_t active_irqs;
int ret = IRQ_NONE;
+ /*
+* The irq is shared with the iommu. If the runtime-pm state of the
+* vop-device is disabled the irq has to be targetted at the iommu.
+*/
+ if (!pm_runtime_get_if_in_use(vop->dev))
+ return IRQ_NONE;
+
+ if (vop_core_clks_enable(vop)) {
+ DRM_DEV_ERROR_RATELIMITED(vop->dev, "couldn't enable clocks\n");
+ goto out;
+ }
+
/*
* interrupt register has interrupt status, enable and clear bits, we
* must hold irq_lock to avoid a race with enable/disable_vblank().
@@ -1210,7 +1218,7 @@ static irqreturn_t vop_isr(int irq, void *data)
/* This is expected for vop iommu irqs, since the irq is shared */
if (!active_irqs)
- return IRQ_NONE;
+ goto out_disable;
if (active_irqs & DSP_HOLD_VALID_INTR) {
complete(>dsp_hold_completion);
@@ -1236,6 +1244,10 @@ static irqreturn_t vop_isr(int irq, void *data)
DRM_DEV_ERROR(vop->dev, "Unknown VOP IRQs: %#02x\n",
active_irqs);
+out_disable:
+ vop_core_clks_disable(vop);
+out:
+ pm_runtime_put(vop->dev);
return ret;
}
@@ -1614,9 +1626,6 @@ static int vop_bind(struct device *dev, struct device
*master, void *data)
if (ret)
goto err_disable_pm_runtime;
- /* IRQ is initially disabled; it gets enabled in power_on */
- disable_irq(vop->irq);
-
return 0;
err_disable_pm_runtime:
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/2] drm/rockchip: try to fix vblank hang resulting from iommu irq change
This still tries to address the hang seen by Ezequiel Garcia on rk3288. As Tomasz noted, trying to count enablement can run into concurrency issues, so instead we'll just check if the vop is runtime-enabled to see if it could be the source of the irq and then just do our own clk_enable in the isr to bridge the possible gap between pm_runtime_enable and clk_enable in the core vop_enable() function. Display tested to still work on rk3328 and rk3399, but as I don't see the hang from Ezequiel I hope that this fixes it. changes in v2: - adapt approach ... don't try to count usage ourself, because of possible concurrency issues with vop enable/disable changes in v3: - fix comment in patch2 - add stable+fixes tags changes in v4: - address Marc's comments to patch2 Heiko Stuebner (1): drm/rockchip: vop: split out core clock enablement into separate functions Sandy Huang (1): drm/rockchip: vop: fix irq disabled after vop driver probed drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 69 ++--- 1 file changed, 48 insertions(+), 21 deletions(-) -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/2] drm/rockchip: vop: split out core clock enablement into separate functions
Judging from the iommu code, both the hclk and aclk are necessary for
register access. Split them off into separate functions from the regular
vop enablement, so that we can use them elsewhere as well.
Fixes: d0b912bd4c23 ("iommu/rockchip: Request irqs in rk_iommu_probe()")
Cc: sta...@vger.kernel.org
Signed-off-by: Heiko Stuebner
Tested-by: Ezequiel Garcia
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 44 +++--
1 file changed, 31 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 2121345a61af..9a1f272e41c7 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -486,6 +486,31 @@ static void vop_line_flag_irq_disable(struct vop *vop)
spin_unlock_irqrestore(>irq_lock, flags);
}
+static int vop_core_clks_enable(struct vop *vop)
+{
+ int ret;
+
+ ret = clk_enable(vop->hclk);
+ if (ret < 0)
+ return ret;
+
+ ret = clk_enable(vop->aclk);
+ if (ret < 0)
+ goto err_disable_hclk;
+
+ return 0;
+
+err_disable_hclk:
+ clk_disable(vop->hclk);
+ return ret;
+}
+
+static void vop_core_clks_disable(struct vop *vop)
+{
+ clk_disable(vop->aclk);
+ clk_disable(vop->hclk);
+}
+
static int vop_enable(struct drm_crtc *crtc)
{
struct vop *vop = to_vop(crtc);
@@ -497,17 +522,13 @@ static int vop_enable(struct drm_crtc *crtc)
return ret;
}
- ret = clk_enable(vop->hclk);
+ ret = vop_core_clks_enable(vop);
if (WARN_ON(ret < 0))
goto err_put_pm_runtime;
ret = clk_enable(vop->dclk);
if (WARN_ON(ret < 0))
- goto err_disable_hclk;
-
- ret = clk_enable(vop->aclk);
- if (WARN_ON(ret < 0))
- goto err_disable_dclk;
+ goto err_disable_core;
/*
* Slave iommu shares power, irq and clock with vop. It was associated
@@ -519,7 +540,7 @@ static int vop_enable(struct drm_crtc *crtc)
if (ret) {
DRM_DEV_ERROR(vop->dev,
"failed to attach dma mapping, %d\n", ret);
- goto err_disable_aclk;
+ goto err_disable_dclk;
}
spin_lock(>reg_lock);
@@ -558,12 +579,10 @@ static int vop_enable(struct drm_crtc *crtc)
return 0;
-err_disable_aclk:
- clk_disable(vop->aclk);
err_disable_dclk:
clk_disable(vop->dclk);
-err_disable_hclk:
- clk_disable(vop->hclk);
+err_disable_core:
+ vop_core_clks_disable(vop);
err_put_pm_runtime:
pm_runtime_put_sync(vop->dev);
return ret;
@@ -609,8 +628,7 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
rockchip_drm_dma_detach_device(vop->drm_dev, vop->dev);
clk_disable(vop->dclk);
- clk_disable(vop->aclk);
- clk_disable(vop->hclk);
+ vop_core_clks_disable(vop);
pm_runtime_put(vop->dev);
mutex_unlock(>vop_lock);
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/2] drm/rockchip: vop: fix irq disabled after vop driver probed
Am Dienstag, 12. Juni 2018, 14:39:03 CEST schrieb Marc Zyngier:
> Hi Heiko,
>
> On 12/06/18 13:15, Heiko Stuebner wrote:
> > From: Sandy Huang
> >
> > The vop irq is shared between vop and iommu and irq probing in the
> > iommu driver moved to the probe function recently. This can in some
> > cases lead to a stall if the irq is triggered while the vop driver
> > still has it disabled, but the vop irq handler gets called.
> >
> > But there is no real need to disable the irq, as the vop can simply
> > also track its enabled state and ignore irqs in that case.
> > For this we can simply check the power-domain state of the vop,
> > similar to how the iommu driver does it.
> >
> > So remove the enable/disable handling and add appropriate condition
> > to the irq handler.
> >
> > changes in v2:
> > - move to just check the power-domain state
> > - add clock handling
> > changes in v3:
> > - clarify comment to speak of runtime-pm not power-domain
> >
> > Fixes: d0b912bd4c23 ("iommu/rockchip: Request irqs in rk_iommu_probe()")
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Sandy Huang
> > Signed-off-by: Heiko Stuebner
> > Tested-by: Ezequiel Garcia
> > ---
> > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 28 ++---
> > 1 file changed, 19 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > index 9a1f272e41c7..ae8a69793aed 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > @@ -573,8 +573,6 @@ static int vop_enable(struct drm_crtc *crtc)
> >
> > spin_unlock(>reg_lock);
> >
> > - enable_irq(vop->irq);
> > -
> > drm_crtc_vblank_on(crtc);
> >
> > return 0;
> > @@ -618,8 +616,6 @@ static void vop_crtc_atomic_disable(struct drm_crtc
> > *crtc,
> >
> > vop_dsp_hold_valid_irq_disable(vop);
> >
> > - disable_irq(vop->irq);
> > -
> > vop->is_enabled = false;
> >
> > /*
> > @@ -1195,6 +1191,16 @@ static irqreturn_t vop_isr(int irq, void *data)
> > uint32_t active_irqs;
> > int ret = IRQ_NONE;
> >
> > + /*
> > +* The irq is shared with the iommu. If the runtime-pm state of the
> > +* vop-device is disabled the irq has to be targetted at the iommu.
> > +*/
> > + if (!pm_runtime_get_if_in_use(vop->dev))
> > + return IRQ_NONE;
> > +
> > + if (WARN_ON(vop_core_clks_enable(vop)))
> > + goto out;
>
> As I mentioned before, a WARN_ON() in an interrupt handler is a good way
> to make a bad problem even worse, and will give information (full
> register and stack dump) that is mostly useless to the context at hand.
> Turning it to a dev_warn_ratelimited() (or DRM_ERROR_RATELIMITED if you
> want to be DRM compliant) would be a better approach, IMHO.
Gah, sorry that I forgot to address your comment from v2 and thanks
for the reminder.
> > +
> > /*
> > * interrupt register has interrupt status, enable and clear bits, we
> > * must hold irq_lock to avoid a race with enable/disable_vblank().
> > @@ -1209,8 +1215,11 @@ static irqreturn_t vop_isr(int irq, void *data)
> > spin_unlock(>irq_lock);
> >
> > /* This is expected for vop iommu irqs, since the irq is shared */
> > - if (!active_irqs)
> > - return IRQ_NONE;
> > + if (!active_irqs) {
> > + ret = IRQ_NONE;
> > + vop_core_clks_disable(vop);
> > + goto out;
> > + }
>
> A couple of nits: ret is already set to IRQ_NONE at this stage, and you
> could simply rewrite it as:
>
> if (!active_irq)
> goto out_disable;
That's only one nit :-P ... but will change the patch accordingly.
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/2] drm/rockchip: vop: fix irq disabled after vop driver probed
Hi Heiko,
On 06/12/2018 08:15 PM, Heiko Stuebner wrote:
From: Sandy Huang
The vop irq is shared between vop and iommu and irq probing in the
iommu driver moved to the probe function recently. This can in some
cases lead to a stall if the irq is triggered while the vop driver
still has it disabled, but the vop irq handler gets called.
hmmm, i think this patch actually fixes another stall case by removing
the unpaired disable_irq() in vop_bind().
if we do disable_irq() in vop_bind() without enable it again in
vop_unbind(), the irq_shutdown() called after vop_unbind()(when
releasing devres) will confuse the irq depth, so the irq will stay
disabled and could never be enabled again.
But there is no real need to disable the irq, as the vop can simply
also track its enabled state and ignore irqs in that case.
For this we can simply check the power-domain state of the vop,
similar to how the iommu driver does it.
So remove the enable/disable handling and add appropriate condition
to the irq handler.
changes in v2:
- move to just check the power-domain state
- add clock handling
changes in v3:
- clarify comment to speak of runtime-pm not power-domain
Fixes: d0b912bd4c23 ("iommu/rockchip: Request irqs in rk_iommu_probe()")
Cc: sta...@vger.kernel.org
Signed-off-by: Sandy Huang
Signed-off-by: Heiko Stuebner
Tested-by: Ezequiel Garcia
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 28 ++---
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 9a1f272e41c7..ae8a69793aed 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -573,8 +573,6 @@ static int vop_enable(struct drm_crtc *crtc)
spin_unlock(>reg_lock);
- enable_irq(vop->irq);
-
drm_crtc_vblank_on(crtc);
return 0;
@@ -618,8 +616,6 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
vop_dsp_hold_valid_irq_disable(vop);
- disable_irq(vop->irq);
-
vop->is_enabled = false;
/*
@@ -1195,6 +1191,16 @@ static irqreturn_t vop_isr(int irq, void *data)
uint32_t active_irqs;
int ret = IRQ_NONE;
+ /*
+* The irq is shared with the iommu. If the runtime-pm state of the
+* vop-device is disabled the irq has to be targetted at the iommu.
+*/
+ if (!pm_runtime_get_if_in_use(vop->dev))
+ return IRQ_NONE;
+
+ if (WARN_ON(vop_core_clks_enable(vop)))
+ goto out;
+
/*
* interrupt register has interrupt status, enable and clear bits, we
* must hold irq_lock to avoid a race with enable/disable_vblank().
@@ -1209,8 +1215,11 @@ static irqreturn_t vop_isr(int irq, void *data)
spin_unlock(>irq_lock);
/* This is expected for vop iommu irqs, since the irq is shared */
- if (!active_irqs)
- return IRQ_NONE;
+ if (!active_irqs) {
+ ret = IRQ_NONE;
+ vop_core_clks_disable(vop);
+ goto out;
+ }
if (active_irqs & DSP_HOLD_VALID_INTR) {
complete(>dsp_hold_completion);
@@ -1236,6 +1245,10 @@ static irqreturn_t vop_isr(int irq, void *data)
DRM_DEV_ERROR(vop->dev, "Unknown VOP IRQs: %#02x\n",
active_irqs);
+ vop_core_clks_disable(vop);
+
+out:
+ pm_runtime_put(vop->dev);
return ret;
}
@@ -1614,9 +1627,6 @@ static int vop_bind(struct device *dev, struct device
*master, void *data)
if (ret)
goto err_disable_pm_runtime;
- /* IRQ is initially disabled; it gets enabled in power_on */
- disable_irq(vop->irq);
-
return 0;
err_disable_pm_runtime:
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/23] omapdrm: Rework the timing-related operations
Hi, On Fri, Jun 08, 2018 at 07:29:03PM +0300, Laurent Pinchart wrote: > Hello, > > This patch series reworks all the timing-related operations (.get_timings(), > .set_timings() and .check_timings()) as a step toward moving from > omap_dss_device to drm_bridge. > > All timing-related operations are called by the omapdrm driver on the > omap_dss_device at the end of display pipeline, and the operations are then > handled directly or forwarded to the previous omap_dss_device in the pipeline. > This causes an issue in our quest to move to drm_bridge: the drm_bridge > equivalent to the timing operations, .mode_valid(), .mode_fixup() and > .mode_set(), are called in the source to sink direction. > > Furthermore, timing handling in the omapdrm driver is very complicated, with > timings getting mangled, stored in random places, retrieved back by unrelated > code, mangled again, stored in different places, and modified across objects. > Simplifying that is crucial to move to drm_bridge. > > This patch series simplifies the timings operation and reverse the direction > in which they're called. The driver still uses the videomode structure instead > of the drm_display_mode structure to store timing information, this will be > fixed in a second step. > > The series is really a succession of cleanups interleaved with the real > changes, with a total of 406 lines of code removed overall. It starts with > small changes, cleanups and code removal in patches 01/23 to 07/23, and then > introduces new DRM bus flags to specify sync signal clock edges using the DRM > bus_flags mechanism in patch 08/23. This is the only extension to the DRM > core. > > Patches 09/23 and 10/23 start reworking the .check_timings() operation by > making use of the bus flags. Patches 11/23 to 13/23 rework the .get_timings() > operation, and patches 14/23 to 21/23 complete the .check_timings() rework. > Patches 22/23 and 23/23 finally rework the .set_timings() operation. The patchset is Reviewed-by: Sebastian Reichel -- Sebastian signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/2] drm/rockchip: vop: split out core clock enablement into separate functions
Judging from the iommu code, both the hclk and aclk are necessary for
register access. Split them off into separate functions from the regular
vop enablement, so that we can use them elsewhere as well.
Fixes: d0b912bd4c23 ("iommu/rockchip: Request irqs in rk_iommu_probe()")
Cc: sta...@vger.kernel.org
Signed-off-by: Heiko Stuebner
Tested-by: Ezequiel Garcia
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 44 +++--
1 file changed, 31 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 2121345a61af..9a1f272e41c7 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -486,6 +486,31 @@ static void vop_line_flag_irq_disable(struct vop *vop)
spin_unlock_irqrestore(>irq_lock, flags);
}
+static int vop_core_clks_enable(struct vop *vop)
+{
+ int ret;
+
+ ret = clk_enable(vop->hclk);
+ if (ret < 0)
+ return ret;
+
+ ret = clk_enable(vop->aclk);
+ if (ret < 0)
+ goto err_disable_hclk;
+
+ return 0;
+
+err_disable_hclk:
+ clk_disable(vop->hclk);
+ return ret;
+}
+
+static void vop_core_clks_disable(struct vop *vop)
+{
+ clk_disable(vop->aclk);
+ clk_disable(vop->hclk);
+}
+
static int vop_enable(struct drm_crtc *crtc)
{
struct vop *vop = to_vop(crtc);
@@ -497,17 +522,13 @@ static int vop_enable(struct drm_crtc *crtc)
return ret;
}
- ret = clk_enable(vop->hclk);
+ ret = vop_core_clks_enable(vop);
if (WARN_ON(ret < 0))
goto err_put_pm_runtime;
ret = clk_enable(vop->dclk);
if (WARN_ON(ret < 0))
- goto err_disable_hclk;
-
- ret = clk_enable(vop->aclk);
- if (WARN_ON(ret < 0))
- goto err_disable_dclk;
+ goto err_disable_core;
/*
* Slave iommu shares power, irq and clock with vop. It was associated
@@ -519,7 +540,7 @@ static int vop_enable(struct drm_crtc *crtc)
if (ret) {
DRM_DEV_ERROR(vop->dev,
"failed to attach dma mapping, %d\n", ret);
- goto err_disable_aclk;
+ goto err_disable_dclk;
}
spin_lock(>reg_lock);
@@ -558,12 +579,10 @@ static int vop_enable(struct drm_crtc *crtc)
return 0;
-err_disable_aclk:
- clk_disable(vop->aclk);
err_disable_dclk:
clk_disable(vop->dclk);
-err_disable_hclk:
- clk_disable(vop->hclk);
+err_disable_core:
+ vop_core_clks_disable(vop);
err_put_pm_runtime:
pm_runtime_put_sync(vop->dev);
return ret;
@@ -609,8 +628,7 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
rockchip_drm_dma_detach_device(vop->drm_dev, vop->dev);
clk_disable(vop->dclk);
- clk_disable(vop->aclk);
- clk_disable(vop->hclk);
+ vop_core_clks_disable(vop);
pm_runtime_put(vop->dev);
mutex_unlock(>vop_lock);
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] drm/rockchip: vop: fix irq disabled after vop driver probed
From: Sandy Huang
The vop irq is shared between vop and iommu and irq probing in the
iommu driver moved to the probe function recently. This can in some
cases lead to a stall if the irq is triggered while the vop driver
still has it disabled, but the vop irq handler gets called.
But there is no real need to disable the irq, as the vop can simply
also track its enabled state and ignore irqs in that case.
For this we can simply check the power-domain state of the vop,
similar to how the iommu driver does it.
So remove the enable/disable handling and add appropriate condition
to the irq handler.
changes in v2:
- move to just check the power-domain state
- add clock handling
changes in v3:
- clarify comment to speak of runtime-pm not power-domain
Fixes: d0b912bd4c23 ("iommu/rockchip: Request irqs in rk_iommu_probe()")
Cc: sta...@vger.kernel.org
Signed-off-by: Sandy Huang
Signed-off-by: Heiko Stuebner
Tested-by: Ezequiel Garcia
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 28 ++---
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 9a1f272e41c7..ae8a69793aed 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -573,8 +573,6 @@ static int vop_enable(struct drm_crtc *crtc)
spin_unlock(>reg_lock);
- enable_irq(vop->irq);
-
drm_crtc_vblank_on(crtc);
return 0;
@@ -618,8 +616,6 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
vop_dsp_hold_valid_irq_disable(vop);
- disable_irq(vop->irq);
-
vop->is_enabled = false;
/*
@@ -1195,6 +1191,16 @@ static irqreturn_t vop_isr(int irq, void *data)
uint32_t active_irqs;
int ret = IRQ_NONE;
+ /*
+* The irq is shared with the iommu. If the runtime-pm state of the
+* vop-device is disabled the irq has to be targetted at the iommu.
+*/
+ if (!pm_runtime_get_if_in_use(vop->dev))
+ return IRQ_NONE;
+
+ if (WARN_ON(vop_core_clks_enable(vop)))
+ goto out;
+
/*
* interrupt register has interrupt status, enable and clear bits, we
* must hold irq_lock to avoid a race with enable/disable_vblank().
@@ -1209,8 +1215,11 @@ static irqreturn_t vop_isr(int irq, void *data)
spin_unlock(>irq_lock);
/* This is expected for vop iommu irqs, since the irq is shared */
- if (!active_irqs)
- return IRQ_NONE;
+ if (!active_irqs) {
+ ret = IRQ_NONE;
+ vop_core_clks_disable(vop);
+ goto out;
+ }
if (active_irqs & DSP_HOLD_VALID_INTR) {
complete(>dsp_hold_completion);
@@ -1236,6 +1245,10 @@ static irqreturn_t vop_isr(int irq, void *data)
DRM_DEV_ERROR(vop->dev, "Unknown VOP IRQs: %#02x\n",
active_irqs);
+ vop_core_clks_disable(vop);
+
+out:
+ pm_runtime_put(vop->dev);
return ret;
}
@@ -1614,9 +1627,6 @@ static int vop_bind(struct device *dev, struct device
*master, void *data)
if (ret)
goto err_disable_pm_runtime;
- /* IRQ is initially disabled; it gets enabled in power_on */
- disable_irq(vop->irq);
-
return 0;
err_disable_pm_runtime:
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/2] drm/rockchip: try to fix vblank hang resulting from iommu irq change
This still tries to address the hang seen by Ezequiel Garcia on rk3288. As Tomasz noted, trying to count enablement can run into concurrency issues, so instead we'll just check if the vop is runtime-enabled to see if it could be the source of the irq and then just do our own clk_enable in the isr to bridge the possible gap between pm_runtime_enable and clk_enable in the core vop_enable() function. Display tested to still work on rk3328 and rk3399, but as I don't see the hang from Ezequiel I hope that this fixes it. changes in v2: - adapt approach ... don't try to count usage ourself, because of possible concurrency issues with vop enable/disable changes in v3: - fix comment in patch2 - add stable+fixes tags Heiko Stuebner (1): drm/rockchip: vop: split out core clock enablement into separate functions Sandy Huang (1): drm/rockchip: vop: fix irq disabled after vop driver probed drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 72 ++--- 1 file changed, 50 insertions(+), 22 deletions(-) -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH][V3] drm/i915/guc: fix GEM_BUG_ON check
On Tue, 12 Jun 2018 11:38:04 +0200, Colin King
wrote:
From: Colin Ian King
The check for level being less than zero always false because flags
is currently unsigned and can never be negative. Fix this by making
level a s32.
Detected by CoverityScan, CID#1468363 ("Macro compares unsigned to 0")
Fixes: cb5d64e9f13e ("drm/i915/guc: Allow user to control default GuC
logging")
Signed-off-by: Colin Ian King
---
V3: Make level s32 and add the missing Fixes: tag, thanks to Dan
Carpenter and
Jani Nikula for correcting my mistakes
---
drivers/gpu/drm/i915/intel_guc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.c
b/drivers/gpu/drm/i915/intel_guc.c
index 116f4ccf1bbd..bdb1fab322bf 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -205,7 +205,7 @@ void intel_guc_fini(struct intel_guc *guc)
static u32 get_log_control_flags(void)
{
- u32 level = i915_modparams.guc_log_level;
+ s32 level = i915_modparams.guc_log_level;
s/s32 level/int level
to match modparam type as already suggested by others
u32 flags = 0;
GEM_BUG_ON(level < 0);
please note that this BUG_ON will go away with pending [1] so maybe
we can just merge series [2] instead ?
Thanks,
Michal
[1] https://patchwork.freedesktop.org/patch/227365/
[2] https://patchwork.freedesktop.org/series/44201/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106892] GPU hang with radeon glx driver
https://bugs.freedesktop.org/show_bug.cgi?id=106892 --- Comment #2 from Simon --- Ok also crashed at 60Hz now, so seems that didn't fix it after all. But seems to crash less often at 60Hz and also I didn't get a crash yet at 1024x768@60Hz.. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv6 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
From: Hans Verkuil This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX feature. This patch series is based on the current media master branch (https://git.linuxtv.org/media_tree.git/log/) but it applies fine on top of the current mainline tree. This patch series has been tested with my NUC7i5BNK, a Google USB-C to HDMI adapter and a Club 3D DisplayPort MST Hub + modified UpTab DP-to-HDMI adapter (where the CEC pin is wired up). The latter is to check that replacing a USB-C to HDMI adapter by a USB-C MST Hub works correctly. CEC for MST is currently not supported. Please note this comment at the start of drm_dp_cec.c: -- Unfortunately it turns out that we have a chicken-and-egg situation here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters have a converter chip that supports CEC-Tunneling-over-AUX (usually the Parade PS176), but they do not wire up the CEC pin, thus making CEC useless. Sadly there is no way for this driver to know this. What happens is that a /dev/cecX device is created that is isolated and unable to see any of the other CEC devices. Quite literally the CEC wire is cut (or in this case, never connected in the first place). The reason so few adapters support this is that this tunneling protocol was never supported by any OS. So there was no easy way of testing it, and no incentive to correctly wire up the CEC pin. Hopefully by creating this driver it will be easier for vendors to finally fix their adapters and test the CEC functionality. I keep a list of known working adapters here: https://hverkuil.home.xs4all.nl/cec-status.txt Please mail me (hverk...@xs4all.nl) if you find an adapter that works and is not yet listed there. Note that the current implementation does not support CEC over an MST hub. As far as I can see there is no mechanism defined in the DisplayPort standard to transport CEC interrupts over an MST device. It might be possible to do this through polling, but I have not been able to get that to work. -- I really hope that this work will provide an incentive for vendors to finally connect the CEC pin. It's a shame that there are so few adapters that work (I found only three USB-C to HDMI adapters that work, and no (mini-)DP to HDMI adapters at all). It is a very nice feature for HTPC boxes. Apologies for the long delay between v5 and this v6: too many other projects needed my attention. The main change since v5 is that the CEC adapter is now unregistered after a user-defined time (by default 1 second) if the EDID is unset. If the EDID comes back within that time, then the existing CEC adapter is used as this is assumed to be a HPD off-and-on toggle from the display. The delay can also be set to 0 through a module option. In that case the CEC adapter will never be unregistered as long as the connector remains registered (or if a new HDMI adapter was connected with different capabilities from the previous adapter). Note that I removed the Tested-by tag from Carlos Santa due to the substantial rework of the code. Carlos, can you test this again? Regards, Hans Changes since v5: - Moved the logic of when to unregister a CEC adapter to the drm core code, since this is independent of the actual driver implementation. - Simplified the calls the driver needs to make: the core code is informed when a connector is (un)registered, when the EDID is unset or set and when a DP short pulse is seen and you need to check if that is for a CEC interrupt. - Added the drm_dp_cec_unregister_delay module option to set the delay between unsetting the EDID and unregistering the CEC adapter. Changes since v4: - Updated comment at the start of drm_dp_cec.c - Add edid pointer to drm_dp_cec_configure_adapter - Reworked the last patch (adding CEC to i915) based on Ville's comments and my MST testing: - register/unregister CEC in intel_dp_connector_register/unregister - add comment and check if connector is registered in long_pulse - unregister CEC if an MST 'connector' is detected. Hans Verkuil (3): drm: add support for DisplayPort CEC-Tunneling-over-AUX drm-kms-helpers.rst: document the DP CEC helpers drm/i915: add DisplayPort CEC-Tunneling-over-AUX support Documentation/gpu/drm-kms-helpers.rst | 9 + drivers/gpu/drm/Kconfig | 10 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_dp_cec.c | 423 ++ drivers/gpu/drm/drm_dp_helper.c | 1 + drivers/gpu/drm/i915/intel_dp.c | 17 +- include/drm/drm_dp_helper.h | 56 7 files changed, 515 insertions(+), 2 deletions(-) create mode 100644 drivers/gpu/drm/drm_dp_cec.c -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org
[PATCHv6 1/3] drm: add support for DisplayPort CEC-Tunneling-over-AUX
From: Hans Verkuil This adds support for the DisplayPort CEC-Tunneling-over-AUX feature that is part of the DisplayPort 1.3 standard. Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a chip that has this capability actually hook up the CEC pin, so even though a CEC device is created, it may not actually work. Signed-off-by: Hans Verkuil --- drivers/gpu/drm/Kconfig | 10 + drivers/gpu/drm/Makefile| 1 + drivers/gpu/drm/drm_dp_cec.c| 423 drivers/gpu/drm/drm_dp_helper.c | 1 + include/drm/drm_dp_helper.h | 56 + 5 files changed, 491 insertions(+) create mode 100644 drivers/gpu/drm/drm_dp_cec.c diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index deeefa7a1773..d63876425cdc 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -121,6 +121,16 @@ config DRM_LOAD_EDID_FIRMWARE default case is N. Details and instructions how to build your own EDID data are given in Documentation/EDID/HOWTO.txt. +config DRM_DP_CEC + bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support" + select CEC_CORE + help + Choose this option if you want to enable HDMI CEC support for + DisplayPort/USB-C to HDMI adapters. + + Note: not all adapters support this feature, and even for those + that do support this they often do not hook up the CEC pin. + config DRM_TTM tristate depends on DRM && MMU diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 50093ff4479b..c787481c2502 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -41,6 +41,7 @@ drm_kms_helper-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o +drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o obj-$(CONFIG_DRM_DEBUG_MM_SELFTEST) += selftests/ diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c new file mode 100644 index ..555a9fca3fef --- /dev/null +++ b/drivers/gpu/drm/drm_dp_cec.c @@ -0,0 +1,423 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * DisplayPort CEC-Tunneling-over-AUX support + * + * Copyright 2018 Cisco Systems, Inc. and/or its affiliates. All rights reserved. + */ + +#include +#include +#include +#include +#include + +/* + * Unfortunately it turns out that we have a chicken-and-egg situation + * here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters + * have a converter chip that supports CEC-Tunneling-over-AUX (usually the + * Parade PS176), but they do not wire up the CEC pin, thus making CEC + * useless. + * + * Sadly there is no way for this driver to know this. What happens is + * that a /dev/cecX device is created that is isolated and unable to see + * any of the other CEC devices. Quite literally the CEC wire is cut + * (or in this case, never connected in the first place). + * + * The reason so few adapters support this is that this tunneling protocol + * was never supported by any OS. So there was no easy way of testing it, + * and no incentive to correctly wire up the CEC pin. + * + * Hopefully by creating this driver it will be easier for vendors to + * finally fix their adapters and test the CEC functionality. + * + * I keep a list of known working adapters here: + * + * https://hverkuil.home.xs4all.nl/cec-status.txt + * + * Please mail me (hverk...@xs4all.nl) if you find an adapter that works + * and is not yet listed there. + * + * Note that the current implementation does not support CEC over an MST hub. + * As far as I can see there is no mechanism defined in the DisplayPort + * standard to transport CEC interrupts over an MST device. It might be + * possible to do this through polling, but I have not been able to get that + * to work. + */ + +/** + * DOC: dp cec helpers + * + * These functions take care of supporting the CEC-Tunneling-over-AUX + * feature of DisplayPort-to-HDMI adapters. + */ + +/* + * When the EDID is unset because the HPD went low, then the CEC DPCD registers + * typically can no longer be read (true for a DP-to-HDMI adapter since it is + * powered by the HPD). However, some displays toggle the HPD off and on for a + * short period for one reason or another, and that would cause the CEC adapter + * to be removed and added again, even though nothing else changed. + * + * This module parameter sets a delay in seconds before the CEC adapter is + * actually unregistered. Only if the HPD does not return within that time will + * the CEC adapter be unregistered. + * + * If it is set to 0, then the CEC adapter will never be unregistered for as + * long as the connector remains registered. + * + * Note that for integrated HDMI branch devices that support CEC the DPCD + * registers remain
[PATCHv6 2/3] drm-kms-helpers.rst: document the DP CEC helpers
From: Hans Verkuil Document the Display Port CEC helper functions. Signed-off-by: Hans Verkuil --- Documentation/gpu/drm-kms-helpers.rst | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index e37557b30f62..62de583e9efe 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -169,6 +169,15 @@ Display Port Helper Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_dp_helper.c :export: +Display Port CEC Helper Functions Reference +=== + +.. kernel-doc:: drivers/gpu/drm/drm_dp_cec.c + :doc: dp cec helpers + +.. kernel-doc:: drivers/gpu/drm/drm_dp_cec.c + :export: + Display Port Dual Mode Adaptor Helper Functions Reference = -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv6 3/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
From: Hans Verkuil
Implement support for this DisplayPort feature.
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/i915/intel_dp.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9a4a51e79fa1..f176af2c0bd6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4471,6 +4471,9 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
}
+ /* Handle CEC interrupts, if any */
+ drm_dp_cec_irq(_dp->aux);
+
/* defer to the hotplug work for link retraining if needed */
if (intel_dp_needs_link_retrain(intel_dp))
return false;
@@ -4785,6 +4788,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
intel_connector->detect_edid = edid;
intel_dp->has_audio = drm_detect_monitor_audio(edid);
+ drm_dp_cec_set_edid(_dp->aux, edid);
}
static void
@@ -4792,6 +4796,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
{
struct intel_connector *intel_connector = intel_dp->attached_connector;
+ drm_dp_cec_unset_edid(_dp->aux);
kfree(intel_connector->detect_edid);
intel_connector->detect_edid = NULL;
@@ -4980,6 +4985,7 @@ static int
intel_dp_connector_register(struct drm_connector *connector)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
+ struct drm_device *dev = connector->dev;
int ret;
ret = intel_connector_register(connector);
@@ -4992,13 +4998,20 @@ intel_dp_connector_register(struct drm_connector
*connector)
intel_dp->aux.name, connector->kdev->kobj.name);
intel_dp->aux.dev = connector->kdev;
- return drm_dp_aux_register(_dp->aux);
+ ret = drm_dp_aux_register(_dp->aux);
+ if (!ret)
+ drm_dp_cec_register_connector(_dp->aux,
+ connector->name, dev->dev);
+ return ret;
}
static void
intel_dp_connector_unregister(struct drm_connector *connector)
{
- drm_dp_aux_unregister(_attached_dp(connector)->aux);
+ struct intel_dp *intel_dp = intel_attached_dp(connector);
+
+ drm_dp_cec_unregister_connector(_dp->aux);
+ drm_dp_aux_unregister(_dp->aux);
intel_connector_unregister(connector);
}
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
On 11/06/18 14:20, Hans Verkuil wrote: > Hi Ville, > > I finally found some time to dig deeper into when a CEC device should be > registered. > > Since it's been a long while since we discussed this let me just recap the > situation > and then propose three solutions: > CEC is implemented for DP-to-HDMI branch devices through DPCD CEC registers. > When > HPD is high we can read these registers and check if CEC is supported or not. > > If an external USB-C/DP/mini-DP to HDMI adapter is used, then when the HPD > goes low > you lose access to the DPCD registers since that is (I think) powered by the > HPD. > > If an integrated branch device is used (such as for the HDMI connector on the > NUC) > the DPCD registers will remain available even if the display is disconnected. > > The problem is with external adapters since if the HPD goes low you do not > know > if the adapter has been disconnected, or if the display just pulled the HPD > low for a > short time (updating the EDID, HDCP changes). In the latter case you do not > want to > unregister and reregister the cec device. > > I see three options: > > 1) register a cec device when a connector is registered and keep it for the > life time > of the connector. If HPD goes low, or the branch device doesn't support CEC, > then just > set the physical address of the CEC adapter to f.f.f.f. > > This is simple, but the disadvantage is that there is a CEC device around, > even if the > branch device doesn't support CEC. > > 2) register a cec device when HPD goes high and if a branch device that > supports CEC is > detected. Unregister the cec device when the HPD goes low and stays low for > more than > a second. This prevents a cec device from disappearing whenever the display > toggles > the HPD. It does require a delayed workqueue to handle this delay. > > It would be nice if there is a way to avoid a delayed workqueue, but I didn't > see > anything in the i915 code. > > 3) A hybrid option where the cec device is only registered when a CEC capable > branch > device is detected, but then we keep it for the remaining lifetime of the > connector. > This avoids the delayed workqueue, and avoids creating cec devices if the > branch > device doesn't support CEC. But once it is created it won't be removed until > the > connector is also unregistered. > > I'm leaning towards the second or third option. > > Opinions? Other ideas? A quick update: I've been working on a next version of this patch series that combines options 2 and 3 and moves the logic out of the i915 driver into the core drm CEC code since all DP drivers will have the same problem. I hope to post the new series later today. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][V3] drm/i915/guc: fix GEM_BUG_ON check
From: Colin Ian King
The check for level being less than zero always false because flags
is currently unsigned and can never be negative. Fix this by making
level a s32.
Detected by CoverityScan, CID#1468363 ("Macro compares unsigned to 0")
Fixes: cb5d64e9f13e ("drm/i915/guc: Allow user to control default GuC logging")
Signed-off-by: Colin Ian King
---
V3: Make level s32 and add the missing Fixes: tag, thanks to Dan Carpenter and
Jani Nikula for correcting my mistakes
---
drivers/gpu/drm/i915/intel_guc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 116f4ccf1bbd..bdb1fab322bf 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -205,7 +205,7 @@ void intel_guc_fini(struct intel_guc *guc)
static u32 get_log_control_flags(void)
{
- u32 level = i915_modparams.guc_log_level;
+ s32 level = i915_modparams.guc_log_level;
u32 flags = 0;
GEM_BUG_ON(level < 0);
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][V2] drm/i915/guc: fix GEM_BUG_ON check
On Tue, 12 Jun 2018, Dan Carpenter wrote:
> On Mon, Jun 11, 2018 at 05:46:53PM +0100, Colin King wrote:
>> From: Colin Ian King
>>
>> The check for level being less than zero always false because flags
>> is currently unsigned and can never be negative. Fix this by making
>> flags a s32.
>>
>> Detected by CoverityScan, CID#1468363 ("Macro compares unsigned to 0")
>>
>> Signed-off-by: Colin Ian King
>>
>> ---
>> V2: Make flags s32 rather than remove the GEM_BUG_ON check, thanks to
>> Ville Syrjälä for spotting the mistake in my first attempt.
>> ---
>> drivers/gpu/drm/i915/intel_guc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_guc.c
>> b/drivers/gpu/drm/i915/intel_guc.c
>> index 116f4ccf1bbd..fb31f5004bcf 100644
>> --- a/drivers/gpu/drm/i915/intel_guc.c
>> +++ b/drivers/gpu/drm/i915/intel_guc.c
>> @@ -206,7 +206,7 @@ void intel_guc_fini(struct intel_guc *guc)
>> static u32 get_log_control_flags(void)
>> {
>> u32 level = i915_modparams.guc_log_level;
>> -u32 flags = 0;
>> +s32 flags = 0;
>>
>> GEM_BUG_ON(level < 0);
>
> Only insane people use "s32" when it's not part of the hardware spec and
> you changed the wrong variable...
Yeah, int level.
Also,
Fixes: cb5d64e9f13e ("drm/i915/guc: Allow user to control default GuC logging")
BR,
Jani.
>
> regards,
> dan carpenter
>
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][V2] drm/i915/guc: fix GEM_BUG_ON check
On Mon, Jun 11, 2018 at 05:46:53PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The check for level being less than zero always false because flags
> is currently unsigned and can never be negative. Fix this by making
> flags a s32.
>
> Detected by CoverityScan, CID#1468363 ("Macro compares unsigned to 0")
>
> Signed-off-by: Colin Ian King
>
> ---
> V2: Make flags s32 rather than remove the GEM_BUG_ON check, thanks to
> Ville Syrjälä for spotting the mistake in my first attempt.
> ---
> drivers/gpu/drm/i915/intel_guc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_guc.c
> b/drivers/gpu/drm/i915/intel_guc.c
> index 116f4ccf1bbd..fb31f5004bcf 100644
> --- a/drivers/gpu/drm/i915/intel_guc.c
> +++ b/drivers/gpu/drm/i915/intel_guc.c
> @@ -206,7 +206,7 @@ void intel_guc_fini(struct intel_guc *guc)
> static u32 get_log_control_flags(void)
> {
> u32 level = i915_modparams.guc_log_level;
> - u32 flags = 0;
> + s32 flags = 0;
>
> GEM_BUG_ON(level < 0);
Only insane people use "s32" when it's not part of the hardware spec and
you changed the wrong variable...
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-fixes
Hey, Only the qxl fix by Jeremy Cline is new. The rest has landed in v4.17 already. drm-misc-fixes-2018-06-12: Only a small qxl fix that was queued for v4.17. The following changes since commit 9a0e9802217291e54c4dd1fc5462f189a4be14ec: drm/vc4: Fix scaling of uni-planar formats (2018-05-09 09:48:23 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-06-12 for you to fetch changes up to 889ad63d41eea20184b0483e7e585e5b20fb6cfe: drm/qxl: Call qxl_bo_unref outside atomic context (2018-06-04 09:31:39 +0200) Only a small qxl fix that was queued for v4.17. Dan Carpenter (1): drm/dumb-buffers: Integer overflow in drm_mode_create_ioctl() Dhinakaran Pandiyan (1): drm/psr: Fix missed entry in PSR setup time table. Eric Anholt (1): drm/vc4: Fix leak of the file_priv that stored the perfmon. Haneen Mohammed (1): drm: Match sysfs name in link removal to link creation Jeremy Cline (1): drm/qxl: Call qxl_bo_unref outside atomic context Neil Armstrong (1): drm/bridge/synopsys: dw-hdmi: fix dw_hdmi_setup_rx_sense Tomi Valkeinen (1): drm/omap: fix NULL deref crash with SDI displays drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 15 --- drivers/gpu/drm/drm_dp_helper.c | 1 + drivers/gpu/drm/drm_drv.c | 2 +- drivers/gpu/drm/drm_dumb_buffers.c| 7 --- drivers/gpu/drm/meson/meson_dw_hdmi.c | 2 +- drivers/gpu/drm/omapdrm/dss/sdi.c | 5 - drivers/gpu/drm/qxl/qxl_display.c | 7 +-- drivers/gpu/drm/vc4/vc4_drv.c | 1 + include/drm/bridge/dw_hdmi.h | 2 +- 9 files changed, 22 insertions(+), 20 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings
Quoting spa...@codeaurora.org (2018-06-05 21:50:16) > On 2018-06-05 20:50, Rob Herring wrote: > > On Tue, Jun 05, 2018 at 11:10:16AM +0530, Sandeep Panda wrote: > >> Document the bindings used for the sn65dsi86 DSI to eDP bridge. [...] > >> and > >> + the second cell is used to specify flags. > >> + See ../../gpio/gpio.txt for more information. > >> +- #pwm-cells : Should be one. See ../../pwm/pwm.txt for description > >> of > >> + the cell formats. > >> + > >> +- clock-names: should be "refclk" > >> +- clocks: Specification for input reference clock. The reference > >> + clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz. > >> + > >> +- lane-mapping: Specification to describe the logical to physical > >> lane > > > > As I mentioned in v7, we already have a property for this. It's called > > 'data-lanes' and defined in media/video-interfaces.txt. Use that. If > > you > > need polarity too, then add a property for that. And add it to > > video-interfaces.txt. > > The data-lanes property mentioned in media/video-interfaces.txt is > referring > to DSI/CSI lanes where assumption is clock lane is fixed at index 0. But > here > the we want to mention about eDP lanes which do not have dedicated clock > lane. > So can we still use the existing data-lanes property here? Why is that a problem? It's just a property name. There are data-lanes and clock-lanes properties in the video-interfaces.txt file by the way. It would be nice if that document could be updated for displayport and DSI (e.g. clock-noncontinuous or link-frequencies) or even just mention in there that these can apply to DSI and displayport too. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings
Quoting Rob Herring (2018-06-05 08:20:50) > > + > > +- ddc-i2c-bus: phandle of the I2C controller used for DDC EDID probing > > + > > +- gpio-controller: Marks the device has a GPIO controller. > > +- #gpio-cells: Should be two. The first cell is the pin number and > > + the second cell is used to specify flags. > > + See ../../gpio/gpio.txt for more information. > > +- #pwm-cells : Should be one. See ../../pwm/pwm.txt for description of > > + the cell formats. > > + > > +- clock-names: should be "refclk" > > +- clocks: Specification for input reference clock. The reference > > + clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz. > > + > > +- lane-mapping: Specification to describe the logical to physical lane > > As I mentioned in v7, we already have a property for this. It's called > 'data-lanes' and defined in media/video-interfaces.txt. Use that. If you > need polarity too, then add a property for that. And add it to > video-interfaces.txt. Looks like inversion is already handled by the 'lane-polarities' property. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199959] amdgpu, regression?: system freezes after resume
https://bugzilla.kernel.org/show_bug.cgi?id=199959 --- Comment #16 from Christian König (christian.koe...@amd.com) --- So the problem seems to be the bridge then. Please provide me with the output of the following commands, once before you suspended, once after you resumed without any change and once after you resumed with your hack to resize the BAR once more: sudo setpci -s 64:00.0 COMMAND PREF_MEMORY_BASE PREF_MEMORY_LIMIT PREF_BASE_UPPER32 PREF_LIMIT_UPPER32 sudo lspci -s 64:00.0 - -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] drm-intel-next
On Tue, 12 Jun 2018, Dave Airlie wrote: > On 12 June 2018 at 02:27, Rodrigo Vivi wrote: >> Hi Dave, >> >> This is the first round targeting 4.19. >> > Does this tree feed into linux-next already? > > Since we shouldn't have new stuff for linux-next feeding into it until > after rc1. I think we'll feed it to linux-next only after merge window closes i.e. rc1. > I won't be pulling this until after rc1 anyways. Seems fair; this doesn't conflict with tagging manageable sized batches in dinq like Rodrigo has done here. So we're good. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106871] Screen with blank cursor (raven ridge on MSI B350)
https://bugs.freedesktop.org/show_bug.cgi?id=106871 --- Comment #3 from Michel Dänzer --- (In reply to Erik from comment #2) > (Still interesting how you can figure this out from my logging.) In a nutshell: Because the dmesg output you attached doesn't contain the word "Display". -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH v2 5/9] xen/gntdev: Allow mappings for DMA buffers
On 06/11/2018 07:51 PM, Stefano Stabellini wrote:
On Mon, 11 Jun 2018, Oleksandr Andrushchenko wrote:
On 06/08/2018 10:21 PM, Boris Ostrovsky wrote:
On 06/08/2018 01:59 PM, Stefano Stabellini wrote:
@@ -325,6 +401,14 @@ static int map_grant_pages(struct
grant_map
*map)
map->unmap_ops[i].handle =
map->map_ops[i].handle;
if (use_ptemod)
map->kunmap_ops[i].handle =
map->kmap_ops[i].handle;
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ else if (map->dma_vaddr) {
+ unsigned long mfn;
+
+ mfn = __pfn_to_mfn(page_to_pfn(map->pages[i]));
Not pfn_to_mfn()?
I'd love to, but pfn_to_mfn is only defined for x86, not ARM:
[1]
and [2]
Thus,
drivers/xen/gntdev.c:408:10: error: implicit declaration of
function
‘pfn_to_mfn’ [-Werror=implicit-function-declaration]
mfn = pfn_to_mfn(page_to_pfn(map->pages[i]));
So, I'll keep __pfn_to_mfn
How will this work on non-PV x86?
So, you mean I need:
#ifdef CONFIG_X86
mfn = pfn_to_mfn(page_to_pfn(map->pages[i]));
#else
mfn = __pfn_to_mfn(page_to_pfn(map->pages[i]));
#endif
I'd rather fix it in ARM code. Stefano, why does ARM uses the
underscored version?
Do you want me to add one more patch for ARM to wrap __pfn_to_mfn
with static inline for ARM? e.g.
static inline ...pfn_to_mfn(...)
{
__pfn_to_mfn();
}
A Xen on ARM guest doesn't actually know the mfns behind its own
pseudo-physical pages. This is why we stopped using pfn_to_mfn and
started using pfn_to_bfn instead, which will generally return "pfn",
unless the page is a foreign grant. See include/xen/arm/page.h.
pfn_to_bfn was also introduced on x86. For example, see the usage of
pfn_to_bfn in drivers/xen/swiotlb-xen.c. Otherwise, if you don't care
about other mapped grants, you can just use pfn_to_gfn, that always
returns pfn.
I think then this code needs to use pfn_to_bfn().
Ok
Also, for your information, we support different page granularities in
Linux as a Xen guest, see the comment at include/xen/arm/page.h:
/*
* The pseudo-physical frame (pfn) used in all the helpers is always
based
* on Xen page granularity (i.e 4KB).
*
* A Linux page may be split across multiple non-contiguous Xen page so
we
* have to keep track with frame based on 4KB page granularity.
*
* PV drivers should never make a direct usage of those helpers
(particularly
* pfn_to_gfn and gfn_to_pfn).
*/
A Linux page could be 64K, but a Xen page is always 4K. A granted page
is also 4K. We have helpers to take into account the offsets to map
multiple Xen grants in a single Linux page, see for example
drivers/xen/grant-table.c:gnttab_foreach_grant. Most PV drivers have
been converted to be able to work with 64K pages correctly, but if I
remember correctly gntdev.c is the only remaining driver that doesn't
support 64K pages yet, so you don't have to deal with it if you don't
want to.
I believe somewhere in this series there is a test for PAGE_SIZE vs.
XEN_PAGE_SIZE. Right, Oleksandr?
Not in gntdev. You might have seen this in xen-drmfront/xen-sndfront,
but I didn't touch gntdev for that. Do you want me to add yet another patch
in the series to check for that?
gntdev.c is already not capable of handling PAGE_SIZE != XEN_PAGE_SIZE,
so you are not going to break anything that is not already broken :-) If
your new gntdev.c code relies on PAGE_SIZE == XEN_PAGE_SIZE, it might be
good to add an in-code comment about it, just to make it easier to fix
the whole of gntdev.c in the future.
Yes, I just mean I can add something like [1] as a separate patch to the
series,
so we are on the safe side here
Thanks for the explanation.
[1]
https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/xen/xen_drm_front.c#n813
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH v2 5/9] xen/gntdev: Allow mappings for DMA buffers
Hi Stefano,
On 06/11/2018 05:51 PM, Stefano Stabellini wrote:
On Mon, 11 Jun 2018, Oleksandr Andrushchenko wrote:
On 06/08/2018 10:21 PM, Boris Ostrovsky wrote:
On 06/08/2018 01:59 PM, Stefano Stabellini wrote:
@@ -325,6 +401,14 @@ static int map_grant_pages(struct
grant_map
*map)
map->unmap_ops[i].handle =
map->map_ops[i].handle;
if (use_ptemod)
map->kunmap_ops[i].handle =
map->kmap_ops[i].handle;
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ else if (map->dma_vaddr) {
+ unsigned long mfn;
+
+ mfn = __pfn_to_mfn(page_to_pfn(map->pages[i]));
Not pfn_to_mfn()?
I'd love to, but pfn_to_mfn is only defined for x86, not ARM:
[1]
and [2]
Thus,
drivers/xen/gntdev.c:408:10: error: implicit declaration of
function
‘pfn_to_mfn’ [-Werror=implicit-function-declaration]
mfn = pfn_to_mfn(page_to_pfn(map->pages[i]));
So, I'll keep __pfn_to_mfn
How will this work on non-PV x86?
So, you mean I need:
#ifdef CONFIG_X86
mfn = pfn_to_mfn(page_to_pfn(map->pages[i]));
#else
mfn = __pfn_to_mfn(page_to_pfn(map->pages[i]));
#endif
I'd rather fix it in ARM code. Stefano, why does ARM uses the
underscored version?
Do you want me to add one more patch for ARM to wrap __pfn_to_mfn
with static inline for ARM? e.g.
static inline ...pfn_to_mfn(...)
{
__pfn_to_mfn();
}
A Xen on ARM guest doesn't actually know the mfns behind its own
pseudo-physical pages. This is why we stopped using pfn_to_mfn and
started using pfn_to_bfn instead, which will generally return "pfn",
unless the page is a foreign grant. See include/xen/arm/page.h.
pfn_to_bfn was also introduced on x86. For example, see the usage of
pfn_to_bfn in drivers/xen/swiotlb-xen.c. Otherwise, if you don't care
about other mapped grants, you can just use pfn_to_gfn, that always
returns pfn.
I think then this code needs to use pfn_to_bfn().
Ok
Also, for your information, we support different page granularities in
Linux as a Xen guest, see the comment at include/xen/arm/page.h:
/*
* The pseudo-physical frame (pfn) used in all the helpers is always
based
* on Xen page granularity (i.e 4KB).
*
* A Linux page may be split across multiple non-contiguous Xen page so
we
* have to keep track with frame based on 4KB page granularity.
*
* PV drivers should never make a direct usage of those helpers
(particularly
* pfn_to_gfn and gfn_to_pfn).
*/
A Linux page could be 64K, but a Xen page is always 4K. A granted page
is also 4K. We have helpers to take into account the offsets to map
multiple Xen grants in a single Linux page, see for example
drivers/xen/grant-table.c:gnttab_foreach_grant. Most PV drivers have
been converted to be able to work with 64K pages correctly, but if I
remember correctly gntdev.c is the only remaining driver that doesn't
support 64K pages yet, so you don't have to deal with it if you don't
want to.
I believe somewhere in this series there is a test for PAGE_SIZE vs.
XEN_PAGE_SIZE. Right, Oleksandr?
Not in gntdev. You might have seen this in xen-drmfront/xen-sndfront,
but I didn't touch gntdev for that. Do you want me to add yet another patch
in the series to check for that?
gntdev.c is already not capable of handling PAGE_SIZE != XEN_PAGE_SIZE,
so you are not going to break anything that is not already broken :-) If
your new gntdev.c code relies on PAGE_SIZE == XEN_PAGE_SIZE, it might be
good to add an in-code comment about it, just to make it easier to fix
the whole of gntdev.c in the future.
Well, I think gntdev is capable of handling PAGE_SIZE != XEN_PAGE_SIZE.
Let's imagine Linux is built with 64K pages. gntdev will map each grant
at a 64K alignment. Although, I am not sure if patches for QEMU ever
make it upstream (I think it is in Centos).
Cheers,
--
Julien Grall
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/meson: Fix an un-handled error path in 'meson_drv_bind_master()'
If 'platform_get_resource_byname()' fails, we should release some resources
before leaving, as already done in the other error handling path of the
function.
Fixes: acaa3f13b8dd ("drm/meson: Fix potential NULL dereference in
meson_drv_bind_master()")
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/meson/meson_drv.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index 32b1a6cdecfc..d3443125e661 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -197,8 +197,10 @@ static int meson_drv_bind_master(struct device *dev, bool
has_components)
priv->io_base = regs;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "hhi");
- if (!res)
- return -EINVAL;
+ if (!res) {
+ ret = -EINVAL;
+ goto free_drm;
+ }
/* Simply ioremap since it may be a shared register zone */
regs = devm_ioremap(dev, res->start, resource_size(res));
if (!regs) {
@@ -215,8 +217,10 @@ static int meson_drv_bind_master(struct device *dev, bool
has_components)
}
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dmc");
- if (!res)
- return -EINVAL;
+ if (!res) {
+ ret = -EINVAL;
+ goto free_drm;
+ }
/* Simply ioremap since it may be a shared register zone */
regs = devm_ioremap(dev, res->start, resource_size(res));
if (!regs) {
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH v2 5/9] xen/gntdev: Allow mappings for DMA buffers
On 06/11/2018 08:46 PM, Julien Grall wrote:
Hi,
On 06/11/2018 06:16 PM, Oleksandr Andrushchenko wrote:
On 06/11/2018 07:51 PM, Stefano Stabellini wrote:
On Mon, 11 Jun 2018, Oleksandr Andrushchenko wrote:
On 06/08/2018 10:21 PM, Boris Ostrovsky wrote:
On 06/08/2018 01:59 PM, Stefano Stabellini wrote:
@@ -325,6 +401,14 @@ static int map_grant_pages(struct
grant_map
*map)
map->unmap_ops[i].handle =
map->map_ops[i].handle;
if (use_ptemod)
map->kunmap_ops[i].handle =
map->kmap_ops[i].handle;
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ else if (map->dma_vaddr) {
+ unsigned long mfn;
+
+ mfn = __pfn_to_mfn(page_to_pfn(map->pages[i]));
Not pfn_to_mfn()?
I'd love to, but pfn_to_mfn is only defined for x86, not ARM:
[1]
and [2]
Thus,
drivers/xen/gntdev.c:408:10: error: implicit declaration of
function
‘pfn_to_mfn’ [-Werror=implicit-function-declaration]
mfn = pfn_to_mfn(page_to_pfn(map->pages[i]));
So, I'll keep __pfn_to_mfn
How will this work on non-PV x86?
So, you mean I need:
#ifdef CONFIG_X86
mfn = pfn_to_mfn(page_to_pfn(map->pages[i]));
#else
mfn = __pfn_to_mfn(page_to_pfn(map->pages[i]));
#endif
I'd rather fix it in ARM code. Stefano, why does ARM uses the
underscored version?
Do you want me to add one more patch for ARM to wrap __pfn_to_mfn
with static inline for ARM? e.g.
static inline ...pfn_to_mfn(...)
{
__pfn_to_mfn();
}
A Xen on ARM guest doesn't actually know the mfns behind its own
pseudo-physical pages. This is why we stopped using pfn_to_mfn and
started using pfn_to_bfn instead, which will generally return "pfn",
unless the page is a foreign grant. See include/xen/arm/page.h.
pfn_to_bfn was also introduced on x86. For example, see the usage of
pfn_to_bfn in drivers/xen/swiotlb-xen.c. Otherwise, if you don't
care
about other mapped grants, you can just use pfn_to_gfn, that always
returns pfn.
I think then this code needs to use pfn_to_bfn().
Ok
Also, for your information, we support different page
granularities in
Linux as a Xen guest, see the comment at include/xen/arm/page.h:
/*
* The pseudo-physical frame (pfn) used in all the helpers is
always
based
* on Xen page granularity (i.e 4KB).
*
* A Linux page may be split across multiple non-contiguous
Xen page so
we
* have to keep track with frame based on 4KB page granularity.
*
* PV drivers should never make a direct usage of those helpers
(particularly
* pfn_to_gfn and gfn_to_pfn).
*/
A Linux page could be 64K, but a Xen page is always 4K. A granted
page
is also 4K. We have helpers to take into account the offsets to map
multiple Xen grants in a single Linux page, see for example
drivers/xen/grant-table.c:gnttab_foreach_grant. Most PV drivers have
been converted to be able to work with 64K pages correctly, but if I
remember correctly gntdev.c is the only remaining driver that
doesn't
support 64K pages yet, so you don't have to deal with it if you
don't
want to.
I believe somewhere in this series there is a test for PAGE_SIZE vs.
XEN_PAGE_SIZE. Right, Oleksandr?
Not in gntdev. You might have seen this in xen-drmfront/xen-sndfront,
but I didn't touch gntdev for that. Do you want me to add yet
another patch
in the series to check for that?
gntdev.c is already not capable of handling PAGE_SIZE != XEN_PAGE_SIZE,
so you are not going to break anything that is not already broken
:-) If
your new gntdev.c code relies on PAGE_SIZE == XEN_PAGE_SIZE, it
might be
good to add an in-code comment about it, just to make it easier to fix
the whole of gntdev.c in the future.
Yes, I just mean I can add something like [1] as a separate patch to
the series,
so we are on the safe side here
See my comment on Stefano's e-mail. I believe gntdev is able to handle
PAGE_SIZE != XEN_PAGE_SIZE. So I would rather keep the behavior we
have today for such case.
Sure, with a note that we waste most of a 64KiB page ;)
Cheers,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH v2 5/9] xen/gntdev: Allow mappings for DMA buffers
Hi,
On 06/11/2018 06:49 PM, Oleksandr Andrushchenko wrote:
On 06/11/2018 08:46 PM, Julien Grall wrote:
Hi,
On 06/11/2018 06:16 PM, Oleksandr Andrushchenko wrote:
On 06/11/2018 07:51 PM, Stefano Stabellini wrote:
On Mon, 11 Jun 2018, Oleksandr Andrushchenko wrote:
On 06/08/2018 10:21 PM, Boris Ostrovsky wrote:
On 06/08/2018 01:59 PM, Stefano Stabellini wrote:
@@ -325,6 +401,14 @@ static int map_grant_pages(struct
grant_map
*map)
map->unmap_ops[i].handle =
map->map_ops[i].handle;
if (use_ptemod)
map->kunmap_ops[i].handle =
map->kmap_ops[i].handle;
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ else if (map->dma_vaddr) {
+ unsigned long mfn;
+
+ mfn = __pfn_to_mfn(page_to_pfn(map->pages[i]));
Not pfn_to_mfn()?
I'd love to, but pfn_to_mfn is only defined for x86, not ARM:
[1]
and [2]
Thus,
drivers/xen/gntdev.c:408:10: error: implicit declaration of
function
‘pfn_to_mfn’ [-Werror=implicit-function-declaration]
mfn = pfn_to_mfn(page_to_pfn(map->pages[i]));
So, I'll keep __pfn_to_mfn
How will this work on non-PV x86?
So, you mean I need:
#ifdef CONFIG_X86
mfn = pfn_to_mfn(page_to_pfn(map->pages[i]));
#else
mfn = __pfn_to_mfn(page_to_pfn(map->pages[i]));
#endif
I'd rather fix it in ARM code. Stefano, why does ARM uses the
underscored version?
Do you want me to add one more patch for ARM to wrap __pfn_to_mfn
with static inline for ARM? e.g.
static inline ...pfn_to_mfn(...)
{
__pfn_to_mfn();
}
A Xen on ARM guest doesn't actually know the mfns behind its own
pseudo-physical pages. This is why we stopped using pfn_to_mfn and
started using pfn_to_bfn instead, which will generally return "pfn",
unless the page is a foreign grant. See include/xen/arm/page.h.
pfn_to_bfn was also introduced on x86. For example, see the usage of
pfn_to_bfn in drivers/xen/swiotlb-xen.c. Otherwise, if you don't
care
about other mapped grants, you can just use pfn_to_gfn, that always
returns pfn.
I think then this code needs to use pfn_to_bfn().
Ok
Also, for your information, we support different page
granularities in
Linux as a Xen guest, see the comment at include/xen/arm/page.h:
/*
* The pseudo-physical frame (pfn) used in all the helpers is
always
based
* on Xen page granularity (i.e 4KB).
*
* A Linux page may be split across multiple non-contiguous
Xen page so
we
* have to keep track with frame based on 4KB page granularity.
*
* PV drivers should never make a direct usage of those helpers
(particularly
* pfn_to_gfn and gfn_to_pfn).
*/
A Linux page could be 64K, but a Xen page is always 4K. A granted
page
is also 4K. We have helpers to take into account the offsets to map
multiple Xen grants in a single Linux page, see for example
drivers/xen/grant-table.c:gnttab_foreach_grant. Most PV drivers have
been converted to be able to work with 64K pages correctly, but if I
remember correctly gntdev.c is the only remaining driver that
doesn't
support 64K pages yet, so you don't have to deal with it if you
don't
want to.
I believe somewhere in this series there is a test for PAGE_SIZE vs.
XEN_PAGE_SIZE. Right, Oleksandr?
Not in gntdev. You might have seen this in xen-drmfront/xen-sndfront,
but I didn't touch gntdev for that. Do you want me to add yet
another patch
in the series to check for that?
gntdev.c is already not capable of handling PAGE_SIZE != XEN_PAGE_SIZE,
so you are not going to break anything that is not already broken
:-) If
your new gntdev.c code relies on PAGE_SIZE == XEN_PAGE_SIZE, it
might be
good to add an in-code comment about it, just to make it easier to fix
the whole of gntdev.c in the future.
Yes, I just mean I can add something like [1] as a separate patch to
the series,
so we are on the safe side here
See my comment on Stefano's e-mail. I believe gntdev is able to handle
PAGE_SIZE != XEN_PAGE_SIZE. So I would rather keep the behavior we
have today for such case.
Sure, with a note that we waste most of a 64KiB page ;)
That's the second definition of "64KB page" ;). In the case of grants,
it is actually quite hard to merge them in a single page. So quite a few
places still allocate 64KB but only map the first 4KB.
You would need to rework most the grant framework (not only gntdev) to
avoid that waste. Patches are welcomed.
Cheers,
--
Julien Grall
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 1/4] drm/bridge: add support for sn65dsi86 bridge driver
Quoting Sandeep Panda (2018-06-04 22:40:15)
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> new file mode 100644
> index 000..add6e0f
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -0,0 +1,666 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> + */
> +
[...]
> +
> +static const struct regmap_config ti_sn_bridge_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .volatile_table = _sn_bridge_volatile_table,
> + .cache_type = REGCACHE_NONE,
> +};
> +
> +static void ti_sn_bridge_write_u16(struct ti_sn_bridge *pdata,
> + unsigned int reg, u16 val)
> +{
> + regmap_write(pdata->regmap, reg, val & 0xFF);
> + regmap_write(pdata->regmap, reg + 1, val >> 8);
> +}
> +
> +static int __maybe_unused ti_sn_bridge_resume(struct device *dev)
> +{
> + struct ti_sn_bridge *pdata = dev_get_drvdata(dev);
> + int ret = 0;
Please don't assign variables and then reassign them again immediately
after. It hides use before real initialization bugs.
> +
> + ret = regulator_bulk_enable(SN_REGULATOR_SUPPLY_NUM, pdata->supplies);
[...]
> +
> +static int ti_sn_bridge_probe(struct i2c_client *client,
> +const struct i2c_device_id *id)
> +{
> + struct ti_sn_bridge *pdata;
> + struct device_node *ddc_node;
> + struct mipi_dsi_host *host;
> + struct mipi_dsi_device *dsi;
> + int ret = 0;
> + const struct mipi_dsi_device_info info = { .type = "ti_sn_bridge",
> + .channel = 0,
> + .node = NULL,
> +};
> +
> + if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
> + DRM_ERROR("device doesn't support I2C\n");
> + return -ENODEV;
> + }
> +
> + ret = ti_sn_bridge_parse_dsi_host(pdata);
> + if (ret)
> + return ret;
> +
> + host = of_find_mipi_dsi_host_by_node(pdata->host_node);
> + if (!host) {
> + DRM_ERROR("failed to find dsi host\n");
Not sure we want to print an error and then return -EPROBE_DEFER.
Usually EPROBE_DEFER is silent.
> + ret = -EPROBE_DEFER;
> + goto err_dsi_host;
> + }
> +
[...]
> +
> + /* TODO: setting to 4 lanes always for now */
> + dsi->lanes = 4;
> + dsi->format = MIPI_DSI_FMT_RGB888;
> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
> MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
> + MIPI_DSI_MODE_EOT_PACKET | MIPI_DSI_MODE_VIDEO_HSE;
> +
> + ret = mipi_dsi_attach(dsi);
> + if (ret < 0) {
> + DRM_ERROR("failed to attach dsi to host\n");
> + goto err_dsi_attach;
> + }
> + pdata->dsi = dsi;
> +
> + pdata->refclk = devm_clk_get(pdata->dev, "refclk");
We need to check for error
if (IS_ERR(pdata->refclk))
And then if it's EPROBE_DEFER I suppose we would bail out, otherwise
assume it's not present?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH v2 5/9] xen/gntdev: Allow mappings for DMA buffers
Hi,
On 06/11/2018 06:16 PM, Oleksandr Andrushchenko wrote:
On 06/11/2018 07:51 PM, Stefano Stabellini wrote:
On Mon, 11 Jun 2018, Oleksandr Andrushchenko wrote:
On 06/08/2018 10:21 PM, Boris Ostrovsky wrote:
On 06/08/2018 01:59 PM, Stefano Stabellini wrote:
@@ -325,6 +401,14 @@ static int map_grant_pages(struct
grant_map
*map)
map->unmap_ops[i].handle =
map->map_ops[i].handle;
if (use_ptemod)
map->kunmap_ops[i].handle =
map->kmap_ops[i].handle;
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ else if (map->dma_vaddr) {
+ unsigned long mfn;
+
+ mfn = __pfn_to_mfn(page_to_pfn(map->pages[i]));
Not pfn_to_mfn()?
I'd love to, but pfn_to_mfn is only defined for x86, not ARM:
[1]
and [2]
Thus,
drivers/xen/gntdev.c:408:10: error: implicit declaration of
function
‘pfn_to_mfn’ [-Werror=implicit-function-declaration]
mfn = pfn_to_mfn(page_to_pfn(map->pages[i]));
So, I'll keep __pfn_to_mfn
How will this work on non-PV x86?
So, you mean I need:
#ifdef CONFIG_X86
mfn = pfn_to_mfn(page_to_pfn(map->pages[i]));
#else
mfn = __pfn_to_mfn(page_to_pfn(map->pages[i]));
#endif
I'd rather fix it in ARM code. Stefano, why does ARM uses the
underscored version?
Do you want me to add one more patch for ARM to wrap __pfn_to_mfn
with static inline for ARM? e.g.
static inline ...pfn_to_mfn(...)
{
__pfn_to_mfn();
}
A Xen on ARM guest doesn't actually know the mfns behind its own
pseudo-physical pages. This is why we stopped using pfn_to_mfn and
started using pfn_to_bfn instead, which will generally return "pfn",
unless the page is a foreign grant. See include/xen/arm/page.h.
pfn_to_bfn was also introduced on x86. For example, see the usage of
pfn_to_bfn in drivers/xen/swiotlb-xen.c. Otherwise, if you don't care
about other mapped grants, you can just use pfn_to_gfn, that always
returns pfn.
I think then this code needs to use pfn_to_bfn().
Ok
Also, for your information, we support different page granularities in
Linux as a Xen guest, see the comment at include/xen/arm/page.h:
/*
* The pseudo-physical frame (pfn) used in all the helpers is
always
based
* on Xen page granularity (i.e 4KB).
*
* A Linux page may be split across multiple non-contiguous Xen
page so
we
* have to keep track with frame based on 4KB page granularity.
*
* PV drivers should never make a direct usage of those helpers
(particularly
* pfn_to_gfn and gfn_to_pfn).
*/
A Linux page could be 64K, but a Xen page is always 4K. A granted page
is also 4K. We have helpers to take into account the offsets to map
multiple Xen grants in a single Linux page, see for example
drivers/xen/grant-table.c:gnttab_foreach_grant. Most PV drivers have
been converted to be able to work with 64K pages correctly, but if I
remember correctly gntdev.c is the only remaining driver that doesn't
support 64K pages yet, so you don't have to deal with it if you don't
want to.
I believe somewhere in this series there is a test for PAGE_SIZE vs.
XEN_PAGE_SIZE. Right, Oleksandr?
Not in gntdev. You might have seen this in xen-drmfront/xen-sndfront,
but I didn't touch gntdev for that. Do you want me to add yet another
patch
in the series to check for that?
gntdev.c is already not capable of handling PAGE_SIZE != XEN_PAGE_SIZE,
so you are not going to break anything that is not already broken :-) If
your new gntdev.c code relies on PAGE_SIZE == XEN_PAGE_SIZE, it might be
good to add an in-code comment about it, just to make it easier to fix
the whole of gntdev.c in the future.
Yes, I just mean I can add something like [1] as a separate patch to the
series,
so we are on the safe side here
See my comment on Stefano's e-mail. I believe gntdev is able to handle
PAGE_SIZE != XEN_PAGE_SIZE. So I would rather keep the behavior we have
today for such case.
Cheers,
--
Julien Grall
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106872] vram sizes reported by the kernel totally off
https://bugs.freedesktop.org/show_bug.cgi?id=106872 --- Comment #2 from Christian König --- (In reply to Michel Dänzer from comment #1) > One possible solution for this would be for amdgpu_bo_pin_restricted and > amdgpu_bo_unpin to walk the list of memory nodes and calculate exactly how > much of each of them lies in visible or invisible VRAM. We actually have a helper for that in amdgpu_vram_mgr_vis_size(). Apart from that if the problem only occurse after a certain time it looks like we have a mismatch between adding the pinned size and subtracting it again. Or alternatively some sort of memory corruption. Have you tried running it with KASAN enabled for a while? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
