Re: [PATCH v2 05/10] arm64: dts: renesas: r8a77961: Add FCP device nodes

2020-09-07 Thread Laurent Pinchart
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_MOD 615>;
> + power-domains = < R8A77961_PD_A3VC>;
> + resets = < 615>;
> + };
> +
> + fcpvb0: fcp@fe96f000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfe96f000 0 0x200>;
> + clocks = < CPG_MOD 607>;
> + power-domains = < R8A77961_PD_A3VC>;
> + resets = < 607>;
> + };
> +
> + fcpvi0: fcp@fe9af000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfe9af000 0 0x200>;
> + clocks = < CPG_MOD 611>;
> + power-domains = < R8A77961_PD_A3VC>;
> + resets = < 611>;
> + iommus = <_vc0 19>;
> + };
> +
> + fcpvd0: fcp@fea27000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfea27000 0 0x200>;
> + clocks = < CPG_MOD 603>;
> + power-domains = < R8A77961_PD_ALWAYS_ON>;
> + resets = < 603>;
> + iommus = <_vi0 8>;
> + };
> +
> + fcpvd1: fcp@fea2f000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfea2f000 0 0x200>;
> + clocks = < CPG_MOD 602>;
> + power-domains = < R8A77961_PD_ALWAYS_ON>;
> + resets = < 602>;
> + iommus = <_vi0 9>;
> + };
> +
> + fcpvd2: fcp@fea37000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfea37000 0 0x200>;
> + clocks = < CPG_MOD 601>;
> + power-domains = < R8A77961_PD_ALWAYS_ON>;
> + resets = < 601>;
> + iommus = <_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

2020-09-07 Thread Laurent Pinchart
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 = _du_r8a7794_info },
>   { .compatible = "renesas,du-r8a7795", .data = _du_r8a7795_info },
>   { .compatible = "renesas,du-r8a7796", .data = _du_r8a7796_info },
> + { .compatible = "renesas,du-r8a77961", .data = _du_r8a7796_info },
>   { .compatible = "renesas,du-r8a77965", .data = _du_r8a77965_info },
>   { .compatible = "renesas,du-r8a77970", .data = _du_r8a77970_info },
>   { .compatible = "renesas,du-r8a77980", .data = _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

2020-09-07 Thread Laurent Pinchart
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.

2020-09-07 Thread Laurent Pinchart
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_CORE R8A7795_CLK_S0D4>, < 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

2020-09-07 Thread Laurent Pinchart
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.

2020-09-07 Thread Gerd Hoffmann
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.

2020-09-07 Thread Gerd Hoffmann
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

2020-09-07 Thread Laurent Pinchart
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 
> > 

Re: [PATCH 1/2] drm/radeon: Add sclk frequency as hwmon sensor

2020-09-07 Thread Sandeep Raghuraman



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

2020-09-07 Thread Stephen Rothwell
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

2020-09-07 Thread Stephen Rothwell
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

2020-09-07 Thread bugzilla-daemon
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=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

2020-09-07 Thread bugzilla-daemon
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=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

2020-09-07 Thread bugzilla-daemon
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

2020-09-07 Thread Kuninori Morimoto


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_MOD 729>, < CPG_CORE 
R8A77961_CLK_HDMI>;
+   clock-names = "iahb", "isfr";
+   power-domains = < R8A77961_PD_ALWAYS_ON>;
+   resets = < 729>;
+   status = "disabled";
 
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
+   dw_hdmi0_in: endpoint {
+   remote-endpoint = 
<_out_hdmi0>;
+   };
};
port@1 {
reg = <1>;
@@ -2191,6 +2200,7 @@ du_out_rgb: endpoint {
port@1 {
reg = <1>;
du_out_hdmi0: endpoint {
+   remote-endpoint = 
<_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

2020-09-07 Thread Kuninori Morimoto
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 = <_con>;
};
};
+   port@2 {
+   reg = <2>;
+   dw_hdmi0_snd_in: endpoint {
+   remote-endpoint = <_endpoint1>;
+   };
+   };
};
 };
 
 _con {
remote-endpoint = <_dw_hdmi0_out>;
 };
+
+_sound {
+   ports {
+   /* rsnd_port0 is on salvator-common */
+   rsnd_port1: port@1 {
+   reg = <1>;
+   rsnd_endpoint1: endpoint {
+   remote-endpoint = <_hdmi0_snd_in>;
+
+   dai-format = "i2s";
+   bitclock-master = <_endpoint1>;
+   frame-master = <_endpoint1>;
+
+   playback = <>;
+   };
+   };
+   };
+};
+
+_card {
+   dais = <_port0 /* ak4613 */
+   _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

2020-09-07 Thread Kuninori Morimoto
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>;
};
 };
+
+ {
+   clocks = < CPG_MOD 724>,
+< CPG_MOD 723>,
+< CPG_MOD 722>,
+< 1>,
+<_clk>,
+< 2>;
+   clock-names = "du.0", "du.1", "du.2",
+ "dclkin.0", "dclkin.1", "dclkin.2";
+};
+
+ {
+   status = "okay";
+
+   ports {
+   port@1 {
+   reg = <1>;
+   rcar_dw_hdmi0_out: endpoint {
+   remote-endpoint = <_con>;
+   };
+   };
+   };
+};
+
+_con {
+   remote-endpoint = <_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

2020-09-07 Thread Kuninori Morimoto


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_MOD 724>, < CPG_MOD 723>,
+< CPG_MOD 722>;
+   clock-names = "du.0", "du.1", "du.2";
+   resets = < 724>, < 722>;
+   reset-names = "du.0", "du.2";
+
+   renesas,vsps = < 0>, < 0>, < 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 06/10] arm64: dts: renesas: r8a77961: Add VSP device nodes

2020-09-07 Thread Kuninori Morimoto


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 = < 615>;
};
 
+   vspb: vsp@fe96 {
+   compatible = "renesas,vsp2";
+   reg = <0 0xfe96 0 0x8000>;
+   interrupts = ;
+   clocks = < CPG_MOD 626>;
+   power-domains = < R8A77961_PD_A3VC>;
+   resets = < 626>;
+
+   renesas,fcp = <>;
+   };
+
fcpvb0: fcp@fe96f000 {
compatible = "renesas,fcpv";
reg = <0 0xfe96f000 0 0x200>;
@@ -2020,6 +2031,17 @@ fcpvb0: fcp@fe96f000 {
resets = < 607>;
};
 
+   vspi0: vsp@fe9a {
+   compatible = "renesas,vsp2";
+   reg = <0 0xfe9a 0 0x8000>;
+   interrupts = ;
+   clocks = < CPG_MOD 631>;
+   power-domains = < R8A77961_PD_A3VC>;
+   resets = < 631>;
+
+   renesas,fcp = <>;
+   };
+
fcpvi0: fcp@fe9af000 {
compatible = "renesas,fcpv";
reg = <0 0xfe9af000 0 0x200>;
@@ -2029,6 +2051,17 @@ fcpvi0: fcp@fe9af000 {
iommus = <_vc0 19>;
};
 
+   vspd0: vsp@fea2 {
+   compatible = "renesas,vsp2";
+   reg = <0 0xfea2 0 0x5000>;
+   interrupts = ;
+   clocks = < CPG_MOD 623>;
+   power-domains = < R8A77961_PD_ALWAYS_ON>;
+   resets = < 623>;
+
+   renesas,fcp = <>;
+   };
+
fcpvd0: fcp@fea27000 {
compatible = "renesas,fcpv";
reg = <0 0xfea27000 0 0x200>;
@@ -2038,6 +2071,17 @@ fcpvd0: fcp@fea27000 {
iommus = <_vi0 8>;
};
 
+   vspd1: vsp@fea28000 {
+   compatible = "renesas,vsp2";
+   reg = <0 0xfea28000 0 0x5000>;
+   interrupts = ;
+   clocks = < CPG_MOD 622>;
+   power-domains = < R8A77961_PD_ALWAYS_ON>;
+   resets = < 622>;
+
+   renesas,fcp = <>;
+   };
+
fcpvd1: fcp@fea2f000 {
compatible = "renesas,fcpv";
reg = <0 0xfea2f000 0 0x200>;
@@ -2047,6 +2091,17 @@ fcpvd1: fcp@fea2f000 {
iommus = <_vi0 9>;
};
 
+   vspd2: vsp@fea3 {
+   compatible = "renesas,vsp2";
+   reg = <0 0xfea3 0 0x5000>;
+   interrupts = ;
+   clocks = < CPG_MOD 621>;
+   power-domains = < R8A77961_PD_ALWAYS_ON>;
+   resets = < 621>;
+
+   renesas,fcp = <>;
+   };
+
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

2020-09-07 Thread Kuninori Morimoto
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

2020-09-07 Thread Kuninori Morimoto
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.

2020-09-07 Thread Kuninori Morimoto
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_CORE R8A7795_CLK_S0D4>, < 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 04/10] drm: rcar-du: Add r8a77961 support

2020-09-07 Thread Kuninori Morimoto


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 = _du_r8a7794_info },
{ .compatible = "renesas,du-r8a7795", .data = _du_r8a7795_info },
{ .compatible = "renesas,du-r8a7796", .data = _du_r8a7796_info },
+   { .compatible = "renesas,du-r8a77961", .data = _du_r8a7796_info },
{ .compatible = "renesas,du-r8a77965", .data = _du_r8a77965_info },
{ .compatible = "renesas,du-r8a77970", .data = _du_r8a77970_info },
{ .compatible = "renesas,du-r8a77980", .data = _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 05/10] arm64: dts: renesas: r8a77961: Add FCP device nodes

2020-09-07 Thread Kuninori Morimoto


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_MOD 615>;
+   power-domains = < R8A77961_PD_A3VC>;
+   resets = < 615>;
+   };
+
+   fcpvb0: fcp@fe96f000 {
+   compatible = "renesas,fcpv";
+   reg = <0 0xfe96f000 0 0x200>;
+   clocks = < CPG_MOD 607>;
+   power-domains = < R8A77961_PD_A3VC>;
+   resets = < 607>;
+   };
+
+   fcpvi0: fcp@fe9af000 {
+   compatible = "renesas,fcpv";
+   reg = <0 0xfe9af000 0 0x200>;
+   clocks = < CPG_MOD 611>;
+   power-domains = < R8A77961_PD_A3VC>;
+   resets = < 611>;
+   iommus = <_vc0 19>;
+   };
+
+   fcpvd0: fcp@fea27000 {
+   compatible = "renesas,fcpv";
+   reg = <0 0xfea27000 0 0x200>;
+   clocks = < CPG_MOD 603>;
+   power-domains = < R8A77961_PD_ALWAYS_ON>;
+   resets = < 603>;
+   iommus = <_vi0 8>;
+   };
+
+   fcpvd1: fcp@fea2f000 {
+   compatible = "renesas,fcpv";
+   reg = <0 0xfea2f000 0 0x200>;
+   clocks = < CPG_MOD 602>;
+   power-domains = < R8A77961_PD_ALWAYS_ON>;
+   resets = < 602>;
+   iommus = <_vi0 9>;
+   };
+
+   fcpvd2: fcp@fea37000 {
+   compatible = "renesas,fcpv";
+   reg = <0 0xfea37000 0 0x200>;
+   clocks = < CPG_MOD 601>;
+   power-domains = < R8A77961_PD_ALWAYS_ON>;
+   resets = < 601>;
+   iommus = <_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

2020-09-07 Thread Kuninori Morimoto


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

2020-09-07 Thread kernel test robot
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 

Re: [PATCH] drm: mxsfb: check framebuffer pitch

2020-09-07 Thread Daniel Abrecht

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

2020-09-07 Thread Ben Skeggs
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

2020-09-07 Thread Kuninori Morimoto


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

2020-09-07 Thread Kuninori Morimoto


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()

2020-09-07 Thread Chun-Kuang Hu
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, ) != 0) {
> dev_err(dev, "Missing reg in %s node\n", node->full_name);
> +   put_device(_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

2020-09-07 Thread Ben Skeggs
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

2020-09-07 Thread Dave Airlie
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 = _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 = _ttm_tt_create,
.ttm_tt_populate = _ttm_populate,
.ttm_tt_unpopulate = _ttm_unpopulate,
+   .ttm_tt_bind = _ttm_bind,
+   .ttm_tt_unbind = _ttm_unbind,
+   .ttm_tt_destroy = _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

2020-09-07 Thread Dave Airlie
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 = _ttm_backend_bind,
-   .unbind = _ttm_backend_unbind,
-   .destroy = _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 = _backend_func;
gtt->gobj = >base;
 
/* allocate space for the uninitialized page entries */
@@ -1679,6 +1672,9 @@ static struct ttm_bo_driver amdgpu_bo_driver = {
.ttm_tt_create = _ttm_tt_create,
.ttm_tt_populate = _ttm_tt_populate,
.ttm_tt_unpopulate = _ttm_tt_unpopulate,
+   .ttm_tt_bind = _ttm_backend_bind,
+   .ttm_tt_unbind = _ttm_backend_unbind,
+   .ttm_tt_destroy = _ttm_backend_destroy,
.eviction_valuable = amdgpu_ttm_bo_eviction_valuable,
.evict_flags = _evict_flags,
.move = _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.

2020-09-07 Thread Dave Airlie
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

2020-09-07 Thread Dave Airlie
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 = _agp_func;
 
if (ttm_tt_init(_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.

2020-09-07 Thread Dave Airlie
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 = _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.

2020-09-07 Thread Dave Airlie
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 _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

2020-09-07 Thread Dave Airlie
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 = >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 >ttm;
 }
 
-static void qxl_move_null(struct ttm_buffer_object *bo,
-struct ttm_resource *new_mem)
-{
-   struct ttm_resource *old_mem = >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 = >mem;
-
-   BUG_ON(old_mem->mm_node != NULL);
-   

[PATCH 06/13] drm/nouveau/ttm: use driver bind/unbind/destroy functions.

2020-09-07 Thread Dave Airlie
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 = _ttm_tt_create,
.ttm_tt_populate = _ttm_tt_populate,
.ttm_tt_unpopulate = _ttm_tt_unpopulate,
+   .ttm_tt_bind = _ttm_tt_bind,
+   .ttm_tt_unbind = _ttm_tt_unbind,
+   .ttm_tt_destroy = _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, >cli->vmm.vmm, >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, >cli->vmm.vmm, >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 = nouveau_mem_host(reg, >ttm);
-   if (ret)
-   

[PATCH 12/13] drm/ttm/agp: remove bdev from agp helpers

2020-09-07 Thread Dave Airlie
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);

[PATCH 03/13] drm/qxl: move bind/unbind/destroy to the driver function table.

2020-09-07 Thread Dave Airlie
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 = _ttm_backend_bind,
-   .unbind = _ttm_backend_unbind,
-   .destroy = _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 = _backend_func;
gtt->qdev = qdev;
if (ttm_tt_init(>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 = _ttm_tt_create,
+   .ttm_tt_bind = _ttm_backend_bind,
+   .ttm_tt_destroy = _ttm_backend_destroy,
+   .ttm_tt_unbind = _ttm_backend_unbind,
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = _evict_flags,
.move = _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)

2020-09-07 Thread Dave Airlie
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 

[PATCH 00/13] ttm tt refactor repost of part 1

2020-09-07 Thread Dave Airlie
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.

2020-09-07 Thread Dave Airlie
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.

2020-09-07 Thread Dave Airlie
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

2020-09-07 Thread Sam Ravnborg
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: 

Re: [PATCH v2 2/3] dt-bindings: display: panel: add TDO tl070wsh30 DSI panel bindings

2020-09-07 Thread Sam Ravnborg
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 = <_lcd_reg>;
> >> +backlight = <_backlight>;
> >> +reset-gpios = <_reset>;
> >> +
> >> +port {
> >> +  panel: endpoint {
> >> +remote-endpoint = <_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

2020-09-07 Thread Dave Airlie
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(>mem, );
> -   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 */
>

Re: [PATCH] drm: mxsfb: check framebuffer pitch

2020-09-07 Thread Daniel Vetter
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,
> >>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

2020-09-07 Thread Daniel Vetter
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

2020-09-07 Thread Daniel Vetter
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, 
> >base);
> - drm_atomic_helper_calc_timestamping_constants(>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()

2020-09-07 Thread Daniel Vetter
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, 
> >base);
> + drm_atomic_helper_calc_timestamping_constants(>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(>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-devel


Re: [Intel-gfx] [PATCH 1/3] drm/atomic-helper: Extract drm_atomic_helper_calc_timestamping_constants()

2020-09-07 Thread Daniel Vetter
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,
>   
> _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

2020-09-07 Thread Daniel Vetter
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

2020-09-07 Thread Daniel Vetter
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 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 

Re: [PATCH v1 0/2] video: fbdev: radeonfb: PCI PM framework upgrade and fix-ups.

2020-09-07 Thread Daniel Vetter
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
> 

[PATCH 1/2] drm/msm/dpu: move vblank events to complete_commit()

2020-09-07 Thread Rob Clark
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

2020-09-07 Thread Rob Clark
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(>event_lock, flags);
-   dpu_crtc->event = crtc->state->event;
-   crtc->state->event = NULL;
-   spin_unlock_irqrestore(>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(>event_lock, flags);
-   dpu_crtc->event = crtc->state->event;
-   crtc->state->event = NULL;
-   spin_unlock_irqrestore(>event_lock, flags);
-   }
+   WARN_ON(dpu_crtc->event);
+   spin_lock_irqsave(>event_lock, flags);
+   dpu_crtc->event = crtc->state->event;
+   crtc->state->event = NULL;
+   spin_unlock_irqrestore(>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;
 
-   if (!crtc) {
-  

[Bug 208997] WARNING: CPU: 3 PID: 1633 at drivers/gpu/drm/drm_modeset_lock.c

2020-09-07 Thread bugzilla-daemon
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

2020-09-07 Thread Sasha Levin
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

2020-09-07 Thread Sasha Levin
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

2020-09-07 Thread Sasha Levin
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

2020-09-07 Thread Laurent Pinchart
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,
>  >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

2020-09-07 Thread Stefan Agner
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,
   >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

2020-09-07 Thread Kieran Bingham
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 = <_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_MOD 626>;
> + power-domains = < R8A77961_PD_A3VC>;
> + resets = < 626>;
> +
> + renesas,fcp = <>;
> + };
> +
> + vspd0: vsp@fea2 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfea2 0 0x5000>;
> + interrupts = ;
> + clocks = < CPG_MOD 623>;
> + power-domains = < R8A77961_PD_ALWAYS_ON>;
> + resets = < 623>;
> +
> + renesas,fcp = <>;
> + };
> +
> + vspd1: vsp@fea28000 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfea28000 0 0x5000>;
> + interrupts = ;
> + clocks = < CPG_MOD 622>;
> + power-domains = < R8A77961_PD_ALWAYS_ON>;
> + resets = < 622>;
> +
> + renesas,fcp = <>;
> + };
> +
> + vspd2: vsp@fea3 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfea3 0 0x5000>;
> + interrupts = ;
> + clocks = < CPG_MOD 621>;
> + power-domains = < R8A77961_PD_ALWAYS_ON>;
> + resets = < 621>;
> +
> + renesas,fcp = <>;
> + };
> +
> + vspi0: vsp@fe9a {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfe9a 0 0x8000>;
> + interrupts = ;
> + clocks = < CPG_MOD 631>;
> + power-domains = < R8A77961_PD_A3VC>;
> + resets = < 631>;
> +
> + renesas,fcp = <>;
> + };
> +
>   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

2020-09-07 Thread Tomasz Figa
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. 

Re: [PATCH v2 03/11] drm/amd/display: Honor the offset for plane 0.

2020-09-07 Thread Sasha Levin
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

2020-09-07 Thread Geert Uytterhoeven
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

2020-09-07 Thread Geert Uytterhoeven
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

2020-09-07 Thread Sergei Shtylyov

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.

2020-09-07 Thread Vaibhav Gupta
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

2020-09-07 Thread Lorenzo Pieralisi
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

2020-09-07 Thread Bernard Zhao
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

2020-09-07 Thread rojay

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 = >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 = >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

2020-09-07 Thread Dmitry Baryshkov

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

2020-09-07 Thread Sergei Shtylyov

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

2020-09-07 Thread rojay

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 = >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 = >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 = _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

2020-09-07 Thread Paul Cercueil




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

2020-09-07 Thread Sergei Shtylyov

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

2020-09-07 Thread Roja Rani Yarubandi
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 = >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, _dma)) {
+   if (dma_buf && geni_se_rx_dma_prep(se, dma_buf, len, >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 = >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, _dma)) {
+   if (dma_buf && geni_se_tx_dma_prep(se, dma_buf, len, >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 = >se;
+
+   ret = pm_runtime_get_sync(gi2c->se.dev);
+   if (ret < 0) {
+   

Re: [PATCH 5/9] arm64: dts: renesas: r8a77961: Add VSP device nodes

2020-09-07 Thread Sergei Shtylyov

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

2020-09-07 Thread Marek Szyprowski
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 Institute Poland

___
dri-devel mailing list
dri-devel@lists.freedesktop.org

Re: [PATCH v4 1/1] drm: allow limiting the scatter list size.

2020-09-07 Thread Daniel Vetter
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 _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)
> +   

Re: [PATCH] drm/doc: Document that modifiers are always required for fb

2020-09-07 Thread Daniel Vetter
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

[PATCH 2/2] drm/ttm: merge offset and base in ttm_bus_placement

2020-09-07 Thread Christian König
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(>mem, );
-   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 

[PATCH 1/2] drm/qxl: don't touch mem.bus.offset

2020-09-07 Thread Christian König
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, >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

2020-09-07 Thread Neil Armstrong
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 = <_lcd_reg>;
>> +backlight = <_backlight>;
>> +reset-gpios = <_reset>;
>> +
>> +port {
>> +  panel: endpoint {
>> +remote-endpoint = <_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

2020-09-07 Thread Tomasz Figa
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

2020-09-07 Thread Joonas Lahtinen
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 

Re: [PATCH] drm/ttm: merge offset and base in ttm_bus_placement

2020-09-07 Thread Nirmoy


Acked-by: Nirmoy Das 

On 9/7/20 2:05 PM, 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(>mem, );

-   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);

Re: [PATCH v1 0/2] video: fbdev: radeonfb: PCI PM framework upgrade and fix-ups.

2020-09-07 Thread Benjamin Herrenschmidt
On Mon, 2020-09-07 at 09:55 +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
> ...

The only thing is, afaik, the DRM drivers never got the D2/D3 code that
I wrote for radeonfb to get old powerbooks to suspend/resume.

Cheers,
Ben.

> -Daniel
> 
> > 
> > 
> > 
> > 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
> 
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/ttm: merge offset and base in ttm_bus_placement

2020-09-07 Thread Christian König
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(>mem, );
-   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 

Re: [PATCH v5 80/80] ARM: dts: bcm2711: Enable the display pipeline

2020-09-07 Thread Hoegeun Kwon
Hi Maxime,

On 9/3/20 5:01 PM, Maxime Ripard wrote:
> Now that all the drivers have been adjusted for it, let's bring in the
> necessary device tree changes.
>
> The VEC and PV3 are left out for now, since it will require a more specific
> clock setup.
>
> Reviewed-by: Dave Stevenson 
> Tested-by: Chanwoo Choi 
> Tested-by: Hoegeun Kwon 
> Tested-by: Stefan Wahren 
> Signed-off-by: Maxime Ripard 

Thanks for your v5 patch


Reviewed-by: Hoegeun Kwon 


Best regards,

Hoegeun

> ---
>   arch/arm/boot/dts/bcm2711-rpi-4-b.dts |  48 +++-
>   arch/arm/boot/dts/bcm2711.dtsi| 122 ++-
>   2 files changed, 169 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts 
> b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> index e94244a215af..09a1182c2936 100644
> --- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> +++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> @@ -70,6 +70,14 @@
>   };
>   };
>   
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
>{
>   firmware_clocks: clocks {
>   compatible = "raspberrypi,firmware-clocks";
> @@ -170,6 +178,38 @@
> "RGMII_TXD3";
>   };
>   
> + {
> + clocks = <_clocks 13>, <_clocks 14>, < 0>, 
> <_27MHz>;
> + clock-names = "hdmi", "bvb", "audio", "cec";
> + status = "okay";
> +};
> +
> + {
> + clocks = <_clocks 13>, <_clocks 14>, < 1>, 
> <_27MHz>;
> + clock-names = "hdmi", "bvb", "audio", "cec";
> + status = "okay";
> +};
> +
> + {
> + clocks = <_clocks 4>;
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
>{
>   pinctrl-names = "default";
>   pinctrl-0 = <_0_gpio40 _1_gpio41>;
> @@ -253,3 +293,11 @@
>{
>   interrupts = ;
>   };
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "disabled";
> +};
> diff --git a/arch/arm/boot/dts/bcm2711.dtsi b/arch/arm/boot/dts/bcm2711.dtsi
> index 00bcaed1be32..4847dd305317 100644
> --- a/arch/arm/boot/dts/bcm2711.dtsi
> +++ b/arch/arm/boot/dts/bcm2711.dtsi
> @@ -12,6 +12,18 @@
>   
>   interrupt-parent = <>;
>   
> + vc4: gpu {
> + compatible = "brcm,bcm2711-vc5";
> + status = "disabled";
> + };
> +
> + clk_27MHz: clk-27M {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <2700>;
> + clock-output-names = "27MHz-clock";
> + };
> +
>   clk_108MHz: clk-108M {
>   #clock-cells = <0>;
>   compatible = "fixed-clock";
> @@ -238,6 +250,27 @@
>   status = "disabled";
>   };
>   
> + pixelvalve0: pixelvalve@7e206000 {
> + compatible = "brcm,bcm2711-pixelvalve0";
> + reg = <0x7e206000 0x100>;
> + interrupts = ;
> + status = "disabled";
> + };
> +
> + pixelvalve1: pixelvalve@7e207000 {
> + compatible = "brcm,bcm2711-pixelvalve1";
> + reg = <0x7e207000 0x100>;
> + interrupts = ;
> + status = "disabled";
> + };
> +
> + pixelvalve2: pixelvalve@7e20a000 {
> + compatible = "brcm,bcm2711-pixelvalve2";
> + reg = <0x7e20a000 0x100>;
> + interrupts = ;
> + status = "disabled";
> + };
> +
>   pwm1: pwm@7e20c800 {
>   compatible = "brcm,bcm2835-pwm";
>   reg = <0x7e20c800 0x28>;
> @@ -248,10 +281,25 @@
>   status = "disabled";
>   };
>   
> - hvs@7e40 {
> + pixelvalve4: pixelvalve@7e216000 {
> + compatible = "brcm,bcm2711-pixelvalve4";
> + reg = <0x7e216000 0x100>;
> + interrupts = ;
> + status = "disabled";
> + };
> +
> + hvs: hvs@7e40 {
> + compatible = "brcm,bcm2711-hvs";
>   interrupts = ;
>   };
>   
> + pixelvalve3: pixelvalve@7ec12000 {
> + compatible = "brcm,bcm2711-pixelvalve3";
> + reg = <0x7ec12000 0x100>;
> + interrupts = ;
> + status = "disabled";
> + };
> +
>   dvp: clock@7ef0 {
>   compatible = "brcm,brcm2711-dvp";
>   reg = <0x7ef0 0x10>;
> @@ -259,6 +307,78 @@
>   #clock-cells = <1>;
>   #reset-cells = <1>;
>   };
> +
> + hdmi0: hdmi@7ef00700 {
> + compatible = "brcm,bcm2711-hdmi0";
> + reg = <0x7ef00700 0x300>,
> +  

[PATCH 1/3] drm/atomic-helper: Extract drm_atomic_helper_calc_timestamping_constants()

2020-09-07 Thread Ville Syrjala
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ä 
---
 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,

_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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 3/3] drm/i915: Drop the drm_atomic_helper_calc_timestamping_constants() call

2020-09-07 Thread Ville Syrjala
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ä 
---
 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, 
>base);
-   drm_atomic_helper_calc_timestamping_constants(>base);
 
intel_set_cdclk_pre_plane_update(state);
 
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 2/3] drm/atomic-helper: Remove the timestamping constant update from drm_atomic_helper_update_legacy_modeset_state()

2020-09-07 Thread Ville Syrjala
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ä 
---
 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, 
>base);
+   drm_atomic_helper_calc_timestamping_constants(>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(>mutex);
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v5 77/80] dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings

2020-09-07 Thread Hoegeun Kwon
Hi Maxime,

On 9/3/20 5:01 PM, Maxime Ripard wrote:
> The HDMI controllers found in the BCM2711 SoC need some adjustments to the
> bindings, especially since the registers have been shuffled around in more
> register ranges.
>
> Reviewed-by: Rob Herring 
> Tested-by: Chanwoo Choi 
> Tested-by: Hoegeun Kwon 
> Tested-by: Stefan Wahren 
> Signed-off-by: Maxime Ripard 

Thanks for your v5 patch


Reviewed-by: Hoegeun Kwon 


Best regards,

Hoegeun

> ---
>   Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml | 117 
> -
>   1 file changed, 117 insertions(+)
>   create mode 100644 
> Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml 
> b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> new file mode 100644
> index ..03a76729d26c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> @@ -0,0 +1,117 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: 
> https://protect2.fireeye.com/v1/url?k=0b6f5f6c-56a4d852-0b6ed423-0cc47a31309a-d9c680091736128f=1=24b01bb3-08a1-4c21-9bf9-e1d1e9ffdc3e=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fdisplay%2Fbrcm%2Cbcm2711-hdmi.yaml%23
> +$schema: 
> https://protect2.fireeye.com/v1/url?k=a854ae90-f59f29ae-a85525df-0cc47a31309a-1160616098892a41=1=24b01bb3-08a1-4c21-9bf9-e1d1e9ffdc3e=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23
> +
> +title: Broadcom BCM2711 HDMI Controller Device Tree Bindings
> +
> +maintainers:
> +  - Eric Anholt 
> +
> +properties:
> +  compatible:
> +enum:
> +  - brcm,bcm2711-hdmi0
> +  - brcm,bcm2711-hdmi1
> +
> +  reg:
> +items:
> +  - description: HDMI controller register range
> +  - description: DVP register range
> +  - description: HDMI PHY register range
> +  - description: Rate Manager register range
> +  - description: Packet RAM register range
> +  - description: Metadata RAM register range
> +  - description: CSC register range
> +  - description: CEC register range
> +  - description: HD register range
> +
> +  reg-names:
> +items:
> +  - const: hdmi
> +  - const: dvp
> +  - const: phy
> +  - const: rm
> +  - const: packet
> +  - const: metadata
> +  - const: csc
> +  - const: cec
> +  - const: hd
> +
> +  clocks:
> +items:
> +  - description: The HDMI state machine clock
> +  - description: The Pixel BVB clock
> +  - description: The HDMI Audio parent clock
> +  - description: The HDMI CEC parent clock
> +
> +  clock-names:
> +items:
> +  - const: hdmi
> +  - const: bvb
> +  - const: audio
> +  - const: cec
> +
> +  ddc:
> +allOf:
> +  - $ref: /schemas/types.yaml#/definitions/phandle
> +description: >
> +  Phandle of the I2C controller used for DDC EDID probing
> +
> +  hpd-gpios:
> +description: >
> +  The GPIO pin for the HDMI hotplug detect (if it doesn't appear
> +  as an interrupt/status bit in the HDMI controller itself)
> +
> +  dmas:
> +maxItems: 1
> +description: >
> +  Should contain one entry pointing to the DMA channel used to
> +  transfer audio data.
> +
> +  dma-names:
> +const: audio-rx
> +
> +  resets:
> +maxItems: 1
> +
> +required:
> +  - compatible
> +  - reg
> +  - reg-names
> +  - clocks
> +  - resets
> +  - ddc
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +hdmi0: hdmi@7ef00700 {
> +compatible = "brcm,bcm2711-hdmi0";
> +reg = <0x7ef00700 0x300>,
> +  <0x7ef00300 0x200>,
> +  <0x7ef00f00 0x80>,
> +  <0x7ef00f80 0x80>,
> +  <0x7ef01b00 0x200>,
> +  <0x7ef01f00 0x400>,
> +  <0x7ef00200 0x80>,
> +  <0x7ef04300 0x100>,
> +  <0x7ef2 0x100>;
> +reg-names = "hdmi",
> +"dvp",
> +"phy",
> +"rm",
> +"packet",
> +"metadata",
> +"csc",
> +"cec",
> +"hd";
> +clocks = <_clocks 13>, <_clocks 14>, < 1>, 
> <_27MHz>;
> +clock-names = "hdmi", "bvb", "audio", "cec";
> +resets = < 0>;
> +ddc = <>;
> +};
> +
> +...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v5 00/80] drm/vc4: Support BCM2711 Display Pipeline

2020-09-07 Thread Hoegeun Kwon
Hi Maxime,

On 9/3/20 5:00 PM, Maxime Ripard wrote:
> Hi everyone,
>
> Here's a (pretty long) series to introduce support in the VC4 DRM driver
> for the display pipeline found in the BCM2711 (and thus the RaspberryPi 4).
>
> The main differences are that there's two HDMI controllers and that there's
> more pixelvalve now. Those pixelvalve come with a mux in the HVS that still
> have only 3 FIFOs. Both of those differences are breaking a bunch of
> expectations in the driver, so we first need a good bunch of cleanup and
> reworks to introduce support for the new controllers.
>
> Similarly, the HDMI controller has all its registers shuffled and split in
> multiple controllers now, so we need a bunch of changes to support this as
> well.
>
> Only the HDMI support is enabled for now (even though the DPI and DSI
> outputs have been tested too).
>
> Let me know if you have any comments
> Maxime
>
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Cc: devicet...@vger.kernel.org
> Cc: Kamal Dasu 
> Cc: Philipp Zabel 
> Cc: Rob Herring 
> Cc: Stephen Boyd 
>
> Changes from v4:
>- Rebased on top of next-20200828
>- Collected the various tags
>- Fixed some issues with 4k support and dual output (thanks Hoegeun!)

Thanks for your v5 patchset.

I tested all patches based on the next-20200812.

Everything else is fine, but the dual hdmi modetest doesn't work well in my
environment...

In my environment, dsi is not connected, I have seen your answer[1].

Do you have any other settings? For example in config.txt.


[1] https://lkml.org/lkml/2020/9/2/566

>- Fixed typos in commit logs (thanks Dave!)
>- Split the csc setup hook into its own patch again
>- Added the CEC clock to the DT binding
>- Fixed the DT binding example
>- Reduced the number of calls to of_device_is_compatible in vc4_kms_load
>- Added back the check for the state commit in our commit hook

Best regards,

Hoegeun

___
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

2020-09-07 Thread Sam Ravnborg
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

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 = <_lcd_reg>;
> +backlight = <_backlight>;
> +reset-gpios = <_reset>;
> +
> +port {
> +  panel: endpoint {
> +remote-endpoint = <_dsi_out>;
> +  };
> +};
> +  };
> +};
> -- 
> 2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


  1   2   >