[PATCH] drm/virtio: drop quirks handling
These days dma ops can be overridden per device, and the virtio core uses that to handle the dma quirks transparently for the rest of the kernel. So we can drop the virtio_has_dma_quirk() checks, just use the dma api unconditionally and depend on the virtio core having setup dma_ops as needed. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/virtio/virtgpu_object.c | 19 ++- drivers/gpu/drm/virtio/virtgpu_vq.c | 16 ++-- 2 files changed, 12 insertions(+), 23 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c b/drivers/gpu/drm/virtio/virtgpu_object.c index 729f98ad7c02..9c35ce64ff9e 100644 --- a/drivers/gpu/drm/virtio/virtgpu_object.c +++ b/drivers/gpu/drm/virtio/virtgpu_object.c @@ -141,7 +141,6 @@ static int virtio_gpu_object_shmem_init(struct virtio_gpu_device *vgdev, struct virtio_gpu_mem_entry **ents, unsigned int *nents) { - bool use_dma_api = !virtio_has_dma_quirk(vgdev->vdev); struct virtio_gpu_object_shmem *shmem = to_virtio_gpu_shmem(bo); struct scatterlist *sg; int si, ret; @@ -162,15 +161,11 @@ static int virtio_gpu_object_shmem_init(struct virtio_gpu_device *vgdev, return -EINVAL; } - if (use_dma_api) { - shmem->mapped = dma_map_sg(vgdev->vdev->dev.parent, - shmem->pages->sgl, - shmem->pages->nents, - DMA_TO_DEVICE); - *nents = shmem->mapped; - } else { - *nents = shmem->pages->nents; - } + shmem->mapped = dma_map_sg(vgdev->vdev->dev.parent, + shmem->pages->sgl, + shmem->pages->nents, + DMA_TO_DEVICE); + *nents = shmem->mapped; *ents = kmalloc_array(*nents, sizeof(struct virtio_gpu_mem_entry), GFP_KERNEL); @@ -180,9 +175,7 @@ static int virtio_gpu_object_shmem_init(struct virtio_gpu_device *vgdev, } for_each_sg(shmem->pages->sgl, sg, *nents, si) { - (*ents)[si].addr = cpu_to_le64(use_dma_api - ? sg_dma_address(sg) - : sg_phys(sg)); + (*ents)[si].addr = cpu_to_le64(sg_dma_address(sg)); (*ents)[si].length = cpu_to_le32(sg->length); (*ents)[si].padding = 0; } diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c index c93c2db35aaf..1c1d2834547d 100644 --- a/drivers/gpu/drm/virtio/virtgpu_vq.c +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c @@ -599,13 +599,11 @@ void virtio_gpu_cmd_transfer_to_host_2d(struct virtio_gpu_device *vgdev, struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(objs->objs[0]); struct virtio_gpu_transfer_to_host_2d *cmd_p; struct virtio_gpu_vbuffer *vbuf; - bool use_dma_api = !virtio_has_dma_quirk(vgdev->vdev); struct virtio_gpu_object_shmem *shmem = to_virtio_gpu_shmem(bo); - if (use_dma_api) - dma_sync_sg_for_device(vgdev->vdev->dev.parent, - shmem->pages->sgl, shmem->pages->nents, - DMA_TO_DEVICE); + dma_sync_sg_for_device(vgdev->vdev->dev.parent, + shmem->pages->sgl, shmem->pages->nents, + DMA_TO_DEVICE); cmd_p = virtio_gpu_alloc_cmd(vgdev, &vbuf, sizeof(*cmd_p)); memset(cmd_p, 0, sizeof(*cmd_p)); @@ -1015,13 +1013,11 @@ void virtio_gpu_cmd_transfer_to_host_3d(struct virtio_gpu_device *vgdev, struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(objs->objs[0]); struct virtio_gpu_transfer_host_3d *cmd_p; struct virtio_gpu_vbuffer *vbuf; - bool use_dma_api = !virtio_has_dma_quirk(vgdev->vdev); struct virtio_gpu_object_shmem *shmem = to_virtio_gpu_shmem(bo); - if (use_dma_api) - dma_sync_sg_for_device(vgdev->vdev->dev.parent, - shmem->pages->sgl, shmem->pages->nents, - DMA_TO_DEVICE); + dma_sync_sg_for_device(vgdev->vdev->dev.parent, + shmem->pages->sgl, shmem->pages->nents, + DMA_TO_DEVICE); cmd_p = virtio_gpu_alloc_cmd(vgdev, &vbuf, sizeof(*cmd_p)); memset(cmd_p, 0, sizeof(*cmd_p)); -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/10] arm64: dts: renesas: r8a77961-salvator-xs: add HDMI Sound support
Hi Laurent > > > > From: Kuninori Morimoto > > > > > > > > This patch enables HDMI Sound on R-Car M3-W+ Salvator-XS board. > > > > > > > > This reverts commit b997613fad58a03588f0f64a3d86db6c5bd76dd2. > > > > > > Which tree can this commit be found in ? > > > > Grr, I forgot to remove it from git-log. > > will fix in v3 > > No worries :-) > > I've applied patch 01 to 04 to my tree and plan to send a pull request > later today. Could you just let me know if you're fine with the small > modification to the commit message proposed in 04/10 ? Yes, no objection about it. Thank you for your help !! Best regards --- Kuninori Morimoto ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/10] arm64: dts: renesas: r8a77961-salvator-xs: add HDMI Sound support
Hi Morimoto-san, On Tue, Sep 08, 2020 at 03:33:29PM +0900, Kuninori Morimoto wrote: > > Hi Laurent > > Thank you for your review > > > > From: Kuninori Morimoto > > > > > > This patch enables HDMI Sound on R-Car M3-W+ Salvator-XS board. > > > > > > This reverts commit b997613fad58a03588f0f64a3d86db6c5bd76dd2. > > > > Which tree can this commit be found in ? > > Grr, I forgot to remove it from git-log. > will fix in v3 No worries :-) I've applied patch 01 to 04 to my tree and plan to send a pull request later today. Could you just let me know if you're fine with the small modification to the commit message proposed in 04/10 ? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/10] arm64: dts: renesas: r8a77961-salvator-xs: add HDMI Sound support
Hi Laurent Thank you for your review > > From: Kuninori Morimoto > > > > This patch enables HDMI Sound on R-Car M3-W+ Salvator-XS board. > > > > This reverts commit b997613fad58a03588f0f64a3d86db6c5bd76dd2. > > Which tree can this commit be found in ? Grr, I forgot to remove it from git-log. will fix in v3 Thank you for your help !! Best regards --- Kuninori Morimoto ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for 5.9-rc5 (special edition)
Hi Linus, The i915 reverts are going to be a bit of a conflict mess for next, so I decided to dequeue them now, along with some msm fixes for a ring corruption issue, that Rob sent over the weekend. Dave. drm-fixes-2020-09-08: drm fixes for 5.9-rc5 (special edition) i915: - revert gpu relocation changes due to regression msm: - fixes for RPTR corruption issue The following changes since commit f4d51dffc6c01a9e94650d95ce0104964f8ae822: Linux 5.9-rc4 (2020-09-06 17:11:40 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-09-08 for you to fetch changes up to 20561da3a2e1e0e827ef5510cb0f74bcfd377e41: Revert "drm/i915/gem: Delete unused code" (2020-09-08 15:45:27 +1000) drm fixes for 5.9-rc5 (special edition) i915: - revert gpu relocation changes due to regression msm: - fixes for RPTR corruption issue Dave Airlie (4): Merge tag 'drm-msm-fixes-2020-09-04' of https://gitlab.freedesktop.org/drm/msm into drm-fixes Revert "drm/i915: Remove i915_gem_object_get_dirty_page()" Revert "drm/i915/gem: Async GPU relocations only" Revert "drm/i915/gem: Delete unused code" Jordan Crouse (4): drm/msm: Split the a5xx preemption record drm/msm: Enable expanded apriv support for a650 drm/msm: Disable preemption on all 5xx targets drm/msm: Disable the RPTR shadow drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 314 +++-- drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 + drivers/gpu/drm/i915/gem/i915_gem_pages.c | 14 + .../drm/i915/gem/selftests/i915_gem_execbuffer.c | 21 +- drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 5 + drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 10 + drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 10 + drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 14 +- drivers/gpu/drm/msm/adreno/a5xx_gpu.h | 1 + drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 25 +- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 13 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c| 27 +- drivers/gpu/drm/msm/msm_gpu.c | 2 +- drivers/gpu/drm/msm/msm_gpu.h | 11 + drivers/gpu/drm/msm/msm_ringbuffer.c | 4 +- 15 files changed, 411 insertions(+), 64 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/10] arm64: dts: renesas: r8a77961-salvator-xs: add HDMI Sound support
Hi Morimoto-san, Thank you for the patch. On Tue, Sep 08, 2020 at 09:35:25AM +0900, Kuninori Morimoto wrote: > From: Kuninori Morimoto > > This patch enables HDMI Sound on R-Car M3-W+ Salvator-XS board. > > This reverts commit b997613fad58a03588f0f64a3d86db6c5bd76dd2. Which tree can this commit be found in ? > Signed-off-by: Kuninori Morimoto > --- > .../boot/dts/renesas/r8a77961-salvator-xs.dts | 29 +++ > 1 file changed, 29 insertions(+) > > diff --git a/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts > b/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts > index ca21a702db54..1e7603365106 100644 > --- a/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts > +++ b/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts > @@ -51,9 +51,38 @@ rcar_dw_hdmi0_out: endpoint { > remote-endpoint = <&hdmi0_con>; > }; > }; > + port@2 { > + reg = <2>; > + dw_hdmi0_snd_in: endpoint { > + remote-endpoint = <&rsnd_endpoint1>; > + }; > + }; > }; > }; > > &hdmi0_con { > remote-endpoint = <&rcar_dw_hdmi0_out>; > }; > + > +&rcar_sound { > + ports { > + /* rsnd_port0 is on salvator-common */ > + rsnd_port1: port@1 { > + reg = <1>; > + rsnd_endpoint1: endpoint { > + remote-endpoint = <&dw_hdmi0_snd_in>; > + > + dai-format = "i2s"; > + bitclock-master = <&rsnd_endpoint1>; > + frame-master = <&rsnd_endpoint1>; > + > + playback = <&ssi2>; > + }; > + }; > + }; > +}; > + > +&sound_card { > + dais = <&rsnd_port0 /* ak4613 */ > + &rsnd_port1>; /* HDMI0 */ > +}; -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 09/10] arm64: dts: renesas: r8a77961-salvator-xs: add HDMI Display support
Hi Morimoto-san, Thank you for the patch. On Tue, Sep 08, 2020 at 09:35:20AM +0900, Kuninori Morimoto wrote: > From: Kuninori Morimoto > > This patch enables HDMI Display on R-Car M3-W+ Salvator-XS board. > > Signed-off-by: Kuninori Morimoto Reviewed-by: Laurent Pinchart > --- > .../boot/dts/renesas/r8a77961-salvator-xs.dts | 28 +++ > 1 file changed, 28 insertions(+) > > diff --git a/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts > b/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts > index 2ffc7e31dd58..ca21a702db54 100644 > --- a/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts > +++ b/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts > @@ -29,3 +29,31 @@ memory@6 { > reg = <0x6 0x 0x1 0x>; > }; > }; > + > +&du { > + clocks = <&cpg CPG_MOD 724>, > + <&cpg CPG_MOD 723>, > + <&cpg CPG_MOD 722>, > + <&versaclock6 1>, > + <&x21_clk>, > + <&versaclock6 2>; > + clock-names = "du.0", "du.1", "du.2", > + "dclkin.0", "dclkin.1", "dclkin.2"; > +}; > + > +&hdmi0 { > + status = "okay"; > + > + ports { > + port@1 { > + reg = <1>; > + rcar_dw_hdmi0_out: endpoint { > + remote-endpoint = <&hdmi0_con>; > + }; > + }; > + }; > +}; > + > +&hdmi0_con { > + remote-endpoint = <&rcar_dw_hdmi0_out>; > +}; -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 08/10] arm64: dts: renesas: r8a77961: Add HDMI device nodes
Hi Morimoto-san, Thank you for the patch. On Tue, Sep 08, 2020 at 09:35:15AM +0900, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > This patch adds HDMI device nodes for R-Car M3-W+ (r8a77961) SoC. > This patch was tested on R-Car M3-W+ Salvator-XS board. > > Signed-off-by: Kuninori Morimoto Reviewed-by: Laurent Pinchart > --- > arch/arm64/boot/dts/renesas/r8a77961.dtsi | 12 +++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi > b/arch/arm64/boot/dts/renesas/r8a77961.dtsi > index c7fabd9e875b..7f21491f6436 100644 > --- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi > +++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi > @@ -2145,14 +2145,23 @@ port@1 { > }; > > hdmi0: hdmi@fead { > + compatible = "renesas,r8a77961-hdmi", > "renesas,rcar-gen3-hdmi"; > reg = <0 0xfead 0 0x1>; > - /* placeholder */ > + interrupts = ; > + clocks = <&cpg CPG_MOD 729>, <&cpg CPG_CORE > R8A77961_CLK_HDMI>; > + clock-names = "iahb", "isfr"; > + power-domains = <&sysc R8A77961_PD_ALWAYS_ON>; > + resets = <&cpg 729>; > + status = "disabled"; > > ports { > #address-cells = <1>; > #size-cells = <0>; > port@0 { > reg = <0>; > + dw_hdmi0_in: endpoint { > + remote-endpoint = > <&du_out_hdmi0>; > + }; > }; > port@1 { > reg = <1>; > @@ -2191,6 +2200,7 @@ du_out_rgb: endpoint { > port@1 { > reg = <1>; > du_out_hdmi0: endpoint { > + remote-endpoint = > <&dw_hdmi0_in>; > }; > }; > port@2 { -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/10] arm64: dts: renesas: r8a77961: Add DU device nodes
Hi Morimoto-san, Thank you for the patch. On Tue, Sep 08, 2020 at 09:35:10AM +0900, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > This patch adds DU device nodes for R-Car M3-W+ (r8a77961) SoC. > This patch was tested on R-Car M3-W+ Salvator-XS board. > > Signed-off-by: Kuninori Morimoto Reviewed-by: Laurent Pinchart > --- > arch/arm64/boot/dts/renesas/r8a77961.dtsi | 13 - > 1 file changed, 12 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi > b/arch/arm64/boot/dts/renesas/r8a77961.dtsi > index 423808b6cd58..c7fabd9e875b 100644 > --- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi > +++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi > @@ -2165,8 +2165,19 @@ port@2 { > }; > > du: display@feb0 { > + compatible = "renesas,du-r8a77961"; > reg = <0 0xfeb0 0 0x7>; > - /* placeholder */ > + interrupts = , > + , > + ; > + clocks = <&cpg CPG_MOD 724>, <&cpg CPG_MOD 723>, > + <&cpg CPG_MOD 722>; > + clock-names = "du.0", "du.1", "du.2"; > + resets = <&cpg 724>, <&cpg 722>; > + reset-names = "du.0", "du.2"; > + > + renesas,vsps = <&vspd0 0>, <&vspd1 0>, <&vspd2 0>; > + status = "disabled"; > > ports { > #address-cells = <1>; -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 06/10] arm64: dts: renesas: r8a77961: Add VSP device nodes
Hi Morimoto-san, On Tue, Sep 08, 2020 at 09:34:59AM +0900, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > This patch adds VSP device nodes for R-Car M3-W+ (r8a77961) SoC. > This patch was tested on R-Car M3-W+ Salvator-XS board. > > Signed-off-by: Kuninori Morimoto Reviewed-by: Laurent Pinchart > --- > arch/arm64/boot/dts/renesas/r8a77961.dtsi | 55 +++ > 1 file changed, 55 insertions(+) > > diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi > b/arch/arm64/boot/dts/renesas/r8a77961.dtsi > index fe0db11b9cb9..423808b6cd58 100644 > --- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi > +++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi > @@ -2012,6 +2012,17 @@ fcpf0: fcp@fe95 { > resets = <&cpg 615>; > }; > > + vspb: vsp@fe96 { > + compatible = "renesas,vsp2"; > + reg = <0 0xfe96 0 0x8000>; > + interrupts = ; > + clocks = <&cpg CPG_MOD 626>; > + power-domains = <&sysc R8A77961_PD_A3VC>; > + resets = <&cpg 626>; > + > + renesas,fcp = <&fcpvb0>; > + }; > + > fcpvb0: fcp@fe96f000 { > compatible = "renesas,fcpv"; > reg = <0 0xfe96f000 0 0x200>; > @@ -2020,6 +2031,17 @@ fcpvb0: fcp@fe96f000 { > resets = <&cpg 607>; > }; > > + vspi0: vsp@fe9a { > + compatible = "renesas,vsp2"; > + reg = <0 0xfe9a 0 0x8000>; > + interrupts = ; > + clocks = <&cpg CPG_MOD 631>; > + power-domains = <&sysc R8A77961_PD_A3VC>; > + resets = <&cpg 631>; > + > + renesas,fcp = <&fcpvi0>; > + }; > + > fcpvi0: fcp@fe9af000 { > compatible = "renesas,fcpv"; > reg = <0 0xfe9af000 0 0x200>; > @@ -2029,6 +2051,17 @@ fcpvi0: fcp@fe9af000 { > iommus = <&ipmmu_vc0 19>; > }; > > + vspd0: vsp@fea2 { > + compatible = "renesas,vsp2"; > + reg = <0 0xfea2 0 0x5000>; > + interrupts = ; > + clocks = <&cpg CPG_MOD 623>; > + power-domains = <&sysc R8A77961_PD_ALWAYS_ON>; > + resets = <&cpg 623>; > + > + renesas,fcp = <&fcpvd0>; > + }; > + > fcpvd0: fcp@fea27000 { > compatible = "renesas,fcpv"; > reg = <0 0xfea27000 0 0x200>; > @@ -2038,6 +2071,17 @@ fcpvd0: fcp@fea27000 { > iommus = <&ipmmu_vi0 8>; > }; > > + vspd1: vsp@fea28000 { > + compatible = "renesas,vsp2"; > + reg = <0 0xfea28000 0 0x5000>; > + interrupts = ; > + clocks = <&cpg CPG_MOD 622>; > + power-domains = <&sysc R8A77961_PD_ALWAYS_ON>; > + resets = <&cpg 622>; > + > + renesas,fcp = <&fcpvd1>; > + }; > + > fcpvd1: fcp@fea2f000 { > compatible = "renesas,fcpv"; > reg = <0 0xfea2f000 0 0x200>; > @@ -2047,6 +2091,17 @@ fcpvd1: fcp@fea2f000 { > iommus = <&ipmmu_vi0 9>; > }; > > + vspd2: vsp@fea3 { > + compatible = "renesas,vsp2"; > + reg = <0 0xfea3 0 0x5000>; > + interrupts = ; > + clocks = <&cpg CPG_MOD 621>; > + power-domains = <&sysc R8A77961_PD_ALWAYS_ON>; > + resets = <&cpg 621>; > + > + renesas,fcp = <&fcpvd2>; > + }; > + > fcpvd2: fcp@fea37000 { > compatible = "renesas,fcpv"; > reg = <0 0xfea37000 0 0x200>; -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 05/10] arm64: dts: renesas: r8a77961: Add FCP device nodes
Hi Morimoto-san, Thank you for the patch. On Tue, Sep 08, 2020 at 09:34:50AM +0900, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > This patch adds FCP device nodes for R-Car M3-W+ (r8a77961) SoC. > This patch was tested on R-Car M3-W+ Salvator-XS board. > > Signed-off-by: Kuninori Morimoto Reviewed-by: Laurent Pinchart > --- > arch/arm64/boot/dts/renesas/r8a77961.dtsi | 52 +++ > 1 file changed, 52 insertions(+) > > diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi > b/arch/arm64/boot/dts/renesas/r8a77961.dtsi > index 0abfea0b27be..fe0db11b9cb9 100644 > --- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi > +++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi > @@ -2004,6 +2004,58 @@ pciec1: pcie@ee80 { > status = "disabled"; > }; > > + fcpf0: fcp@fe95 { > + compatible = "renesas,fcpf"; > + reg = <0 0xfe95 0 0x200>; > + clocks = <&cpg CPG_MOD 615>; > + power-domains = <&sysc R8A77961_PD_A3VC>; > + resets = <&cpg 615>; > + }; > + > + fcpvb0: fcp@fe96f000 { > + compatible = "renesas,fcpv"; > + reg = <0 0xfe96f000 0 0x200>; > + clocks = <&cpg CPG_MOD 607>; > + power-domains = <&sysc R8A77961_PD_A3VC>; > + resets = <&cpg 607>; > + }; > + > + fcpvi0: fcp@fe9af000 { > + compatible = "renesas,fcpv"; > + reg = <0 0xfe9af000 0 0x200>; > + clocks = <&cpg CPG_MOD 611>; > + power-domains = <&sysc R8A77961_PD_A3VC>; > + resets = <&cpg 611>; > + iommus = <&ipmmu_vc0 19>; > + }; > + > + fcpvd0: fcp@fea27000 { > + compatible = "renesas,fcpv"; > + reg = <0 0xfea27000 0 0x200>; > + clocks = <&cpg CPG_MOD 603>; > + power-domains = <&sysc R8A77961_PD_ALWAYS_ON>; > + resets = <&cpg 603>; > + iommus = <&ipmmu_vi0 8>; > + }; > + > + fcpvd1: fcp@fea2f000 { > + compatible = "renesas,fcpv"; > + reg = <0 0xfea2f000 0 0x200>; > + clocks = <&cpg CPG_MOD 602>; > + power-domains = <&sysc R8A77961_PD_ALWAYS_ON>; > + resets = <&cpg 602>; > + iommus = <&ipmmu_vi0 9>; > + }; > + > + fcpvd2: fcp@fea37000 { > + compatible = "renesas,fcpv"; > + reg = <0 0xfea37000 0 0x200>; > + clocks = <&cpg CPG_MOD 601>; > + power-domains = <&sysc R8A77961_PD_ALWAYS_ON>; > + resets = <&cpg 601>; > + iommus = <&ipmmu_vi0 10>; > + }; > + > csi20: csi2@fea8 { > reg = <0 0xfea8 0 0x1>; > /* placeholder */ -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 04/10] drm: rcar-du: Add r8a77961 support
Hi Morimoto-san, Thank you for the patch. On Tue, Sep 08, 2020 at 09:34:32AM +0900, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > This patch adds R-Car M3-W+ (R8A77961) support which has > compatible to R-Car M3-W (R8A77960). Maybe "... is compatible with the ..." ? > Signed-off-by: Kuninori Morimoto Reviewed-by: Laurent Pinchart > --- > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c > b/drivers/gpu/drm/rcar-du/rcar_du_drv.c > index f53b0ec71085..64533cbdbef0 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c > @@ -458,6 +458,7 @@ static const struct of_device_id rcar_du_of_table[] = { > { .compatible = "renesas,du-r8a7794", .data = &rcar_du_r8a7794_info }, > { .compatible = "renesas,du-r8a7795", .data = &rcar_du_r8a7795_info }, > { .compatible = "renesas,du-r8a7796", .data = &rcar_du_r8a7796_info }, > + { .compatible = "renesas,du-r8a77961", .data = &rcar_du_r8a7796_info }, > { .compatible = "renesas,du-r8a77965", .data = &rcar_du_r8a77965_info }, > { .compatible = "renesas,du-r8a77970", .data = &rcar_du_r8a77970_info }, > { .compatible = "renesas,du-r8a77980", .data = &rcar_du_r8a77970_info }, -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 03/10] dt-bindings: display: renesas: dw-hdmi: Add R8A77961 support
Hi Morimoto-san, Thank you for the patch. On Tue, Sep 08, 2020 at 09:34:17AM +0900, Kuninori Morimoto wrote: > From: Kuninori Morimoto > > This patch adds R-Car M3-W+ (R8A77961) SoC bindings. > > Signed-off-by: Kuninori Morimoto > Reviewed-by: Geert Uytterhoeven Reviewed-by: Laurent Pinchart > --- > .../devicetree/bindings/display/bridge/renesas,dw-hdmi.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt > b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt > index e6526ab485d0..2086f4514911 100644 > --- a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt > @@ -16,6 +16,7 @@ Required properties: >- "renesas,r8a774b1-hdmi" for R8A774B1 (RZ/G2N) compatible HDMI TX >- "renesas,r8a7795-hdmi" for R8A7795 (R-Car H3) compatible HDMI TX >- "renesas,r8a7796-hdmi" for R8A7796 (R-Car M3-W) compatible HDMI TX > + - "renesas,r8a77961-hdmi" for R8A77961 (R-Car M3-W+) compatible HDMI TX >- "renesas,r8a77965-hdmi" for R8A77965 (R-Car M3-N) compatible HDMI TX >- "renesas,rcar-gen3-hdmi" for the generic R-Car Gen3 and RZ/G2 compatible >HDMI TX -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/10] dt-bindings: display: renesas: dw-hdmi: tidyup example compatible.
Hi Morimoto-san, Thank you for the patch. On Tue, Sep 08, 2020 at 09:34:11AM +0900, Kuninori Morimoto wrote: > From: Kuninori Morimoto > > required is "renesas,r8a7795-hdmi", instead of "renesas,r8a7795-dw-hdmi" > > Signed-off-by: Kuninori Morimoto Reviewed-by: Laurent Pinchart > --- > .../devicetree/bindings/display/bridge/renesas,dw-hdmi.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt > b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt > index 819f3e31013c..e6526ab485d0 100644 > --- a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt > @@ -42,7 +42,7 @@ Optional properties: > Example: > > hdmi0: hdmi@fead { > - compatible = "renesas,r8a7795-dw-hdmi"; > + compatible = "renesas,r8a7795-hdmi"; > reg = <0 0xfead 0 0x1>; > interrupts = <0 389 IRQ_TYPE_LEVEL_HIGH>; > clocks = <&cpg CPG_CORE R8A7795_CLK_S0D4>, <&cpg CPG_MOD 729>; -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/10] dt-bindings: display: renesas: du: Document the r8a77961 bindings
Hi Morimoto-san, Thank you for the patch. On Tue, Sep 08, 2020 at 09:34:04AM +0900, Kuninori Morimoto wrote: > From: Kuninori Morimoto > > Document the R-Car M3-W+ (R8A77961) SoC in the R-Car DU bindings. > > Signed-off-by: Kuninori Morimoto Reviewed-by: Laurent Pinchart > --- > Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt > b/Documentation/devicetree/bindings/display/renesas,du.txt > index 51cd4d162770..317c9dd2d57c 100644 > --- a/Documentation/devicetree/bindings/display/renesas,du.txt > +++ b/Documentation/devicetree/bindings/display/renesas,du.txt > @@ -18,6 +18,7 @@ Required Properties: > - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU > - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU > - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU > +- "renesas,du-r8a77961" for R8A77961 (R-Car M3-W+) compatible DU > - "renesas,du-r8a77965" for R8A77965 (R-Car M3-N) compatible DU > - "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU > - "renesas,du-r8a77980" for R8A77980 (R-Car V3H) compatible DU > @@ -83,6 +84,7 @@ corresponding to each DU output. > R8A7794 (R-Car E2) DPAD 0 DPAD 1 - - > R8A7795 (R-Car H3) DPAD 0 HDMI 0 HDMI 1 LVDS 0 > R8A7796 (R-Car M3-W) DPAD 0 HDMI 0 LVDS 0 - > + R8A77961 (R-Car M3-W+) DPAD 0 HDMI 0 LVDS 0 - > R8A77965 (R-Car M3-N) DPAD 0 HDMI 0 LVDS 0 - > R8A77970 (R-Car V3M) DPAD 0 LVDS 0 - - > R8A77980 (R-Car V3H) DPAD 0 LVDS 0 - - -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/13] drm/qxl: move bind/unbind/destroy to the driver function table.
On Tue, Sep 08, 2020 at 06:46:20AM +1000, Dave Airlie wrote: > From: Dave Airlie > > Acked-by: Christian König > Signed-off-by: Dave Airlie Reviewed-by: Gerd Hoffmann ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/1] drm: allow limiting the scatter list size.
On Mon, Sep 07, 2020 at 03:53:02PM +0200, Daniel Vetter wrote: > On Mon, Sep 7, 2020 at 1:24 PM Gerd Hoffmann wrote: > > > > Add drm_device argument to drm_prime_pages_to_sg(), so we can > > call dma_max_mapping_size() to figure the segment size limit > > and call into __sg_alloc_table_from_pages() with the correct > > limit. > > > > This fixes virtio-gpu with sev. Possibly it'll fix other bugs > > too given that drm seems to totaly ignore segment size limits > > so far ... > > > > v2: place max_segment in drm driver not gem object. > > v3: move max_segment next to the other gem fields. > > v4: just use dma_max_mapping_size(). > > > > Signed-off-by: Gerd Hoffmann > > Uh, are you sure this works in all cases for virtio? Sure, I've tested it ;) > The comments I've found suggest very much not ... Or is that all very > old stuff only that no one cares about anymore? I think these days it is possible to override dma_ops per device, which in turn allows virtio to deal with the quirks without the rest of the kernel knowing about these details. I also think virtio-gpu can drop the virtio_has_dma_quirk() checks, just use the dma api path unconditionally and depend on virtio core having setup dma_ops in a way that it JustWorks[tm]. I'll look into that next. take care, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Experimental DMA-BUF Device Heaps
Hi Daniel, On Tue, Sep 01, 2020 at 09:32:22AM +0200, Daniel Vetter wrote: > On Sun, Aug 16, 2020 at 02:22:46PM -0300, Ezequiel Garcia wrote: > > This heap is basically a wrapper around DMA-API dma_alloc_attrs, > > which will allocate memory suitable for the given device. > > > > The implementation is mostly a port of the Contiguous Videobuf2 > > memory allocator (see videobuf2/videobuf2-dma-contig.c) > > over to the DMA-BUF Heap interface. > > > > The intention of this allocator is to provide applications > > with a more system-agnostic API: the only thing the application > > needs to know is which device to get the buffer for. > > > > Whether the buffer is backed by CMA, IOMMU or a DMA Pool > > is unknown to the application. > > > > I'm not really expecting this patch to be correct or even > > a good idea, but just submitting it to start a discussion on DMA-BUF > > heap discovery and negotiation. > > > > Given Plumbers is just a couple weeks from now, I've submitted > > a BoF proposal to discuss this, as perhaps it would make > > sense to discuss this live? > > > > Not-signed-off-by: Ezequiel Garcia > > I think on the uapi/constraint solving side there's been already tons of > discussions while I enjoyed vacations, so different concern from me > entirely on the implementation side: > > In the past the only thing we had in upstream was subsystem/driver > specific allocators, and dma-buf for sharing. With dma-buf heaps we kinda > get a central allocator, which duplicates large chunks of of all these > allocators. And since it's a central allocator by design, the reason for > having per-subsystem allocators is kinda gone. > > I think there's two approaches here: > - we convert e.g. drm allocator helpers to internally use the right heap > implementation. We however don't always have a need for a dmabuf, as not all buffers are meant to be shared (and we often can't tell beforehand, at allocation time, if a given buffer will be shared or not). While the overhead of allocating a dmabuf should be file, assigning a file descriptor to each buffer would be prohibitely expensive. We would need to decouple the dma heaps from file descriptors. I think that's doable, but it changes the philosophy of dma heaps and needs careful consideration. In particular, one may wonder what that would bring us, compared to the DMA mapping API for instance. > That would also give us some fairly direct way to expose > these constraints in sysfs so a userspace allocator knows which dma-buf > heap to pick for shared stuff. sysfs won't work I'm afraid, as constraints may depend on the format for instace. We need subsystem-specific APIs to expose constraints. > - we require that any heap is just a different uapi for an existing driver > allocator, e.g. by having a dma-buf wrapper for all gem drivers. > > Otherwise I think what we end up with is a pile of dma-buf heaps for > android's blob gpu driver world, and not used anywhere else. Not something > even remotely interesting for upstream :-) > > tldr; I'd like to see how dma-buf heaps closely integrate with all the > existing buffer management code we have. Both kernel (and throuhg some > allocator library effort) in userspace. > > > --- > > drivers/dma-buf/heaps/Kconfig | 9 + > > drivers/dma-buf/heaps/Makefile | 1 + > > drivers/dma-buf/heaps/device_heap.c | 268 > > include/linux/device.h | 5 + > > include/linux/dma-heap.h| 6 + > > 5 files changed, 289 insertions(+) > > create mode 100644 drivers/dma-buf/heaps/device_heap.c > > > > diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig > > index a5eef06c4226..2bb3604184bd 100644 > > --- a/drivers/dma-buf/heaps/Kconfig > > +++ b/drivers/dma-buf/heaps/Kconfig > > @@ -12,3 +12,12 @@ config DMABUF_HEAPS_CMA > > Choose this option to enable dma-buf CMA heap. This heap is backed > > by the Contiguous Memory Allocator (CMA). If your system has these > > regions, you should say Y here. > > + > > +config DMABUF_HEAPS_DEVICES > > + bool "DMA-BUF Device DMA Heap (Experimental)" > > + depends on DMABUF_HEAPS > > + help > > + Choose this option to enable dma-buf per-device heap. This heap is > > backed > > + by the DMA-API and it's an Experimental feature, meant mostly for > > testing > > + and experimentation. > > + Just say N here. > > diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile > > index 6e54cdec3da0..c691d85b3044 100644 > > --- a/drivers/dma-buf/heaps/Makefile > > +++ b/drivers/dma-buf/heaps/Makefile > > @@ -2,3 +2,4 @@ > > obj-y += heap-helpers.o > > obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o > > obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o > > +obj-$(CONFIG_DMABUF_HEAPS_DEVICES) += device_heap.o > > diff --git a/drivers/dma-buf/heaps/device_heap.c > > b/drivers/dma-buf/heaps/device_heap.
Re: [PATCH 1/2] drm/radeon: Add sclk frequency as hwmon sensor
On 9/1/20 2:03 AM, Alex Deucher wrote: > On Sun, Aug 30, 2020 at 3:25 AM Sandeep Raghuraman > wrote: >> >> This patch series adds support for reporting sclk and vddc values for Radeon >> GPUs, where supported. > > This commit message should be specific to this particular patch rather > than the series. You could probably expose mclk as well. > > Alex > > I only have a Radeon iGPU, and don't have a Radeon dGPU to test with, so that's why I didn't wire up mclk. Yours sincerely, Sandeep ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: build warning after merge of the drm-misc tree
Hi all, After merging the drm-misc tree, today's linux-next build (x86_64 allmodconfig) produced this warning: WARNING: modpost: missing MODULE_LICENSE() in drivers/gpu/drm/panel/panel-samsung-s6e63m0.o Introduced by commit b7b23e447687 ("drm/panel: s6e63m0: Break out SPI transport") -- Cheers, Stephen Rothwell pgp_p73uDR_Lw.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: manual merge of the drm-intel tree with Linus' tree
Hi all, Today's linux-next merge of the drm-intel tree got a conflict in: drivers/gpu/drm/i915/display/intel_panel.c between commit: f8bd54d21904 ("drm/i915: panel: Use atomic PWM API for devs with an external PWM controller") from Linus' tree and commit: 6b51e7d23aa8 ("drm/i915: panel: Honor the VBT PWM frequency for devs with an external PWM controller") from the drm-intel tree. I fixed it up (I just used the latter) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell pgpkWWWzny3sd.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 203905] amdgpu:actual_brightness has unreal/wrong value
https://bugzilla.kernel.org/show_bug.cgi?id=203905 --- Comment #17 from John Shand (jshand2...@gmail.com) --- Created attachment 292419 --> https://bugzilla.kernel.org/attachment.cgi?id=292419&action=edit Journalctl 8-9-2020 -- 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 203905] amdgpu:actual_brightness has unreal/wrong value
https://bugzilla.kernel.org/show_bug.cgi?id=203905 --- Comment #16 from John Shand (jshand2...@gmail.com) --- Created attachment 292417 --> https://bugzilla.kernel.org/attachment.cgi?id=292417&action=edit Dmesg 8-9-2020 -- 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 203905] amdgpu:actual_brightness has unreal/wrong value
https://bugzilla.kernel.org/show_bug.cgi?id=203905 John Shand (jshand2...@gmail.com) changed: What|Removed |Added CC||jshand2...@gmail.com --- Comment #15 from John Shand (jshand2...@gmail.com) --- i have had this problem as well. was recently working well with kernel 5.8.7. i then install ucode-amd and then grub-mkconfig -o /boot/grub/grub.cfg to set the changes. grub automatically made the new code image work with initramfs and then, backlight went back to about 20% or 255. would this have anything to do with amd's ucode image?? -- 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
[PATCH v2 08/10] arm64: dts: renesas: r8a77961: Add HDMI device nodes
From: Kuninori Morimoto This patch adds HDMI device nodes for R-Car M3-W+ (r8a77961) SoC. This patch was tested on R-Car M3-W+ Salvator-XS board. Signed-off-by: Kuninori Morimoto --- arch/arm64/boot/dts/renesas/r8a77961.dtsi | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi b/arch/arm64/boot/dts/renesas/r8a77961.dtsi index c7fabd9e875b..7f21491f6436 100644 --- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi @@ -2145,14 +2145,23 @@ port@1 { }; hdmi0: hdmi@fead { + compatible = "renesas,r8a77961-hdmi", "renesas,rcar-gen3-hdmi"; reg = <0 0xfead 0 0x1>; - /* placeholder */ + interrupts = ; + clocks = <&cpg CPG_MOD 729>, <&cpg CPG_CORE R8A77961_CLK_HDMI>; + clock-names = "iahb", "isfr"; + power-domains = <&sysc R8A77961_PD_ALWAYS_ON>; + resets = <&cpg 729>; + status = "disabled"; ports { #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; + dw_hdmi0_in: endpoint { + remote-endpoint = <&du_out_hdmi0>; + }; }; port@1 { reg = <1>; @@ -2191,6 +2200,7 @@ du_out_rgb: endpoint { port@1 { reg = <1>; du_out_hdmi0: endpoint { + remote-endpoint = <&dw_hdmi0_in>; }; }; port@2 { -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 10/10] arm64: dts: renesas: r8a77961-salvator-xs: add HDMI Sound support
From: Kuninori Morimoto This patch enables HDMI Sound on R-Car M3-W+ Salvator-XS board. This reverts commit b997613fad58a03588f0f64a3d86db6c5bd76dd2. Signed-off-by: Kuninori Morimoto --- .../boot/dts/renesas/r8a77961-salvator-xs.dts | 29 +++ 1 file changed, 29 insertions(+) diff --git a/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts b/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts index ca21a702db54..1e7603365106 100644 --- a/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts +++ b/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts @@ -51,9 +51,38 @@ rcar_dw_hdmi0_out: endpoint { remote-endpoint = <&hdmi0_con>; }; }; + port@2 { + reg = <2>; + dw_hdmi0_snd_in: endpoint { + remote-endpoint = <&rsnd_endpoint1>; + }; + }; }; }; &hdmi0_con { remote-endpoint = <&rcar_dw_hdmi0_out>; }; + +&rcar_sound { + ports { + /* rsnd_port0 is on salvator-common */ + rsnd_port1: port@1 { + reg = <1>; + rsnd_endpoint1: endpoint { + remote-endpoint = <&dw_hdmi0_snd_in>; + + dai-format = "i2s"; + bitclock-master = <&rsnd_endpoint1>; + frame-master = <&rsnd_endpoint1>; + + playback = <&ssi2>; + }; + }; + }; +}; + +&sound_card { + dais = <&rsnd_port0 /* ak4613 */ + &rsnd_port1>; /* HDMI0 */ +}; -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 09/10] arm64: dts: renesas: r8a77961-salvator-xs: add HDMI Display support
From: Kuninori Morimoto This patch enables HDMI Display on R-Car M3-W+ Salvator-XS board. Signed-off-by: Kuninori Morimoto --- .../boot/dts/renesas/r8a77961-salvator-xs.dts | 28 +++ 1 file changed, 28 insertions(+) diff --git a/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts b/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts index 2ffc7e31dd58..ca21a702db54 100644 --- a/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts +++ b/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts @@ -29,3 +29,31 @@ memory@6 { reg = <0x6 0x 0x1 0x>; }; }; + +&du { + clocks = <&cpg CPG_MOD 724>, +<&cpg CPG_MOD 723>, +<&cpg CPG_MOD 722>, +<&versaclock6 1>, +<&x21_clk>, +<&versaclock6 2>; + clock-names = "du.0", "du.1", "du.2", + "dclkin.0", "dclkin.1", "dclkin.2"; +}; + +&hdmi0 { + status = "okay"; + + ports { + port@1 { + reg = <1>; + rcar_dw_hdmi0_out: endpoint { + remote-endpoint = <&hdmi0_con>; + }; + }; + }; +}; + +&hdmi0_con { + remote-endpoint = <&rcar_dw_hdmi0_out>; +}; -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 07/10] arm64: dts: renesas: r8a77961: Add DU device nodes
From: Kuninori Morimoto This patch adds DU device nodes for R-Car M3-W+ (r8a77961) SoC. This patch was tested on R-Car M3-W+ Salvator-XS board. Signed-off-by: Kuninori Morimoto --- arch/arm64/boot/dts/renesas/r8a77961.dtsi | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi b/arch/arm64/boot/dts/renesas/r8a77961.dtsi index 423808b6cd58..c7fabd9e875b 100644 --- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi @@ -2165,8 +2165,19 @@ port@2 { }; du: display@feb0 { + compatible = "renesas,du-r8a77961"; reg = <0 0xfeb0 0 0x7>; - /* placeholder */ + interrupts = , +, +; + clocks = <&cpg CPG_MOD 724>, <&cpg CPG_MOD 723>, +<&cpg CPG_MOD 722>; + clock-names = "du.0", "du.1", "du.2"; + resets = <&cpg 724>, <&cpg 722>; + reset-names = "du.0", "du.2"; + + renesas,vsps = <&vspd0 0>, <&vspd1 0>, <&vspd2 0>; + status = "disabled"; ports { #address-cells = <1>; -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 04/10] drm: rcar-du: Add r8a77961 support
From: Kuninori Morimoto This patch adds R-Car M3-W+ (R8A77961) support which has compatible to R-Car M3-W (R8A77960). Signed-off-by: Kuninori Morimoto --- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index f53b0ec71085..64533cbdbef0 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c @@ -458,6 +458,7 @@ static const struct of_device_id rcar_du_of_table[] = { { .compatible = "renesas,du-r8a7794", .data = &rcar_du_r8a7794_info }, { .compatible = "renesas,du-r8a7795", .data = &rcar_du_r8a7795_info }, { .compatible = "renesas,du-r8a7796", .data = &rcar_du_r8a7796_info }, + { .compatible = "renesas,du-r8a77961", .data = &rcar_du_r8a7796_info }, { .compatible = "renesas,du-r8a77965", .data = &rcar_du_r8a77965_info }, { .compatible = "renesas,du-r8a77970", .data = &rcar_du_r8a77970_info }, { .compatible = "renesas,du-r8a77980", .data = &rcar_du_r8a77970_info }, -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 06/10] arm64: dts: renesas: r8a77961: Add VSP device nodes
From: Kuninori Morimoto This patch adds VSP device nodes for R-Car M3-W+ (r8a77961) SoC. This patch was tested on R-Car M3-W+ Salvator-XS board. Signed-off-by: Kuninori Morimoto --- arch/arm64/boot/dts/renesas/r8a77961.dtsi | 55 +++ 1 file changed, 55 insertions(+) diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi b/arch/arm64/boot/dts/renesas/r8a77961.dtsi index fe0db11b9cb9..423808b6cd58 100644 --- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi @@ -2012,6 +2012,17 @@ fcpf0: fcp@fe95 { resets = <&cpg 615>; }; + vspb: vsp@fe96 { + compatible = "renesas,vsp2"; + reg = <0 0xfe96 0 0x8000>; + interrupts = ; + clocks = <&cpg CPG_MOD 626>; + power-domains = <&sysc R8A77961_PD_A3VC>; + resets = <&cpg 626>; + + renesas,fcp = <&fcpvb0>; + }; + fcpvb0: fcp@fe96f000 { compatible = "renesas,fcpv"; reg = <0 0xfe96f000 0 0x200>; @@ -2020,6 +2031,17 @@ fcpvb0: fcp@fe96f000 { resets = <&cpg 607>; }; + vspi0: vsp@fe9a { + compatible = "renesas,vsp2"; + reg = <0 0xfe9a 0 0x8000>; + interrupts = ; + clocks = <&cpg CPG_MOD 631>; + power-domains = <&sysc R8A77961_PD_A3VC>; + resets = <&cpg 631>; + + renesas,fcp = <&fcpvi0>; + }; + fcpvi0: fcp@fe9af000 { compatible = "renesas,fcpv"; reg = <0 0xfe9af000 0 0x200>; @@ -2029,6 +2051,17 @@ fcpvi0: fcp@fe9af000 { iommus = <&ipmmu_vc0 19>; }; + vspd0: vsp@fea2 { + compatible = "renesas,vsp2"; + reg = <0 0xfea2 0 0x5000>; + interrupts = ; + clocks = <&cpg CPG_MOD 623>; + power-domains = <&sysc R8A77961_PD_ALWAYS_ON>; + resets = <&cpg 623>; + + renesas,fcp = <&fcpvd0>; + }; + fcpvd0: fcp@fea27000 { compatible = "renesas,fcpv"; reg = <0 0xfea27000 0 0x200>; @@ -2038,6 +2071,17 @@ fcpvd0: fcp@fea27000 { iommus = <&ipmmu_vi0 8>; }; + vspd1: vsp@fea28000 { + compatible = "renesas,vsp2"; + reg = <0 0xfea28000 0 0x5000>; + interrupts = ; + clocks = <&cpg CPG_MOD 622>; + power-domains = <&sysc R8A77961_PD_ALWAYS_ON>; + resets = <&cpg 622>; + + renesas,fcp = <&fcpvd1>; + }; + fcpvd1: fcp@fea2f000 { compatible = "renesas,fcpv"; reg = <0 0xfea2f000 0 0x200>; @@ -2047,6 +2091,17 @@ fcpvd1: fcp@fea2f000 { iommus = <&ipmmu_vi0 9>; }; + vspd2: vsp@fea3 { + compatible = "renesas,vsp2"; + reg = <0 0xfea3 0 0x5000>; + interrupts = ; + clocks = <&cpg CPG_MOD 621>; + power-domains = <&sysc R8A77961_PD_ALWAYS_ON>; + resets = <&cpg 621>; + + renesas,fcp = <&fcpvd2>; + }; + fcpvd2: fcp@fea37000 { compatible = "renesas,fcpv"; reg = <0 0xfea37000 0 0x200>; -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 01/10] dt-bindings: display: renesas: du: Document the r8a77961 bindings
From: Kuninori Morimoto Document the R-Car M3-W+ (R8A77961) SoC in the R-Car DU bindings. Signed-off-by: Kuninori Morimoto --- Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt b/Documentation/devicetree/bindings/display/renesas,du.txt index 51cd4d162770..317c9dd2d57c 100644 --- a/Documentation/devicetree/bindings/display/renesas,du.txt +++ b/Documentation/devicetree/bindings/display/renesas,du.txt @@ -18,6 +18,7 @@ Required Properties: - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU +- "renesas,du-r8a77961" for R8A77961 (R-Car M3-W+) compatible DU - "renesas,du-r8a77965" for R8A77965 (R-Car M3-N) compatible DU - "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU - "renesas,du-r8a77980" for R8A77980 (R-Car V3H) compatible DU @@ -83,6 +84,7 @@ corresponding to each DU output. R8A7794 (R-Car E2) DPAD 0 DPAD 1 - - R8A7795 (R-Car H3) DPAD 0 HDMI 0 HDMI 1 LVDS 0 R8A7796 (R-Car M3-W) DPAD 0 HDMI 0 LVDS 0 - + R8A77961 (R-Car M3-W+) DPAD 0 HDMI 0 LVDS 0 - R8A77965 (R-Car M3-N) DPAD 0 HDMI 0 LVDS 0 - R8A77970 (R-Car V3M) DPAD 0 LVDS 0 - - R8A77980 (R-Car V3H) DPAD 0 LVDS 0 - - -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 03/10] dt-bindings: display: renesas: dw-hdmi: Add R8A77961 support
From: Kuninori Morimoto This patch adds R-Car M3-W+ (R8A77961) SoC bindings. Signed-off-by: Kuninori Morimoto Reviewed-by: Geert Uytterhoeven --- .../devicetree/bindings/display/bridge/renesas,dw-hdmi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt index e6526ab485d0..2086f4514911 100644 --- a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt @@ -16,6 +16,7 @@ Required properties: - "renesas,r8a774b1-hdmi" for R8A774B1 (RZ/G2N) compatible HDMI TX - "renesas,r8a7795-hdmi" for R8A7795 (R-Car H3) compatible HDMI TX - "renesas,r8a7796-hdmi" for R8A7796 (R-Car M3-W) compatible HDMI TX + - "renesas,r8a77961-hdmi" for R8A77961 (R-Car M3-W+) compatible HDMI TX - "renesas,r8a77965-hdmi" for R8A77965 (R-Car M3-N) compatible HDMI TX - "renesas,rcar-gen3-hdmi" for the generic R-Car Gen3 and RZ/G2 compatible HDMI TX -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 02/10] dt-bindings: display: renesas: dw-hdmi: tidyup example compatible.
From: Kuninori Morimoto required is "renesas,r8a7795-hdmi", instead of "renesas,r8a7795-dw-hdmi" Signed-off-by: Kuninori Morimoto --- .../devicetree/bindings/display/bridge/renesas,dw-hdmi.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt index 819f3e31013c..e6526ab485d0 100644 --- a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt @@ -42,7 +42,7 @@ Optional properties: Example: hdmi0: hdmi@fead { - compatible = "renesas,r8a7795-dw-hdmi"; + compatible = "renesas,r8a7795-hdmi"; reg = <0 0xfead 0 0x1>; interrupts = <0 389 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cpg CPG_CORE R8A7795_CLK_S0D4>, <&cpg CPG_MOD 729>; -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/10] arm64: dts: renesas: r8a77961: Add FCP device nodes
From: Kuninori Morimoto This patch adds FCP device nodes for R-Car M3-W+ (r8a77961) SoC. This patch was tested on R-Car M3-W+ Salvator-XS board. Signed-off-by: Kuninori Morimoto --- arch/arm64/boot/dts/renesas/r8a77961.dtsi | 52 +++ 1 file changed, 52 insertions(+) diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi b/arch/arm64/boot/dts/renesas/r8a77961.dtsi index 0abfea0b27be..fe0db11b9cb9 100644 --- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi @@ -2004,6 +2004,58 @@ pciec1: pcie@ee80 { status = "disabled"; }; + fcpf0: fcp@fe95 { + compatible = "renesas,fcpf"; + reg = <0 0xfe95 0 0x200>; + clocks = <&cpg CPG_MOD 615>; + power-domains = <&sysc R8A77961_PD_A3VC>; + resets = <&cpg 615>; + }; + + fcpvb0: fcp@fe96f000 { + compatible = "renesas,fcpv"; + reg = <0 0xfe96f000 0 0x200>; + clocks = <&cpg CPG_MOD 607>; + power-domains = <&sysc R8A77961_PD_A3VC>; + resets = <&cpg 607>; + }; + + fcpvi0: fcp@fe9af000 { + compatible = "renesas,fcpv"; + reg = <0 0xfe9af000 0 0x200>; + clocks = <&cpg CPG_MOD 611>; + power-domains = <&sysc R8A77961_PD_A3VC>; + resets = <&cpg 611>; + iommus = <&ipmmu_vc0 19>; + }; + + fcpvd0: fcp@fea27000 { + compatible = "renesas,fcpv"; + reg = <0 0xfea27000 0 0x200>; + clocks = <&cpg CPG_MOD 603>; + power-domains = <&sysc R8A77961_PD_ALWAYS_ON>; + resets = <&cpg 603>; + iommus = <&ipmmu_vi0 8>; + }; + + fcpvd1: fcp@fea2f000 { + compatible = "renesas,fcpv"; + reg = <0 0xfea2f000 0 0x200>; + clocks = <&cpg CPG_MOD 602>; + power-domains = <&sysc R8A77961_PD_ALWAYS_ON>; + resets = <&cpg 602>; + iommus = <&ipmmu_vi0 9>; + }; + + fcpvd2: fcp@fea37000 { + compatible = "renesas,fcpv"; + reg = <0 0xfea37000 0 0x200>; + clocks = <&cpg CPG_MOD 601>; + power-domains = <&sysc R8A77961_PD_ALWAYS_ON>; + resets = <&cpg 601>; + iommus = <&ipmmu_vi0 10>; + }; + csi20: csi2@fea8 { reg = <0 0xfea8 0 0x1>; /* placeholder */ -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 00/10] arm64: renesas: enable HDMI Display/Sound on R-Car M3-W+ Salvator-XS
Hi Geert, Laurent These are v2 of HDMI Display/Sound support for R8A77961. These are tested on R-Car M3-W+ Salvator-XS board. v1 -> v2 - "is test" to "was tested" at git-log - add M3-W+ port entry to DU table (= [01/10]) - add dw-hdmi tidyup new patch (= [02/10]) - add Geert's Reviewed-by (= [03/10]) - address sorting for VSP node (= [06/10]) Kuninori Morimoto (10): dt-bindings: display: renesas: du: Document the r8a77961 bindings dt-bindings: display: renesas: dw-hdmi: tidyup example compatible. dt-bindings: display: renesas: dw-hdmi: Add R8A77961 support drm: rcar-du: Add r8a77961 support arm64: dts: renesas: r8a77961: Add FCP device nodes arm64: dts: renesas: r8a77961: Add VSP device nodes arm64: dts: renesas: r8a77961: Add DU device nodes arm64: dts: renesas: r8a77961: Add HDMI device nodes arm64: dts: renesas: r8a77961-salvator-xs: add HDMI Display support arm64: dts: renesas: r8a77961-salvator-xs: add HDMI Sound support .../display/bridge/renesas,dw-hdmi.txt| 3 +- .../bindings/display/renesas,du.txt | 2 + .../boot/dts/renesas/r8a77961-salvator-xs.dts | 57 arch/arm64/boot/dts/renesas/r8a77961.dtsi | 132 +- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 + 5 files changed, 192 insertions(+), 3 deletions(-) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/msm/dpu: clean up some impossibilities
Hi Rob, I love your patch! Perhaps something to improve: [auto build test WARNING on drm-tip/drm-tip] [also build test WARNING on linus/master v5.9-rc4 next-20200903] [cannot apply to drm-intel/for-linux-next tegra-drm/drm/tegra/for-next drm/drm-next drm-exynos/exynos-drm-next] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Rob-Clark/drm-msm-dpu-move-vblank-events-to-complete_commit/20200908-020331 base: git://anongit.freedesktop.org/drm/drm-tip drm-tip config: arm-defconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c: In function '_dpu_crtc_setup_cp_blocks': drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:455:23: warning: variable 'lm' set but not used [-Wunused-but-set-variable] 455 | struct dpu_hw_mixer *lm; | ^~ drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c: In function 'dpu_crtc_atomic_begin': >> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:497:21: warning: variable 'dev' set >> but not used [-Wunused-but-set-variable] 497 | struct drm_device *dev; | ^~~ drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:494:19: warning: variable 'dpu_crtc' set but not used [-Wunused-but-set-variable] 494 | struct dpu_crtc *dpu_crtc; | ^~~~ # https://github.com/0day-ci/linux/commit/b151bdc57ce4c96820a99dd0c5cec106f227444c git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Rob-Clark/drm-msm-dpu-move-vblank-events-to-complete_commit/20200908-020331 git checkout b151bdc57ce4c96820a99dd0c5cec106f227444c vim +/dev +497 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 4259ff7ae509ed Kalyan Thota 2020-03-24 490 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 491 static void dpu_crtc_atomic_begin(struct drm_crtc *crtc, 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 492struct drm_crtc_state *old_state) 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 493 { 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 494struct dpu_crtc *dpu_crtc; 9222cdd27e823c Jeykumar Sankaran 2018-09-05 495struct dpu_crtc_state *cstate; 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 496struct drm_encoder *encoder; 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 @497struct drm_device *dev; 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 498 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 499if (!crtc->state->enable) { 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 500 DPU_DEBUG("crtc%d -> enable %d, skip atomic_begin\n", 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 501 crtc->base.id, crtc->state->enable); 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 502return; 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 503} 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 504 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 505DPU_DEBUG("crtc%d\n", crtc->base.id); 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 506 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 507dpu_crtc = to_dpu_crtc(crtc); 9222cdd27e823c Jeykumar Sankaran 2018-09-05 508cstate = to_dpu_crtc_state(crtc->state); 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 509dev = crtc->dev; 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 510 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 511 _dpu_crtc_setup_lm_bounds(crtc, crtc->state); 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 512 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 513/* encoder will trigger pending mask now */ 4b8c6279593aa6 Sean Paul 2018-11-16 514 drm_for_each_encoder_mask(encoder, crtc->dev, crtc->state->encoder_mask) 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 515 dpu_encoder_trigger_kickoff_pending(encoder); 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 516 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 517/* 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 518 * If no mixers have been allocated in dpu_crtc_atomic_check(), 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 519 * it means we are trying to flush a CRTC whose state is disabled: 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 520 * nothing else needs to be done. 25fdd5933e4c0f Jeykumar Sankaran 2018-06-27 521 */ 9222cdd27e823c Jeyk
Re: [PATCH] drm: mxsfb: check framebuffer pitch
Am 2020-09-07 16:03, schrieb Stefan Agner: The lcdif IP does not support a framebuffer pitch (stride) other than the CRTC width. This may be true for some SOCs, but not for all of them. I used to have this working flawlessly on the imx8mq like so: http://projects.dpa.li/git/?p=linux.git;a=commitdiff;h=5a7baa8ba7f1f30139cfcd0f9e13b3773f3605ff That in turn was based on some patches which weren't fully upstreamed yet at the time, and was inspired by another patch I had seen here: https://lore.kernel.org/linux-arm-kernel/20190722174853.GA31795@bogus/t/#m7ac218480eb1d827ff65f82f2e03a5a84c94a5e0 I had almost forgotten about this already, since I currently don't need it anymore, and I was waiting for the patches it was based on to get taken up. But if anyone else needs this, feel free to do whatever you want with it. I could also take another look at this and submit some patches if this is preferred, but I'm quiet busy right now, so that could take a while. In the meantime and for other SOCs, I think checking for an unsupported pitch is still needed regardless. I'm not against this patch, this is just a note to make sure it's known that and how this can be done on the imx8mq. Regards, Daniel Abrecht ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH v5 1/2] drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps
On Sat, 5 Sep 2020 at 06:28, Lyude Paul wrote: > > Not entirely sure why this never came up when I originally tested this > (maybe some BIOSes already have this setup?) but the ->caps_init vfunc > appears to cause the display engine to throw an exception on driver > init, at least on my ThinkPad P72: > > nouveau :01:00.0: disp: chid 0 mthd 008c data 508c 102b > > This is magic nvidia speak for "You need to have the DMA notifier offset > programmed before you can call NV507D_GET_CAPABILITIES." So, let's fix > this by doing that, and also perform an update afterwards to prevent > racing with the GPU when reading capabilities. > > v2: > * Don't just program the DMA notifier offset, make sure to actually > perform an update > v3: > * Don't call UPDATE() > * Actually read the correct notifier fields, as apparently the > CAPABILITIES_DONE field lives in a different location than the main > NV_DISP_CORE_NOTIFIER_1 field. As well, 907d+ use a different > CAPABILITIES_DONE field then pre-907d cards. > v4: > * Don't forget to check the return value of core507d_read_caps() > v5: > * Get rid of NV50_DISP_CAPS_NTFY[14], use NV50_DISP_CORE_NTFY > * Disable notifier after calling GetCapabilities() > > Signed-off-by: Lyude Paul > Fixes: 4a2cb4181b07 ("drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP > interlacing support") > Cc: # v5.8+ Thanks Lyude, looks good, and merged! Ben. > --- > drivers/gpu/drm/nouveau/dispnv50/core.h | 2 + > drivers/gpu/drm/nouveau/dispnv50/core507d.c | 41 ++- > drivers/gpu/drm/nouveau/dispnv50/core907d.c | 36 +++- > drivers/gpu/drm/nouveau/dispnv50/core917d.c | 2 +- > .../drm/nouveau/include/nvhw/class/cl507d.h | 5 ++- > .../drm/nouveau/include/nvhw/class/cl907d.h | 4 ++ > 6 files changed, 85 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/dispnv50/core.h > b/drivers/gpu/drm/nouveau/dispnv50/core.h > index 498622c0c670d..f75088186fba3 100644 > --- a/drivers/gpu/drm/nouveau/dispnv50/core.h > +++ b/drivers/gpu/drm/nouveau/dispnv50/core.h > @@ -44,6 +44,7 @@ int core507d_new_(const struct nv50_core_func *, struct > nouveau_drm *, s32, > struct nv50_core **); > int core507d_init(struct nv50_core *); > void core507d_ntfy_init(struct nouveau_bo *, u32); > +int core507d_read_caps(struct nv50_disp *disp); > int core507d_caps_init(struct nouveau_drm *, struct nv50_disp *); > int core507d_ntfy_wait_done(struct nouveau_bo *, u32, struct nvif_device *); > int core507d_update(struct nv50_core *, u32 *, bool); > @@ -55,6 +56,7 @@ extern const struct nv50_outp_func pior507d; > int core827d_new(struct nouveau_drm *, s32, struct nv50_core **); > > int core907d_new(struct nouveau_drm *, s32, struct nv50_core **); > +int core907d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp); > extern const struct nv50_outp_func dac907d; > extern const struct nv50_outp_func sor907d; > > diff --git a/drivers/gpu/drm/nouveau/dispnv50/core507d.c > b/drivers/gpu/drm/nouveau/dispnv50/core507d.c > index 248edf69e1683..e6f16a7750f07 100644 > --- a/drivers/gpu/drm/nouveau/dispnv50/core507d.c > +++ b/drivers/gpu/drm/nouveau/dispnv50/core507d.c > @@ -78,18 +78,55 @@ core507d_ntfy_init(struct nouveau_bo *bo, u32 offset) > } > > int > -core507d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp) > +core507d_read_caps(struct nv50_disp *disp) > { > struct nvif_push *push = disp->core->chan.push; > int ret; > > - if ((ret = PUSH_WAIT(push, 2))) > + ret = PUSH_WAIT(push, 6); > + if (ret) > return ret; > > + PUSH_MTHD(push, NV507D, SET_NOTIFIER_CONTROL, > + NVDEF(NV507D, SET_NOTIFIER_CONTROL, MODE, WRITE) | > + NVVAL(NV507D, SET_NOTIFIER_CONTROL, OFFSET, > NV50_DISP_CORE_NTFY >> 2) | > + NVDEF(NV507D, SET_NOTIFIER_CONTROL, NOTIFY, ENABLE)); > + > PUSH_MTHD(push, NV507D, GET_CAPABILITIES, 0x); > + > + PUSH_MTHD(push, NV507D, SET_NOTIFIER_CONTROL, > + NVDEF(NV507D, SET_NOTIFIER_CONTROL, NOTIFY, DISABLE)); > + > return PUSH_KICK(push); > } > > +int > +core507d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp) > +{ > + struct nv50_core *core = disp->core; > + struct nouveau_bo *bo = disp->sync; > + s64 time; > + int ret; > + > + NVBO_WR32(bo, NV50_DISP_CORE_NTFY, NV_DISP_CORE_NOTIFIER_1, > CAPABILITIES_1, > +NVDEF(NV_DISP_CORE_NOTIFIER_1, > CAPABILITIES_1, DONE, FALSE)); > + > + ret = core507d_read_caps(disp); > + if (ret < 0) > + return ret; > + > + time = nvif_msec(core->chan.base.device, 2000ULL, > +if (NVBO_TD32(bo, NV50_DISP_CORE_NTFY, > + NV_DISP_CORE_NOTIFIER_1, > CAPABILITIES_1, DONE, ==, TRUE)) > +break; > +
Re: [PATCH 5/9] arm64: dts: renesas: r8a77961: Add VSP device nodes
Hi Kieran > > From: Kuninori Morimoto > > > > This patch adds VSP device nodes for R-Car M3-W+ (r8a77961) SoC. > > This patch is test on R-Car M3-W+ Salvator-XS board. > > > > Signed-off-by: Kuninori Morimoto > > --- (snip) > Do we keep the items grouped by the first occurrence? or sort the nodes > based on address? (snip) > Is there a set policy? The order is same as r8a77960.dtsi, not my policy. Will sort in v2 Thank you for your help !! Best regards --- Kuninori Morimoto ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] dt-bindings: display: renesas: du: Document the r8a77961 bindings
Hi Geert > > --- a/Documentation/devicetree/bindings/display/renesas,du.txt > > +++ b/Documentation/devicetree/bindings/display/renesas,du.txt > > @@ -18,6 +18,7 @@ Required Properties: > > - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU > > - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU > > - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU > > +- "renesas,du-r8a77961" for R8A77961 (R-Car M3-W+) compatible DU > > - "renesas,du-r8a77965" for R8A77965 (R-Car M3-N) compatible DU > > - "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU > > - "renesas,du-r8a77980" for R8A77980 (R-Car V3H) compatible DU > > Looks good to me, but please also add an entry to the table below > describing the port mappings. Oops indeed. Thank you for pointing it, I didn't noticed about it. Will do in v2 Thank you for your help !! Best regards --- Kuninori Morimoto ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mediatek: add missing put_device() call in mtk_ddp_comp_init()
Hi Yu Kuai: Yu Kuai 於 2020年9月5日 週六 下午4:31寫道: > > if of_find_device_by_node() succeed, mtk_ddp_comp_init() doesn't have > a corresponding put_device(). Thus add put_device() to fix the exception > handling for this function implementation. > This patch looks good to me, but I find another thing related to this. mtk_ddp_comp_init() is called in a loop in mtk_drm_probe(), when this component init fail, I think we should uninitialize previous successive init component and put their device. Would you like to make this patch more complete? Regards, Chun-Kuang. > Fixes: d0afe37f5209 ("drm/mediatek: support CMDQ interface in ddp component") > Signed-off-by: Yu Kuai > --- > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c > index 57c88de9a329..526648885b97 100644 > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c > @@ -496,6 +496,7 @@ int mtk_ddp_comp_init(struct device *dev, struct > device_node *node, > #if IS_REACHABLE(CONFIG_MTK_CMDQ) > if (of_address_to_resource(node, 0, &res) != 0) { > dev_err(dev, "Missing reg in %s node\n", node->full_name); > + put_device(&larb_pdev->dev); > return -EINVAL; > } > comp->regs_pa = res.start; > -- > 2.25.4 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/13] ttm tt refactor repost of part 1
On Tue, 8 Sep 2020 at 06:46, Dave Airlie wrote: > > Most of these have r-b or acks already, patch 1 I may have > posted before but found in my tree, so reposting it, and patch > 5 for radeon I think were what needed re-review. R-b for ttm and nouveau changes, A-b for the other drivers. Ben. > > I'd like to land these, and I'll revisit the remainder of this > series. > > Dave. > > ___ > 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
[PATCH 07/13] drm/vmwgfx: move to driver binding functions
From: Dave Airlie Acked-by: Christian König Signed-off-by: Dave Airlie --- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c index a76a7f542dd8..6757be98be14 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c @@ -668,12 +668,6 @@ static void vmw_ttm_unpopulate(struct ttm_bo_device *bdev, ttm_pool_unpopulate(ttm); } -static struct ttm_backend_func vmw_ttm_func = { - .bind = vmw_ttm_bind, - .unbind = vmw_ttm_unbind, - .destroy = vmw_ttm_destroy, -}; - static struct ttm_tt *vmw_ttm_tt_create(struct ttm_buffer_object *bo, uint32_t page_flags) { @@ -684,7 +678,6 @@ static struct ttm_tt *vmw_ttm_tt_create(struct ttm_buffer_object *bo, if (!vmw_be) return NULL; - vmw_be->dma_ttm.ttm.func = &vmw_ttm_func; vmw_be->dev_priv = container_of(bo->bdev, struct vmw_private, bdev); vmw_be->mob = NULL; @@ -770,6 +763,9 @@ struct ttm_bo_driver vmw_bo_driver = { .ttm_tt_create = &vmw_ttm_tt_create, .ttm_tt_populate = &vmw_ttm_populate, .ttm_tt_unpopulate = &vmw_ttm_unpopulate, + .ttm_tt_bind = &vmw_ttm_bind, + .ttm_tt_unbind = &vmw_ttm_unbind, + .ttm_tt_destroy = &vmw_ttm_destroy, .eviction_valuable = ttm_bo_eviction_valuable, .evict_flags = vmw_evict_flags, .move = NULL, -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/13] drm/amdgpu/ttm: move to driver backend binding funcs
From: Dave Airlie Reviewed-by: Christian König Signed-off-by: Dave Airlie --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index 9592505563bf..f07e7121bcc5 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -1255,12 +1255,6 @@ static void amdgpu_ttm_backend_destroy(struct ttm_bo_device *bdev, kfree(gtt); } -static struct ttm_backend_func amdgpu_backend_func = { - .bind = &amdgpu_ttm_backend_bind, - .unbind = &amdgpu_ttm_backend_unbind, - .destroy = &amdgpu_ttm_backend_destroy, -}; - /** * amdgpu_ttm_tt_create - Create a ttm_tt object for a given BO * @@ -1277,7 +1271,6 @@ static struct ttm_tt *amdgpu_ttm_tt_create(struct ttm_buffer_object *bo, if (gtt == NULL) { return NULL; } - gtt->ttm.ttm.func = &amdgpu_backend_func; gtt->gobj = &bo->base; /* allocate space for the uninitialized page entries */ @@ -1679,6 +1672,9 @@ static struct ttm_bo_driver amdgpu_bo_driver = { .ttm_tt_create = &amdgpu_ttm_tt_create, .ttm_tt_populate = &amdgpu_ttm_tt_populate, .ttm_tt_unpopulate = &amdgpu_ttm_tt_unpopulate, + .ttm_tt_bind = &amdgpu_ttm_backend_bind, + .ttm_tt_unbind = &amdgpu_ttm_backend_unbind, + .ttm_tt_destroy = &amdgpu_ttm_backend_destroy, .eviction_valuable = amdgpu_ttm_bo_eviction_valuable, .evict_flags = &amdgpu_evict_flags, .move = &amdgpu_bo_move, -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 13/13] drm/ttm: drop the tt backend function paths.
From: Dave Airlie These are now driver side. Reviewed-by: Christian König Signed-off-by: Dave Airlie --- drivers/gpu/drm/ttm/ttm_tt.c | 15 +++--- include/drm/ttm/ttm_tt.h | 39 2 files changed, 3 insertions(+), 51 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c index 73c97dcfa512..67aa7fe39432 100644 --- a/drivers/gpu/drm/ttm/ttm_tt.c +++ b/drivers/gpu/drm/ttm/ttm_tt.c @@ -222,10 +222,7 @@ void ttm_tt_destroy(struct ttm_bo_device *bdev, struct ttm_tt *ttm) fput(ttm->swap_storage); ttm->swap_storage = NULL; - if (bdev->driver->ttm_tt_destroy) - bdev->driver->ttm_tt_destroy(bdev, ttm); - else - ttm->func->destroy(bdev, ttm); + bdev->driver->ttm_tt_destroy(bdev, ttm); } static void ttm_tt_init_fields(struct ttm_tt *ttm, @@ -313,10 +310,7 @@ EXPORT_SYMBOL(ttm_dma_tt_fini); void ttm_tt_unbind(struct ttm_bo_device *bdev, struct ttm_tt *ttm) { if (ttm->state == tt_bound) { - if (bdev->driver->ttm_tt_unbind) - bdev->driver->ttm_tt_unbind(bdev, ttm); - else - ttm->func->unbind(bdev, ttm); + bdev->driver->ttm_tt_unbind(bdev, ttm); ttm->state = tt_unbound; } } @@ -337,10 +331,7 @@ int ttm_tt_bind(struct ttm_bo_device *bdev, if (ret) return ret; - if (bdev->driver->ttm_tt_bind) - ret = bdev->driver->ttm_tt_bind(bdev, ttm, bo_mem); - else - ret = ttm->func->bind(bdev, ttm, bo_mem); + ret = bdev->driver->ttm_tt_bind(bdev, ttm, bo_mem); if (unlikely(ret != 0)) return ret; diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h index bdc8aadf3246..146544ba1c10 100644 --- a/include/drm/ttm/ttm_tt.h +++ b/include/drm/ttm/ttm_tt.h @@ -48,47 +48,9 @@ enum ttm_caching_state { tt_cached }; -struct ttm_backend_func { - /** -* struct ttm_backend_func member bind -* -* @ttm: Pointer to a struct ttm_tt. -* @bo_mem: Pointer to a struct ttm_resource describing the -* memory type and location for binding. -* -* Bind the backend pages into the aperture in the location -* indicated by @bo_mem. This function should be able to handle -* differences between aperture and system page sizes. -*/ - int (*bind) (struct ttm_bo_device *bdev, struct ttm_tt *ttm, struct ttm_resource *bo_mem); - - /** -* struct ttm_backend_func member unbind -* -* @ttm: Pointer to a struct ttm_tt. -* -* Unbind previously bound backend pages. This function should be -* able to handle differences between aperture and system page sizes. -*/ - void (*unbind) (struct ttm_bo_device *bdev, struct ttm_tt *ttm); - - /** -* struct ttm_backend_func member destroy -* -* @ttm: Pointer to a struct ttm_tt. -* -* Destroy the backend. This will be call back from ttm_tt_destroy so -* don't call ttm_tt_destroy from the callback or infinite loop. -*/ - void (*destroy) (struct ttm_bo_device *bdev, struct ttm_tt *ttm); -}; - /** * struct ttm_tt * - * @func: Pointer to a struct ttm_backend_func that describes - * the backend methods. - * pointer. * @pages: Array of pages backing the data. * @num_pages: Number of pages in the page array. * @bdev: Pointer to the current struct ttm_bo_device. @@ -102,7 +64,6 @@ struct ttm_backend_func { * memory. */ struct ttm_tt { - struct ttm_backend_func *func; struct page **pages; uint32_t page_flags; unsigned long num_pages; -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/13] drm/ttm/agp: drop back end bindings from agp
From: Dave Airlie These aren't used anymore. Reviewed-by: Christian König Signed-off-by: Dave Airlie --- drivers/gpu/drm/ttm/ttm_agp_backend.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c b/drivers/gpu/drm/ttm/ttm_agp_backend.c index fbf98cd1a3e5..8072fb7c5bc8 100644 --- a/drivers/gpu/drm/ttm/ttm_agp_backend.c +++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c @@ -112,12 +112,6 @@ void ttm_agp_destroy(struct ttm_bo_device *bdev, } EXPORT_SYMBOL(ttm_agp_destroy); -static struct ttm_backend_func ttm_agp_func = { - .bind = ttm_agp_bind, - .unbind = ttm_agp_unbind, - .destroy = ttm_agp_destroy, -}; - struct ttm_tt *ttm_agp_tt_create(struct ttm_buffer_object *bo, struct agp_bridge_data *bridge, uint32_t page_flags) @@ -130,7 +124,6 @@ struct ttm_tt *ttm_agp_tt_create(struct ttm_buffer_object *bo, agp_be->mem = NULL; agp_be->bridge = bridge; - agp_be->ttm.func = &ttm_agp_func; if (ttm_tt_init(&agp_be->ttm, bo, page_flags)) { kfree(agp_be); -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/13] drm/gem_vram/ttm: move to driver backend destroy function.
From: Dave Airlie Acked-by: Thomas Zimmermann Acked-by: Christian König Signed-off-by: Dave Airlie --- drivers/gpu/drm/drm_gem_vram_helper.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c b/drivers/gpu/drm/drm_gem_vram_helper.c index 788557bc5c01..51f9fa4c178c 100644 --- a/drivers/gpu/drm/drm_gem_vram_helper.c +++ b/drivers/gpu/drm/drm_gem_vram_helper.c @@ -967,16 +967,12 @@ static const struct drm_gem_object_funcs drm_gem_vram_object_funcs = { * TTM TT */ -static void backend_func_destroy(struct ttm_bo_device *bdev, struct ttm_tt *tt) +static void bo_driver_ttm_tt_destroy(struct ttm_bo_device *bdev, struct ttm_tt *tt) { ttm_tt_fini(tt); kfree(tt); } -static struct ttm_backend_func backend_func = { - .destroy = backend_func_destroy -}; - /* * TTM BO device */ @@ -991,8 +987,6 @@ static struct ttm_tt *bo_driver_ttm_tt_create(struct ttm_buffer_object *bo, if (!tt) return NULL; - tt->func = &backend_func; - ret = ttm_tt_init(tt, bo, page_flags); if (ret < 0) goto err_ttm_tt_init; @@ -1055,6 +1049,7 @@ static int bo_driver_io_mem_reserve(struct ttm_bo_device *bdev, static struct ttm_bo_driver bo_driver = { .ttm_tt_create = bo_driver_ttm_tt_create, + .ttm_tt_destroy = bo_driver_ttm_tt_destroy, .eviction_valuable = ttm_bo_eviction_valuable, .evict_flags = bo_driver_evict_flags, .move_notify = bo_driver_move_notify, -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/13] drm/ttm: get rid of agp specific populate/unpopulate paths.
From: Dave Airlie Reviewed-by: Christian König Signed-off-by: Dave Airlie --- drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++-- drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++-- drivers/gpu/drm/ttm/ttm_agp_backend.c | 17 - include/drm/ttm/ttm_tt.h | 2 -- 4 files changed, 4 insertions(+), 23 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index f6cac6eec687..cf3275b557ee 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -1268,7 +1268,7 @@ nouveau_ttm_tt_populate(struct ttm_bo_device *bdev, #if IS_ENABLED(CONFIG_AGP) if (drm->agp.bridge) { - return ttm_agp_tt_populate(bdev, ttm, ctx); + return ttm_pool_populate(ttm, ctx); } #endif @@ -1297,7 +1297,7 @@ nouveau_ttm_tt_unpopulate(struct ttm_bo_device *bdev, #if IS_ENABLED(CONFIG_AGP) if (drm->agp.bridge) { - ttm_agp_tt_unpopulate(bdev, ttm); + ttm_pool_unpopulate(ttm); return; } #endif diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index ff6821356ea7..1996796be7fe 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -627,7 +627,7 @@ static int radeon_ttm_tt_populate(struct ttm_bo_device *bdev, #if IS_ENABLED(CONFIG_AGP) if (rdev->flags & RADEON_IS_AGP) { - return ttm_agp_tt_populate(bdev, ttm, ctx); + return ttm_pool_populate(ttm, ctx); } #endif @@ -657,7 +657,7 @@ static void radeon_ttm_tt_unpopulate(struct ttm_bo_device *bdev, struct ttm_tt * #if IS_ENABLED(CONFIG_AGP) if (rdev->flags & RADEON_IS_AGP) { - ttm_agp_tt_unpopulate(bdev, ttm); + ttm_pool_unpopulate(ttm); return; } #endif diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c b/drivers/gpu/drm/ttm/ttm_agp_backend.c index 8072fb7c5bc8..3d0a5e9f4c5f 100644 --- a/drivers/gpu/drm/ttm/ttm_agp_backend.c +++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c @@ -133,20 +133,3 @@ struct ttm_tt *ttm_agp_tt_create(struct ttm_buffer_object *bo, return &agp_be->ttm; } EXPORT_SYMBOL(ttm_agp_tt_create); - -int ttm_agp_tt_populate(struct ttm_bo_device *bdev, - struct ttm_tt *ttm, struct ttm_operation_ctx *ctx) -{ - if (ttm->state != tt_unpopulated) - return 0; - - return ttm_pool_populate(ttm, ctx); -} -EXPORT_SYMBOL(ttm_agp_tt_populate); - -void ttm_agp_tt_unpopulate(struct ttm_bo_device *bdev, - struct ttm_tt *ttm) -{ - ttm_pool_unpopulate(ttm); -} -EXPORT_SYMBOL(ttm_agp_tt_unpopulate); diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h index 5a34f1640865..591d4927d501 100644 --- a/include/drm/ttm/ttm_tt.h +++ b/include/drm/ttm/ttm_tt.h @@ -264,8 +264,6 @@ void ttm_tt_unpopulate(struct ttm_bo_device *bdev, struct ttm_tt *ttm); struct ttm_tt *ttm_agp_tt_create(struct ttm_buffer_object *bo, struct agp_bridge_data *bridge, uint32_t page_flags); -int ttm_agp_tt_populate(struct ttm_bo_device *bdev, struct ttm_tt *ttm, struct ttm_operation_ctx *ctx); -void ttm_agp_tt_unpopulate(struct ttm_bo_device *bdev, struct ttm_tt *ttm); int ttm_agp_bind(struct ttm_bo_device *bdev, struct ttm_tt *ttm, struct ttm_resource *bo_mem); void ttm_agp_unbind(struct ttm_bo_device *bdev, -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/13] drm/ttm: introduce ttm_bo_move_null
From: Dave Airlie This pattern is cut-n-pasted across 4 drivers, switch it to a WARN_ON instead, as BUG_ON is considered a bad idea usually. Signed-off-by: Dave Airlie --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 24 +++- drivers/gpu/drm/nouveau/nouveau_bo.c| 4 +--- drivers/gpu/drm/qxl/qxl_ttm.c | 12 +--- drivers/gpu/drm/radeon/radeon_ttm.c | 14 ++ include/drm/ttm/ttm_bo_driver.h | 17 + 5 files changed, 24 insertions(+), 47 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index ca568e25c41c..9592505563bf 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -174,24 +174,6 @@ static int amdgpu_verify_access(struct ttm_buffer_object *bo, struct file *filp) filp->private_data); } -/** - * amdgpu_move_null - Register memory for a buffer object - * - * @bo: The bo to assign the memory to - * @new_mem: The memory to be assigned. - * - * Assign the memory from new_mem to the memory of the buffer object bo. - */ -static void amdgpu_move_null(struct ttm_buffer_object *bo, -struct ttm_resource *new_mem) -{ - struct ttm_resource *old_mem = &bo->mem; - - BUG_ON(old_mem->mm_node != NULL); - *old_mem = *new_mem; - new_mem->mm_node = NULL; -} - /** * amdgpu_mm_node_addr - Compute the GPU relative offset of a GTT buffer. * @@ -676,7 +658,7 @@ static int amdgpu_bo_move(struct ttm_buffer_object *bo, bool evict, adev = amdgpu_ttm_adev(bo->bdev); if (old_mem->mem_type == TTM_PL_SYSTEM && bo->ttm == NULL) { - amdgpu_move_null(bo, new_mem); + ttm_bo_move_null(bo, new_mem); return 0; } if ((old_mem->mem_type == TTM_PL_TT && @@ -684,7 +666,7 @@ static int amdgpu_bo_move(struct ttm_buffer_object *bo, bool evict, (old_mem->mem_type == TTM_PL_SYSTEM && new_mem->mem_type == TTM_PL_TT)) { /* bind is enough */ - amdgpu_move_null(bo, new_mem); + ttm_bo_move_null(bo, new_mem); return 0; } if (old_mem->mem_type == AMDGPU_PL_GDS || @@ -694,7 +676,7 @@ static int amdgpu_bo_move(struct ttm_buffer_object *bo, bool evict, new_mem->mem_type == AMDGPU_PL_GWS || new_mem->mem_type == AMDGPU_PL_OA) { /* Nothing to save here */ - amdgpu_move_null(bo, new_mem); + ttm_bo_move_null(bo, new_mem); return 0; } diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index 41aa7ac31bd5..091f80fbbd7c 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -993,9 +993,7 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool evict, /* Fake bo copy. */ if (old_reg->mem_type == TTM_PL_SYSTEM && !bo->ttm) { - BUG_ON(bo->mem.mm_node != NULL); - bo->mem = *new_reg; - new_reg->mm_node = NULL; + ttm_bo_move_null(bo, new_reg); goto out; } diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c index 3ab460339145..c3530c6e46bd 100644 --- a/drivers/gpu/drm/qxl/qxl_ttm.c +++ b/drivers/gpu/drm/qxl/qxl_ttm.c @@ -159,16 +159,6 @@ static struct ttm_tt *qxl_ttm_tt_create(struct ttm_buffer_object *bo, return >t->ttm; } -static void qxl_move_null(struct ttm_buffer_object *bo, -struct ttm_resource *new_mem) -{ - struct ttm_resource *old_mem = &bo->mem; - - BUG_ON(old_mem->mm_node != NULL); - *old_mem = *new_mem; - new_mem->mm_node = NULL; -} - static int qxl_bo_move(struct ttm_buffer_object *bo, bool evict, struct ttm_operation_ctx *ctx, struct ttm_resource *new_mem) @@ -181,7 +171,7 @@ static int qxl_bo_move(struct ttm_buffer_object *bo, bool evict, return ret; if (old_mem->mem_type == TTM_PL_SYSTEM && bo->ttm == NULL) { - qxl_move_null(bo, new_mem); + ttm_bo_move_null(bo, new_mem); return 0; } return ttm_bo_move_memcpy(bo, ctx, new_mem); diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index a8d6ca88c6e3..1d3e8bb69f8e 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -148,16 +148,6 @@ static int radeon_verify_access(struct ttm_buffer_object *bo, struct file *filp) filp->private_data); } -static void radeon_move_null(struct ttm_buffer_object *bo, -struct ttm_resource *new_mem) -{ - struct ttm_resource *old_mem = &bo->mem; - - BUG_ON(old_mem->mm_node != NULL);
[PATCH 06/13] drm/nouveau/ttm: use driver bind/unbind/destroy functions.
From: Dave Airlie Acked-by: Christian König Reviewed-by: Ben Skeggs Signed-off-by: Dave Airlie --- drivers/gpu/drm/nouveau/nouveau_bo.c| 44 drivers/gpu/drm/nouveau/nouveau_sgdma.c | 54 ++--- drivers/gpu/drm/nouveau/nouveau_ttm.h | 3 ++ 3 files changed, 59 insertions(+), 42 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index 091f80fbbd7c..f6cac6eec687 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -668,6 +668,33 @@ nouveau_ttm_tt_create(struct ttm_buffer_object *bo, uint32_t page_flags) return nouveau_sgdma_create_ttm(bo, page_flags); } +static int +nouveau_ttm_tt_bind(struct ttm_bo_device *bdev, struct ttm_tt *ttm, + struct ttm_resource *reg) +{ +#if IS_ENABLED(CONFIG_AGP) + struct nouveau_drm *drm = nouveau_bdev(bdev); + + if (drm->agp.bridge) + return ttm_agp_bind(bdev, ttm, reg); +#endif + return nouveau_sgdma_bind(bdev, ttm, reg); +} + +static void +nouveau_ttm_tt_unbind(struct ttm_bo_device *bdev, struct ttm_tt *ttm) +{ +#if IS_ENABLED(CONFIG_AGP) + struct nouveau_drm *drm = nouveau_bdev(bdev); + + if (drm->agp.bridge) { + ttm_agp_unbind(bdev, ttm); + return; + } +#endif + nouveau_sgdma_unbind(bdev, ttm); +} + static void nouveau_bo_evict_flags(struct ttm_buffer_object *bo, struct ttm_placement *pl) { @@ -1285,6 +1312,20 @@ nouveau_ttm_tt_unpopulate(struct ttm_bo_device *bdev, ttm_unmap_and_unpopulate_pages(dev, ttm_dma); } +static void +nouveau_ttm_tt_destroy(struct ttm_bo_device *bdev, + struct ttm_tt *ttm) +{ +#if IS_ENABLED(CONFIG_AGP) + struct nouveau_drm *drm = nouveau_bdev(bdev); + if (drm->agp.bridge) { + ttm_agp_destroy(bdev, ttm); + return; + } +#endif + nouveau_sgdma_destroy(bdev, ttm); +} + void nouveau_bo_fence(struct nouveau_bo *nvbo, struct nouveau_fence *fence, bool exclusive) { @@ -1300,6 +1341,9 @@ struct ttm_bo_driver nouveau_bo_driver = { .ttm_tt_create = &nouveau_ttm_tt_create, .ttm_tt_populate = &nouveau_ttm_tt_populate, .ttm_tt_unpopulate = &nouveau_ttm_tt_unpopulate, + .ttm_tt_bind = &nouveau_ttm_tt_bind, + .ttm_tt_unbind = &nouveau_ttm_tt_unbind, + .ttm_tt_destroy = &nouveau_ttm_tt_destroy, .eviction_valuable = ttm_bo_eviction_valuable, .evict_flags = nouveau_bo_evict_flags, .move_notify = nouveau_bo_move_ntfy, diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c b/drivers/gpu/drm/nouveau/nouveau_sgdma.c index 6000c650b105..05e542254e1f 100644 --- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c +++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c @@ -14,7 +14,7 @@ struct nouveau_sgdma_be { struct nouveau_mem *mem; }; -static void +void nouveau_sgdma_destroy(struct ttm_bo_device *bdev, struct ttm_tt *ttm) { struct nouveau_sgdma_be *nvbe = (struct nouveau_sgdma_be *)ttm; @@ -25,10 +25,11 @@ nouveau_sgdma_destroy(struct ttm_bo_device *bdev, struct ttm_tt *ttm) } } -static int -nv04_sgdma_bind(struct ttm_bo_device *bdev, struct ttm_tt *ttm, struct ttm_resource *reg) +int +nouveau_sgdma_bind(struct ttm_bo_device *bdev, struct ttm_tt *ttm, struct ttm_resource *reg) { struct nouveau_sgdma_be *nvbe = (struct nouveau_sgdma_be *)ttm; + struct nouveau_drm *drm = nouveau_bdev(bdev); struct nouveau_mem *mem = nouveau_mem(reg); int ret; @@ -36,65 +37,34 @@ nv04_sgdma_bind(struct ttm_bo_device *bdev, struct ttm_tt *ttm, struct ttm_resou if (ret) return ret; - ret = nouveau_mem_map(mem, &mem->cli->vmm.vmm, &mem->vma[0]); - if (ret) { - nouveau_mem_fini(mem); - return ret; + if (drm->client.device.info.family < NV_DEVICE_INFO_V0_TESLA) { + ret = nouveau_mem_map(mem, &mem->cli->vmm.vmm, &mem->vma[0]); + if (ret) { + nouveau_mem_fini(mem); + return ret; + } } nvbe->mem = mem; return 0; } -static void -nv04_sgdma_unbind(struct ttm_bo_device *bdev, struct ttm_tt *ttm) +void +nouveau_sgdma_unbind(struct ttm_bo_device *bdev, struct ttm_tt *ttm) { struct nouveau_sgdma_be *nvbe = (struct nouveau_sgdma_be *)ttm; nouveau_mem_fini(nvbe->mem); } -static struct ttm_backend_func nv04_sgdma_backend = { - .bind = nv04_sgdma_bind, - .unbind = nv04_sgdma_unbind, - .destroy= nouveau_sgdma_destroy -}; - -static int -nv50_sgdma_bind(struct ttm_bo_device *bdev, struct ttm_tt *ttm, struct ttm_resource *reg) -{ - struct nouveau_sgdma_be *nvbe = (struct nouveau_sgdma_be *)ttm; - struct nouveau_mem *mem = nouveau_mem(reg); - int ret; - - ret
[PATCH 12/13] drm/ttm/agp: remove bdev from agp helpers
From: Dave Airlie Since the agp bind/unbind/destroy are now getting called from drivers rather than via the func table, drop the bdev parameter. Reviewed-by: Christian König Signed-off-by: Dave Airlie --- drivers/gpu/drm/nouveau/nouveau_bo.c | 6 +++--- drivers/gpu/drm/radeon/radeon_ttm.c | 6 +++--- drivers/gpu/drm/ttm/ttm_agp_backend.c | 11 --- include/drm/ttm/ttm_tt.h | 9 +++-- 4 files changed, 13 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index cf3275b557ee..f61c4424ee2b 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -676,7 +676,7 @@ nouveau_ttm_tt_bind(struct ttm_bo_device *bdev, struct ttm_tt *ttm, struct nouveau_drm *drm = nouveau_bdev(bdev); if (drm->agp.bridge) - return ttm_agp_bind(bdev, ttm, reg); + return ttm_agp_bind(ttm, reg); #endif return nouveau_sgdma_bind(bdev, ttm, reg); } @@ -688,7 +688,7 @@ nouveau_ttm_tt_unbind(struct ttm_bo_device *bdev, struct ttm_tt *ttm) struct nouveau_drm *drm = nouveau_bdev(bdev); if (drm->agp.bridge) { - ttm_agp_unbind(bdev, ttm); + ttm_agp_unbind(ttm); return; } #endif @@ -1319,7 +1319,7 @@ nouveau_ttm_tt_destroy(struct ttm_bo_device *bdev, #if IS_ENABLED(CONFIG_AGP) struct nouveau_drm *drm = nouveau_bdev(bdev); if (drm->agp.bridge) { - ttm_agp_destroy(bdev, ttm); + ttm_agp_destroy(ttm); return; } #endif diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 1996796be7fe..e5f5c47f623e 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -695,7 +695,7 @@ static int radeon_ttm_tt_bind(struct ttm_bo_device *bdev, #if IS_ENABLED(CONFIG_AGP) if (rdev->flags & RADEON_IS_AGP) - return ttm_agp_bind(bdev, ttm, bo_mem); + return ttm_agp_bind(ttm, bo_mem); #endif return radeon_ttm_backend_bind(bdev, ttm, bo_mem); @@ -708,7 +708,7 @@ static void radeon_ttm_tt_unbind(struct ttm_bo_device *bdev, struct radeon_device *rdev = radeon_get_rdev(bdev); if (rdev->flags & RADEON_IS_AGP) { - ttm_agp_unbind(bdev, ttm); + ttm_agp_unbind(ttm); return; } #endif @@ -722,7 +722,7 @@ static void radeon_ttm_tt_destroy(struct ttm_bo_device *bdev, struct radeon_device *rdev = radeon_get_rdev(bdev); if (rdev->flags & RADEON_IS_AGP) { - ttm_agp_destroy(bdev, ttm); + ttm_agp_destroy(ttm); return; } #endif diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c b/drivers/gpu/drm/ttm/ttm_agp_backend.c index 3d0a5e9f4c5f..7b36fdaab766 100644 --- a/drivers/gpu/drm/ttm/ttm_agp_backend.c +++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c @@ -48,8 +48,7 @@ struct ttm_agp_backend { struct agp_bridge_data *bridge; }; -int ttm_agp_bind(struct ttm_bo_device *bdev, -struct ttm_tt *ttm, struct ttm_resource *bo_mem) +int ttm_agp_bind(struct ttm_tt *ttm, struct ttm_resource *bo_mem) { struct ttm_agp_backend *agp_be = container_of(ttm, struct ttm_agp_backend, ttm); struct page *dummy_read_page = ttm_bo_glob.dummy_read_page; @@ -84,8 +83,7 @@ int ttm_agp_bind(struct ttm_bo_device *bdev, } EXPORT_SYMBOL(ttm_agp_bind); -void ttm_agp_unbind(struct ttm_bo_device *bdev, - struct ttm_tt *ttm) +void ttm_agp_unbind(struct ttm_tt *ttm) { struct ttm_agp_backend *agp_be = container_of(ttm, struct ttm_agp_backend, ttm); @@ -100,13 +98,12 @@ void ttm_agp_unbind(struct ttm_bo_device *bdev, } EXPORT_SYMBOL(ttm_agp_unbind); -void ttm_agp_destroy(struct ttm_bo_device *bdev, -struct ttm_tt *ttm) +void ttm_agp_destroy(struct ttm_tt *ttm) { struct ttm_agp_backend *agp_be = container_of(ttm, struct ttm_agp_backend, ttm); if (agp_be->mem) - ttm_agp_unbind(bdev, ttm); + ttm_agp_unbind(ttm); ttm_tt_fini(ttm); kfree(agp_be); } diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h index 591d4927d501..bdc8aadf3246 100644 --- a/include/drm/ttm/ttm_tt.h +++ b/include/drm/ttm/ttm_tt.h @@ -264,12 +264,9 @@ void ttm_tt_unpopulate(struct ttm_bo_device *bdev, struct ttm_tt *ttm); struct ttm_tt *ttm_agp_tt_create(struct ttm_buffer_object *bo, struct agp_bridge_data *bridge, uint32_t page_flags); -int ttm_agp_bind(struct ttm_bo_device *bdev, -struct ttm_tt *ttm, struct ttm_resource *bo_mem); -void ttm_agp_unbind(struct ttm_bo_device *bdev, - struct ttm_tt *ttm); -void ttm_agp_destroy(struct ttm_bo_device *bdev, -struct ttm_tt *ttm); +in
[PATCH 03/13] drm/qxl: move bind/unbind/destroy to the driver function table.
From: Dave Airlie Acked-by: Christian König Signed-off-by: Dave Airlie --- drivers/gpu/drm/qxl/qxl_ttm.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c index c3530c6e46bd..4970c3450e88 100644 --- a/drivers/gpu/drm/qxl/qxl_ttm.c +++ b/drivers/gpu/drm/qxl/qxl_ttm.c @@ -134,12 +134,6 @@ static void qxl_ttm_backend_destroy(struct ttm_bo_device *bdev, kfree(gtt); } -static struct ttm_backend_func qxl_backend_func = { - .bind = &qxl_ttm_backend_bind, - .unbind = &qxl_ttm_backend_unbind, - .destroy = &qxl_ttm_backend_destroy, -}; - static struct ttm_tt *qxl_ttm_tt_create(struct ttm_buffer_object *bo, uint32_t page_flags) { @@ -150,7 +144,6 @@ static struct ttm_tt *qxl_ttm_tt_create(struct ttm_buffer_object *bo, gtt = kzalloc(sizeof(struct qxl_ttm_tt), GFP_KERNEL); if (gtt == NULL) return NULL; - gtt->ttm.func = &qxl_backend_func; gtt->qdev = qdev; if (ttm_tt_init(>t->ttm, bo, page_flags)) { kfree(gtt); @@ -195,6 +188,9 @@ static void qxl_bo_move_notify(struct ttm_buffer_object *bo, static struct ttm_bo_driver qxl_bo_driver = { .ttm_tt_create = &qxl_ttm_tt_create, + .ttm_tt_bind = &qxl_ttm_backend_bind, + .ttm_tt_destroy = &qxl_ttm_backend_destroy, + .ttm_tt_unbind = &qxl_ttm_backend_unbind, .eviction_valuable = ttm_bo_eviction_valuable, .evict_flags = &qxl_evict_flags, .move = &qxl_bo_move, -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/13] drm/radeon/ttm: move to driver binding/destroy functions. (v2)
From: Dave Airlie Do agp decision in the driver, instead of special binding funcs v2: use container_of, drop some {}. Signed-off-by: Dave Airlie --- drivers/gpu/drm/radeon/radeon.h| 7 +- drivers/gpu/drm/radeon/radeon_cs.c | 2 +- drivers/gpu/drm/radeon/radeon_gem.c| 6 +- drivers/gpu/drm/radeon/radeon_object.c | 2 +- drivers/gpu/drm/radeon/radeon_prime.c | 2 +- drivers/gpu/drm/radeon/radeon_ttm.c| 92 +++--- drivers/gpu/drm/radeon/radeon_vm.c | 2 +- 7 files changed, 80 insertions(+), 33 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index cc4f58d16589..df6f0b49836b 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -2815,10 +2815,11 @@ extern void radeon_legacy_set_clock_gating(struct radeon_device *rdev, int enabl extern void radeon_atom_set_clock_gating(struct radeon_device *rdev, int enable); extern void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain); extern bool radeon_ttm_bo_is_radeon_bo(struct ttm_buffer_object *bo); -extern int radeon_ttm_tt_set_userptr(struct ttm_tt *ttm, uint64_t addr, +extern int radeon_ttm_tt_set_userptr(struct radeon_device *rdev, +struct ttm_tt *ttm, uint64_t addr, uint32_t flags); -extern bool radeon_ttm_tt_has_userptr(struct ttm_tt *ttm); -extern bool radeon_ttm_tt_is_readonly(struct ttm_tt *ttm); +extern bool radeon_ttm_tt_has_userptr(struct radeon_device *rdev, struct ttm_tt *ttm); +extern bool radeon_ttm_tt_is_readonly(struct radeon_device *rdev, struct ttm_tt *ttm); extern void radeon_vram_location(struct radeon_device *rdev, struct radeon_mc *mc, u64 base); extern void radeon_gtt_location(struct radeon_device *rdev, struct radeon_mc *mc); extern int radeon_resume_kms(struct drm_device *dev, bool resume, bool fbcon); diff --git a/drivers/gpu/drm/radeon/radeon_cs.c b/drivers/gpu/drm/radeon/radeon_cs.c index 33ae1b883268..21ce2f9502c0 100644 --- a/drivers/gpu/drm/radeon/radeon_cs.c +++ b/drivers/gpu/drm/radeon/radeon_cs.c @@ -160,7 +160,7 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser *p) p->relocs[i].allowed_domains = domain; } - if (radeon_ttm_tt_has_userptr(p->relocs[i].robj->tbo.ttm)) { + if (radeon_ttm_tt_has_userptr(p->rdev, p->relocs[i].robj->tbo.ttm)) { uint32_t domain = p->relocs[i].preferred_domains; if (!(domain & RADEON_GEM_DOMAIN_GTT)) { DRM_ERROR("Only RADEON_GEM_DOMAIN_GTT is " diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c index 7f5dfe04789e..e5c4271e64ed 100644 --- a/drivers/gpu/drm/radeon/radeon_gem.c +++ b/drivers/gpu/drm/radeon/radeon_gem.c @@ -331,7 +331,7 @@ int radeon_gem_userptr_ioctl(struct drm_device *dev, void *data, goto handle_lockup; bo = gem_to_radeon_bo(gobj); - r = radeon_ttm_tt_set_userptr(bo->tbo.ttm, args->addr, args->flags); + r = radeon_ttm_tt_set_userptr(rdev, bo->tbo.ttm, args->addr, args->flags); if (r) goto release_object; @@ -420,7 +420,7 @@ int radeon_mode_dumb_mmap(struct drm_file *filp, return -ENOENT; } robj = gem_to_radeon_bo(gobj); - if (radeon_ttm_tt_has_userptr(robj->tbo.ttm)) { + if (radeon_ttm_tt_has_userptr(robj->rdev, robj->tbo.ttm)) { drm_gem_object_put(gobj); return -EPERM; } @@ -721,7 +721,7 @@ int radeon_gem_op_ioctl(struct drm_device *dev, void *data, robj = gem_to_radeon_bo(gobj); r = -EPERM; - if (radeon_ttm_tt_has_userptr(robj->tbo.ttm)) + if (radeon_ttm_tt_has_userptr(robj->rdev, robj->tbo.ttm)) goto out; r = radeon_bo_reserve(robj, false); diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c index bb7582afd803..3fcd15d21ddc 100644 --- a/drivers/gpu/drm/radeon/radeon_object.c +++ b/drivers/gpu/drm/radeon/radeon_object.c @@ -331,7 +331,7 @@ int radeon_bo_pin_restricted(struct radeon_bo *bo, u32 domain, u64 max_offset, struct ttm_operation_ctx ctx = { false, false }; int r, i; - if (radeon_ttm_tt_has_userptr(bo->tbo.ttm)) + if (radeon_ttm_tt_has_userptr(bo->rdev, bo->tbo.ttm)) return -EPERM; if (bo->pin_count) { diff --git a/drivers/gpu/drm/radeon/radeon_prime.c b/drivers/gpu/drm/radeon/radeon_prime.c index b906e8fbd5f3..d6d9c8b46ab4 100644 --- a/drivers/gpu/drm/radeon/radeon_prime.c +++ b/drivers/gpu/drm/radeon/radeon_prime.c @@ -121,7 +121,7 @@ struct dma_buf *radeon_gem_prime_export(struct drm_gem_object *gobj, int flags) { struct radeon_bo *bo = gem_to_radeon_bo(gobj); - if (radeon_ttm_tt_has_userptr(bo->
[PATCH 00/13] ttm tt refactor repost of part 1
Most of these have r-b or acks already, patch 1 I may have posted before but found in my tree, so reposting it, and patch 5 for radeon I think were what needed re-review. I'd like to land these, and I'll revisit the remainder of this series. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/13] drm/ttm: add optional bind/unbind via driver.
From: Dave Airlie I want to remove the backend funcs Reviewed-by: Christian König Signed-off-by: Dave Airlie --- drivers/gpu/drm/ttm/ttm_tt.c| 15 +++--- include/drm/ttm/ttm_bo_driver.h | 36 + 2 files changed, 48 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c index 50a899104022..73c97dcfa512 100644 --- a/drivers/gpu/drm/ttm/ttm_tt.c +++ b/drivers/gpu/drm/ttm/ttm_tt.c @@ -222,7 +222,10 @@ void ttm_tt_destroy(struct ttm_bo_device *bdev, struct ttm_tt *ttm) fput(ttm->swap_storage); ttm->swap_storage = NULL; - ttm->func->destroy(bdev, ttm); + if (bdev->driver->ttm_tt_destroy) + bdev->driver->ttm_tt_destroy(bdev, ttm); + else + ttm->func->destroy(bdev, ttm); } static void ttm_tt_init_fields(struct ttm_tt *ttm, @@ -310,7 +313,10 @@ EXPORT_SYMBOL(ttm_dma_tt_fini); void ttm_tt_unbind(struct ttm_bo_device *bdev, struct ttm_tt *ttm) { if (ttm->state == tt_bound) { - ttm->func->unbind(bdev, ttm); + if (bdev->driver->ttm_tt_unbind) + bdev->driver->ttm_tt_unbind(bdev, ttm); + else + ttm->func->unbind(bdev, ttm); ttm->state = tt_unbound; } } @@ -331,7 +337,10 @@ int ttm_tt_bind(struct ttm_bo_device *bdev, if (ret) return ret; - ret = ttm->func->bind(bdev, ttm, bo_mem); + if (bdev->driver->ttm_tt_bind) + ret = bdev->driver->ttm_tt_bind(bdev, ttm, bo_mem); + else + ret = ttm->func->bind(bdev, ttm, bo_mem); if (unlikely(ret != 0)) return ret; diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h index ebba282667ba..32c0651cc0fd 100644 --- a/include/drm/ttm/ttm_bo_driver.h +++ b/include/drm/ttm/ttm_bo_driver.h @@ -90,6 +90,42 @@ struct ttm_bo_driver { */ void (*ttm_tt_unpopulate)(struct ttm_bo_device *bdev, struct ttm_tt *ttm); + /** +* ttm_tt_bind +* +* @bdev: Pointer to a ttm device +* @ttm: Pointer to a struct ttm_tt. +* @bo_mem: Pointer to a struct ttm_resource describing the +* memory type and location for binding. +* +* Bind the backend pages into the aperture in the location +* indicated by @bo_mem. This function should be able to handle +* differences between aperture and system page sizes. +*/ + int (*ttm_tt_bind)(struct ttm_bo_device *bdev, struct ttm_tt *ttm, struct ttm_resource *bo_mem); + + /** +* ttm_tt_unbind +* +* @bdev: Pointer to a ttm device +* @ttm: Pointer to a struct ttm_tt. +* +* Unbind previously bound backend pages. This function should be +* able to handle differences between aperture and system page sizes. +*/ + void (*ttm_tt_unbind)(struct ttm_bo_device *bdev, struct ttm_tt *ttm); + + /** +* ttm_tt_destroy +* +* @bdev: Pointer to a ttm device +* @ttm: Pointer to a struct ttm_tt. +* +* Destroy the backend. This will be call back from ttm_tt_destroy so +* don't call ttm_tt_destroy from the callback or infinite loop. +*/ + void (*ttm_tt_destroy)(struct ttm_bo_device *bdev, struct ttm_tt *ttm); + /** * struct ttm_bo_driver member eviction_valuable * -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/13] drm/ttm/agp: export bind/unbind/destroy for drivers to use.
From: Dave Airlie Reviewed-by: Christian König Signed-off-by: Dave Airlie --- drivers/gpu/drm/ttm/ttm_agp_backend.c | 15 +-- include/drm/ttm/ttm_tt.h | 6 ++ 2 files changed, 15 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c b/drivers/gpu/drm/ttm/ttm_agp_backend.c index 934a69491547..fbf98cd1a3e5 100644 --- a/drivers/gpu/drm/ttm/ttm_agp_backend.c +++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c @@ -48,8 +48,8 @@ struct ttm_agp_backend { struct agp_bridge_data *bridge; }; -static int ttm_agp_bind(struct ttm_bo_device *bdev, - struct ttm_tt *ttm, struct ttm_resource *bo_mem) +int ttm_agp_bind(struct ttm_bo_device *bdev, +struct ttm_tt *ttm, struct ttm_resource *bo_mem) { struct ttm_agp_backend *agp_be = container_of(ttm, struct ttm_agp_backend, ttm); struct page *dummy_read_page = ttm_bo_glob.dummy_read_page; @@ -82,9 +82,10 @@ static int ttm_agp_bind(struct ttm_bo_device *bdev, return ret; } +EXPORT_SYMBOL(ttm_agp_bind); -static void ttm_agp_unbind(struct ttm_bo_device *bdev, - struct ttm_tt *ttm) +void ttm_agp_unbind(struct ttm_bo_device *bdev, + struct ttm_tt *ttm) { struct ttm_agp_backend *agp_be = container_of(ttm, struct ttm_agp_backend, ttm); @@ -97,9 +98,10 @@ static void ttm_agp_unbind(struct ttm_bo_device *bdev, agp_be->mem = NULL; } } +EXPORT_SYMBOL(ttm_agp_unbind); -static void ttm_agp_destroy(struct ttm_bo_device *bdev, - struct ttm_tt *ttm) +void ttm_agp_destroy(struct ttm_bo_device *bdev, +struct ttm_tt *ttm) { struct ttm_agp_backend *agp_be = container_of(ttm, struct ttm_agp_backend, ttm); @@ -108,6 +110,7 @@ static void ttm_agp_destroy(struct ttm_bo_device *bdev, ttm_tt_fini(ttm); kfree(agp_be); } +EXPORT_SYMBOL(ttm_agp_destroy); static struct ttm_backend_func ttm_agp_func = { .bind = ttm_agp_bind, diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h index 6bda88f8da46..5a34f1640865 100644 --- a/include/drm/ttm/ttm_tt.h +++ b/include/drm/ttm/ttm_tt.h @@ -266,6 +266,12 @@ struct ttm_tt *ttm_agp_tt_create(struct ttm_buffer_object *bo, uint32_t page_flags); int ttm_agp_tt_populate(struct ttm_bo_device *bdev, struct ttm_tt *ttm, struct ttm_operation_ctx *ctx); void ttm_agp_tt_unpopulate(struct ttm_bo_device *bdev, struct ttm_tt *ttm); +int ttm_agp_bind(struct ttm_bo_device *bdev, +struct ttm_tt *ttm, struct ttm_resource *bo_mem); +void ttm_agp_unbind(struct ttm_bo_device *bdev, + struct ttm_tt *ttm); +void ttm_agp_destroy(struct ttm_bo_device *bdev, +struct ttm_tt *ttm); #endif #endif -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] drm: panel: add TDO tl070wsh30 panel driver
Hi Neil. On Mon, Sep 07, 2020 at 01:10:27PM +0200, Neil Armstrong wrote: > This adds support for the TDO TL070WSH30 TFT-LCD panel module. > The panel has a 1024×600 resolution and uses 24 bit RGB per pixel. > It provides a MIPI DSI interface to the host, a built-in LED backlight > and touch controller. Despite a nicely written driver I noticed a few things that needs to be addressed. Sam > > Signed-off-by: Neil Armstrong > --- > drivers/gpu/drm/panel/Kconfig| 11 + > drivers/gpu/drm/panel/Makefile | 1 + > drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c | 256 +++ > 3 files changed, 268 insertions(+) > create mode 100644 drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c > > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig > index 8d97d07c5871..2d488a875b99 100644 > --- a/drivers/gpu/drm/panel/Kconfig > +++ b/drivers/gpu/drm/panel/Kconfig > @@ -433,6 +433,17 @@ config DRM_PANEL_SONY_ACX565AKM > Say Y here if you want to enable support for the Sony ACX565AKM > 800x600 3.5" panel (found on the Nokia N900). > > +config DRM_PANEL_TDO_TL070WSH30 > + tristate "TDO TL070WSH30 DSI panel" > + depends on OF > + depends on DRM_MIPI_DSI > + depends on BACKLIGHT_CLASS_DEVICE > + help > + Say Y here if you want to enable support for TDO TL070WSH30 TFT-LCD > + panel module. The panel has a 1024×600 resolution and uses > + 24 bit RGB per pixel. It provides a MIPI DSI interface to > + the host, a built-in LED backlight and touch controller. > + > config DRM_PANEL_TPO_TD028TTEC1 > tristate "Toppoly (TPO) TD028TTEC1 panel driver" > depends on OF && SPI > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile > index 15a4e7752951..35ee06a1b5c2 100644 > --- a/drivers/gpu/drm/panel/Makefile > +++ b/drivers/gpu/drm/panel/Makefile > @@ -45,6 +45,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7703) += > panel-sitronix-st7703.o > obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o > obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o > obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o > +obj-$(CONFIG_DRM_PANEL_TDO_TL070WSH30) += panel-tdo-tl070wsh30.o > obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o > obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o > obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o > diff --git a/drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c > b/drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c > new file mode 100644 > index ..c7a6c2c42c52 > --- /dev/null > +++ b/drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c > @@ -0,0 +1,256 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2020 BayLibre, SAS > + * Author: Neil Armstrong > + */ > + > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +#include > +#include > +#include > +#include > +#include > + > +struct tdo_tl070wsh30_panel { > + struct drm_panel base; > + struct mipi_dsi_device *link; > + > + struct regulator *supply; > + struct gpio_desc *reset_gpio; > + > + bool prepared; > +}; > + > +static inline > +struct tdo_tl070wsh30_panel *to_tdo_tl070wsh30_panel(struct drm_panel *panel) > +{ > + return container_of(panel, struct tdo_tl070wsh30_panel, base); > +} bikeshedding - but my preference is to order the functions: prepare enable disable unprepare As this is the natural order they are used. Feel free to ignore! > + > +static int tdo_tl070wsh30_panel_unprepare(struct drm_panel *panel) > +{ > + struct tdo_tl070wsh30_panel *tdo_tl070wsh30 = > to_tdo_tl070wsh30_panel(panel); > + int err; > + > + if (!tdo_tl070wsh30->prepared) > + return 0; > + > + err = mipi_dsi_dcs_set_display_off(tdo_tl070wsh30->link); > + if (err < 0) > + dev_err(panel->dev, "failed to set display off: %d\n", err); > + > + usleep_range(1, 11000); > + > + err = mipi_dsi_dcs_enter_sleep_mode(tdo_tl070wsh30->link); > + if (err < 0) { > + dev_err(panel->dev, "failed to enter sleep mode: %d\n", err); > + return err; > + } > + > + usleep_range(1, 11000); > + > + tdo_tl070wsh30->prepared = false; > + > + return 0; > +} > + > +static int tdo_tl070wsh30_panel_prepare(struct drm_panel *panel) > +{ > + struct tdo_tl070wsh30_panel *tdo_tl070wsh30 = > to_tdo_tl070wsh30_panel(panel); > + int err; > + > + if (tdo_tl070wsh30->prepared) > + return 0; > + > + err = mipi_dsi_dcs_exit_sleep_mode(tdo_tl070wsh30->link); > + if (err < 0) { > + dev_err(panel->dev, "failed to exit sleep mode: %d\n", err); > + return err; > + } > + > + msleep(200); > + > + err = mipi_dsi_dcs_set_display_on(tdo_tl070wsh30->link); > + if (err < 0) { > + dev_err(panel->dev, "failed to set display on: %d\n
Re: [PATCH v2 2/3] dt-bindings: display: panel: add TDO tl070wsh30 DSI panel bindings
Hi Neil. On Mon, Sep 07, 2020 at 03:24:47PM +0200, Neil Armstrong wrote: > Hi, > > On 07/09/2020 13:45, Sam Ravnborg wrote: > > Hi Neil. > > > > On Mon, Sep 07, 2020 at 01:10:26PM +0200, Neil Armstrong wrote: > >> This add the bindings for the 1024*600 tl070wsh30 DSI panel. > > > > The binding looks like a panel-simple-dsi.yaml candidate. > > Only differen is enable-gpios versus reset-gpios > > This is the only difference, the panel only has a reset signal and no > enable signal. > > But I can add a reset-gpios to panel-simple-dsi.yaml, would it be ok ? Yes, that would be fine as long as it is not a required property. It was a mistake we did not add it from the beginning. There has been patches floating to add reset-gpios to panle.simple.c that I rejected - this was also wrong. Really simple and dumb panels has no reset but dsi panels that panel-simple supports too has a reset. Sam > > Neil > > > > > Could you check if we can use panel-simple-dsi-yaml. > > > > Sam > > > >> > >> Signed-off-by: Neil Armstrong > >> --- > >> .../display/panel/tdo,tl070wsh30.yaml | 58 +++ > >> 1 file changed, 58 insertions(+) > >> create mode 100644 > >> Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml > >> > >> diff --git > >> a/Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml > >> b/Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml > >> new file mode 100644 > >> index ..20f4fdedfcb0 > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml > >> @@ -0,0 +1,58 @@ > >> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) > >> +# Copyright 2020 BayLibre, SAS > >> +%YAML 1.2 > >> +--- > >> +$id: http://devicetree.org/schemas/display/panel/tdo,tl070wsh30.yaml# > >> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >> + > >> +title: TDO TL070WSH30 DSI panel > >> + > >> +maintainers: > >> + - Neil Armstrong > >> + > >> +allOf: > >> + - $ref: panel-common.yaml# > >> + > >> +properties: > >> + > >> + compatible: > >> +enum: > >> + - tdo,tl070wsh30 > >> + > >> + reg: > >> +maxItems: 1 > >> +description: DSI virtual channel > >> + > >> + backlight: true > >> + reset-gpios: true > >> + port: true > >> + power-supply: true > >> + > >> +additionalProperties: false > >> + > >> +required: > >> + - compatible > >> + - power-supply > >> + - reset-gpios > >> + - port > >> + - reg > >> + > >> +examples: > >> + - | > >> +dsi { > >> + #address-cells = <1>; > >> + #size-cells = <0>; > >> + panel@0 { > >> +compatible = "tdo,tl070wsh30"; > >> +reg = <0>; > >> +power-supply = <&vcc_lcd_reg>; > >> +backlight = <&panel_backlight>; > >> +reset-gpios = <&gpio_reset>; > >> + > >> +port { > >> + panel: endpoint { > >> +remote-endpoint = <&mipi_dsi_out>; > >> + }; > >> +}; > >> + }; > >> +}; > >> -- > >> 2.22.0 > > ___ > 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 2/2] drm/ttm: merge offset and base in ttm_bus_placement
I'd written something similar but didn't finish it! For the series, Reviewed-by: Dave Airlie On Mon, 7 Sep 2020 at 23:29, Christian König wrote: > > This is used by TTM to communicate the physical address > which should be used with ioremap(), ioremap_wc(). We don't > need to separate the base and offset in any way here. > > Signed-off-by: Christian König > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 7 --- > drivers/gpu/drm/drm_gem_ttm_helper.c | 5 + > drivers/gpu/drm/drm_gem_vram_helper.c | 3 +-- > drivers/gpu/drm/nouveau/nouveau_bo.c | 9 - > drivers/gpu/drm/nouveau/nouveau_fbcon.c| 3 +-- > drivers/gpu/drm/qxl/qxl_ttm.c | 7 +++ > drivers/gpu/drm/radeon/radeon_ttm.c| 14 ++ > drivers/gpu/drm/ttm/ttm_bo.c | 3 --- > drivers/gpu/drm/ttm/ttm_bo_util.c | 17 ++--- > drivers/gpu/drm/ttm/ttm_bo_vm.c| 3 +-- > drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 4 ++-- > include/drm/ttm/ttm_resource.h | 6 ++ > 12 files changed, 31 insertions(+), 50 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > index 46d620817482..b39d2a834340 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > @@ -773,7 +773,7 @@ static int amdgpu_ttm_io_mem_reserve(struct ttm_bo_device > *bdev, struct ttm_reso > mem->bus.addr = (u8 *)adev->mman.aper_base_kaddr + > mem->bus.offset; > > - mem->bus.base = adev->gmc.aper_base; > + mem->bus.offset += adev->gmc.aper_base; > mem->bus.is_iomem = true; > break; > default: > @@ -785,12 +785,13 @@ static int amdgpu_ttm_io_mem_reserve(struct > ttm_bo_device *bdev, struct ttm_reso > static unsigned long amdgpu_ttm_io_mem_pfn(struct ttm_buffer_object *bo, >unsigned long page_offset) > { > + struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev); > uint64_t offset = (page_offset << PAGE_SHIFT); > struct drm_mm_node *mm; > > mm = amdgpu_find_mm_node(&bo->mem, &offset); > - return (bo->mem.bus.base >> PAGE_SHIFT) + mm->start + > - (offset >> PAGE_SHIFT); > + offset += adev->gmc.aper_base; > + return mm->start + (offset >> PAGE_SHIFT); > } > > /** > diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c > b/drivers/gpu/drm/drm_gem_ttm_helper.c > index 892b2288a104..0e4fb9ba43ad 100644 > --- a/drivers/gpu/drm/drm_gem_ttm_helper.c > +++ b/drivers/gpu/drm/drm_gem_ttm_helper.c > @@ -43,12 +43,9 @@ void drm_gem_ttm_print_info(struct drm_printer *p, > unsigned int indent, > drm_print_bits(p, bo->mem.placement, plname, ARRAY_SIZE(plname)); > drm_printf(p, "\n"); > > - if (bo->mem.bus.is_iomem) { > - drm_printf_indent(p, indent, "bus.base=%lx\n", > - (unsigned long)bo->mem.bus.base); > + if (bo->mem.bus.is_iomem) > drm_printf_indent(p, indent, "bus.offset=%lx\n", > (unsigned long)bo->mem.bus.offset); > - } > } > EXPORT_SYMBOL(drm_gem_ttm_print_info); > > diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c > b/drivers/gpu/drm/drm_gem_vram_helper.c > index 545a877406f4..255560591916 100644 > --- a/drivers/gpu/drm/drm_gem_vram_helper.c > +++ b/drivers/gpu/drm/drm_gem_vram_helper.c > @@ -1042,8 +1042,7 @@ static int bo_driver_io_mem_reserve(struct > ttm_bo_device *bdev, > case TTM_PL_SYSTEM: /* nothing to do */ > break; > case TTM_PL_VRAM: > - mem->bus.offset = mem->start << PAGE_SHIFT; > - mem->bus.base = vmm->vram_base; > + mem->bus.offset = (mem->start << PAGE_SHIFT) + vmm->vram_base; > mem->bus.is_iomem = true; > break; > default: > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c > b/drivers/gpu/drm/nouveau/nouveau_bo.c > index f74988771ed8..4c2cc862eb19 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c > @@ -1081,8 +1081,8 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, > struct ttm_resource *reg) > case TTM_PL_TT: > #if IS_ENABLED(CONFIG_AGP) > if (drm->agp.bridge) { > - reg->bus.offset = reg->start << PAGE_SHIFT; > - reg->bus.base = drm->agp.base; > + reg->bus.offset = (reg->start << PAGE_SHIFT) + > + drm->agp.base; > reg->bus.is_iomem = !drm->agp.cma; > } > #endif > @@ -1094,8 +1094,8 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, > struct ttm_resource *reg) > } > fallthrough;/* tiled memo
Re: [PATCH] drm: mxsfb: check framebuffer pitch
On Mon, Sep 07, 2020 at 07:17:12PM +0300, Laurent Pinchart wrote: > Hi Stefan, > > Thank you for the patch. > > On Mon, Sep 07, 2020 at 06:03:43PM +0200, Stefan Agner wrote: > > The lcdif IP does not support a framebuffer pitch (stride) other than > > the CRTC width. Check for equality and reject the state otherwise. > > > > This prevents a distorted picture when using 640x800 and running the > > Mesa graphics stack. Mesa tires to use a cache aligned stride, which > > s/tires/tries/ > > > leads at that particular resolution to width != stride. Currently > > Mesa has no fallback behavior, but rejecting this configuration allows > > userspace to handle the issue correctly. > > I'm increasingly impressed by how featureful this IP core is :-) > > > Signed-off-by: Stefan Agner > > --- > > drivers/gpu/drm/mxsfb/mxsfb_kms.c | 22 ++ > > 1 file changed, 18 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c > > b/drivers/gpu/drm/mxsfb/mxsfb_kms.c > > index b721b8b262ce..79aa14027f91 100644 > > --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c > > +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c > > @@ -403,14 +403,28 @@ static int mxsfb_plane_atomic_check(struct drm_plane > > *plane, > > { > > struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(plane->dev); > > struct drm_crtc_state *crtc_state; > > + unsigned int pitch; > > + int ret; > > > > crtc_state = drm_atomic_get_new_crtc_state(plane_state->state, > >&mxsfb->crtc); > > > > - return drm_atomic_helper_check_plane_state(plane_state, crtc_state, > > - DRM_PLANE_HELPER_NO_SCALING, > > - DRM_PLANE_HELPER_NO_SCALING, > > - false, true); > > + ret = drm_atomic_helper_check_plane_state(plane_state, crtc_state, > > + DRM_PLANE_HELPER_NO_SCALING, > > + DRM_PLANE_HELPER_NO_SCALING, > > + false, true); > > + if (ret || !plane_state->visible) > > Would it be more explict to check for !plane_state->fb ? Otherwise I'll > have to verify that !fb always implies !visible :-) > > > + return ret; > > + > > + pitch = crtc_state->mode.hdisplay * > > + plane_state->fb->format->cpp[0]; > > This holds on a single line. > > > + if (plane_state->fb->pitches[0] != pitch) { > > + dev_err(plane->dev->dev, > > + "Invalid pitch: fb and crtc widths must be the same"); > > I'd turn this into a dev_dbg(), printing error messages to the kernel > log in response to user-triggered conditions is a bit too verbose and > could flood the log. > > Wouldn't it be best to catch this issue when creating the framebuffer ? Yeah this should be verified at addfb time. We try to validate as early as possible. -Daniel > > > + return -EINVAL; > > + } > > + > > + return 0; > > } > > > > static void mxsfb_plane_primary_atomic_update(struct drm_plane *plane, > > -- > Regards, > > Laurent Pinchart -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu/drm: cleanup coding style a bit
On Mon, Sep 07, 2020 at 05:31:29AM -0700, Bernard Zhao wrote: > Remove first assignment to info which is meaningless. > Put the width and higth check first. > This change is to make the code a bit readable. > > Signed-off-by: Bernard Zhao Looks reasonable, thanks for your patch. Applied to drm-misc-next for 5.10. -Daniel > --- > drivers/gpu/drm/drm_framebuffer.c | 9 - > 1 file changed, 4 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/drm_framebuffer.c > b/drivers/gpu/drm/drm_framebuffer.c > index df656366a530..2f5b0c2bb0fe 100644 > --- a/drivers/gpu/drm/drm_framebuffer.c > +++ b/drivers/gpu/drm/drm_framebuffer.c > @@ -176,8 +176,7 @@ static int framebuffer_check(struct drm_device *dev, > int i; > > /* check if the format is supported at all */ > - info = __drm_format_info(r->pixel_format); > - if (!info) { > + if (!__drm_format_info(r->pixel_format)) { > struct drm_format_name_buf format_name; > > DRM_DEBUG_KMS("bad framebuffer format %s\n", > @@ -186,9 +185,6 @@ static int framebuffer_check(struct drm_device *dev, > return -EINVAL; > } > > - /* now let the driver pick its own format info */ > - info = drm_get_format_info(dev, r); > - > if (r->width == 0) { > DRM_DEBUG_KMS("bad framebuffer width %u\n", r->width); > return -EINVAL; > @@ -199,6 +195,9 @@ static int framebuffer_check(struct drm_device *dev, > return -EINVAL; > } > > + /* now let the driver pick its own format info */ > + info = drm_get_format_info(dev, r); > + > for (i = 0; i < info->num_planes; i++) { > unsigned int width = fb_plane_width(r->width, info, i); > unsigned int height = fb_plane_height(r->height, info, i); > -- > 2.28.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Drop the drm_atomic_helper_calc_timestamping_constants() call
On Mon, Sep 07, 2020 at 03:00:26PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > We update the timestamping constants per-crtc explicitly in > intel_crtc_update_active_timings(). Furtermore the helper will > use uapi.adjusted_mode whereas we want hw.adjusted_mode. Thus > let's drop the helper call an rely on what we already have in > intel_crtc_update_active_timings(). We can now also drop the > hw.adjusted_mode -> uapi.adjusted_mode copy hack that was added > to keep the helper from deriving the timestamping constants from > the wrong thing. > > Signed-off-by: Ville Syrjälä Does this fix some CI fail? I'd kinda expect/hope for that ... Anyway looks like a good idea to not mess with the uapi state like this. Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/i915/display/intel_display.c | 7 --- > 1 file changed, 7 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index 035840ce3825..a846f414c759 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -13472,12 +13472,6 @@ intel_modeset_pipe_config(struct intel_crtc_state > *pipe_config) > "hw max bpp: %i, pipe bpp: %i, dithering: %i\n", > base_bpp, pipe_config->pipe_bpp, pipe_config->dither); > > - /* > - * Make drm_calc_timestamping_constants in > - * drm_atomic_helper_update_legacy_modeset_state() happy > - */ > - pipe_config->uapi.adjusted_mode = pipe_config->hw.adjusted_mode; > - > return 0; > } > > @@ -15578,7 +15572,6 @@ static void intel_atomic_commit_tail(struct > intel_atomic_state *state) > > if (state->modeset) { > drm_atomic_helper_update_legacy_modeset_state(dev, > &state->base); > - drm_atomic_helper_calc_timestamping_constants(&state->base); > > intel_set_cdclk_pre_plane_update(state); > > -- > 2.26.2 > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/3] drm/atomic-helper: Remove the timestamping constant update from drm_atomic_helper_update_legacy_modeset_state()
On Mon, Sep 07, 2020 at 03:00:25PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > The timestamping constants have nothing to do with any legacy state > so should not be updated from > drm_atomic_helper_update_legacy_modeset_state(). > > Let's make everyone call drm_atomic_helper_calc_timestamping_constants() > directly instead of relying on > drm_atomic_helper_update_legacy_modeset_state() to call it. > > @@ > expression S; > @@ > - drm_atomic_helper_calc_timestamping_constants(S); > > @@ > expression D, S; > @@ > drm_atomic_helper_update_legacy_modeset_state(D, S); > + drm_atomic_helper_calc_timestamping_constants(S); > > Signed-off-by: Ville Syrjälä I think the kerneldoc for drm_crtc_vblank_helper_get_vblank/_timestamp_internal (both of them) also needs to be updated to mention the new function. With that fixed: Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 + > drivers/gpu/drm/drm_atomic_helper.c | 7 ++- > drivers/gpu/drm/i915/display/intel_display.c | 1 + > drivers/gpu/drm/nouveau/dispnv50/disp.c | 1 + > 4 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index 490684787cff..0511097343da 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -7397,6 +7397,7 @@ static void amdgpu_dm_atomic_commit_tail(struct > drm_atomic_state *state) > int crtc_disable_count = 0; > > drm_atomic_helper_update_legacy_modeset_state(dev, state); > + drm_atomic_helper_calc_timestamping_constants(state); > > dm_state = dm_atomic_get_new_state(state); > if (dm_state && dm_state->context) { > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > b/drivers/gpu/drm/drm_atomic_helper.c > index 673e3fc282d9..45ee613c8efd 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -1115,9 +1115,7 @@ disable_outputs(struct drm_device *dev, struct > drm_atomic_state *old_state) > * @old_state: atomic state object with old state structures > * > * This function updates all the various legacy modeset state pointers in > - * connectors, encoders and CRTCs. It also updates the timestamping constants > - * used for precise vblank timestamps by calling > - * drm_calc_timestamping_constants(). > + * connectors, encoders and CRTCs. > * > * Drivers can use this for building their own atomic commit if they don't > have > * a pure helper-based modeset implementation. > @@ -1187,8 +1185,6 @@ drm_atomic_helper_update_legacy_modeset_state(struct > drm_device *dev, > crtc->y = new_plane_state->src_y >> 16; > } > } > - > - drm_atomic_helper_calc_timestamping_constants(old_state); > } > EXPORT_SYMBOL(drm_atomic_helper_update_legacy_modeset_state); > > @@ -1296,6 +1292,7 @@ void drm_atomic_helper_commit_modeset_disables(struct > drm_device *dev, > disable_outputs(dev, old_state); > > drm_atomic_helper_update_legacy_modeset_state(dev, old_state); > + drm_atomic_helper_calc_timestamping_constants(old_state); > > crtc_set_mode(dev, old_state); > } > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index ec148a8da2c2..035840ce3825 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -15578,6 +15578,7 @@ static void intel_atomic_commit_tail(struct > intel_atomic_state *state) > > if (state->modeset) { > drm_atomic_helper_update_legacy_modeset_state(dev, > &state->base); > + drm_atomic_helper_calc_timestamping_constants(&state->base); > > intel_set_cdclk_pre_plane_update(state); > > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c > b/drivers/gpu/drm/nouveau/dispnv50/disp.c > index 7799530e07c1..b6d1b926bc5e 100644 > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c > @@ -2069,6 +2069,7 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state > *state) > drm_atomic_helper_wait_for_fences(dev, state, false); > drm_atomic_helper_wait_for_dependencies(state); > drm_atomic_helper_update_legacy_modeset_state(dev, state); > + drm_atomic_helper_calc_timestamping_constants(state); > > if (atom->lock_core) > mutex_lock(&disp->mutex); > -- > 2.26.2 > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-deve
Re: [Intel-gfx] [PATCH 1/3] drm/atomic-helper: Extract drm_atomic_helper_calc_timestamping_constants()
On Mon, Sep 07, 2020 at 03:00:24PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Put the vblank timestamping constants update loop into its own > function. It has no business living inside > drm_atomic_helper_update_legacy_modeset_state() so we'll be wanting > to move it out entirely. As a first step we'll still call it > from drm_atomic_helper_update_legacy_modeset_state(). > > Signed-off-by: Ville Syrjälä Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/drm_atomic_helper.c | 22 +- > include/drm/drm_atomic_helper.h | 3 +++ > 2 files changed, 24 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > b/drivers/gpu/drm/drm_atomic_helper.c > index 9e1ad493e689..673e3fc282d9 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -1186,13 +1186,33 @@ drm_atomic_helper_update_legacy_modeset_state(struct > drm_device *dev, > crtc->x = new_plane_state->src_x >> 16; > crtc->y = new_plane_state->src_y >> 16; > } > + } > > + drm_atomic_helper_calc_timestamping_constants(old_state); > +} > +EXPORT_SYMBOL(drm_atomic_helper_update_legacy_modeset_state); > + > +/** > + * drm_atomic_helper_calc_timestamping_constants - update vblank > timestamping constants > + * @state: atomic state object > + * > + * Updates the timestamping constants used for precise vblank timestamps > + * by calling drm_calc_timestamping_constants() for all enabled crtcs in > @state. > + */ > +void drm_atomic_helper_calc_timestamping_constants(struct drm_atomic_state > *state) > +{ > + struct drm_crtc_state *new_crtc_state; > + struct drm_crtc *crtc; > + int i; > + > + /* set legacy state in the crtc structure */ > + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) { > if (new_crtc_state->enable) > drm_calc_timestamping_constants(crtc, > > &new_crtc_state->adjusted_mode); > } > } > -EXPORT_SYMBOL(drm_atomic_helper_update_legacy_modeset_state); > +EXPORT_SYMBOL(drm_atomic_helper_calc_timestamping_constants); > > static void > crtc_set_mode(struct drm_device *dev, struct drm_atomic_state *old_state) > diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h > index b268180c97eb..85df04c8e62f 100644 > --- a/include/drm/drm_atomic_helper.h > +++ b/include/drm/drm_atomic_helper.h > @@ -74,6 +74,9 @@ void > drm_atomic_helper_update_legacy_modeset_state(struct drm_device *dev, > struct drm_atomic_state > *old_state); > > +void > +drm_atomic_helper_calc_timestamping_constants(struct drm_atomic_state > *state); > + > void drm_atomic_helper_commit_modeset_disables(struct drm_device *dev, > struct drm_atomic_state *state); > void drm_atomic_helper_commit_modeset_enables(struct drm_device *dev, > -- > 2.26.2 > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: dw-mipi-dsi: fix dw_mipi_dsi_debugfs_show/write warnings
On Mon, Sep 07, 2020 at 12:27:11PM +0200, Neil Armstrong wrote: > This fixes the following warnings while building in W=1 : > dw-mipi-dsi.c:1002:5: warning: no previous prototype for > 'dw_mipi_dsi_debugfs_write' [-Wmissing-prototypes] > dw-mipi-dsi.c:1027:5: warning: no previous prototype for > 'dw_mipi_dsi_debugfs_show' [-Wmissing-prototypes] > > Fixes: e2435d69204c ("drm/bridge: dw-mipi-dsi.c: Add VPG runtime config > through debugfs") > Reported-by: kernel test robot > Cc: Angelo Ribeiro > Cc: Maxime Ripard > Cc: Maarten Lankhorst > Cc: Thomas Zimmermann > Signed-off-by: Neil Armstrong Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > index 0b3825a4fbdb..52f5c5a2ed64 100644 > --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > @@ -999,7 +999,7 @@ static const struct drm_bridge_funcs > dw_mipi_dsi_bridge_funcs = { > > #ifdef CONFIG_DEBUG_FS > > -int dw_mipi_dsi_debugfs_write(void *data, u64 val) > +static int dw_mipi_dsi_debugfs_write(void *data, u64 val) > { > struct debugfs_entries *vpg = data; > struct dw_mipi_dsi *dsi; > @@ -1024,7 +1024,7 @@ int dw_mipi_dsi_debugfs_write(void *data, u64 val) > return 0; > } > > -int dw_mipi_dsi_debugfs_show(void *data, u64 *val) > +static int dw_mipi_dsi_debugfs_show(void *data, u64 *val) > { > struct debugfs_entries *vpg = data; > > -- > 2.22.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver
On Mon, Sep 07, 2020 at 11:03:29AM +0200, Neil Armstrong wrote: > On 07/09/2020 10:44, Daniel Vetter wrote: > > On Mon, Sep 07, 2020 at 10:43:51AM +0200, Daniel Vetter wrote: > >> On Mon, Sep 07, 2020 at 10:18:25AM +0200, Neil Armstrong wrote: > >>> The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver > >>> 1.21a), with a custom > >>> glue managing the IP resets, clock and data input similar to the DW-HDMI > >>> Glue on other > >>> Amlogic SoCs. > >>> > >>> This adds support for the Glue managing the transceiver, mimicing the > >>> init flow provided > >>> by Amlogic to setup the ENCl encoder, the glue, the transceiver, the > >>> digital D-PHY and the > >>> Analog PHY in the proper way. > >>> > >>> The DW-MIPI-DSI transceiver + D-PHY are directly clocked by the VCLK2 > >>> clock, which pixel clock > >>> is derived and feeds the ENCL encoder and the VIU pixel reader. > >>> > >>> An optional "MEAS" clock can be enabled to measure the delay between each > >>> vsync feeding the > >>> DW-MIPI-DSI transceiver. > >>> > >>> Signed-off-by: Neil Armstrong > >> > >> More dw-hdmi drivers which aren't bridges but components, and the thing is > >> still midlayer-y as heck :-/ > > > > *dw-dsi, but really they both work the same way and should both be fixed > > ... > > They are bridges but since they have platform-dependent code due to theirs's > generic IP > nature, they need to be intanciated by components to sync with the platform > code. Yeah that's how it currently works, but there's not much reason why it needs to work like that. That platform glue code can also be put behind the drm_bridge abstraction, and we could use the normal dt based bridge lookup like for everything else. Afaiui the only reason dw-* bridge drivers work like that is because for historical reasons we only had component.c at first, and none of the more fancy dynamic bridge lookup. So would be really good to switch this all over to a proper&clean bridge abstraction, and not leak everything around. I've typed up what I think should be the way forward a few times already, but thus far not even the todo.rst entry materialized: https://lore.kernel.org/dri-devel/20200430135841.GE10381@phenom.ffwll.local/ If everyone is always about "not in my patch series" it'll never happen. Cheers, Daniel > > Neil > > > > >> > >> Can we try to fix this? There's a ton of this going on, and the more we > >> add the old fashioned way the harder this gets to fix up for real. > >> -Daniel > >> > >>> --- > >>> drivers/gpu/drm/meson/Kconfig | 7 + > >>> drivers/gpu/drm/meson/Makefile| 1 + > >>> drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 562 ++ > >>> 3 files changed, 570 insertions(+) > >>> create mode 100644 drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > >>> > >>> diff --git a/drivers/gpu/drm/meson/Kconfig b/drivers/gpu/drm/meson/Kconfig > >>> index 9f9281dd49f8..385f6f23839b 100644 > >>> --- a/drivers/gpu/drm/meson/Kconfig > >>> +++ b/drivers/gpu/drm/meson/Kconfig > >>> @@ -16,3 +16,10 @@ config DRM_MESON_DW_HDMI > >>> default y if DRM_MESON > >>> select DRM_DW_HDMI > >>> imply DRM_DW_HDMI_I2S_AUDIO > >>> + > >>> +config DRM_MESON_DW_MIPI_DSI > >>> + tristate "MIPI DSI Synopsys Controller support for Amlogic Meson > >>> Display" > >>> + depends on DRM_MESON > >>> + default y if DRM_MESON > >>> + select DRM_DW_MIPI_DSI > >>> + select GENERIC_PHY_MIPI_DPHY > >>> diff --git a/drivers/gpu/drm/meson/Makefile > >>> b/drivers/gpu/drm/meson/Makefile > >>> index 28a519cdf66b..2cc870e91182 100644 > >>> --- a/drivers/gpu/drm/meson/Makefile > >>> +++ b/drivers/gpu/drm/meson/Makefile > >>> @@ -5,3 +5,4 @@ meson-drm-y += meson_rdma.o meson_osd_afbcd.o > >>> > >>> obj-$(CONFIG_DRM_MESON) += meson-drm.o > >>> obj-$(CONFIG_DRM_MESON_DW_HDMI) += meson_dw_hdmi.o > >>> +obj-$(CONFIG_DRM_MESON_DW_MIPI_DSI) += meson_dw_mipi_dsi.o > >>> diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > >>> b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > >>> new file mode 100644 > >>> index ..bbe1294fce7c > >>> --- /dev/null > >>> +++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > >>> @@ -0,0 +1,562 @@ > >>> +// SPDX-License-Identifier: GPL-2.0-or-later > >>> +/* > >>> + * Copyright (C) 2016 BayLibre, SAS > >>> + * Author: Neil Armstrong > >>> + * Copyright (C) 2015 Amlogic, Inc. All rights reserved. > >>> + */ > >>> + > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> + > >>> +#include > >>> + > >>> +#include > >>> +#include > >>> + > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> + > >>> +#include "meson_drv.h" > >>> +#include "meson_dw_mipi_dsi.h" > >>> +#include "meson_registers.h" > >>> +#include "meson_venc.h" > >>> + > >>> +#define DRIVER_NAME "meson-dw-mipi-dsi" > >>> +#define DRIVER_DESC "Amlogic Meson MIPI-DSI DRM driver" > >>> + > >>> +/* MIPI DSI/VENC Color Format Def
Re: [PATCH v1 0/2] video: fbdev: radeonfb: PCI PM framework upgrade and fix-ups.
On Mon, Sep 07, 2020 at 02:46:21PM +0530, Vaibhav Gupta wrote: > On Mon, Sep 07, 2020 at 09:55:59AM +0200, Daniel Vetter wrote: > > On Thu, Aug 06, 2020 at 12:52:54PM +0530, Vaibhav Gupta wrote: > > > Linux Kernel Mentee: Remove Legacy Power Management. > > > > > > The original goal of the patch series is to upgrade the power management > > > framework of radeonfb fbdev driver. This has been done by upgrading > > > .suspend() > > > and .resume() callbacks. > > > > > > The upgrade makes sure that the involvement of PCI Core does not change > > > the > > > order of operations executed in a driver. Thus, does not change its > > > behavior. > > > > > > During this process, it was found that "#if defined(CONFIG_PM)" at line > > > 1434 is > > > redundant. This was introduced in the commit > > > 42ddb453a0cd ("radeon: Conditionally compile PM code"). > > > > I do wonder whether it wouldn't be better to just outright delete these, > > we have the drm radeon driver for pretty much all the same hardware ... > > -Daniel > > > Hello Daniel, > I don't have any problem in either way. My priority is to get rid of the > legacy .suspend and .resume pointers from "struct pci_driver" . Hence, > modifying > every driver that is using them. Ok, also sounds like we can't just ditch it outright and merging your patches makes sense. Please note that Bart (he's usually picking up the fbdev patches) is on vacations until next week, I guess he'll then go and vacuum up everything for 5.10 as he usually does. Cheers, Daniel > > Vaibhav Gupta > > > > > > > > > > > > Before 42ddb453a0cd: > > > $ git show 65122f7e80b5:drivers/video/aty/radeon_pm.c | grep -n > > > "#ifdef\|#if\|#else\|#endif\|#elif\|#ifndef" > > > > > > Based on output in terminal: > > > > > > 547:#ifdef CONFIG_PM > > >|-- 959:#ifdef CONFIG_PPC_PMAC > > >|-- 972:#endif > > >|-- 1291:#ifdef CONFIG_PPC_OF > > >|-- 1301:#endif /* CONFIG_PPC_OF */ > > >|-- 1943:#ifdef CONFIG_PPC_OF > > >|-- 2206:#if 0 /* Not ready yet */ > > >|-- 2508:#endif /* 0 */ > > >|-- 2510:#endif /* CONFIG_PPC_OF */ > > >|-- 2648:#ifdef CONFIG_PPC_PMAC > > >|-- 2654:#endif /* CONFIG_PPC_PMAC */ > > >|-- 2768:#ifdef CONFIG_PPC_PMAC > > >|-- 2774:#endif /* CONFIG_PPC_PMAC */ > > >|-- 2791:#ifdef CONFIG_PPC_OF__disabled > > >|-- 2801:#endif /* CONFIG_PPC_OF */ > > > 2803:#endif /* CONFIG_PM */ > > > > > > > > > > > > After 42ddb453a0cd: > > > $ git show 42ddb453a0cd:drivers/video/aty/radeon_pm.c | grep -n > > > "#ifdef\|#if\|#else\|#endif\|#elif\|#ifndef" > > > > > > Based on output in terminal: > > > > > > 547:#ifdef CONFIG_PM > > >|-- 959:#ifdef CONFIG_PPC_PMAC > > >|-- 972:#endif > > >|-- 1291:#ifdef CONFIG_PPC_OF > > >|-- 1301:#endif /* CONFIG_PPC_OF */ > > >|-- 1430:#if defined(CONFIG_PM) > > >|-- 1431:#if defined(CONFIG_X86) || > > > defined(CONFIG_PPC_PMAC) > > >|-- 1944:#endif > > >|-- 1946:#ifdef CONFIG_PPC_OF > > >|-- 1947:#ifdef CONFIG_PPC_PMAC > > >|-- 2208:#endif > > >|-- 2209:#endif > > >|-- 2211:#if 0 /* Not ready yet */ > > >|-- 2513:#endif /* 0 */ > > >|-- 2515:#endif /* CONFIG_PPC_OF */ > > >|-- 2653:#ifdef CONFIG_PPC_PMAC > > >|-- 2659:#endif /* CONFIG_PPC_PMAC */ > > >|-- 2773:#ifdef CONFIG_PPC_PMAC > > >|-- 2779:#endif /* CONFIG_PPC_PMAC */ > > >|-- 2796:#ifdef CONFIG_PPC_OF__disabled > > >|-- 2806:#endif /* CONFIG_PPC_OF */ > > > 2808:#endif /* CONFIG_PM */ > > > > > > > > > > > > This also affected the CONFIG_PPC_OF container (line 1943 at commit > > > 65122f7e80b5) > > > > > > The patch-series fixes it along with PM upgrade. > > > > > > All patches are compile-tested only. > > > > > > Test tools: > > > - Compiler: gcc (GCC) 10.1.0 > > > - allmodconfig build: make -j$(nproc) W=1 all > > > > > > Vaibhav Gupta (2): > > > video: fbdev: aty: radeon_pm: remove redundant CONFIG_PM container > > > fbdev: radeonfb:use generic power management > > > > > > drivers/video/fbdev/aty/radeon_base.c | 10 --- > > > drivers/video/fbdev/aty/radeon_pm.c | 38 --- > > > drivers/video/fbdev/aty/radeonfb.h| 3 +-- > > > 3 files changed, 35 insertions(+), 16 deletions(-) > > > > > > -- > > > 2.27.0 > > > > > > ___ > > > dri-devel mailing list > > > dri-devel@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch > ___ > dri-devel mailing list > dri-devel@lists.fre
[PATCH 1/2] drm/msm/dpu: move vblank events to complete_commit()
From: Rob Clark We could get a vblank event racing with the current atomic commit, resulting in sending the pageflip event to userspace early, causing tearing. On the other hand, complete_commit() ensures that the pending flush is complete. Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c index c2729f71e2fa..89c0245b5de5 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c @@ -297,7 +297,6 @@ void dpu_crtc_vblank_callback(struct drm_crtc *crtc) dpu_crtc->vblank_cb_time = ktime_get(); else dpu_crtc->vblank_cb_count++; - _dpu_crtc_complete_flip(crtc); drm_crtc_handle_vblank(crtc); trace_dpu_crtc_vblank_cb(DRMID(crtc)); } @@ -402,6 +401,7 @@ static void dpu_crtc_frame_event_cb(void *data, u32 event) void dpu_crtc_complete_commit(struct drm_crtc *crtc) { trace_dpu_crtc_complete_commit(DRMID(crtc)); + _dpu_crtc_complete_flip(crtc); } static void _dpu_crtc_setup_lm_bounds(struct drm_crtc *crtc, -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/msm/dpu: clean up some impossibilities
From: Rob Clark Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 81 1 file changed, 12 insertions(+), 69 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c index 89c0245b5de5..ad49b0e17fcb 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c @@ -265,11 +265,6 @@ enum dpu_intf_mode dpu_crtc_get_intf_mode(struct drm_crtc *crtc) { struct drm_encoder *encoder; - if (!crtc) { - DPU_ERROR("invalid crtc\n"); - return INTF_MODE_NONE; - } - /* * TODO: This function is called from dpu debugfs and as part of atomic * check. When called from debugfs, the crtc->mutex must be held to @@ -500,12 +495,6 @@ static void dpu_crtc_atomic_begin(struct drm_crtc *crtc, struct dpu_crtc_state *cstate; struct drm_encoder *encoder; struct drm_device *dev; - unsigned long flags; - - if (!crtc) { - DPU_ERROR("invalid crtc\n"); - return; - } if (!crtc->state->enable) { DPU_DEBUG("crtc%d -> enable %d, skip atomic_begin\n", @@ -521,15 +510,6 @@ static void dpu_crtc_atomic_begin(struct drm_crtc *crtc, _dpu_crtc_setup_lm_bounds(crtc, crtc->state); - if (dpu_crtc->event) { - WARN_ON(dpu_crtc->event); - } else { - spin_lock_irqsave(&dev->event_lock, flags); - dpu_crtc->event = crtc->state->event; - crtc->state->event = NULL; - spin_unlock_irqrestore(&dev->event_lock, flags); - } - /* encoder will trigger pending mask now */ drm_for_each_encoder_mask(encoder, crtc->dev, crtc->state->encoder_mask) dpu_encoder_trigger_kickoff_pending(encoder); @@ -583,14 +563,11 @@ static void dpu_crtc_atomic_flush(struct drm_crtc *crtc, return; } - if (dpu_crtc->event) { - DPU_DEBUG("already received dpu_crtc->event\n"); - } else { - spin_lock_irqsave(&dev->event_lock, flags); - dpu_crtc->event = crtc->state->event; - crtc->state->event = NULL; - spin_unlock_irqrestore(&dev->event_lock, flags); - } + WARN_ON(dpu_crtc->event); + spin_lock_irqsave(&dev->event_lock, flags); + dpu_crtc->event = crtc->state->event; + crtc->state->event = NULL; + spin_unlock_irqrestore(&dev->event_lock, flags); /* * If no mixers has been allocated in dpu_crtc_atomic_check(), @@ -635,14 +612,7 @@ static void dpu_crtc_atomic_flush(struct drm_crtc *crtc, static void dpu_crtc_destroy_state(struct drm_crtc *crtc, struct drm_crtc_state *state) { - struct dpu_crtc_state *cstate; - - if (!crtc || !state) { - DPU_ERROR("invalid argument(s)\n"); - return; - } - - cstate = to_dpu_crtc_state(state); + struct dpu_crtc_state *cstate = to_dpu_crtc_state(state); DPU_DEBUG("crtc%d\n", crtc->base.id); @@ -731,14 +701,8 @@ static void dpu_crtc_reset(struct drm_crtc *crtc) */ static struct drm_crtc_state *dpu_crtc_duplicate_state(struct drm_crtc *crtc) { - struct dpu_crtc_state *cstate, *old_cstate; - - if (!crtc || !crtc->state) { - DPU_ERROR("invalid argument(s)\n"); - return NULL; - } + struct dpu_crtc_state *cstate, *old_cstate = to_dpu_crtc_state(crtc->state); - old_cstate = to_dpu_crtc_state(crtc->state); cstate = kmemdup(old_cstate, sizeof(*old_cstate), GFP_KERNEL); if (!cstate) { DPU_ERROR("failed to allocate state\n"); @@ -754,19 +718,12 @@ static struct drm_crtc_state *dpu_crtc_duplicate_state(struct drm_crtc *crtc) static void dpu_crtc_disable(struct drm_crtc *crtc, struct drm_crtc_state *old_crtc_state) { - struct dpu_crtc *dpu_crtc; - struct dpu_crtc_state *cstate; + struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc); + struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc->state); struct drm_encoder *encoder; unsigned long flags; bool release_bandwidth = false; - if (!crtc || !crtc->state) { - DPU_ERROR("invalid crtc\n"); - return; - } - dpu_crtc = to_dpu_crtc(crtc); - cstate = to_dpu_crtc_state(crtc->state); - DRM_DEBUG_KMS("crtc%d\n", crtc->base.id); /* Disable/save vblank irq handling */ @@ -825,19 +782,13 @@ static void dpu_crtc_disable(struct drm_crtc *crtc, static void dpu_crtc_enable(struct drm_crtc *crtc, struct drm_crtc_state *old_crtc_state) { - struct dpu_crtc *dpu_crtc; + struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc); struct drm_encoder *encoder; bool request_bandwidth = false; -
[Bug 208997] WARNING: CPU: 3 PID: 1633 at drivers/gpu/drm/drm_modeset_lock.c
https://bugzilla.kernel.org/show_bug.cgi?id=208997 Martin (martin...@gmx.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #2 from Martin (martin...@gmx.com) --- After upgrading to 5.8.6 I don't see the messages any more. Cheers. -- 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
[PATCH AUTOSEL 5.4 41/43] drm/amdgpu: Fix bug in reporting voltage for CIK
From: Sandeep Raghuraman [ Upstream commit d98299885c9ea140c1108545186593deba36c4ac ] On my R9 390, the voltage was reported as a constant 1000 mV. This was due to a bug in smu7_hwmgr.c, in the smu7_read_sensor() function, where some magic constants were used in a condition, to determine whether the voltage should be read from PLANE2_VID or PLANE1_VID. The VDDC mask was incorrectly used, instead of the VDDGFX mask. This patch changes the code to use the correct defined constants (and apply the correct bitshift), thus resulting in correct voltage reporting. Signed-off-by: Sandeep Raghuraman Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c index e6da53e9c3f46..3a2a1dc9a786a 100644 --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c @@ -3575,7 +3575,8 @@ static int smu7_read_sensor(struct pp_hwmgr *hwmgr, int idx, case AMDGPU_PP_SENSOR_GPU_POWER: return smu7_get_gpu_power(hwmgr, (uint32_t *)value); case AMDGPU_PP_SENSOR_VDDGFX: - if ((data->vr_config & 0xff) == 0x2) + if ((data->vr_config & VRCONF_VDDGFX_MASK) == + (VR_SVI2_PLANE_2 << VRCONF_VDDGFX_SHIFT)) val_vid = PHM_READ_INDIRECT_FIELD(hwmgr->device, CGS_IND_REG__SMC, PWR_SVI2_STATUS, PLANE2_VID); else -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 24/26] drm/amdgpu: Fix bug in reporting voltage for CIK
From: Sandeep Raghuraman [ Upstream commit d98299885c9ea140c1108545186593deba36c4ac ] On my R9 390, the voltage was reported as a constant 1000 mV. This was due to a bug in smu7_hwmgr.c, in the smu7_read_sensor() function, where some magic constants were used in a condition, to determine whether the voltage should be read from PLANE2_VID or PLANE1_VID. The VDDC mask was incorrectly used, instead of the VDDGFX mask. This patch changes the code to use the correct defined constants (and apply the correct bitshift), thus resulting in correct voltage reporting. Signed-off-by: Sandeep Raghuraman Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c index 219440bebd052..72c0a2ae2dd4f 100644 --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c @@ -3566,7 +3566,8 @@ static int smu7_read_sensor(struct pp_hwmgr *hwmgr, int idx, case AMDGPU_PP_SENSOR_GPU_POWER: return smu7_get_gpu_power(hwmgr, (uint32_t *)value); case AMDGPU_PP_SENSOR_VDDGFX: - if ((data->vr_config & 0xff) == 0x2) + if ((data->vr_config & VRCONF_VDDGFX_MASK) == + (VR_SVI2_PLANE_2 << VRCONF_VDDGFX_SHIFT)) val_vid = PHM_READ_INDIRECT_FIELD(hwmgr->device, CGS_IND_REG__SMC, PWR_SVI2_STATUS, PLANE2_VID); else -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 50/53] drm/amdgpu: Fix bug in reporting voltage for CIK
From: Sandeep Raghuraman [ Upstream commit d98299885c9ea140c1108545186593deba36c4ac ] On my R9 390, the voltage was reported as a constant 1000 mV. This was due to a bug in smu7_hwmgr.c, in the smu7_read_sensor() function, where some magic constants were used in a condition, to determine whether the voltage should be read from PLANE2_VID or PLANE1_VID. The VDDC mask was incorrectly used, instead of the VDDGFX mask. This patch changes the code to use the correct defined constants (and apply the correct bitshift), thus resulting in correct voltage reporting. Signed-off-by: Sandeep Raghuraman Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c index 753cb2cf6b77e..3adf9c1dfdbb0 100644 --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c @@ -3587,7 +3587,8 @@ static int smu7_read_sensor(struct pp_hwmgr *hwmgr, int idx, case AMDGPU_PP_SENSOR_GPU_POWER: return smu7_get_gpu_power(hwmgr, (uint32_t *)value); case AMDGPU_PP_SENSOR_VDDGFX: - if ((data->vr_config & 0xff) == 0x2) + if ((data->vr_config & VRCONF_VDDGFX_MASK) == + (VR_SVI2_PLANE_2 << VRCONF_VDDGFX_SHIFT)) val_vid = PHM_READ_INDIRECT_FIELD(hwmgr->device, CGS_IND_REG__SMC, PWR_SVI2_STATUS, PLANE2_VID); else -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: mxsfb: check framebuffer pitch
Hi Stefan, Thank you for the patch. On Mon, Sep 07, 2020 at 06:03:43PM +0200, Stefan Agner wrote: > The lcdif IP does not support a framebuffer pitch (stride) other than > the CRTC width. Check for equality and reject the state otherwise. > > This prevents a distorted picture when using 640x800 and running the > Mesa graphics stack. Mesa tires to use a cache aligned stride, which s/tires/tries/ > leads at that particular resolution to width != stride. Currently > Mesa has no fallback behavior, but rejecting this configuration allows > userspace to handle the issue correctly. I'm increasingly impressed by how featureful this IP core is :-) > Signed-off-by: Stefan Agner > --- > drivers/gpu/drm/mxsfb/mxsfb_kms.c | 22 ++ > 1 file changed, 18 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c > b/drivers/gpu/drm/mxsfb/mxsfb_kms.c > index b721b8b262ce..79aa14027f91 100644 > --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c > +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c > @@ -403,14 +403,28 @@ static int mxsfb_plane_atomic_check(struct drm_plane > *plane, > { > struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(plane->dev); > struct drm_crtc_state *crtc_state; > + unsigned int pitch; > + int ret; > > crtc_state = drm_atomic_get_new_crtc_state(plane_state->state, > &mxsfb->crtc); > > - return drm_atomic_helper_check_plane_state(plane_state, crtc_state, > -DRM_PLANE_HELPER_NO_SCALING, > -DRM_PLANE_HELPER_NO_SCALING, > -false, true); > + ret = drm_atomic_helper_check_plane_state(plane_state, crtc_state, > + DRM_PLANE_HELPER_NO_SCALING, > + DRM_PLANE_HELPER_NO_SCALING, > + false, true); > + if (ret || !plane_state->visible) Would it be more explict to check for !plane_state->fb ? Otherwise I'll have to verify that !fb always implies !visible :-) > + return ret; > + > + pitch = crtc_state->mode.hdisplay * > + plane_state->fb->format->cpp[0]; This holds on a single line. > + if (plane_state->fb->pitches[0] != pitch) { > + dev_err(plane->dev->dev, > + "Invalid pitch: fb and crtc widths must be the same"); I'd turn this into a dev_dbg(), printing error messages to the kernel log in response to user-triggered conditions is a bit too verbose and could flood the log. Wouldn't it be best to catch this issue when creating the framebuffer ? > + return -EINVAL; > + } > + > + return 0; > } > > static void mxsfb_plane_primary_atomic_update(struct drm_plane *plane, -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: mxsfb: check framebuffer pitch
The lcdif IP does not support a framebuffer pitch (stride) other than the CRTC width. Check for equality and reject the state otherwise. This prevents a distorted picture when using 640x800 and running the Mesa graphics stack. Mesa tires to use a cache aligned stride, which leads at that particular resolution to width != stride. Currently Mesa has no fallback behavior, but rejecting this configuration allows userspace to handle the issue correctly. Signed-off-by: Stefan Agner --- drivers/gpu/drm/mxsfb/mxsfb_kms.c | 22 ++ 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c b/drivers/gpu/drm/mxsfb/mxsfb_kms.c index b721b8b262ce..79aa14027f91 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c @@ -403,14 +403,28 @@ static int mxsfb_plane_atomic_check(struct drm_plane *plane, { struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(plane->dev); struct drm_crtc_state *crtc_state; + unsigned int pitch; + int ret; crtc_state = drm_atomic_get_new_crtc_state(plane_state->state, &mxsfb->crtc); - return drm_atomic_helper_check_plane_state(plane_state, crtc_state, - DRM_PLANE_HELPER_NO_SCALING, - DRM_PLANE_HELPER_NO_SCALING, - false, true); + ret = drm_atomic_helper_check_plane_state(plane_state, crtc_state, + DRM_PLANE_HELPER_NO_SCALING, + DRM_PLANE_HELPER_NO_SCALING, + false, true); + if (ret || !plane_state->visible) + return ret; + + pitch = crtc_state->mode.hdisplay * + plane_state->fb->format->cpp[0]; + if (plane_state->fb->pitches[0] != pitch) { + dev_err(plane->dev->dev, + "Invalid pitch: fb and crtc widths must be the same"); + return -EINVAL; + } + + return 0; } static void mxsfb_plane_primary_atomic_update(struct drm_plane *plane, -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/9] arm64: dts: renesas: r8a77961: Add VSP device nodes
Hi Morimoto-san, On 07/09/2020 03:59, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > This patch adds VSP device nodes for R-Car M3-W+ (r8a77961) SoC. > This patch is test on R-Car M3-W+ Salvator-XS board. > > Signed-off-by: Kuninori Morimoto > --- > arch/arm64/boot/dts/renesas/r8a77961.dtsi | 55 +++ > 1 file changed, 55 insertions(+) > > diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi > b/arch/arm64/boot/dts/renesas/r8a77961.dtsi > index fe0db11b9cb9..c2a6918ed5e6 100644 > --- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi > +++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi > @@ -2056,6 +2056,61 @@ fcpvd2: fcp@fea37000 { > iommus = <&ipmmu_vi0 10>; > }; The FCP's added are: fcpf0: fcp@fe95 { fcpf1: fcp@fe951000 { fcpvb0: fcp@fe96f000 { fcpvb1: fcp@fe92f000 { fcpvi0: fcp@fe9af000 { fcpvi1: fcp@fe9bf000 { fcpvd0: fcp@fea27000 { fcpvd1: fcp@fea2f000 { fcpvd2: fcp@fea37000 { So indeed, the first fcpf0 comes before fe96. Do we keep the items grouped by the first occurrence? or sort the nodes based on address? for some reason I thought we were ordering based on address, but I see other situations where we group too - so I'm confused (and wishing there was an automatic tool to get the sorting correct without fuss). Is there a set policy? -- Kieran > + vspb: vsp@fe96 { > + compatible = "renesas,vsp2"; > + reg = <0 0xfe96 0 0x8000>; > + interrupts = ; > + clocks = <&cpg CPG_MOD 626>; > + power-domains = <&sysc R8A77961_PD_A3VC>; > + resets = <&cpg 626>; > + > + renesas,fcp = <&fcpvb0>; > + }; > + > + vspd0: vsp@fea2 { > + compatible = "renesas,vsp2"; > + reg = <0 0xfea2 0 0x5000>; > + interrupts = ; > + clocks = <&cpg CPG_MOD 623>; > + power-domains = <&sysc R8A77961_PD_ALWAYS_ON>; > + resets = <&cpg 623>; > + > + renesas,fcp = <&fcpvd0>; > + }; > + > + vspd1: vsp@fea28000 { > + compatible = "renesas,vsp2"; > + reg = <0 0xfea28000 0 0x5000>; > + interrupts = ; > + clocks = <&cpg CPG_MOD 622>; > + power-domains = <&sysc R8A77961_PD_ALWAYS_ON>; > + resets = <&cpg 622>; > + > + renesas,fcp = <&fcpvd1>; > + }; > + > + vspd2: vsp@fea3 { > + compatible = "renesas,vsp2"; > + reg = <0 0xfea3 0 0x5000>; > + interrupts = ; > + clocks = <&cpg CPG_MOD 621>; > + power-domains = <&sysc R8A77961_PD_ALWAYS_ON>; > + resets = <&cpg 621>; > + > + renesas,fcp = <&fcpvd2>; > + }; > + > + vspi0: vsp@fe9a { > + compatible = "renesas,vsp2"; > + reg = <0 0xfe9a 0 0x8000>; > + interrupts = ; > + clocks = <&cpg CPG_MOD 631>; > + power-domains = <&sysc R8A77961_PD_A3VC>; > + resets = <&cpg 631>; > + > + renesas,fcp = <&fcpvi0>; > + }; > + > csi20: csi2@fea8 { > reg = <0 0xfea8 0 0x1>; > /* placeholder */ > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 30/30] videobuf2: use sgtable-based scatterlist wrappers
On Mon, Sep 7, 2020 at 4:02 PM Marek Szyprowski wrote: > > Hi Tomasz, > > On 07.09.2020 15:07, Tomasz Figa wrote: > > On Fri, Sep 4, 2020 at 3:35 PM Marek Szyprowski > > wrote: > >> Use recently introduced common wrappers operating directly on the struct > >> sg_table objects and scatterlist page iterators to make the code a bit > >> more compact, robust, easier to follow and copy/paste safe. > >> > >> No functional change, because the code already properly did all the > >> scatterlist related calls. > >> > >> Signed-off-by: Marek Szyprowski > >> Reviewed-by: Robin Murphy > >> --- > >> .../common/videobuf2/videobuf2-dma-contig.c | 34 --- > >> .../media/common/videobuf2/videobuf2-dma-sg.c | 32 +++-- > >> .../common/videobuf2/videobuf2-vmalloc.c | 12 +++ > >> 3 files changed, 31 insertions(+), 47 deletions(-) > >> > > Thanks for the patch! Please see my comments inline. > > > >> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c > >> b/drivers/media/common/videobuf2/videobuf2-dma-contig.c > >> index ec3446cc45b8..1b242d844dde 100644 > >> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c > >> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c > >> @@ -58,10 +58,10 @@ static unsigned long vb2_dc_get_contiguous_size(struct > >> sg_table *sgt) > >> unsigned int i; > >> unsigned long size = 0; > >> > >> - for_each_sg(sgt->sgl, s, sgt->nents, i) { > >> + for_each_sgtable_dma_sg(sgt, s, i) { > >> if (sg_dma_address(s) != expected) > >> break; > >> - expected = sg_dma_address(s) + sg_dma_len(s); > >> + expected += sg_dma_len(s); > >> size += sg_dma_len(s); > >> } > >> return size; > >> @@ -103,8 +103,7 @@ static void vb2_dc_prepare(void *buf_priv) > >> if (!sgt) > >> return; > >> > >> - dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents, > >> - buf->dma_dir); > >> + dma_sync_sgtable_for_device(buf->dev, sgt, buf->dma_dir); > >> } > >> > >> static void vb2_dc_finish(void *buf_priv) > >> @@ -115,7 +114,7 @@ static void vb2_dc_finish(void *buf_priv) > >> if (!sgt) > >> return; > >> > >> - dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents, > >> buf->dma_dir); > >> + dma_sync_sgtable_for_cpu(buf->dev, sgt, buf->dma_dir); > >> } > >> > >> /*/ > >> @@ -275,8 +274,8 @@ static void vb2_dc_dmabuf_ops_detach(struct dma_buf > >> *dbuf, > >> * memory locations do not require any explicit cache > >> * maintenance prior or after being used by the device. > >> */ > >> - dma_unmap_sg_attrs(db_attach->dev, sgt->sgl, > >> sgt->orig_nents, > >> - attach->dma_dir, > >> DMA_ATTR_SKIP_CPU_SYNC); > >> + dma_unmap_sgtable(db_attach->dev, sgt, attach->dma_dir, > >> + DMA_ATTR_SKIP_CPU_SYNC); > >> sg_free_table(sgt); > >> kfree(attach); > >> db_attach->priv = NULL; > >> @@ -301,8 +300,8 @@ static struct sg_table *vb2_dc_dmabuf_ops_map( > >> > >> /* release any previous cache */ > >> if (attach->dma_dir != DMA_NONE) { > >> - dma_unmap_sg_attrs(db_attach->dev, sgt->sgl, > >> sgt->orig_nents, > >> - attach->dma_dir, > >> DMA_ATTR_SKIP_CPU_SYNC); > >> + dma_unmap_sgtable(db_attach->dev, sgt, attach->dma_dir, > >> + DMA_ATTR_SKIP_CPU_SYNC); > >> attach->dma_dir = DMA_NONE; > >> } > >> > >> @@ -310,9 +309,8 @@ static struct sg_table *vb2_dc_dmabuf_ops_map( > >> * mapping to the client with new direction, no cache sync > >> * required see comment in vb2_dc_dmabuf_ops_detach() > >> */ > >> - sgt->nents = dma_map_sg_attrs(db_attach->dev, sgt->sgl, > >> sgt->orig_nents, > >> - dma_dir, DMA_ATTR_SKIP_CPU_SYNC); > >> - if (!sgt->nents) { > >> + if (dma_map_sgtable(db_attach->dev, sgt, dma_dir, > >> + DMA_ATTR_SKIP_CPU_SYNC)) { > >> pr_err("failed to map scatterlist\n"); > >> mutex_unlock(lock); > >> return ERR_PTR(-EIO); > > As opposed to dma_map_sg_attrs(), dma_map_sgtable() now returns an > > error code on its own. Is it expected to ignore it and return -EIO? > > Those errors are more or less propagated to userspace and -EIO has been > already widely documented in V4L2 documentation as the error code for > the most of the V4L2 ioctls. I don't want to change it. A possible > -EINVAL returned from dma_map_sgtable() was just one of the 'generic' > error codes, not very descriptive in that case. Prob
Re: [PATCH v2 03/11] drm/amd/display: Honor the offset for plane 0.
Hi [This is an automated email] This commit has been processed because it contains a -stable tag. The stable tag indicates that it's relevant for the following trees: all The bot has tested the following trees: v5.8.7, v5.4.63, v4.19.143, v4.14.196, v4.9.235, v4.4.235. v5.8.7: Build OK! v5.4.63: Build OK! v4.19.143: Failed to apply! Possible dependencies: 180db303ff46 ("drm/amd/display: Add below the range support for FreeSync") 7df7e505e82a ("drm/amd/display: Set requested plane state DCC params for GFX9") 8c3db1284a01 ("drm/amdgpu: fill in amdgpu_dm_remove_sink_from_freesync_module") 98e6436d3af5 ("drm/amd/display: Refactor FreeSync module") c1ee92f94ce3 ("drm/amd: Add abm level drm property") d999853e60a0 ("drm/amd/display: Guard against null stream dereference in do flip") e5d0170e5644 ("drm/amd/display: Use non-deprecated vblank handler") v4.14.196: Failed to apply! Possible dependencies: 1b0c0f9dc5ca ("drm/amdgpu: move userptr BOs to CPU domain during CS v2") 3fe89771cb0a ("drm/amdgpu: stop reserving the BO in the MMU callback v3") 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") 60de1c1740f3 ("drm/amdgpu: use a rw_semaphore for MMU notifiers") 7df7e505e82a ("drm/amd/display: Set requested plane state DCC params for GFX9") 9a18999640fa ("drm/amdgpu: move MMU notifier related defines to amdgpu_mn.h") 9cca0b8e5df0 ("drm/amdgpu: move amdgpu_cs_sysvm_access_required into find_mapping") a216ab09955d ("drm/amdgpu: fix userptr put_page handling") b72cf4fca2bb ("drm/amdgpu: move taking mmap_sem into get_user_pages v2") ca666a3c298f ("drm/amdgpu: stop using BO status for user pages") e7b07ceef2a6 ("drm/amd/display: Merge amdgpu_dm_types and amdgpu_dm") v4.9.235: Failed to apply! Possible dependencies: 1cec20f0ea0e ("dma-buf: Restart reservation_object_wait_timeout_rcu() after writes") 248a1d6f1ac4 ("drm/amd: fix include notation and remove -Iinclude/drm flag") 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") 78010cd9736e ("dma-buf/fence: add an lockdep_assert_held()") 7df7e505e82a ("drm/amd/display: Set requested plane state DCC params for GFX9") e7b07ceef2a6 ("drm/amd/display: Merge amdgpu_dm_types and amdgpu_dm") f54d1867005c ("dma-buf: Rename struct fence to dma_fence") fedf54132d24 ("dma-buf: Restart reservation_object_get_fences_rcu() after writes") v4.4.235: Failed to apply! Possible dependencies: 0f477c6dea70 ("staging/android/sync: add sync_fence_create_dma") 1f7371b2a5fa ("drm/amd/powerplay: add basic powerplay framework") 248a1d6f1ac4 ("drm/amd: fix include notation and remove -Iinclude/drm flag") 288912cb95d1 ("drm/amdgpu: use $(src) in Makefile (v2)") 375fb53ec1be ("staging: android: replace explicit NULL comparison") 395dec6f6bc5 ("Documentation: add doc for sync_file_get_fence()") 4325198180e5 ("drm/amdgpu: remove GART page addr array") 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") 62304fb1fc08 ("dma-buf/sync_file: de-stage sync_file") 7df7e505e82a ("drm/amd/display: Set requested plane state DCC params for GFX9") a1d29476d666 ("drm/amdgpu: optionally enable GART debugfs file") a8fe58cec351 ("drm/amd: add ACP driver support") b70f014d58b9 ("drm/amdgpu: change default sched jobs to 32") c784c82a3fd6 ("Documentation: add Sync File doc") d4cab38e153d ("staging/android: prepare sync_file for de-staging") d7fdb0ae9d11 ("staging/android: rename sync_fence to sync_file") e7b07ceef2a6 ("drm/amd/display: Merge amdgpu_dm_types and amdgpu_dm") f54d1867005c ("dma-buf: Rename struct fence to dma_fence") fac8434dab96 ("Documentation: Fix some grammar mistakes in sync_file.txt") fdba11f4079e ("drm/amdgpu: move all Kconfig options to amdgpu/Kconfig") NOTE: The patch will not be queued to stable trees until it is upstream. How should we proceed with this patch? -- Thanks Sasha ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/9] dt-bindings: display: renesas: dw-hdmi: Add R8A77961 support
On Mon, Sep 7, 2020 at 4:58 AM Kuninori Morimoto wrote: > From: Kuninori Morimoto > > This patch adds R-Car M3-W+ (R8A77961) SoC bindings. > > Signed-off-by: Kuninori Morimoto Reviewed-by: Geert Uytterhoeven Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] dt-bindings: display: renesas: du: Document the r8a77961 bindings
Hi Morimoto-san, On Mon, Sep 7, 2020 at 4:58 AM Kuninori Morimoto wrote: > From: Kuninori Morimoto > > Document the R-Car M3-W+ (R8A77961) SoC in the R-Car DU bindings. > > Signed-off-by: Kuninori Morimoto Thanks for your patch! > --- a/Documentation/devicetree/bindings/display/renesas,du.txt > +++ b/Documentation/devicetree/bindings/display/renesas,du.txt > @@ -18,6 +18,7 @@ Required Properties: > - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU > - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU > - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU > +- "renesas,du-r8a77961" for R8A77961 (R-Car M3-W+) compatible DU > - "renesas,du-r8a77965" for R8A77965 (R-Car M3-N) compatible DU > - "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU > - "renesas,du-r8a77980" for R8A77980 (R-Car V3H) compatible DU Looks good to me, but please also add an entry to the table below describing the port mappings. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/9] arm64: dts: renesas: r8a77961: Add VSP device nodes
On 07.09.2020 5:59, Kuninori Morimoto wrote: From: Kuninori Morimoto This patch adds VSP device nodes for R-Car M3-W+ (r8a77961) SoC. This patch is test on R-Car M3-W+ Salvator-XS board. Was tested? Signed-off-by: Kuninori Morimoto [...] MBR, Sergei ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 0/2] video: fbdev: radeonfb: PCI PM framework upgrade and fix-ups.
On Mon, Sep 07, 2020 at 09:55:59AM +0200, Daniel Vetter wrote: > On Thu, Aug 06, 2020 at 12:52:54PM +0530, Vaibhav Gupta wrote: > > Linux Kernel Mentee: Remove Legacy Power Management. > > > > The original goal of the patch series is to upgrade the power management > > framework of radeonfb fbdev driver. This has been done by upgrading > > .suspend() > > and .resume() callbacks. > > > > The upgrade makes sure that the involvement of PCI Core does not change the > > order of operations executed in a driver. Thus, does not change its > > behavior. > > > > During this process, it was found that "#if defined(CONFIG_PM)" at line > > 1434 is > > redundant. This was introduced in the commit > > 42ddb453a0cd ("radeon: Conditionally compile PM code"). > > I do wonder whether it wouldn't be better to just outright delete these, > we have the drm radeon driver for pretty much all the same hardware ... > -Daniel > Hello Daniel, I don't have any problem in either way. My priority is to get rid of the legacy .suspend and .resume pointers from "struct pci_driver" . Hence, modifying every driver that is using them. Vaibhav Gupta > > > > > > > > Before 42ddb453a0cd: > > $ git show 65122f7e80b5:drivers/video/aty/radeon_pm.c | grep -n > > "#ifdef\|#if\|#else\|#endif\|#elif\|#ifndef" > > > > Based on output in terminal: > > > > 547:#ifdef CONFIG_PM > >|-- 959:#ifdef CONFIG_PPC_PMAC > >|-- 972:#endif > >|-- 1291:#ifdef CONFIG_PPC_OF > >|-- 1301:#endif /* CONFIG_PPC_OF */ > >|-- 1943:#ifdef CONFIG_PPC_OF > >|-- 2206:#if 0 /* Not ready yet */ > >|-- 2508:#endif /* 0 */ > >|-- 2510:#endif /* CONFIG_PPC_OF */ > >|-- 2648:#ifdef CONFIG_PPC_PMAC > >|-- 2654:#endif /* CONFIG_PPC_PMAC */ > >|-- 2768:#ifdef CONFIG_PPC_PMAC > >|-- 2774:#endif /* CONFIG_PPC_PMAC */ > >|-- 2791:#ifdef CONFIG_PPC_OF__disabled > >|-- 2801:#endif /* CONFIG_PPC_OF */ > > 2803:#endif /* CONFIG_PM */ > > > > > > > > After 42ddb453a0cd: > > $ git show 42ddb453a0cd:drivers/video/aty/radeon_pm.c | grep -n > > "#ifdef\|#if\|#else\|#endif\|#elif\|#ifndef" > > > > Based on output in terminal: > > > > 547:#ifdef CONFIG_PM > >|-- 959:#ifdef CONFIG_PPC_PMAC > >|-- 972:#endif > >|-- 1291:#ifdef CONFIG_PPC_OF > >|-- 1301:#endif /* CONFIG_PPC_OF */ > >|-- 1430:#if defined(CONFIG_PM) > >|-- 1431:#if defined(CONFIG_X86) || > > defined(CONFIG_PPC_PMAC) > >|-- 1944:#endif > >|-- 1946:#ifdef CONFIG_PPC_OF > >|-- 1947:#ifdef CONFIG_PPC_PMAC > >|-- 2208:#endif > >|-- 2209:#endif > >|-- 2211:#if 0 /* Not ready yet */ > >|-- 2513:#endif /* 0 */ > >|-- 2515:#endif /* CONFIG_PPC_OF */ > >|-- 2653:#ifdef CONFIG_PPC_PMAC > >|-- 2659:#endif /* CONFIG_PPC_PMAC */ > >|-- 2773:#ifdef CONFIG_PPC_PMAC > >|-- 2779:#endif /* CONFIG_PPC_PMAC */ > >|-- 2796:#ifdef CONFIG_PPC_OF__disabled > >|-- 2806:#endif /* CONFIG_PPC_OF */ > > 2808:#endif /* CONFIG_PM */ > > > > > > > > This also affected the CONFIG_PPC_OF container (line 1943 at commit > > 65122f7e80b5) > > > > The patch-series fixes it along with PM upgrade. > > > > All patches are compile-tested only. > > > > Test tools: > > - Compiler: gcc (GCC) 10.1.0 > > - allmodconfig build: make -j$(nproc) W=1 all > > > > Vaibhav Gupta (2): > > video: fbdev: aty: radeon_pm: remove redundant CONFIG_PM container > > fbdev: radeonfb:use generic power management > > > > drivers/video/fbdev/aty/radeon_base.c | 10 --- > > drivers/video/fbdev/aty/radeon_pm.c | 38 --- > > drivers/video/fbdev/aty/radeonfb.h| 3 +-- > > 3 files changed, 35 insertions(+), 16 deletions(-) > > > > -- > > 2.27.0 > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 00/11] PCI: brcmstb: enable PCIe for STB chips
On Thu, Aug 27, 2020 at 09:29:59AM -0400, Jim Quinlan wrote: > On Thu, Aug 27, 2020 at 2:35 AM Christoph Hellwig wrote: > > > > On Tue, Aug 25, 2020 at 10:40:27AM -0700, Florian Fainelli wrote: > > > Hi, > > > > > > On 8/24/2020 12:30 PM, Jim Quinlan wrote: > > >> > > >> Patchset Summary: > > >>Enhance a PCIe host controller driver. Because of its unusual design > > >>we are foced to change dev->dma_pfn_offset into a more general role > > >>allowing multiple offsets. See the 'v1' notes below for more info. > > > > > > We are version 11 and counting, and it is not clear to me whether there is > > > any chance of getting these patches reviewed and hopefully merged for the > > > 5.10 merge window. > > > > > > There are a lot of different files being touched, so what would be the > > > ideal way of routing those changes towards inclusion? > > > > FYI, I offered to take the dma-mapping bits through the dma-mapping tree. > > I have a bit of a backlog, but plan to review and if Jim is ok with that > > apply the current version. > Sounds good to me. Hi Jim, is the dependency now solved ? Should we review/take this series as is for v5.10 through the PCI tree ? Thanks, Lorenzo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu/drm: cleanup coding style a bit
Remove first assignment to info which is meaningless. Put the width and higth check first. This change is to make the code a bit readable. Signed-off-by: Bernard Zhao --- drivers/gpu/drm/drm_framebuffer.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c index df656366a530..2f5b0c2bb0fe 100644 --- a/drivers/gpu/drm/drm_framebuffer.c +++ b/drivers/gpu/drm/drm_framebuffer.c @@ -176,8 +176,7 @@ static int framebuffer_check(struct drm_device *dev, int i; /* check if the format is supported at all */ - info = __drm_format_info(r->pixel_format); - if (!info) { + if (!__drm_format_info(r->pixel_format)) { struct drm_format_name_buf format_name; DRM_DEBUG_KMS("bad framebuffer format %s\n", @@ -186,9 +185,6 @@ static int framebuffer_check(struct drm_device *dev, return -EINVAL; } - /* now let the driver pick its own format info */ - info = drm_get_format_info(dev, r); - if (r->width == 0) { DRM_DEBUG_KMS("bad framebuffer width %u\n", r->width); return -EINVAL; @@ -199,6 +195,9 @@ static int framebuffer_check(struct drm_device *dev, return -EINVAL; } + /* now let the driver pick its own format info */ + info = drm_get_format_info(dev, r); + for (i = 0; i < info->num_planes; i++) { unsigned int width = fb_plane_width(r->width, info, i); unsigned int height = fb_plane_height(r->height, info, i); -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 1/2] i2c: i2c-qcom-geni: Store DMA mapping data in geni_i2c_dev struct
On 2020-08-26 17:25, Akash Asthana wrote: Hi Roja, On 8/20/2020 4:05 PM, Roja Rani Yarubandi wrote: Store DMA mapping data in geni_i2c_dev struct to enhance DMA mapping data scope. For example during shutdown callback to unmap DMA mapping, this stored DMA mapping data can be used to call geni_se_tx_dma_unprep and geni_se_rx_dma_unprep functions. Signed-off-by: Roja Rani Yarubandi --- Changes in V2: - As per Stephen's comments, changed commit text, fixed minor nitpicks. drivers/i2c/busses/i2c-qcom-geni.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c index 7f130829bf01..1fda5c7c2cfc 100644 --- a/drivers/i2c/busses/i2c-qcom-geni.c +++ b/drivers/i2c/busses/i2c-qcom-geni.c @@ -86,6 +86,9 @@ struct geni_i2c_dev { u32 clk_freq_out; const struct geni_i2c_clk_fld *clk_fld; int suspended; + dma_addr_t tx_dma; + dma_addr_t rx_dma; + size_t xfer_len; }; struct geni_i2c_err_log { @@ -358,6 +361,7 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, struct geni_se *se = &gi2c->se; size_t len = msg->len; + gi2c->xfer_len = msg->len; nit: gi2c->xfer = len, for tx_one_msg as well. Regards, Akash Okay if (!of_machine_is_compatible("lenovo,yoga-c630")) dma_buf = i2c_get_dma_safe_msg_buf(msg, 32); @@ -384,6 +388,7 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, if (dma_buf) { if (gi2c->err) geni_i2c_rx_fsm_rst(gi2c); + gi2c->rx_dma = rx_dma; geni_se_rx_dma_unprep(se, rx_dma, len); i2c_put_dma_safe_msg_buf(dma_buf, msg, !gi2c->err); } @@ -400,6 +405,7 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, struct geni_se *se = &gi2c->se; size_t len = msg->len; + gi2c->xfer_len = msg->len; if (!of_machine_is_compatible("lenovo,yoga-c630")) dma_buf = i2c_get_dma_safe_msg_buf(msg, 32); @@ -429,6 +435,7 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, if (dma_buf) { if (gi2c->err) geni_i2c_tx_fsm_rst(gi2c); + gi2c->tx_dma = tx_dma; geni_se_tx_dma_unprep(se, tx_dma, len); i2c_put_dma_safe_msg_buf(dma_buf, msg, !gi2c->err); } ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/msm/dsi: support SM8150 and SM8250
On 04/09/2020 20:28, Jonathan Marek wrote: Add support for SM8150 and SM8250 DSI. Note I haven't tested SM8150 recently, but DSI is almost identical to SM8250. On SM8250: Tested-by: Dmitry Baryshkov Jonathan Marek (3): drm/msm/dsi: remove unused clk_pre/clk_post in msm_dsi_dphy_timing drm/msm/dsi: add DSI config for sm8150 and sm8250 drm/msm/dsi: add support for 7nm DSI PHY/PLL .../devicetree/bindings/display/msm/dsi.txt | 6 +- drivers/gpu/drm/msm/Kconfig | 7 + drivers/gpu/drm/msm/Makefile | 2 + drivers/gpu/drm/msm/dsi/dsi.h | 2 + drivers/gpu/drm/msm/dsi/dsi.xml.h | 423 drivers/gpu/drm/msm/dsi/dsi_cfg.c | 5 +- drivers/gpu/drm/msm/dsi/dsi_cfg.h | 2 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 102 ++ drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 6 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 255 + drivers/gpu/drm/msm/dsi/pll/dsi_pll.c | 4 + drivers/gpu/drm/msm/dsi/pll/dsi_pll.h | 10 + drivers/gpu/drm/msm/dsi/pll/dsi_pll_7nm.c | 902 ++ 13 files changed, 1721 insertions(+), 5 deletions(-) create mode 100644 drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c create mode 100644 drivers/gpu/drm/msm/dsi/pll/dsi_pll_7nm.c -- With best wishes Dmitry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/9] arm64: dts: renesas: r8a77961-salvator-xs: add HDMI Display support
Hello! On 07.09.2020 5:59, Kuninori Morimoto wrote: From: Kuninori Morimoto This patch enables HDMI Display on R-Car M3-W+ Salvator-XS board. This patch is test on R-Car M3-W+ Salvator-XS board. Was tested, perhaps? Signed-off-by: Kuninori Morimoto [...] MBR, Sergei ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 2/2] i2c: i2c-qcom-geni: Add shutdown callback for i2c
On 2020-08-26 17:26, Akash Asthana wrote: Hi Roja, On 8/20/2020 4:05 PM, Roja Rani Yarubandi wrote: If the hardware is still accessing memory after SMMU translation is disabled (as part of smmu shutdown callback), then the IOVAs (I/O virtual address) which it was using will go on the bus as the physical addresses which will result in unknown crashes like NoC/interconnect errors. So, implement shutdown callback to i2c driver to unmap DMA mappings during system "reboot" or "shutdown". Signed-off-by: Roja Rani Yarubandi --- Changes in V2: - As per Stephen's comments added seperate function for stop transfer, fixed minor nitpicks. drivers/i2c/busses/i2c-qcom-geni.c | 43 ++ include/linux/qcom-geni-se.h | 5 2 files changed, 48 insertions(+) diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c index 1fda5c7c2cfc..d07f2f33bb75 100644 --- a/drivers/i2c/busses/i2c-qcom-geni.c +++ b/drivers/i2c/busses/i2c-qcom-geni.c @@ -486,6 +486,28 @@ static int geni_i2c_xfer(struct i2c_adapter *adap, return ret; } +static void geni_i2c_stop_xfer(struct geni_i2c_dev *gi2c) +{ + u32 val; + struct geni_se *se = &gi2c->se; + + val = readl_relaxed(gi2c->se.base + SE_DMA_DEBUG_REG0); + if (val & DMA_TX_ACTIVE) { + geni_i2c_abort_xfer(gi2c); + gi2c->cur_wr = 0; + if (gi2c->err) + geni_i2c_tx_fsm_rst(gi2c); + geni_se_tx_dma_unprep(se, gi2c->tx_dma, gi2c->xfer_len); + } should be 'else if', because TX and RX can't happen parallel. + if (val & DMA_RX_ACTIVE) { + geni_i2c_abort_xfer(gi2c); + gi2c->cur_rd = 0; + if (gi2c->err) + geni_i2c_rx_fsm_rst(gi2c); + geni_se_rx_dma_unprep(se, gi2c->rx_dma, gi2c->xfer_len); + } +} + static u32 geni_i2c_func(struct i2c_adapter *adap) { return I2C_FUNC_I2C | (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK); @@ -617,6 +639,26 @@ static int geni_i2c_remove(struct platform_device *pdev) return 0; } +static void geni_i2c_shutdown(struct platform_device *pdev) +{ + int ret; + u32 dma; + struct geni_i2c_dev *gi2c = platform_get_drvdata(pdev); + struct geni_se *se = &gi2c->se; + + ret = pm_runtime_get_sync(gi2c->se.dev); + if (ret < 0) { + dev_err(gi2c->se.dev, "Failed to resume device: %d\n", ret); + return; + } + + dma = readl_relaxed(se->base + SE_GENI_DMA_MODE_EN); Wrt to current issue context it may be suffice to stop just DMA mode transfers but why not stop all mode of active transfer during shutdown in a generic way. Regards, Akash Okay, I will include FIFO transfer case also in stop_xfer + if (dma) + geni_i2c_stop_xfer(gi2c); + + pm_runtime_put_sync_suspend(gi2c->se.dev); +} + static int __maybe_unused geni_i2c_runtime_suspend(struct device *dev) { int ret; @@ -677,6 +719,7 @@ MODULE_DEVICE_TABLE(of, geni_i2c_dt_match); static struct platform_driver geni_i2c_driver = { .probe = geni_i2c_probe, .remove = geni_i2c_remove, + .shutdown = geni_i2c_shutdown, .driver = { .name = "geni_i2c", .pm = &geni_i2c_pm_ops, diff --git a/include/linux/qcom-geni-se.h b/include/linux/qcom-geni-se.h index dd464943f717..c3c016496d98 100644 --- a/include/linux/qcom-geni-se.h +++ b/include/linux/qcom-geni-se.h @@ -77,6 +77,7 @@ struct geni_se { #define SE_DMA_RX_FSM_RST 0xd58 #define SE_HW_PARAM_0 0xe24 #define SE_HW_PARAM_1 0xe28 +#define SE_DMA_DEBUG_REG0 0xe40 /* GENI_FORCE_DEFAULT_REG fields */ #define FORCE_DEFAULT BIT(0) @@ -207,6 +208,10 @@ struct geni_se { #define RX_GENI_CANCEL_IRQBIT(11) #define RX_GENI_GP_IRQ_EXTGENMASK(13, 12) +/* SE_DMA_DEBUG_REG0 Register fields */ +#define DMA_TX_ACTIVE BIT(0) +#define DMA_RX_ACTIVE BIT(1) + /* SE_HW_PARAM_0 fields */ #define TX_FIFO_WIDTH_MSK GENMASK(29, 24) #define TX_FIFO_WIDTH_SHFT24 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 答复: [PATCH v2 6/6] drm/panel: Add Ilitek ILI9341 DBI panel driver
Le dim. 30 août 2020 à 22:28, Sam Ravnborg a écrit : Hi Laurent. > > Please read the cover letter, it explains why it's done this way. The > whole point of this patchset is to merge DSI and DBI frameworks in a > way that can be maintained. I think this proves the point that the proposed naming is confusing. At least a rename would be required. Do you have any inputs on the amount of rename we are looking into. Is this a simple s/struct mipi_dsi_device/struct mipi_dxi_device/ or something more? We should script the rename as it will tocuh a lot of files, and without a script we would chase this. But once it is scripted it would be trivial to perform. I did not look at this enough, but I had an idea that we would have do to a s/dsi/dxi/ in a lot of places. (dxi is my best proposal at the moment for something covering both dsi and dbi). dcs? Since DBI and DSI panels generally all use DCS commands. -Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/9] arm64: dts: renesas: r8a77961: Add FCP device nodes
On 07.09.2020 5:58, Kuninori Morimoto wrote: From: Kuninori Morimoto This patch adds FCP device nodes for R-Car M3-W+ (r8a77961) SoC. This patch is test on R-Car M3-W+ Salvator-XS board. Was tested? Signed-off-by: Kuninori Morimoto [...] MBR, Sergei ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V3] i2c: i2c-qcom-geni: Add shutdown callback for i2c
If the hardware is still accessing memory after SMMU translation is disabled (as part of smmu shutdown callback), then the IOVAs (I/O virtual address) which it was using will go on the bus as the physical addresses which will result in unknown crashes like NoC/interconnect errors. So, implement shutdown callback to i2c driver to stop on-going transfer and unmap DMA mappings during system "reboot" or "shutdown". Store DMA mapping data in geni_i2c_dev struct to enhance DMA mapping data scope. For example during shutdown callback to unmap DMA mapping, this stored DMA mapping data can be used to call geni_se_tx_dma_unprep and geni_se_rx_dma_unprep functions. Fixes: 37692de5d523 ("i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller") Signed-off-by: Roja Rani Yarubandi --- Changes in V2: - As per Stephen's comments added seperate function for stop transfer, fixed minor nitpicks. - As per Stephen's comments, changed commit text. Changes in V3: - As per Stephen's comments, squashed patch 1 into patch 2, added Fixes tag. - As per Akash's comments, included FIFO case in stop_xfer, fixed minor nitpicks. drivers/i2c/busses/i2c-qcom-geni.c | 70 +++--- include/linux/qcom-geni-se.h | 5 +++ 2 files changed, 69 insertions(+), 6 deletions(-) diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c index dead5db3315a..b3609760909f 100644 --- a/drivers/i2c/busses/i2c-qcom-geni.c +++ b/drivers/i2c/busses/i2c-qcom-geni.c @@ -86,6 +86,9 @@ struct geni_i2c_dev { u32 clk_freq_out; const struct geni_i2c_clk_fld *clk_fld; int suspended; + dma_addr_t tx_dma; + dma_addr_t rx_dma; + size_t xfer_len; }; struct geni_i2c_err_log { @@ -352,12 +355,12 @@ static void geni_i2c_tx_fsm_rst(struct geni_i2c_dev *gi2c) static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, u32 m_param) { - dma_addr_t rx_dma; unsigned long time_left; void *dma_buf = NULL; struct geni_se *se = &gi2c->se; size_t len = msg->len; + gi2c->xfer_len = len; if (!of_machine_is_compatible("lenovo,yoga-c630")) dma_buf = i2c_get_dma_safe_msg_buf(msg, 32); @@ -368,7 +371,7 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, writel_relaxed(len, se->base + SE_I2C_RX_TRANS_LEN); - if (dma_buf && geni_se_rx_dma_prep(se, dma_buf, len, &rx_dma)) { + if (dma_buf && geni_se_rx_dma_prep(se, dma_buf, len, &gi2c->rx_dma)) { geni_se_select_mode(se, GENI_SE_FIFO); i2c_put_dma_safe_msg_buf(dma_buf, msg, false); dma_buf = NULL; @@ -384,7 +387,8 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, if (dma_buf) { if (gi2c->err) geni_i2c_rx_fsm_rst(gi2c); - geni_se_rx_dma_unprep(se, rx_dma, len); + geni_se_rx_dma_unprep(se, gi2c->rx_dma, len); + gi2c->rx_dma = (dma_addr_t)NULL; i2c_put_dma_safe_msg_buf(dma_buf, msg, !gi2c->err); } @@ -394,12 +398,12 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, u32 m_param) { - dma_addr_t tx_dma; unsigned long time_left; void *dma_buf = NULL; struct geni_se *se = &gi2c->se; size_t len = msg->len; + gi2c->xfer_len = len; if (!of_machine_is_compatible("lenovo,yoga-c630")) dma_buf = i2c_get_dma_safe_msg_buf(msg, 32); @@ -410,7 +414,7 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, writel_relaxed(len, se->base + SE_I2C_TX_TRANS_LEN); - if (dma_buf && geni_se_tx_dma_prep(se, dma_buf, len, &tx_dma)) { + if (dma_buf && geni_se_tx_dma_prep(se, dma_buf, len, &gi2c->tx_dma)) { geni_se_select_mode(se, GENI_SE_FIFO); i2c_put_dma_safe_msg_buf(dma_buf, msg, false); dma_buf = NULL; @@ -429,7 +433,8 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, if (dma_buf) { if (gi2c->err) geni_i2c_tx_fsm_rst(gi2c); - geni_se_tx_dma_unprep(se, tx_dma, len); + geni_se_tx_dma_unprep(se, gi2c->tx_dma, len); + gi2c->tx_dma = (dma_addr_t)NULL; i2c_put_dma_safe_msg_buf(dma_buf, msg, !gi2c->err); } @@ -479,6 +484,51 @@ static int geni_i2c_xfer(struct i2c_adapter *adap, return ret; } +static void geni_i2c_stop_xfer(struct geni_i2c_dev *gi2c) +{ + int ret; + u32 dma; + u32 val; + u32 geni_status; + struct geni_se *se = &gi2c->se; + + ret = pm_runtime_get_sync(gi2c->se.d
Re: [PATCH 5/9] arm64: dts: renesas: r8a77961: Add VSP device nodes
On 07.09.2020 11:08, Sergei Shtylyov wrote: From: Kuninori Morimoto This patch adds VSP device nodes for R-Car M3-W+ (r8a77961) SoC. This patch is test on R-Car M3-W+ Salvator-XS board. Was tested? The same comment to the patches 6 & 7. Signed-off-by: Kuninori Morimoto [...] MBR, Sergei ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 30/30] videobuf2: use sgtable-based scatterlist wrappers
Hi Tomasz, On 07.09.2020 15:07, Tomasz Figa wrote: > On Fri, Sep 4, 2020 at 3:35 PM Marek Szyprowski > wrote: >> Use recently introduced common wrappers operating directly on the struct >> sg_table objects and scatterlist page iterators to make the code a bit >> more compact, robust, easier to follow and copy/paste safe. >> >> No functional change, because the code already properly did all the >> scatterlist related calls. >> >> Signed-off-by: Marek Szyprowski >> Reviewed-by: Robin Murphy >> --- >> .../common/videobuf2/videobuf2-dma-contig.c | 34 --- >> .../media/common/videobuf2/videobuf2-dma-sg.c | 32 +++-- >> .../common/videobuf2/videobuf2-vmalloc.c | 12 +++ >> 3 files changed, 31 insertions(+), 47 deletions(-) >> > Thanks for the patch! Please see my comments inline. > >> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c >> b/drivers/media/common/videobuf2/videobuf2-dma-contig.c >> index ec3446cc45b8..1b242d844dde 100644 >> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c >> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c >> @@ -58,10 +58,10 @@ static unsigned long vb2_dc_get_contiguous_size(struct >> sg_table *sgt) >> unsigned int i; >> unsigned long size = 0; >> >> - for_each_sg(sgt->sgl, s, sgt->nents, i) { >> + for_each_sgtable_dma_sg(sgt, s, i) { >> if (sg_dma_address(s) != expected) >> break; >> - expected = sg_dma_address(s) + sg_dma_len(s); >> + expected += sg_dma_len(s); >> size += sg_dma_len(s); >> } >> return size; >> @@ -103,8 +103,7 @@ static void vb2_dc_prepare(void *buf_priv) >> if (!sgt) >> return; >> >> - dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents, >> - buf->dma_dir); >> + dma_sync_sgtable_for_device(buf->dev, sgt, buf->dma_dir); >> } >> >> static void vb2_dc_finish(void *buf_priv) >> @@ -115,7 +114,7 @@ static void vb2_dc_finish(void *buf_priv) >> if (!sgt) >> return; >> >> - dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents, >> buf->dma_dir); >> + dma_sync_sgtable_for_cpu(buf->dev, sgt, buf->dma_dir); >> } >> >> /*/ >> @@ -275,8 +274,8 @@ static void vb2_dc_dmabuf_ops_detach(struct dma_buf >> *dbuf, >> * memory locations do not require any explicit cache >> * maintenance prior or after being used by the device. >> */ >> - dma_unmap_sg_attrs(db_attach->dev, sgt->sgl, sgt->orig_nents, >> - attach->dma_dir, DMA_ATTR_SKIP_CPU_SYNC); >> + dma_unmap_sgtable(db_attach->dev, sgt, attach->dma_dir, >> + DMA_ATTR_SKIP_CPU_SYNC); >> sg_free_table(sgt); >> kfree(attach); >> db_attach->priv = NULL; >> @@ -301,8 +300,8 @@ static struct sg_table *vb2_dc_dmabuf_ops_map( >> >> /* release any previous cache */ >> if (attach->dma_dir != DMA_NONE) { >> - dma_unmap_sg_attrs(db_attach->dev, sgt->sgl, sgt->orig_nents, >> - attach->dma_dir, DMA_ATTR_SKIP_CPU_SYNC); >> + dma_unmap_sgtable(db_attach->dev, sgt, attach->dma_dir, >> + DMA_ATTR_SKIP_CPU_SYNC); >> attach->dma_dir = DMA_NONE; >> } >> >> @@ -310,9 +309,8 @@ static struct sg_table *vb2_dc_dmabuf_ops_map( >> * mapping to the client with new direction, no cache sync >> * required see comment in vb2_dc_dmabuf_ops_detach() >> */ >> - sgt->nents = dma_map_sg_attrs(db_attach->dev, sgt->sgl, >> sgt->orig_nents, >> - dma_dir, DMA_ATTR_SKIP_CPU_SYNC); >> - if (!sgt->nents) { >> + if (dma_map_sgtable(db_attach->dev, sgt, dma_dir, >> + DMA_ATTR_SKIP_CPU_SYNC)) { >> pr_err("failed to map scatterlist\n"); >> mutex_unlock(lock); >> return ERR_PTR(-EIO); > As opposed to dma_map_sg_attrs(), dma_map_sgtable() now returns an > error code on its own. Is it expected to ignore it and return -EIO? Those errors are more or less propagated to userspace and -EIO has been already widely documented in V4L2 documentation as the error code for the most of the V4L2 ioctls. I don't want to change it. A possible -EINVAL returned from dma_map_sgtable() was just one of the 'generic' error codes, not very descriptive in that case. Probably the main problem here is that dma_map_sg() and friend doesn't return any error codes... > ... Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://li
Re: [PATCH v4 1/1] drm: allow limiting the scatter list size.
On Mon, Sep 7, 2020 at 1:24 PM Gerd Hoffmann wrote: > > Add drm_device argument to drm_prime_pages_to_sg(), so we can > call dma_max_mapping_size() to figure the segment size limit > and call into __sg_alloc_table_from_pages() with the correct > limit. > > This fixes virtio-gpu with sev. Possibly it'll fix other bugs > too given that drm seems to totaly ignore segment size limits > so far ... > > v2: place max_segment in drm driver not gem object. > v3: move max_segment next to the other gem fields. > v4: just use dma_max_mapping_size(). > > Signed-off-by: Gerd Hoffmann Uh, are you sure this works in all cases for virtio? The comments I've found suggest very much not ... Or is that all very old stuff only that no one cares about anymore? -Daniel > --- > include/drm/drm_prime.h | 3 ++- > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 3 ++- > drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +- > drivers/gpu/drm/drm_prime.c | 13 ++--- > drivers/gpu/drm/etnaviv/etnaviv_gem.c | 3 ++- > drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 +- > drivers/gpu/drm/msm/msm_gem.c | 2 +- > drivers/gpu/drm/msm/msm_gem_prime.c | 2 +- > drivers/gpu/drm/nouveau/nouveau_prime.c | 2 +- > drivers/gpu/drm/radeon/radeon_prime.c | 2 +- > drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 5 +++-- > drivers/gpu/drm/tegra/gem.c | 2 +- > drivers/gpu/drm/vgem/vgem_drv.c | 2 +- > drivers/gpu/drm/xen/xen_drm_front_gem.c | 3 ++- > 14 files changed, 29 insertions(+), 17 deletions(-) > > diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h > index 9af7422b44cf..bf141e74a1c2 100644 > --- a/include/drm/drm_prime.h > +++ b/include/drm/drm_prime.h > @@ -88,7 +88,8 @@ void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void > *vaddr); > int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct > *vma); > int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma); > > -struct sg_table *drm_prime_pages_to_sg(struct page **pages, unsigned int > nr_pages); > +struct sg_table *drm_prime_pages_to_sg(struct drm_device *dev, > + struct page **pages, unsigned int > nr_pages); > struct dma_buf *drm_gem_prime_export(struct drm_gem_object *obj, > int flags); > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c > index 519ce4427fce..d7050ab95946 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c > @@ -302,7 +302,8 @@ static struct sg_table *amdgpu_dma_buf_map(struct > dma_buf_attachment *attach, > > switch (bo->tbo.mem.mem_type) { > case TTM_PL_TT: > - sgt = drm_prime_pages_to_sg(bo->tbo.ttm->pages, > + sgt = drm_prime_pages_to_sg(obj->dev, > + bo->tbo.ttm->pages, > bo->tbo.num_pages); > if (IS_ERR(sgt)) > return sgt; > diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c > b/drivers/gpu/drm/drm_gem_shmem_helper.c > index 4b7cfbac4daa..0a952f27c184 100644 > --- a/drivers/gpu/drm/drm_gem_shmem_helper.c > +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c > @@ -656,7 +656,7 @@ struct sg_table *drm_gem_shmem_get_sg_table(struct > drm_gem_object *obj) > > WARN_ON(shmem->base.import_attach); > > - return drm_prime_pages_to_sg(shmem->pages, obj->size >> PAGE_SHIFT); > + return drm_prime_pages_to_sg(obj->dev, shmem->pages, obj->size >> > PAGE_SHIFT); > } > EXPORT_SYMBOL_GPL(drm_gem_shmem_get_sg_table); > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c > index 1693aa7c14b5..8a6a3c99b7d8 100644 > --- a/drivers/gpu/drm/drm_prime.c > +++ b/drivers/gpu/drm/drm_prime.c > @@ -802,9 +802,11 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops > = { > * > * This is useful for implementing &drm_gem_object_funcs.get_sg_table. > */ > -struct sg_table *drm_prime_pages_to_sg(struct page **pages, unsigned int > nr_pages) > +struct sg_table *drm_prime_pages_to_sg(struct drm_device *dev, > + struct page **pages, unsigned int > nr_pages) > { > struct sg_table *sg = NULL; > + size_t max_segment = 0; > int ret; > > sg = kmalloc(sizeof(struct sg_table), GFP_KERNEL); > @@ -813,8 +815,13 @@ struct sg_table *drm_prime_pages_to_sg(struct page > **pages, unsigned int nr_page > goto out; > } > > - ret = sg_alloc_table_from_pages(sg, pages, nr_pages, 0, > - nr_pages << PAGE_SHIFT, GFP_KERNEL); > + if (dev) > + max_segment = dma_max_mapping_size(dev->dev); > + if (max_segment == 0 || max_segment > SCATTERLIST_MAX_SEGMENT) > + max_s
Re: [PATCH] drm/doc: Document that modifiers are always required for fb
On Mon, Sep 7, 2020 at 11:07 AM Pekka Paalanen wrote: > > On Mon, 7 Sep 2020 10:41:37 +0200 > Daniel Vetter wrote: > > > On Mon, Sep 07, 2020 at 08:37:31AM +, Simon Ser wrote: > > > On Monday, September 7, 2020 10:31 AM, Daniel Vetter > > > wrote: > > > > > > > On Wed, Sep 02, 2020 at 02:59:49PM +, Simon Ser wrote: > > > > > > > > > On Wednesday, September 2, 2020 4:29 PM, Daniel Vetter > > > > > daniel.vet...@ffwll.ch wrote: > > > > > > > > > > > On Wed, Sep 2, 2020 at 2:49 PM Simon Ser cont...@emersion.fr wrote: > > > > > > > > > > > > > On Wednesday, September 2, 2020 2:44 PM, Daniel Vetter > > > > > > > daniel.vet...@ffwll.ch wrote: > > > > > > > > > > > > > > > > I suppose something similar happens in user-space: > > > > > > > > > gbm_bo_create > > > > > > > > > without modifiers needs to properly set the implicit > > > > > > > > > modifier, ie. > > > > > > > > > gbm_bo_get_modifier needs to return the effective modifier. > > > > > > > > > Is this > > > > > > > > > something already documented? > > > > > > > > > > > > > > > > I don't think that happens, but it has come up in discussions. > > > > > > > > It's > > > > > > > > kinda different scenario though: getfb2 is for cross-compositor > > > > > > > > stuff, > > > > > > > > enabling smooth transitions at boot-up and when switching. So > > > > > > > > you have > > > > > > > > a legit reason for mixing modifier-aware userspace with > > > > > > > > non-modifier-aware userspace. And the modifier-aware userspace > > > > > > > > would > > > > > > > > like that everything works with modifiers consistently, > > > > > > > > including > > > > > > > > getfb2. But gbm is just within a single process, and that should > > > > > > > > either run all with modifiers, or not at all, since these > > > > > > > > worlds just > > > > > > > > dont mix well. Hence I'm not seeing much use for that, > > > > > > > > -modesetting > > > > > > > > being a confused mess nonwithstanding :-) > > > > > > > > > > > > > > Well… There's also the case where some legacy Wayland client > > > > > > > talks to a > > > > > > > modifier-aware compositor. gbm_bo_import would be called without a > > > > > > > modifier, but the compositor expects gbm_bo_get_modifier to work. > > > > > > > Also, wlroots will call gbm_bo_create without a modifier to only > > > > > > > let > > > > > > > the driver pick "safe" modifiers in case passing the full list of > > > > > > > modifiers results in a black screen. Later on wlroots will call > > > > > > > gbm_bo_get_modifier to figure out what modifier the driver picked. > > > > > > > > > > > > gbm_bo_import is a different thing from gbm_bo_create. Former I > > > > > > agree > > > > > > should figure out the right modifiers (and I think it does that, at > > > > > > least on intel mesa). For gbm_bo_create I'm not sure we should/need > > > > > > to > > > > > > require that. > > > > > > > > > > I guess the compositor will just forward the value returned by > > > > > gbm_bo_get_modifier in any case, so returning INVALID would be fine > > > > > too (to mean "implicit modifier"). > > > > > In both the create and import cases, other metadata like pitches and > > > > > offsets should be correctly set I think? > > > > > > > > Well if you have a modifier format underneath, the non-modifiered > > > > offsets > > > > and pitches might be pure fiction. Also, they might not be sufficient, > > > > if > > > > the modifier adds more planes. > > > > > > In this case (gbm_bo_create without modifiers), we're discussing > > > whether we require gbm_bo_get_modifier to return a valid modifier, or > > > if INVALID is fine. > > > > Hm then I missed the use-case for a gbm_bo_create without modifiers, where > > afterwards userspace wants the modifiers. That sounds like a bug (and yes > > -modesetting is buggy that way). > > I'm guessing that use case might be related to > https://gitlab.freedesktop.org/wayland/weston/-/issues/429 > > The weston issue is about > gbm_surface_create/gbm_surface_create_with_modifiers, but that's not > too different from gbm_bo_create/gbm_bo_create_with_modifiers? > > Weston happens to have this code: > https://gitlab.freedesktop.org/wayland/weston/-/blob/9.0.0/libweston/backend-drm/drm-gbm.c#L209-230 > and then it unconditionally calls gbm_bo_get_modifier(). However, > DRM_FORMAT_MOD_INVALID is handled specially: > https://gitlab.freedesktop.org/wayland/weston/-/blob/9.0.0/libweston/backend-drm/fb.c#L80-97 Hm yeah that feels a bit like an interim hack instead of more modifiers fallback logic. I guess shouldn't be too tricky for mesa to support that, since internally modifier aware drivers work only with modifiers anyway (or at least should, that's what we're requiring on the kms side with this patch at least). Up to mesa people I'd say. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://
[PATCH 2/2] drm/ttm: merge offset and base in ttm_bus_placement
This is used by TTM to communicate the physical address which should be used with ioremap(), ioremap_wc(). We don't need to separate the base and offset in any way here. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 7 --- drivers/gpu/drm/drm_gem_ttm_helper.c | 5 + drivers/gpu/drm/drm_gem_vram_helper.c | 3 +-- drivers/gpu/drm/nouveau/nouveau_bo.c | 9 - drivers/gpu/drm/nouveau/nouveau_fbcon.c| 3 +-- drivers/gpu/drm/qxl/qxl_ttm.c | 7 +++ drivers/gpu/drm/radeon/radeon_ttm.c| 14 ++ drivers/gpu/drm/ttm/ttm_bo.c | 3 --- drivers/gpu/drm/ttm/ttm_bo_util.c | 17 ++--- drivers/gpu/drm/ttm/ttm_bo_vm.c| 3 +-- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 4 ++-- include/drm/ttm/ttm_resource.h | 6 ++ 12 files changed, 31 insertions(+), 50 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index 46d620817482..b39d2a834340 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -773,7 +773,7 @@ static int amdgpu_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct ttm_reso mem->bus.addr = (u8 *)adev->mman.aper_base_kaddr + mem->bus.offset; - mem->bus.base = adev->gmc.aper_base; + mem->bus.offset += adev->gmc.aper_base; mem->bus.is_iomem = true; break; default: @@ -785,12 +785,13 @@ static int amdgpu_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct ttm_reso static unsigned long amdgpu_ttm_io_mem_pfn(struct ttm_buffer_object *bo, unsigned long page_offset) { + struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev); uint64_t offset = (page_offset << PAGE_SHIFT); struct drm_mm_node *mm; mm = amdgpu_find_mm_node(&bo->mem, &offset); - return (bo->mem.bus.base >> PAGE_SHIFT) + mm->start + - (offset >> PAGE_SHIFT); + offset += adev->gmc.aper_base; + return mm->start + (offset >> PAGE_SHIFT); } /** diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c b/drivers/gpu/drm/drm_gem_ttm_helper.c index 892b2288a104..0e4fb9ba43ad 100644 --- a/drivers/gpu/drm/drm_gem_ttm_helper.c +++ b/drivers/gpu/drm/drm_gem_ttm_helper.c @@ -43,12 +43,9 @@ void drm_gem_ttm_print_info(struct drm_printer *p, unsigned int indent, drm_print_bits(p, bo->mem.placement, plname, ARRAY_SIZE(plname)); drm_printf(p, "\n"); - if (bo->mem.bus.is_iomem) { - drm_printf_indent(p, indent, "bus.base=%lx\n", - (unsigned long)bo->mem.bus.base); + if (bo->mem.bus.is_iomem) drm_printf_indent(p, indent, "bus.offset=%lx\n", (unsigned long)bo->mem.bus.offset); - } } EXPORT_SYMBOL(drm_gem_ttm_print_info); diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c b/drivers/gpu/drm/drm_gem_vram_helper.c index 545a877406f4..255560591916 100644 --- a/drivers/gpu/drm/drm_gem_vram_helper.c +++ b/drivers/gpu/drm/drm_gem_vram_helper.c @@ -1042,8 +1042,7 @@ static int bo_driver_io_mem_reserve(struct ttm_bo_device *bdev, case TTM_PL_SYSTEM: /* nothing to do */ break; case TTM_PL_VRAM: - mem->bus.offset = mem->start << PAGE_SHIFT; - mem->bus.base = vmm->vram_base; + mem->bus.offset = (mem->start << PAGE_SHIFT) + vmm->vram_base; mem->bus.is_iomem = true; break; default: diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index f74988771ed8..4c2cc862eb19 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -1081,8 +1081,8 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct ttm_resource *reg) case TTM_PL_TT: #if IS_ENABLED(CONFIG_AGP) if (drm->agp.bridge) { - reg->bus.offset = reg->start << PAGE_SHIFT; - reg->bus.base = drm->agp.base; + reg->bus.offset = (reg->start << PAGE_SHIFT) + + drm->agp.base; reg->bus.is_iomem = !drm->agp.cma; } #endif @@ -1094,8 +1094,8 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct ttm_resource *reg) } fallthrough;/* tiled memory */ case TTM_PL_VRAM: - reg->bus.offset = reg->start << PAGE_SHIFT; - reg->bus.base = device->func->resource_addr(device, 1); + reg->bus.offset = (reg->start << PAGE_SHIFT) + + device->func->resource_addr(device, 1); reg->bus.is_iomem = true; if (drm->
[PATCH 1/2] drm/qxl: don't touch mem.bus.offset
This is internal to TTM and should not be used by drivers directly. Drop the call to qxl_ttm_io_mem_reserve() and use mem->start instead. Signed-off-by: Christian König --- drivers/gpu/drm/qxl/qxl_object.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/qxl/qxl_object.c b/drivers/gpu/drm/qxl/qxl_object.c index f838b6d689aa..b2a1fa61920b 100644 --- a/drivers/gpu/drm/qxl/qxl_object.c +++ b/drivers/gpu/drm/qxl/qxl_object.c @@ -167,6 +167,7 @@ int qxl_bo_kmap(struct qxl_bo *bo, void **ptr) void *qxl_bo_kmap_atomic_page(struct qxl_device *qdev, struct qxl_bo *bo, int page_offset) { + unsigned long offset; void *rptr; int ret; struct io_mapping *map; @@ -178,9 +179,8 @@ void *qxl_bo_kmap_atomic_page(struct qxl_device *qdev, else goto fallback; - ret = qxl_ttm_io_mem_reserve(bo->tbo.bdev, &bo->tbo.mem); - - return io_mapping_map_atomic_wc(map, bo->tbo.mem.bus.offset + page_offset); + offset = bo->tbo.mem.start << PAGE_SHIFT; + return io_mapping_map_atomic_wc(map, offset + page_offset); fallback: if (bo->kptr) { rptr = bo->kptr + (page_offset * PAGE_SIZE); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] dt-bindings: display: panel: add TDO tl070wsh30 DSI panel bindings
Hi, On 07/09/2020 13:45, Sam Ravnborg wrote: > Hi Neil. > > On Mon, Sep 07, 2020 at 01:10:26PM +0200, Neil Armstrong wrote: >> This add the bindings for the 1024*600 tl070wsh30 DSI panel. > > The binding looks like a panel-simple-dsi.yaml candidate. > Only differen is enable-gpios versus reset-gpios This is the only difference, the panel only has a reset signal and no enable signal. But I can add a reset-gpios to panel-simple-dsi.yaml, would it be ok ? Neil > > Could you check if we can use panel-simple-dsi-yaml. > > Sam > >> >> Signed-off-by: Neil Armstrong >> --- >> .../display/panel/tdo,tl070wsh30.yaml | 58 +++ >> 1 file changed, 58 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml >> >> diff --git >> a/Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml >> b/Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml >> new file mode 100644 >> index ..20f4fdedfcb0 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml >> @@ -0,0 +1,58 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) >> +# Copyright 2020 BayLibre, SAS >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/display/panel/tdo,tl070wsh30.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: TDO TL070WSH30 DSI panel >> + >> +maintainers: >> + - Neil Armstrong >> + >> +allOf: >> + - $ref: panel-common.yaml# >> + >> +properties: >> + >> + compatible: >> +enum: >> + - tdo,tl070wsh30 >> + >> + reg: >> +maxItems: 1 >> +description: DSI virtual channel >> + >> + backlight: true >> + reset-gpios: true >> + port: true >> + power-supply: true >> + >> +additionalProperties: false >> + >> +required: >> + - compatible >> + - power-supply >> + - reset-gpios >> + - port >> + - reg >> + >> +examples: >> + - | >> +dsi { >> + #address-cells = <1>; >> + #size-cells = <0>; >> + panel@0 { >> +compatible = "tdo,tl070wsh30"; >> +reg = <0>; >> +power-supply = <&vcc_lcd_reg>; >> +backlight = <&panel_backlight>; >> +reset-gpios = <&gpio_reset>; >> + >> +port { >> + panel: endpoint { >> +remote-endpoint = <&mipi_dsi_out>; >> + }; >> +}; >> + }; >> +}; >> -- >> 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 30/30] videobuf2: use sgtable-based scatterlist wrappers
Hi Marek, On Fri, Sep 4, 2020 at 3:35 PM Marek Szyprowski wrote: > > Use recently introduced common wrappers operating directly on the struct > sg_table objects and scatterlist page iterators to make the code a bit > more compact, robust, easier to follow and copy/paste safe. > > No functional change, because the code already properly did all the > scatterlist related calls. > > Signed-off-by: Marek Szyprowski > Reviewed-by: Robin Murphy > --- > .../common/videobuf2/videobuf2-dma-contig.c | 34 --- > .../media/common/videobuf2/videobuf2-dma-sg.c | 32 +++-- > .../common/videobuf2/videobuf2-vmalloc.c | 12 +++ > 3 files changed, 31 insertions(+), 47 deletions(-) > Thanks for the patch! Please see my comments inline. > diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c > b/drivers/media/common/videobuf2/videobuf2-dma-contig.c > index ec3446cc45b8..1b242d844dde 100644 > --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c > +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c > @@ -58,10 +58,10 @@ static unsigned long vb2_dc_get_contiguous_size(struct > sg_table *sgt) > unsigned int i; > unsigned long size = 0; > > - for_each_sg(sgt->sgl, s, sgt->nents, i) { > + for_each_sgtable_dma_sg(sgt, s, i) { > if (sg_dma_address(s) != expected) > break; > - expected = sg_dma_address(s) + sg_dma_len(s); > + expected += sg_dma_len(s); > size += sg_dma_len(s); > } > return size; > @@ -103,8 +103,7 @@ static void vb2_dc_prepare(void *buf_priv) > if (!sgt) > return; > > - dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents, > - buf->dma_dir); > + dma_sync_sgtable_for_device(buf->dev, sgt, buf->dma_dir); > } > > static void vb2_dc_finish(void *buf_priv) > @@ -115,7 +114,7 @@ static void vb2_dc_finish(void *buf_priv) > if (!sgt) > return; > > - dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents, > buf->dma_dir); > + dma_sync_sgtable_for_cpu(buf->dev, sgt, buf->dma_dir); > } > > /*/ > @@ -275,8 +274,8 @@ static void vb2_dc_dmabuf_ops_detach(struct dma_buf *dbuf, > * memory locations do not require any explicit cache > * maintenance prior or after being used by the device. > */ > - dma_unmap_sg_attrs(db_attach->dev, sgt->sgl, sgt->orig_nents, > - attach->dma_dir, DMA_ATTR_SKIP_CPU_SYNC); > + dma_unmap_sgtable(db_attach->dev, sgt, attach->dma_dir, > + DMA_ATTR_SKIP_CPU_SYNC); > sg_free_table(sgt); > kfree(attach); > db_attach->priv = NULL; > @@ -301,8 +300,8 @@ static struct sg_table *vb2_dc_dmabuf_ops_map( > > /* release any previous cache */ > if (attach->dma_dir != DMA_NONE) { > - dma_unmap_sg_attrs(db_attach->dev, sgt->sgl, sgt->orig_nents, > - attach->dma_dir, DMA_ATTR_SKIP_CPU_SYNC); > + dma_unmap_sgtable(db_attach->dev, sgt, attach->dma_dir, > + DMA_ATTR_SKIP_CPU_SYNC); > attach->dma_dir = DMA_NONE; > } > > @@ -310,9 +309,8 @@ static struct sg_table *vb2_dc_dmabuf_ops_map( > * mapping to the client with new direction, no cache sync > * required see comment in vb2_dc_dmabuf_ops_detach() > */ > - sgt->nents = dma_map_sg_attrs(db_attach->dev, sgt->sgl, > sgt->orig_nents, > - dma_dir, DMA_ATTR_SKIP_CPU_SYNC); > - if (!sgt->nents) { > + if (dma_map_sgtable(db_attach->dev, sgt, dma_dir, > + DMA_ATTR_SKIP_CPU_SYNC)) { > pr_err("failed to map scatterlist\n"); > mutex_unlock(lock); > return ERR_PTR(-EIO); As opposed to dma_map_sg_attrs(), dma_map_sgtable() now returns an error code on its own. Is it expected to ignore it and return -EIO? > @@ -455,8 +453,8 @@ static void vb2_dc_put_userptr(void *buf_priv) > * No need to sync to CPU, it's already synced to the CPU > * since the finish() memop will have been called before this. > */ > - dma_unmap_sg_attrs(buf->dev, sgt->sgl, sgt->orig_nents, > - buf->dma_dir, DMA_ATTR_SKIP_CPU_SYNC); > + dma_unmap_sgtable(buf->dev, sgt, buf->dma_dir, > + DMA_ATTR_SKIP_CPU_SYNC); > pages = frame_vector_pages(buf->vec); > /* sgt should exist only if vector contains pages... */ > BUG_ON(IS_ERR(pages)); > @@ -553,9 +551,8 @@ static void *vb2_dc_get_userptr(struct device *dev, > unsigned long vaddr, >
[PULL] drm-intel-gt-next
Hi Dave & Daniel, Exactly same content as previous PR: https://lists.freedesktop.org/archives/intel-gfx/2020-September/247626.html Just rebased adding the missing S-o-b:s and updated "Fixes:" tags accordingly as requested. Regards, Joonas *** drm-intel-gt-next-2020-09-07: (Same content as drm-intel-gt-next-2020-09-04-3, S-o-b's added) UAPI Changes: (- Potential implicit changes from WW locking refactoring) Cross-subsystem Changes: (- WW locking changes should align the i915 locking more with others) Driver Changes: - MAJOR: Apply WW locking across the driver (Maarten) - Reverts for 5 commits to make applying WW locking faster (Maarten) - Disable preparser around invalidations on Tigerlake for non-RCS engines (Chris) - Add missing dma_fence_put() for error case of syncobj timeline (Chris) - Parse command buffer earlier in eb_relocate(slow) to facilitate backoff (Maarten) - Pin engine before pinning all objects (Maarten) - Rework intel_context pinning to do everything outside of pin_mutex (Maarten) - Avoid tracking GEM context until registered (Cc: stable, Chris) - Provide a fastpath for waiting on vma bindings (Chris) - Fixes to preempt-to-busy mechanism (Chris) - Distinguish the virtual breadcrumbs from the irq breadcrumbs (Chris) - Switch to object allocations for page directories (Chris) - Hold context/request reference while breadcrumbs are active (Chris) - Make sure execbuffer always passes ww state to i915_vma_pin (Maarten) - Code refactoring to facilitate use of WW locking (Maarten) - Locking refactoring to use more granular locking (Maarten, Chris) - Support for multiple pinned timelines per engine (Chris) - Move complication of I915_GEM_THROTTLE to the ioctl from general code (Chris) - Make active tracking/vma page-directory stash work preallocated (Chris) - Avoid flushing submission tasklet too often (Chris) - Reduce context termination list iteration guard to RCU (Chris) - Reductions to locking contention (Chris) - Fixes for issues found by CI (Chris) The following changes since commit 3393649977f9a8847c659e282ea290d4b703295c: Merge tag 'drm-intel-next-2020-08-24-1' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2020-08-28 14:09:31 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2020-09-07 for you to fetch changes up to e0ee152fce25dc9269c7ea5280c98aa4b3682759: drm/i915: Unlock the shared hwsp_gtt object after pinning (2020-09-07 15:08:11 +0300) (Same content as drm-intel-gt-next-2020-09-04-3, S-o-b's added) UAPI Changes: (- Potential implicit changes from WW locking refactoring) Cross-subsystem Changes: (- WW locking changes should align the i915 locking more with others) Driver Changes: - MAJOR: Apply WW locking across the driver (Maarten) - Reverts for 5 commits to make applying WW locking faster (Maarten) - Disable preparser around invalidations on Tigerlake for non-RCS engines (Chris) - Add missing dma_fence_put() for error case of syncobj timeline (Chris) - Parse command buffer earlier in eb_relocate(slow) to facilitate backoff (Maarten) - Pin engine before pinning all objects (Maarten) - Rework intel_context pinning to do everything outside of pin_mutex (Maarten) - Avoid tracking GEM context until registered (Cc: stable, Chris) - Provide a fastpath for waiting on vma bindings (Chris) - Fixes to preempt-to-busy mechanism (Chris) - Distinguish the virtual breadcrumbs from the irq breadcrumbs (Chris) - Switch to object allocations for page directories (Chris) - Hold context/request reference while breadcrumbs are active (Chris) - Make sure execbuffer always passes ww state to i915_vma_pin (Maarten) - Code refactoring to facilitate use of WW locking (Maarten) - Locking refactoring to use more granular locking (Maarten, Chris) - Support for multiple pinned timelines per engine (Chris) - Move complication of I915_GEM_THROTTLE to the ioctl from general code (Chris) - Make active tracking/vma page-directory stash work preallocated (Chris) - Avoid flushing submission tasklet too often (Chris) - Reduce context termination list iteration guard to RCU (Chris) - Reductions to locking contention (Chris) - Fixes for issues found by CI (Chris) Chris Wilson (33): drm/i915: Reduce i915_request.lock contention for i915_request_wait drm/i915/selftests: Mock the status_page.vma for the kernel_context drm/i915: Soften the tasklet flush frequency before waits drm/i915/gem: Remove disordered per-file request list for throttling drm/i915/gt: Disable preparser around xcs invalidations on tgl drm/i915/gt: Delay taking the spinlock for grabbing from the buffer pool drm/i915/selftests: Flush the active barriers before asserting drm/i915/gt: Fix termination condition for freeing all buffer objects drm/i915/gem: Delay t