date:20201111

Re: [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema

2020-11-11 Thread Laurent Pinchart

Hi Rob,

On Wed, Nov 11, 2020 at 05:03:26PM -0600, Rob Herring wrote:
> On Wed, Nov 11, 2020 at 8:27 AM Laurent Pinchart wrote:
> > On Wed, Nov 11, 2020 at 08:25:40AM -0600, Rob Herring wrote:
> > > On Wed, Nov 11, 2020 at 8:00 AM Laurent Pinchart wrote:
> > > > On Mon, Nov 02, 2020 at 02:36:54PM -0600, Rob Herring wrote:
> > > > > From: Sameer Pujar 
> > > > >
> > > > > Convert device tree bindings of graph to YAML format. Currently 
> > > > > graph.txt
> > > > > doc is referenced in multiple files and all of these need to use 
> > > > > schema
> > > > > references. For now graph.txt is updated to refer to graph.yaml.
> > > > >
> > > > > For users of the graph binding, they should reference to the graph
> > > > > schema from either 'ports' or 'port' property:
> > > > >
> > > > > properties:
> > > > >   ports:
> > > > > type: object
> > > > > $ref: graph.yaml#/properties/ports
> > > > >
> > > > > properties:
> > > > >   port@0:
> > > > > description: What data this port has
> > > > >
> > > > >   ...
> > > > >
> > > > > Or:
> > > > >
> > > > > properties:
> > > > >   port:
> > > > > description: What data this port has
> > > > > type: object
> > > > > $ref: graph.yaml#/properties/port
> > > >
> > > > Sounds like a good approach.
> > > >
> > > > > Signed-off-by: Sameer Pujar 
> > > > > Acked-by: Philipp Zabel 
> > > > > Signed-off-by: Rob Herring 
> > > > > ---
> > > > > v3:
> > > > >  - Move port 'reg' to port@* and make required
> > > > >  - Make remote-endpoint required
> > > > >  - Add 'additionalProperties: true' now required
> > > > >  - Fix yamllint warnings
> > > > >
> > > > >  Documentation/devicetree/bindings/graph.txt  | 129 +---
> > > > >  Documentation/devicetree/bindings/graph.yaml | 199 
> > > > > +++
> > > > >  2 files changed, 200 insertions(+), 128 deletions(-)
> > > > >  create mode 100644 Documentation/devicetree/bindings/graph.yaml
> > >
> > > [...]
> > >
> > > > > diff --git a/Documentation/devicetree/bindings/graph.yaml 
> > > > > b/Documentation/devicetree/bindings/graph.yaml
> > > > > new file mode 100644
> > > > > index ..b56720c5a13e
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/graph.yaml
> > > > > @@ -0,0 +1,199 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/graph.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: Common bindings for device graphs
> > > > > +
> > > > > +description: |
> > > > > +  The hierarchical organisation of the device tree is well suited to 
> > > > > describe
> > > > > +  control flow to devices, but there can be more complex connections 
> > > > > between
> > > > > +  devices that work together to form a logical compound device, 
> > > > > following an
> > > > > +  arbitrarily complex graph.
> > > > > +  There already is a simple directed graph between devices tree 
> > > > > nodes using
> > > > > +  phandle properties pointing to other nodes to describe connections 
> > > > > that
> > > > > +  can not be inferred from device tree parent-child relationships. 
> > > > > The device
> > > > > +  tree graph bindings described herein abstract more complex devices 
> > > > > that can
> > > > > +  have multiple specifiable ports, each of which can be linked to 
> > > > > one or more
> > > > > +  ports of other devices.
> > > > > +
> > > > > +  These common bindings do not contain any information about the 
> > > > > direction or
> > > > > +  type of the connections, they just map their existence. Specific 
> > > > > properties
> > > > > +  may be described by specialized bindings depending on the type of 
> > > > > connection.
> > > > > +
> > > > > +  To see how this binding applies to video pipelines, for example, 
> > > > > see
> > > > > +  Documentation/devicetree/bindings/media/video-interfaces.txt.
> > > > > +  Here the ports describe data interfaces, and the links between 
> > > > > them are
> > > > > +  the connecting data buses. A single port with multiple connections 
> > > > > can
> > > > > +  correspond to multiple devices being connected to the same 
> > > > > physical bus.
> > > > > +
> > > > > +maintainers:
> > > > > +  - Philipp Zabel 
> > > > > +
> > > > > +select: false
> > > > > +
> > > > > +properties:
> > > > > +  port:
> > > > > +type: object
> > > > > +description:
> > > > > +  If there is more than one endpoint node or 'reg' property 
> > > > > present in
> > > > > +  endpoint nodes then '#address-cells' and '#size-cells' 
> > > > > properties are
> > > > > +  required.
> > > > > +
> > > > > +properties:
> > > > > +  "#address-cells":
> > > > > +const: 1
> > > > > +
> > > > > +  "#size-cells":
> > > > > +const: 0
> > > > > +
> > > > > +patternProperties:
> > > > > +  "^endpoint(@[0-9a-f]+)?$":
> > > > > +type: object
>

Re: [PATCH v5 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation

2020-11-11 Thread Sumit Semwal

Hi John,

On Tue, 10 Nov 2020 at 09:19, John Stultz  wrote:
>
> Hey All,
>   So just wanted to send my last revision of my patch series
> of performance optimizations to the dma-buf system heap.

Thanks very much for your patches - I think the first 5 patches look good to me.

I know there was a bit of discussion over adding a new system-uncached
heap v/s using a flag to identify that; I think I prefer the separate
heap idea, but lets ask one last time if any one else has any real
objections to it.

Daniel, Christian: any comments from your side on this?

I am planning to merge this series to drm-misc this week if I hear no
objections.
>
> This series reworks the system heap to use sgtables, and then
> consolidates the pagelist method from the heap-helpers into the
> CMA heap. After which the heap-helpers logic is removed (as it
> is unused). I'd still like to find a better way to avoid some of
> the logic duplication in implementing the entire dma_buf_ops
> handlers per heap. But unfortunately that code is tied somewhat
> to how the buffer's memory is tracked. As more heaps show up I
> think we'll have a better idea how to best share code, so for
> now I think this is ok.
>
> After this, the series introduces an optimization that
> Ørjan Eide implemented for ION that avoids calling sync on
> attachments that don't have a mapping.
>
> Next, an optimization to use larger order pages for the system
> heap. This change brings us closer to the current performance
> of the ION allocation code (though there still is a gap due
> to ION using a mix of deferred-freeing and page pools, I'll be
> looking at integrating those eventually).
>
> Finally, a reworked version of my uncached system heap
> implementation I was submitting a few weeks back. Since it
> duplicated a lot of the now reworked system heap code, I
> realized it would be much simpler to add the functionality to
> the system_heap implementation itself.
>
> While not improving the core allocation performance, the
> uncached heap allocations do result in *much* improved
> performance on HiKey960 as it avoids a lot of flushing and
> invalidating buffers that the cpu doesn't touch often.
>
> Feedback on these would be great!
>
> thanks
> -john
>
> New in v5:
> * Added a comment explaining why the order sizes are
>   chosen as they are
>
> Cc: Sumit Semwal 
> Cc: Liam Mark 
> Cc: Laura Abbott 
> Cc: Brian Starkey 
> Cc: Hridya Valsaraju 
> Cc: Suren Baghdasaryan 
> Cc: Sandeep Patil 
> Cc: Daniel Mentz 
> Cc: Chris Goldsworthy 
> Cc: Ørjan Eide 
> Cc: Robin Murphy 
> Cc: Ezequiel Garcia 
> Cc: Simon Ser 
> Cc: James Jones 
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
>
> John Stultz (7):
>   dma-buf: system_heap: Rework system heap to use sgtables instead of
> pagelists
>   dma-buf: heaps: Move heap-helper logic into the cma_heap
> implementation
>   dma-buf: heaps: Remove heap-helpers code
>   dma-buf: heaps: Skip sync if not mapped
>   dma-buf: system_heap: Allocate higher order pages if available
>   dma-buf: dma-heap: Keep track of the heap device struct
>   dma-buf: system_heap: Add a system-uncached heap re-using the system
> heap
>
>  drivers/dma-buf/dma-heap.c   |  33 +-
>  drivers/dma-buf/heaps/Makefile   |   1 -
>  drivers/dma-buf/heaps/cma_heap.c | 324 +++---
>  drivers/dma-buf/heaps/heap-helpers.c | 270 ---
>  drivers/dma-buf/heaps/heap-helpers.h |  53 ---
>  drivers/dma-buf/heaps/system_heap.c  | 494 ---
>  include/linux/dma-heap.h |   9 +
>  7 files changed, 753 insertions(+), 431 deletions(-)
>  delete mode 100644 drivers/dma-buf/heaps/heap-helpers.c
>  delete mode 100644 drivers/dma-buf/heaps/heap-helpers.h
>
> --
> 2.17.1
>
Thanks much,

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

Re: [PATCH v2 4/8] drm/amdgpu: Split amdgpu_device_fini into early and late

2020-11-11 Thread Andrey Grodzovsky




On 6/22/20 5:48 AM, Daniel Vetter wrote:

On Sun, Jun 21, 2020 at 02:03:04AM -0400, Andrey Grodzovsky wrote:

Some of the stuff in amdgpu_device_fini such as HW interrupts
disable and pending fences finilization must be done right away on
pci_remove while most of the stuff which relates to finilizing and releasing
driver data structures can be kept until drm_driver.release hook is called, i.e.
when the last device reference is dropped.

Signed-off-by: Andrey Grodzovsky 

Long term I think best if as much of this code is converted over to devm
(for hw stuff) and drmm (for sw stuff and allocations). Doing this all
manually is very error prone.

I've started various such patches and others followed, but thus far only
very simple drivers tackled. But it should be doable step by step at
least, so you should have incremental benefits in code complexity right
away I hope.
-Daniel



Sure, I will definitely add this to my TODOs for after landing (hopefully) this 
patch set (after a few more iterations)

as indeed the required changes for using devm and drmm are non trivial and I 
prefer
to avoid diverging here into multiple directions at once.

Andrey





---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  6 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 15 +++
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  6 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c| 24 +++-
  drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h|  1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 23 +--
  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c|  3 +++
  7 files changed, 54 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 2a806cb..604a681 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1003,7 +1003,9 @@ int amdgpu_device_init(struct amdgpu_device *adev,
   struct drm_device *ddev,
   struct pci_dev *pdev,
   uint32_t flags);
-void amdgpu_device_fini(struct amdgpu_device *adev);
+void amdgpu_device_fini_early(struct amdgpu_device *adev);
+void amdgpu_device_fini_late(struct amdgpu_device *adev);
+
  int amdgpu_gpu_wait_for_idle(struct amdgpu_device *adev);
  
  void amdgpu_device_vram_access(struct amdgpu_device *adev, loff_t pos,

@@ -1188,6 +1190,8 @@ void amdgpu_driver_lastclose_kms(struct drm_device *dev);
  int amdgpu_driver_open_kms(struct drm_device *dev, struct drm_file 
*file_priv);
  void amdgpu_driver_postclose_kms(struct drm_device *dev,
 struct drm_file *file_priv);
+void amdgpu_driver_release_kms(struct drm_device *dev);
+
  int amdgpu_device_ip_suspend(struct amdgpu_device *adev);
  int amdgpu_device_suspend(struct drm_device *dev, bool fbcon);
  int amdgpu_device_resume(struct drm_device *dev, bool fbcon);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index cc41e8f..e7b9065 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2309,6 +2309,8 @@ static int amdgpu_device_ip_fini(struct amdgpu_device 
*adev)
  {
int i, r;
  
+	//DRM_ERROR("adev 0x%llx", (long long unsigned int)adev);

+
amdgpu_ras_pre_fini(adev);
  
  	if (adev->gmc.xgmi.num_physical_nodes > 1)

@@ -3304,10 +3306,8 @@ int amdgpu_device_init(struct amdgpu_device *adev,
   * Tear down the driver info (all asics).
   * Called at driver shutdown.
   */
-void amdgpu_device_fini(struct amdgpu_device *adev)
+void amdgpu_device_fini_early(struct amdgpu_device *adev)
  {
-   int r;
-
DRM_INFO("amdgpu: finishing device.\n");
flush_delayed_work(>delayed_init_work);
adev->shutdown = true;
@@ -3330,7 +3330,13 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
if (adev->pm_sysfs_en)
amdgpu_pm_sysfs_fini(adev);
amdgpu_fbdev_fini(adev);
-   r = amdgpu_device_ip_fini(adev);
+
+   amdgpu_irq_fini_early(adev);
+}
+
+void amdgpu_device_fini_late(struct amdgpu_device *adev)
+{
+   amdgpu_device_ip_fini(adev);
if (adev->firmware.gpu_info_fw) {
release_firmware(adev->firmware.gpu_info_fw);
adev->firmware.gpu_info_fw = NULL;
@@ -3368,6 +3374,7 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
amdgpu_pmu_fini(adev);
if (amdgpu_discovery && adev->asic_type >= CHIP_NAVI10)
amdgpu_discovery_fini(adev);
+
  }
  
  
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c

index 9e5afa5..43592dc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1134,12 +1134,9 @@ amdgpu_pci_remove(struct pci_dev *pdev)
  {
struct drm_device *dev = pci_get_drvdata(pdev);
  
-#ifdef MODULE

-   if (THIS_MODULE->state != MODULE_STATE_GOING)
-#endif
-

[PULL] nouveau-fixes 5.10

2020-11-11 Thread Ben Skeggs

The following changes since commit 512bce50a41c528fa15c4c014293e7bebf018658:

  Merge v5.10-rc3 into drm-next (2020-11-10 14:36:36 +0100)

are available in the Git repository at:

  git://github.com/skeggsb/linux linux-5.10

for you to fetch changes up to f67e5ecab785631cf7f776533432ba5aba06615a:

  drm/nouveau/ttm: avoid using nouveau_drm.ttm.type_vram prior to nv50
(2020-11-12 14:09:45 +1000)


Alexander Kapshuk (1):
  drm/nouveau/kms: Fix NULL pointer dereference in
nouveau_connector_detect_depth

Ben Skeggs (1):
  drm/nouveau/ttm: avoid using nouveau_drm.ttm.type_vram prior to nv50

 drivers/gpu/drm/nouveau/nouveau_bo.c|  3 +--
 drivers/gpu/drm/nouveau/nouveau_connector.c | 14 +-
 2 files changed, 10 insertions(+), 7 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau: Fix out-of-bounds access when deferencing MMU type

2020-11-11 Thread Ben Skeggs

On Thu, 12 Nov 2020 at 02:27, Ruhl, Michael J  wrote:
>
> >-Original Message-
> >From: Thomas Zimmermann 
> >Sent: Wednesday, November 11, 2020 7:08 AM
> >To: Ruhl, Michael J ; bske...@redhat.com;
> >airl...@linux.ie; dan...@ffwll.ch; christian.koe...@amd.com
> >Cc: nouv...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> >Maarten Lankhorst ; Maxime Ripard
> >; Dave Airlie ; Gerd Hoffmann
> >; Alex Deucher ;
> >VMware Graphics ; Roland
> >Scheidegger ; Huang Rui ;
> >Felix Kuehling ; Hawking Zhang
> >; Jason Gunthorpe ; Likun Gao
> >; virtualizat...@lists.linux-foundation.org; spice-
> >de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
> >Subject: Re: [PATCH] drm/nouveau: Fix out-of-bounds access when
> >deferencing MMU type
> >
> >Hi
> >
> >Am 10.11.20 um 16:27 schrieb Ruhl, Michael J:
> >>
> >>
> >>> -Original Message-
> >>> From: Thomas Zimmermann 
> >>> Sent: Tuesday, November 10, 2020 8:37 AM
> >>> To: bske...@redhat.com; airl...@linux.ie; dan...@ffwll.ch; Ruhl, Michael J
> >>> ; christian.koe...@amd.com
> >>> Cc: nouv...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> >Thomas
> >>> Zimmermann ; Maarten Lankhorst
> >>> ; Maxime Ripard
> >>> ; Dave Airlie ; Gerd Hoffmann
> >>> ; Alex Deucher ;
> >>> VMware Graphics ; Roland
> >>> Scheidegger ; Huang Rui ;
> >>> Felix Kuehling ; Hawking Zhang
> >>> ; Jason Gunthorpe ; Likun
> >Gao
> >>> ; virtualizat...@lists.linux-foundation.org; spice-
> >>> de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
> >>> Subject: [PATCH] drm/nouveau: Fix out-of-bounds access when
> >deferencing
> >>> MMU type
> >>>
> >>> The value of struct drm_device.ttm.type_vram can become -1 for
> >unknown
> >>> types of memory (see nouveau_ttm_init()). This leads to an out-of-bounds
> >>> error when accessing struct nvif_mmu.type[]:
> >>
> >> Would this make more sense to just set the type_vram = 0 instead of -1?
> >
> >From what I understand, these indices refer to an internal type of MMU,
> >rsp the MMU's capabilities. However, my hardware (pre-NV50) does not
> >have an MMU at all.
>
> Yeah, and upon further review I see that my comment was completely wrong
> (value vs. index).
>
> A better suggestion would have been, create an entry in the array that means,
> "unsupported type" with a value of 0, but...
>
> >I agree that it would be nice to have a cleaner design that incorporates
> >this case, but resolving that would apparently require more than a bugfix.
>
> I agree.  The -1 index is a special case for the platform path
> (platform != NV_DEVICE_INFO_V0_SOC).  This is a fix for the issue, but not
> a complete solution.
>
> If you need it:
> Reviewed-by: Michael J. Ruhl 
I've put an alternate fix for this here[1], and will get it into
drm-fixes later today.

Ben.

[1] 
https://github.com/skeggsb/nouveau/commit/4590f7120c2f1f4aea9d8b93a2dae43b312d35ad

>
> Thanks,
> Mike
>
> >Best regards
> >Thomas
> >
> >>
> >> Mike
> >>
> >>>
> >>>  [   18.304116]
> >>>
> >===
> >>> ===
> >>>  [   18.311649] BUG: KASAN: slab-out-of-bounds in
> >>> nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
> >>>  [   18.320415] Read of size 1 at addr 88810ffac1fe by task systemd-
> >>> udevd/342
> >>>  [   18.327681]
> >>>  [   18.329208] CPU: 1 PID: 342 Comm: systemd-udevd Tainted: G
> >>> E
> >>> 5.10.0-rc2-1-default+ #581
> >>>  [   18.338681] Hardware name: Dell Inc. OptiPlex 9020/0N4YC8, BIOS A24
> >>> 10/24/2018
> >>>  [   18.346032] Call Trace:
> >>>  [   18.348536]  dump_stack+0xae/0xe5
> >>>  [   18.351919]  print_address_description.constprop.0+0x17/0xf0
> >>>  [   18.357787]  ? nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
> >>>  [   18.363818]  __kasan_report.cold+0x20/0x38
> >>>  [   18.368099]  ? nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
> >>>  [   18.374133]  kasan_report+0x3a/0x50
> >>>  [   18.377789]  nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
> >>>  <...>
> >>>  [   18.767690] Allocated by task 342:
> >>>  [   18.773087]  kasan_save_stack+0x1b/0x40
> >>>  [   18.778890]  __kasan_kmalloc.constprop.0+0xbf/0xd0
> >>>  [   18.785646]  __kmalloc_track_caller+0x1be/0x390
> >>>  [   18.792165]  kstrdup_const+0x46/0x70
> >>>  [   18.797686]  kobject_set_name_vargs+0x2f/0xb0
> >>>  [   18.803992]  kobject_init_and_add+0x9d/0xf0
> >>>  [   18.810117]  ttm_mem_global_init+0x12c/0x210 [ttm]
> >>>  [   18.816853]  ttm_bo_global_init+0x4a/0x160 [ttm]
> >>>  [   18.823420]  ttm_bo_device_init+0x39/0x220 [ttm]
> >>>  [   18.830046]  nouveau_ttm_init+0x2c3/0x830 [nouveau]
> >>>  [   18.836929]  nouveau_drm_device_init+0x1b4/0x3f0 [nouveau]
> >>>  <...>
> >>>  [   19.105336]
> >>>
> >===
> >>> ===
> >>>
> >>> Fix this error, by not using type_vram as an index if it's negative.
> >>> Assume default values instead.
> >>>
> >>> The error was seen on Nvidia G72 hardware.
> >>>
> >>> Signed-off-by: Thomas

Re: [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema

2020-11-11 Thread Rob Herring

On Wed, Nov 11, 2020 at 8:27 AM Laurent Pinchart
 wrote:
>
> Hi Rob,
>
> On Wed, Nov 11, 2020 at 08:25:40AM -0600, Rob Herring wrote:
> > On Wed, Nov 11, 2020 at 8:00 AM Laurent Pinchart wrote:
> > > On Mon, Nov 02, 2020 at 02:36:54PM -0600, Rob Herring wrote:
> > > > From: Sameer Pujar 
> > > >
> > > > Convert device tree bindings of graph to YAML format. Currently 
> > > > graph.txt
> > > > doc is referenced in multiple files and all of these need to use schema
> > > > references. For now graph.txt is updated to refer to graph.yaml.
> > > >
> > > > For users of the graph binding, they should reference to the graph
> > > > schema from either 'ports' or 'port' property:
> > > >
> > > > properties:
> > > >   ports:
> > > > type: object
> > > > $ref: graph.yaml#/properties/ports
> > > >
> > > > properties:
> > > >   port@0:
> > > > description: What data this port has
> > > >
> > > >   ...
> > > >
> > > > Or:
> > > >
> > > > properties:
> > > >   port:
> > > > description: What data this port has
> > > > type: object
> > > > $ref: graph.yaml#/properties/port
> > >
> > > Sounds like a good approach.
> > >
> > > > Signed-off-by: Sameer Pujar 
> > > > Acked-by: Philipp Zabel 
> > > > Signed-off-by: Rob Herring 
> > > > ---
> > > > v3:
> > > >  - Move port 'reg' to port@* and make required
> > > >  - Make remote-endpoint required
> > > >  - Add 'additionalProperties: true' now required
> > > >  - Fix yamllint warnings
> > > >
> > > >  Documentation/devicetree/bindings/graph.txt  | 129 +---
> > > >  Documentation/devicetree/bindings/graph.yaml | 199 +++
> > > >  2 files changed, 200 insertions(+), 128 deletions(-)
> > > >  create mode 100644 Documentation/devicetree/bindings/graph.yaml
> >
> > [...]
> >
> > > > diff --git a/Documentation/devicetree/bindings/graph.yaml 
> > > > b/Documentation/devicetree/bindings/graph.yaml
> > > > new file mode 100644
> > > > index ..b56720c5a13e
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/graph.yaml
> > > > @@ -0,0 +1,199 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/graph.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Common bindings for device graphs
> > > > +
> > > > +description: |
> > > > +  The hierarchical organisation of the device tree is well suited to 
> > > > describe
> > > > +  control flow to devices, but there can be more complex connections 
> > > > between
> > > > +  devices that work together to form a logical compound device, 
> > > > following an
> > > > +  arbitrarily complex graph.
> > > > +  There already is a simple directed graph between devices tree nodes 
> > > > using
> > > > +  phandle properties pointing to other nodes to describe connections 
> > > > that
> > > > +  can not be inferred from device tree parent-child relationships. The 
> > > > device
> > > > +  tree graph bindings described herein abstract more complex devices 
> > > > that can
> > > > +  have multiple specifiable ports, each of which can be linked to one 
> > > > or more
> > > > +  ports of other devices.
> > > > +
> > > > +  These common bindings do not contain any information about the 
> > > > direction or
> > > > +  type of the connections, they just map their existence. Specific 
> > > > properties
> > > > +  may be described by specialized bindings depending on the type of 
> > > > connection.
> > > > +
> > > > +  To see how this binding applies to video pipelines, for example, see
> > > > +  Documentation/devicetree/bindings/media/video-interfaces.txt.
> > > > +  Here the ports describe data interfaces, and the links between them 
> > > > are
> > > > +  the connecting data buses. A single port with multiple connections 
> > > > can
> > > > +  correspond to multiple devices being connected to the same physical 
> > > > bus.
> > > > +
> > > > +maintainers:
> > > > +  - Philipp Zabel 
> > > > +
> > > > +select: false
> > > > +
> > > > +properties:
> > > > +  port:
> > > > +type: object
> > > > +description:
> > > > +  If there is more than one endpoint node or 'reg' property 
> > > > present in
> > > > +  endpoint nodes then '#address-cells' and '#size-cells' 
> > > > properties are
> > > > +  required.
> > > > +
> > > > +properties:
> > > > +  "#address-cells":
> > > > +const: 1
> > > > +
> > > > +  "#size-cells":
> > > > +const: 0
> > > > +
> > > > +patternProperties:
> > > > +  "^endpoint(@[0-9a-f]+)?$":
> > > > +type: object
> > > > +properties:
> > > > +  reg:
> > > > +maxItems: 1
> > > > +
> > > > +  remote-endpoint:
> > > > +description: |
> > > > +  phandle to an 'endpoint' subnode of a remote device node.
> > > > +$ref: /schemas/types.yaml#/definitions/phandle
> > > > +
> > > > +

Re: [PATCH v2] dt-bindings: display: panel: one file of all simple LVDS panels with dual ports

2020-11-11 Thread Rob Herring

On Tue, Nov 10, 2020 at 03:36:37PM +0800, Liu Ying wrote:
> To complement panel-simple.yaml, create panel-simple-lvds-dual-ports.yaml.
> panel-simple-lvds-dual-ports.yaml is for all simple LVDS panels that
> has dual LVDS ports and requires only a single power-supply.
> One LVDS port receives even pixels, and the other receives odd pixels.
> Optionally, a backlight and an enable GPIO can be specified as properties.
> 
> Migrate 'auo,g133han01', 'auo,g185han01', 'auo,g190ean01',
> 'koe,tx26d202vm0bwa' and 'nlt,nl192108ac18-02d' over to the new file.

Also, what about advantech,idk-2121wr?

> 
> The objectives with one file for all the simple LVDS panels with dual ports 
> are:
> - Make it simpler to add bindings for this kind of LVDS panels
> - Keep the number of bindings file lower
> - Keep the binding documentation for this kind of LVDS panels more consistent
> - Make it possible for drivers to get pixel order via
>   drm_of_lvds_get_dual_link_pixel_order(), as the optional 'ports' property is
>   allowed
> 
> Suggested-by: Sam Ravnborg 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Rob Herring 
> Cc: Lucas Stach 
> Cc: Sebastian Reichel 
> Signed-off-by: Liu Ying 
> ---
> v1->v2:
> * Correct pixel order in example LVDS panel node.
> 
>  .../panel/panel-simple-lvds-dual-ports.yaml| 85 
> ++
>  .../bindings/display/panel/panel-simple.yaml   | 10 ---
>  2 files changed, 85 insertions(+), 10 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
>  
> b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
> new file mode 100644
> index ..58774ed
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
> @@ -0,0 +1,85 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: 
> http://devicetree.org/schemas/display/panel/panel-simple-lvds-dual-ports.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Simple LVDS panels with one power supply and dual LVDS ports
> +
> +maintainers:
> +  - Liu Ying 
> +  - Thierry Reding 
> +  - Sam Ravnborg 
> +
> +description: |
> +  This binding file is a collection of the LVDS panels that
> +  has dual LVDS ports and requires only a single power-supply.
> +  One LVDS port receives even pixels, and the other receives odd pixels.
> +  There are optionally a backlight and an enable GPIO.
> +  The panel may use an OF graph binding for the association to the display,
> +  or it may be a direct child node of the display.
> +
> +  If the panel is more advanced a dedicated binding file is required.
> +
> +allOf:
> +  - $ref: panel-common.yaml#
> +
> +properties:
> +
> +  compatible:
> +enum:
> +# compatible must be listed in alphabetical order, ordered by compatible.
> +# The description in the comment is mandatory for each compatible.
> +
> +# AU Optronics Corporation 13.3" FHD (1920x1080) TFT LCD panel
> +  - auo,g133han01
> +# AU Optronics Corporation 18.5" FHD (1920x1080) TFT LCD panel
> +  - auo,g185han01
> +# AU Optronics Corporation 19.0" (1280x1024) TFT LCD panel
> +  - auo,g190ean01
> +# Kaohsiung Opto-Electronics Inc. 10.1" WUXGA (1920 x 1200) LVDS TFT 
> LCD panel
> +  - koe,tx26d202vm0bwa
> +# NLT Technologies, Ltd. 15.6" FHD (1920x1080) LVDS TFT LCD panel
> +  - nlt,nl192108ac18-02d
> +
> +  backlight: true
> +  enable-gpios: true
> +  port: true
> +  ports: true
> +  power-supply: true
> +
> +additionalProperties: false
> +
> +required:
> +  - compatible
> +  - power-supply
> +
> +examples:
> +  - |
> +panel: panel-lvds {
> +  compatible = "koe,tx26d202vm0bwa";
> +  power-supply = <_lcd_reg>;
> +
> +  ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +  dual-lvds-odd-pixels;
> +  reg = <0>;
> +
> +  panel_lvds0_in: endpoint {
> +remote-endpoint = <_out>;
> +  };
> +};
> +
> +port@1 {
> +  dual-lvds-even-pixels;
> +  reg = <1>;
> +
> +  panel_lvds1_in: endpoint {
> +remote-endpoint = <_out>;
> +  };
> +};
> +  };
> +};
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
> b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> index f9750b0..62618e4 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> @@ -57,14 +57,8 @@ properties:
>- auo,g104sn02
>  # AU Optronics Corporation 12.1" (1280x800) TFT LCD panel
>- auo,g121ean01
> -# AU Optronics Corporation

Re: [PATCH v2] dt-bindings: display: panel: one file of all simple LVDS panels with dual ports

2020-11-11 Thread Rob Herring

On Tue, Nov 10, 2020 at 03:36:37PM +0800, Liu Ying wrote:
> To complement panel-simple.yaml, create panel-simple-lvds-dual-ports.yaml.
> panel-simple-lvds-dual-ports.yaml is for all simple LVDS panels that
> has dual LVDS ports and requires only a single power-supply.
> One LVDS port receives even pixels, and the other receives odd pixels.
> Optionally, a backlight and an enable GPIO can be specified as properties.
> 
> Migrate 'auo,g133han01', 'auo,g185han01', 'auo,g190ean01',
> 'koe,tx26d202vm0bwa' and 'nlt,nl192108ac18-02d' over to the new file.
> 
> The objectives with one file for all the simple LVDS panels with dual ports 
> are:
> - Make it simpler to add bindings for this kind of LVDS panels
> - Keep the number of bindings file lower
> - Keep the binding documentation for this kind of LVDS panels more consistent
> - Make it possible for drivers to get pixel order via
>   drm_of_lvds_get_dual_link_pixel_order(), as the optional 'ports' property is
>   allowed
> 
> Suggested-by: Sam Ravnborg 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Rob Herring 
> Cc: Lucas Stach 
> Cc: Sebastian Reichel 
> Signed-off-by: Liu Ying 
> ---
> v1->v2:
> * Correct pixel order in example LVDS panel node.
> 
>  .../panel/panel-simple-lvds-dual-ports.yaml| 85 
> ++
>  .../bindings/display/panel/panel-simple.yaml   | 10 ---
>  2 files changed, 85 insertions(+), 10 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
>  
> b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
> new file mode 100644
> index ..58774ed
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
> @@ -0,0 +1,85 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: 
> http://devicetree.org/schemas/display/panel/panel-simple-lvds-dual-ports.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Simple LVDS panels with one power supply and dual LVDS ports
> +
> +maintainers:
> +  - Liu Ying 
> +  - Thierry Reding 
> +  - Sam Ravnborg 
> +
> +description: |
> +  This binding file is a collection of the LVDS panels that
> +  has dual LVDS ports and requires only a single power-supply.
> +  One LVDS port receives even pixels, and the other receives odd pixels.

You have to define which port number is which in the schema.

> +  There are optionally a backlight and an enable GPIO.
> +  The panel may use an OF graph binding for the association to the display,
> +  or it may be a direct child node of the display.
> +
> +  If the panel is more advanced a dedicated binding file is required.
> +
> +allOf:
> +  - $ref: panel-common.yaml#
> +
> +properties:
> +
> +  compatible:
> +enum:
> +# compatible must be listed in alphabetical order, ordered by compatible.
> +# The description in the comment is mandatory for each compatible.
> +
> +# AU Optronics Corporation 13.3" FHD (1920x1080) TFT LCD panel
> +  - auo,g133han01
> +# AU Optronics Corporation 18.5" FHD (1920x1080) TFT LCD panel
> +  - auo,g185han01
> +# AU Optronics Corporation 19.0" (1280x1024) TFT LCD panel
> +  - auo,g190ean01
> +# Kaohsiung Opto-Electronics Inc. 10.1" WUXGA (1920 x 1200) LVDS TFT 
> LCD panel
> +  - koe,tx26d202vm0bwa
> +# NLT Technologies, Ltd. 15.6" FHD (1920x1080) LVDS TFT LCD panel
> +  - nlt,nl192108ac18-02d
> +
> +  backlight: true
> +  enable-gpios: true
> +  port: true

A single port shouldn't be valid.

> +  ports: true
> +  power-supply: true
> +
> +additionalProperties: false
> +
> +required:
> +  - compatible
> +  - power-supply
> +
> +examples:
> +  - |
> +panel: panel-lvds {
> +  compatible = "koe,tx26d202vm0bwa";
> +  power-supply = <_lcd_reg>;
> +
> +  ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +  dual-lvds-odd-pixels;

This needs to be documented. Though really, this property seems 
pointless if the port numbering is fixed (though 0 for even and 1 for 
odd would be a bit more logical).

> +  reg = <0>;
> +
> +  panel_lvds0_in: endpoint {
> +remote-endpoint = <_out>;
> +  };
> +};
> +
> +port@1 {
> +  dual-lvds-even-pixels;
> +  reg = <1>;
> +
> +  panel_lvds1_in: endpoint {
> +remote-endpoint = <_out>;
> +  };
> +};
> +  };
> +};
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
> b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> index f9750b0..62618e4 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> +++

Re: [PATCH][next] drm/kmb: fix spelling mistakes in drm_info and drm_dbg messages

2020-11-11 Thread Sam Ravnborg

Hi Colin,

On Mon, Nov 09, 2020 at 11:12:25AM +, Colin King wrote:
> From: Colin Ian King 
> 
> There are two spelling mistakes of the word sync in drm_info
> and drm_dbg messages. Fix these.
> 
> Signed-off-by: Colin Ian King 

Thanks, applied to drm-misc-next.

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

Re: [PATCH v2] dt-bindings: display: mcde: Convert to YAML schema

2020-11-11 Thread Sam Ravnborg

Hi Linus.

A few comments when I read through this.

Sam

On Wed, Nov 11, 2020 at 02:07:54PM +0100, Linus Walleij wrote:
> This moves the MCDE bindings over to using the YAML schema
> to describe the ST-Ericsson MCDE display controller,
> making use of the generic DSI controller schema.
> 
> We also add the "port" node, we will use this when adding
> LCD panels using the direct parallel interface DPI instead
> of DSI.
> 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Linus Walleij 
> ---
> ChangeLog v1->v2:
> - Cut the description on the interrupts.
> - Drop maxItems: 3 on clocks and clock-names: implicit from
>   the number of listed items.
> - Tag the DSI ports with unevaluatedProperties: false
> - Tag the MCDE as such with additionalProperties: true
> - It was a bit hard to test this because of the code base
>   being out of phase with the validation tools but it seems
>   to check out.
> ---
>  .../devicetree/bindings/display/ste,mcde.txt  | 104 ---
>  .../devicetree/bindings/display/ste,mcde.yaml | 166 ++
>  2 files changed, 166 insertions(+), 104 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/display/ste,mcde.txt
>  create mode 100644 Documentation/devicetree/bindings/display/ste,mcde.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/ste,mcde.txt 
> b/Documentation/devicetree/bindings/display/ste,mcde.txt
> deleted file mode 100644
> index 4c33c692bd5f..
> --- a/Documentation/devicetree/bindings/display/ste,mcde.txt
> +++ /dev/null
> @@ -1,104 +0,0 @@
> -ST-Ericsson Multi Channel Display Engine MCDE
> -
> -The ST-Ericsson MCDE is a display controller with support for compositing
> -and displaying several channels memory resident graphics data on DSI or
> -LCD displays or bridges. It is used in the ST-Ericsson U8500 platform.
> -
> -Required properties:
> -
> -- compatible: must be:
> -  "ste,mcde"
> -- reg: register base for the main MCDE control registers, should be
> -  0x1000 in size
> -- interrupts: the interrupt line for the MCDE
> -- epod-supply: a phandle to the EPOD regulator
> -- vana-supply: a phandle to the analog voltage regulator
> -- clocks: an array of the MCDE clocks in this strict order:
> -  MCDECLK (main MCDE clock), LCDCLK (LCD clock), PLLDSI
> -  (HDMI clock), DSI0ESCLK (DSI0 energy save clock),

> -  DSI1ESCLK (DSI1 energy save clock), DSI2ESCLK (DSI2 energy
> -  save clock)
I did not find these two clocks in the binding below.

> -- clock-names: must be the following array:
> -  "mcde", "lcd", "hdmi"
> -  to match the required clock inputs above.
> -- #address-cells: should be <1> (for the DSI hosts that will be children)
> -- #size-cells: should be <1> (for the DSI hosts that will be children)
> -- ranges: this should always be stated
> -
> -Required subnodes:
> -
> -The devicetree must specify subnodes for the DSI host adapters.
> -These must have the following characteristics:
> -
> -- compatible: must be:
> -  "ste,mcde-dsi"
> -- reg: must specify the register range for the DSI host
> -- vana-supply: phandle to the VANA voltage regulator
> -- clocks: phandles to the high speed and low power (energy save) clocks
> -  the high speed clock is not present on the third (dsi2) block, so it
> -  should only have the "lp" clock
> -- clock-names: "hs" for the high speed clock and "lp" for the low power
> -  (energy save) clock
> -- #address-cells: should be <1>
> -- #size-cells: should be <0>
> -
> -Display panels and bridges will appear as children on the DSI hosts, and
> -the displays are connected to the DSI hosts using the common binding
> -for video transmitter interfaces; see
> -Documentation/devicetree/bindings/media/video-interfaces.txt
> -
> -If a DSI host is unused (not connected) it will have no children defined.
> -
> -Example:
> -
> -mcde@a035 {
> - compatible = "ste,mcde";
> - reg = <0xa035 0x1000>;
> - interrupts = ;
> - epod-supply = <_b2r2_mcde_reg>;
> - vana-supply = <_ldo_ana_reg>;
> - clocks = <_clk PRCMU_MCDECLK>, /* Main MCDE clock */
> -  <_clk PRCMU_LCDCLK>, /* LCD clock */
> -  <_clk PRCMU_PLLDSI>; /* HDMI clock */
> - clock-names = "mcde", "lcd", "hdmi";
> - #address-cells = <1>;
> - #size-cells = <1>;
> - ranges;
> -
> - dsi0: dsi@a0351000 {
> - compatible = "ste,mcde-dsi";
> - reg = <0xa0351000 0x1000>;
> - vana-supply = <_ldo_ana_reg>;
> - clocks = <_clk PRCMU_DSI0CLK>, <_clk 
> PRCMU_DSI0ESCCLK>;
> - clock-names = "hs", "lp";
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - panel {
> - compatible = "samsung,s6d16d0";
> - reg = <0>;
> - vdd1-supply = <_ldo_aux1_reg>;
> - reset-gpios = < 1 GPIO_ACTIVE_LOW>;
> - };
> -
> - };
> - dsi1: dsi@a0352000 {
> - compatible = "ste,mcde-dsi";
> -

Re: [PATCH] drm/kmb: Fix build warnings

2020-11-11 Thread Sam Ravnborg

Hi Anitha,

On Tue, Nov 10, 2020 at 01:52:49PM -0800, Anitha Chrisanthus wrote:
> Fixed the following W=1 kernel build warnings
>  drivers/gpu/drm/kmb/kmb_plane.h:74:18: warning: ‘kmb_formats_v’
>  defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/kmb/kmb_plane.h:61:18: warning: ‘kmb_formats_g’
>  defined but not used [-Wunused-const-variable=]
> 
> Signed-off-by: Anitha Chrisanthus 
> Cc: Sam Ravnborg 

Thanks, applied to drm-misc-next.

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

Re: [PATCH v3 33/56] drm/omap: dsi: convert to drm_panel

2020-11-11 Thread Tomi Valkeinen

On 09/11/2020 12:39, Laurent Pinchart wrote:
> On Thu, Nov 05, 2020 at 02:03:10PM +0200, Tomi Valkeinen wrote:
>> From: Sebastian Reichel 
>>
>> This converts the DSI module to expect common drm_panel display
>> drivers instead of dssdev based ones.
>>
>> Signed-off-by: Sebastian Reichel 
>> Signed-off-by: Tomi Valkeinen 
>> ---
>>  .../gpu/drm/omapdrm/displays/panel-dsi-cm.c   | 204 +++---
>>  drivers/gpu/drm/omapdrm/dss/dsi.c | 133 ++--
>>  .../gpu/drm/omapdrm/dss/omapdss-boot-init.c   |   1 -
>>  drivers/gpu/drm/omapdrm/dss/omapdss.h |   8 -
>>  4 files changed, 189 insertions(+), 157 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c 
>> b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
>> index d9b3444b4faf..3668b3f0aff2 100644
>> --- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
>> +++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
>> @@ -6,8 +6,6 @@
>>   * Author: Tomi Valkeinen 
>>   */
>>  
>> -/* #define DEBUG */
>> -
>>  #include 
>>  #include 
>>  #include 
>> @@ -20,11 +18,14 @@
>>  #include 
>>  
>>  #include 
>> +#include 
>> +#include 
>> +#include 
> 
> Alphabetically ordered please.
> 
>>  
>> +#include 
>>  #include 
>>  #include 
>> -
>> -#include "../dss/omapdss.h"
>> +#include 
>>  
>>  #define DCS_READ_NUM_ERRORS 0x05
>>  #define DCS_GET_ID1 0xda
>> @@ -35,11 +36,8 @@
>>  
>>  struct panel_drv_data {
>>  struct mipi_dsi_device *dsi;
>> -
>> -struct omap_dss_device dssdev;
>> -struct omap_dss_device *src;
>> -
>> -struct videomode vm;
>> +struct drm_panel panel;
>> +struct drm_display_mode mode;
>>  
>>  struct mutex lock;
>>  
>> @@ -71,7 +69,11 @@ struct panel_drv_data {
>>  bool ulps_enabled;
>>  };
>>  
>> -#define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
>> +
> 
> A single blank line is enough.
> 
>> +static inline struct panel_drv_data *panel_to_ddata(struct drm_panel *panel)
>> +{
>> +return container_of(panel, struct panel_drv_data, panel);
>> +}
>>  
>>  static int _dsicm_enable_te(struct panel_drv_data *ddata, bool enable);
>>  
>> @@ -285,7 +287,6 @@ static void dsicm_hw_reset(struct panel_drv_data *ddata)
>>  
>>  static int dsicm_power_on(struct panel_drv_data *ddata)
>>  {
>> -struct omap_dss_device *src = ddata->src;
>>  u8 id1, id2, id3;
>>  int r;
>>  
>> @@ -322,10 +323,6 @@ static int dsicm_power_on(struct panel_drv_data *ddata)
>>  if (r)
>>  goto err;
>>  
>> -r = src->ops->dsi.enable_video_output(src, ddata->dsi->channel);
>> -if (r)
>> -goto err;
>> -
>>  ddata->enabled = true;
>>  
>>  if (!ddata->intro_printed) {
>> @@ -345,15 +342,12 @@ static int dsicm_power_on(struct panel_drv_data *ddata)
>>  return r;
>>  }
>>  
>> -static void dsicm_power_off(struct panel_drv_data *ddata)
>> +static int dsicm_power_off(struct panel_drv_data *ddata)
>>  {
>> -struct omap_dss_device *src = ddata->src;
>>  int r;
>>  
>>  ddata->enabled = false;
>>  
>> -src->ops->dsi.disable_video_output(src, ddata->dsi->channel);
>> -
>>  r = mipi_dsi_dcs_set_display_off(ddata->dsi);
>>  if (!r)
>>  r = dsicm_sleep_in(ddata);
>> @@ -363,51 +357,25 @@ static void dsicm_power_off(struct panel_drv_data 
>> *ddata)
>>  "error disabling panel, issuing HW reset\n");
>>  dsicm_hw_reset(ddata);
>>  }
>> -}
>> -
>> -static int dsicm_connect(struct omap_dss_device *src,
>> - struct omap_dss_device *dst)
>> -{
>> -struct panel_drv_data *ddata = to_panel_data(dst);
>> -
>> -ddata->src = src;
>> -return 0;
>> -}
>> -
>> -static void dsicm_disconnect(struct omap_dss_device *src,
>> - struct omap_dss_device *dst)
>> -{
>> -struct panel_drv_data *ddata = to_panel_data(dst);
>>  
>> -ddata->src = NULL;
>> +return r;
>>  }
>>  
>> -static void dsicm_pre_enable(struct omap_dss_device *dssdev)
>> +static int dsicm_prepare(struct drm_panel *panel)
>>  {
>> -struct panel_drv_data *ddata = to_panel_data(dssdev);
>> -struct omap_dss_device *src = ddata->src;
>> +struct panel_drv_data *ddata = panel_to_ddata(panel);
>>  int r;
>> -struct omap_dss_dsi_config dsi_config = {
>> -.vm = >vm,
>> -.hs_clk_min = 15000,
>> -.hs_clk_max = 3,
>> -.lp_clk_min = 700,
>> -.lp_clk_max = 1000,
>> -};
>>  
>>  r = regulator_bulk_enable(DCS_REGULATOR_SUPPLY_NUM, ddata->supplies);
>>  if (r)
>>  dev_err(>dsi->dev, "failed to enable supplies: %d\n", r);
>>  
>> -r = src->ops->dsi.set_config(src, _config);
>> -if (r) {
>> -dev_err(>dsi->dev, "failed to configure DSI\n");
>> -}
>> +return r;
>>  }
>>  
>> -static void dsicm_enable(struct omap_dss_device *dssdev)
>> +static int dsicm_enable(struct drm_panel *panel)
>>  {
>> -struct

Re: [PATCH v3 30/56] drm/omap: dsi: move panel refresh function to host

2020-11-11 Thread Tomi Valkeinen

On 09/11/2020 12:10, Laurent Pinchart wrote:
> Hi Tomi and Sebastian,
> 
> Thank you for the patch.
> 
> On Thu, Nov 05, 2020 at 02:03:07PM +0200, Tomi Valkeinen wrote:
>> From: Sebastian Reichel 
>>
>> This moves the panel refresh/update function from the panel
>> driver into the DSI host driver to prepare for common drm_panel
>> support.
>>
>> Signed-off-by: Sebastian Reichel 
>> Signed-off-by: Tomi Valkeinen 
>> ---
>>  .../gpu/drm/omapdrm/displays/panel-dsi-cm.c   |  68 
>>  drivers/gpu/drm/omapdrm/dss/dsi.c | 101 --
>>  drivers/gpu/drm/omapdrm/dss/omapdss.h |  13 +--
>>  drivers/gpu/drm/omapdrm/omap_crtc.c   |  11 +-
>>  4 files changed, 97 insertions(+), 96 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c 
>> b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
>> index 030a8fa140db..1582960f9e90 100644
>> --- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
>> +++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
>> @@ -177,27 +177,6 @@ static int dsicm_get_id(struct panel_drv_data *ddata, 
>> u8 *id1, u8 *id2, u8 *id3)
>>  return 0;
>>  }
>>  
>> -static int dsicm_set_update_window(struct panel_drv_data *ddata,
>> -u16 x, u16 y, u16 w, u16 h)
>> -{
>> -struct mipi_dsi_device *dsi = ddata->dsi;
>> -int r;
>> -u16 x1 = x;
>> -u16 x2 = x + w - 1;
>> -u16 y1 = y;
>> -u16 y2 = y + h - 1;
>> -
>> -r = mipi_dsi_dcs_set_column_address(dsi, x1, x2);
>> -if (r < 0)
>> -return r;
>> -
>> -r = mipi_dsi_dcs_set_page_address(dsi, y1, y2);
>> -if (r < 0)
>> -return r;
>> -
>> -return 0;
>> -}
>> -
> 
> I can't tell whether this is common to all command-mode panels, or if
> there could be a need for panel-specific update procedures, so I can't
> really ack this patch.

I can't say either, but all the command mode panels I know need and support 
this. And, afaik, we
have only the single cmd mode panel driver which we add in this series.

>>  static int dsicm_bl_update_status(struct backlight_device *dev)
>>  {
>>  struct panel_drv_data *ddata = dev_get_drvdata(>dev);
>> @@ -470,48 +449,6 @@ static void dsicm_disable(struct omap_dss_device 
>> *dssdev)
>>  mutex_unlock(>lock);
>>  }
>>  
>> -static void dsicm_framedone_cb(int err, void *data)
>> -{
>> -struct panel_drv_data *ddata = data;
>> -
>> -dev_dbg(>dsi->dev, "framedone, err %d\n", err);
>> -mutex_unlock(>lock);
>> -}
>> -
>> -static int dsicm_update(struct omap_dss_device *dssdev,
>> -u16 x, u16 y, u16 w, u16 h)
>> -{
>> -struct panel_drv_data *ddata = to_panel_data(dssdev);
>> -struct omap_dss_device *src = ddata->src;
>> -int r;
>> -
>> -dev_dbg(>dsi->dev, "update %d, %d, %d x %d\n", x, y, w, h);
>> -
>> -mutex_lock(>lock);
>> -
>> -if (!ddata->enabled) {
>> -r = 0;
>> -goto err;
>> -}
>> -
>> -/* XXX no need to send this every frame, but dsi break if not done */
>> -r = dsicm_set_update_window(ddata, 0, 0, ddata->vm.hactive,
>> -ddata->vm.vactive);
>> -if (r)
>> -goto err;
>> -
>> -r = src->ops->dsi.update(src, ddata->dsi->channel, dsicm_framedone_cb,
>> -ddata);
>> -if (r)
>> -goto err;
>> -
>> -/* note: no unlock here. unlock is src framedone_cb */
>> -return 0;
>> -err:
>> -mutex_unlock(>lock);
>> -return r;
>> -}
>> -
>>  static int _dsicm_enable_te(struct panel_drv_data *ddata, bool enable)
>>  {
>>  struct mipi_dsi_device *dsi = ddata->dsi;
>> @@ -572,10 +509,6 @@ static const struct omap_dss_device_ops dsicm_ops = {
>>  .check_timings  = dsicm_check_timings,
>>  };
>>  
>> -static const struct omap_dss_driver dsicm_dss_driver = {
>> -.update = dsicm_update,
>> -};
>> -
>>  static int dsicm_probe_of(struct mipi_dsi_device *dsi)
>>  {
>>  struct device_node *node = dsi->dev.of_node;
>> @@ -658,7 +591,6 @@ static int dsicm_probe(struct mipi_dsi_device *dsi)
>>  dssdev = >dssdev;
>>  dssdev->dev = dev;
>>  dssdev->ops = _ops;
>> -dssdev->driver = _dss_driver;
>>  dssdev->type = OMAP_DISPLAY_TYPE_DSI;
>>  dssdev->display = true;
>>  dssdev->owner = THIS_MODULE;
>> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
>> b/drivers/gpu/drm/omapdrm/dss/dsi.c
>> index 0f264654792d..0aa0d21cf896 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
>> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
>> @@ -214,6 +214,9 @@ static void dsi_display_uninit_dispc(struct dsi_data 
>> *dsi);
>>  
>>  static int dsi_vc_send_null(struct dsi_data *dsi, int channel);
>>  
>> +static ssize_t _omap_dsi_host_transfer(struct dsi_data *dsi,
>> +   const struct mipi_dsi_msg *msg);
>> +
>>  /* DSI PLL HSDIV indices */
>>  #define HSDIV_DISPC 0
>>  #define HSDIV_DSI   1
>> @@ -383,9 +386,6 @@ struct dsi_data {
>>  
>>  struct

Re: [PATCH v3 29/56] drm/omap: dsi: do ULPS in host driver

2020-11-11 Thread Tomi Valkeinen

On 09/11/2020 12:03, Laurent Pinchart wrote:
> Hi Tomi and Sebastian,
> 
> Thank you for the patch.
> 
> On Thu, Nov 05, 2020 at 02:03:06PM +0200, Tomi Valkeinen wrote:
>> From: Sebastian Reichel 
>>
>> Move ULPS handling into the DSI host controller, so that we
>> no longer need a custom API for the DSI client.
>>
>> Signed-off-by: Sebastian Reichel 
>> Signed-off-by: Tomi Valkeinen 
>> ---
>>  .../gpu/drm/omapdrm/displays/panel-dsi-cm.c   | 273 +-
>>  drivers/gpu/drm/omapdrm/dss/dsi.c |  63 +++-
>>  drivers/gpu/drm/omapdrm/dss/omapdss.h |   2 -
>>  3 files changed, 62 insertions(+), 276 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c 
>> b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
>> index 78247dcb1848..030a8fa140db 100644
>> --- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
>> +++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
>> @@ -16,7 +16,6 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>>  #include 
>>  #include 
>>  
>> @@ -69,21 +68,13 @@ struct panel_drv_data {
>>  
>>  bool intro_printed;
>>  
>> -struct workqueue_struct *workqueue;
>> -
>>  bool ulps_enabled;
>> -unsigned int ulps_timeout;
>> -struct delayed_work ulps_work;
>>  };
>>  
>>  #define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
>>  
>>  static int _dsicm_enable_te(struct panel_drv_data *ddata, bool enable);
>>  
>> -static int dsicm_panel_reset(struct panel_drv_data *ddata);
>> -
>> -static void dsicm_ulps_work(struct work_struct *work);
>> -
>>  static void dsicm_bl_power(struct panel_drv_data *ddata, bool enable)
>>  {
>>  struct backlight_device *backlight;
>> @@ -207,94 +198,6 @@ static int dsicm_set_update_window(struct 
>> panel_drv_data *ddata,
>>  return 0;
>>  }
>>  
>> -static void dsicm_queue_ulps_work(struct panel_drv_data *ddata)
>> -{
>> -if (ddata->ulps_timeout > 0)
>> -queue_delayed_work(ddata->workqueue, >ulps_work,
>> -msecs_to_jiffies(ddata->ulps_timeout));
>> -}
>> -
>> -static void dsicm_cancel_ulps_work(struct panel_drv_data *ddata)
>> -{
>> -cancel_delayed_work(>ulps_work);
>> -}
>> -
>> -static int dsicm_enter_ulps(struct panel_drv_data *ddata)
>> -{
>> -struct omap_dss_device *src = ddata->src;
>> -int r;
>> -
>> -if (ddata->ulps_enabled)
>> -return 0;
>> -
>> -dsicm_cancel_ulps_work(ddata);
>> -
>> -r = _dsicm_enable_te(ddata, false);
>> -if (r)
>> -goto err;
>> -
>> -src->ops->dsi.ulps(src, true);
>> -
>> -ddata->ulps_enabled = true;
>> -
>> -return 0;
>> -
>> -err:
>> -dev_err(>dsi->dev, "enter ULPS failed");
>> -dsicm_panel_reset(ddata);
>> -
>> -ddata->ulps_enabled = false;
>> -
>> -dsicm_queue_ulps_work(ddata);
>> -
>> -return r;
>> -}
>> -
>> -static int dsicm_exit_ulps(struct panel_drv_data *ddata)
>> -{
>> -struct omap_dss_device *src = ddata->src;
>> -int r;
>> -
>> -if (!ddata->ulps_enabled)
>> -return 0;
>> -
>> -src->ops->dsi.ulps(src, false);
>> -ddata->dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
>> -
>> -r = _dsicm_enable_te(ddata, ddata->te_enabled);
>> -if (r) {
>> -dev_err(>dsi->dev, "failed to re-enable TE");
>> -goto err2;
>> -}
>> -
>> -dsicm_queue_ulps_work(ddata);
>> -
>> -ddata->ulps_enabled = false;
>> -
>> -return 0;
>> -
>> -err2:
>> -dev_err(>dsi->dev, "failed to exit ULPS");
>> -
>> -r = dsicm_panel_reset(ddata);
>> -if (!r)
>> -ddata->ulps_enabled = false;
>> -
>> -dsicm_queue_ulps_work(ddata);
>> -
>> -return r;
>> -}
>> -
>> -static int dsicm_wake_up(struct panel_drv_data *ddata)
>> -{
>> -if (ddata->ulps_enabled)
>> -return dsicm_exit_ulps(ddata);
>> -
>> -dsicm_cancel_ulps_work(ddata);
>> -dsicm_queue_ulps_work(ddata);
>> -return 0;
>> -}
>> -
>>  static int dsicm_bl_update_status(struct backlight_device *dev)
>>  {
>>  struct panel_drv_data *ddata = dev_get_drvdata(>dev);
>> @@ -312,11 +215,8 @@ static int dsicm_bl_update_status(struct 
>> backlight_device *dev)
>>  mutex_lock(>lock);
>>  
>>  if (ddata->enabled) {
>> -r = dsicm_wake_up(ddata);
>> -if (!r) {
>> -r = dsicm_dcs_write_1(ddata,
>> -MIPI_DCS_SET_DISPLAY_BRIGHTNESS, level);
>> -}
>> +r = dsicm_dcs_write_1(ddata, MIPI_DCS_SET_DISPLAY_BRIGHTNESS,
>> +  level);
>>  }
>>  
>>  mutex_unlock(>lock);
>> @@ -343,18 +243,12 @@ static ssize_t dsicm_num_errors_show(struct device 
>> *dev,
>>  {
>>  struct panel_drv_data *ddata = dev_get_drvdata(dev);
>>  u8 errors = 0;
>> -int r;
>> +int r = -ENODEV;
>>  
>>  mutex_lock(>lock);
>>  
>> -if (ddata->enabled) {
>> -r = dsicm_wake_up(ddata);
>> -if (!r)
>> -r =

[PATCH 18/19] drm/radeon/cik: Move 'vce_v2_0_enable_mgcg()'s prototype to shared header

2020-11-11 Thread Lee Jones

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/radeon/vce_v2_0.c:111:6: warning: no previous prototype for 
‘vce_v2_0_enable_mgcg’ [-Wmissing-prototypes]
 111 | void vce_v2_0_enable_mgcg(struct radeon_device *rdev, bool enable)
 | ^~~~

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/radeon/cik.c  | 2 +-
 drivers/gpu/drm/radeon/vce.h  | 1 +
 drivers/gpu/drm/radeon/vce_v2_0.c | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 4520ec4c7b2e2..ae2a507d13bb7 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -41,6 +41,7 @@
 #include "radeon_audio.h"
 #include "radeon_ucode.h"
 #include "si.h"
+#include "vce.h"
 
 #define SH_MEM_CONFIG_GFX_DEFAULT \
ALIGNMENT_MODE(SH_MEM_ALIGNMENT_MODE_UNALIGNED)
@@ -129,7 +130,6 @@ MODULE_FIRMWARE("radeon/mullins_rlc.bin");
 MODULE_FIRMWARE("radeon/mullins_sdma.bin");
 
 static u32 cik_get_cu_active_bitmap(struct radeon_device *rdev, u32 se, u32 
sh);
-extern void vce_v2_0_enable_mgcg(struct radeon_device *rdev, bool enable);
 static void cik_rlc_stop(struct radeon_device *rdev);
 static void cik_pcie_gen3_enable(struct radeon_device *rdev);
 static void cik_program_aspm(struct radeon_device *rdev);
diff --git a/drivers/gpu/drm/radeon/vce.h b/drivers/gpu/drm/radeon/vce.h
index 1eb4f5715202e..ccc9c00f0d02c 100644
--- a/drivers/gpu/drm/radeon/vce.h
+++ b/drivers/gpu/drm/radeon/vce.h
@@ -30,5 +30,6 @@
 struct radeon_device;
 
 void vce_v1_0_enable_mgcg(struct radeon_device *rdev, bool enable);
+void vce_v2_0_enable_mgcg(struct radeon_device *rdev, bool enable);
 
 #endif /* __VCE_H__ */
diff --git a/drivers/gpu/drm/radeon/vce_v2_0.c 
b/drivers/gpu/drm/radeon/vce_v2_0.c
index d6fde3659e65f..163c9bfc03da8 100644
--- a/drivers/gpu/drm/radeon/vce_v2_0.c
+++ b/drivers/gpu/drm/radeon/vce_v2_0.c
@@ -30,6 +30,7 @@
 #include "radeon.h"
 #include "radeon_asic.h"
 #include "cikd.h"
+#include "vce.h"
 
 #define VCE_V2_0_FW_SIZE   (256 * 1024)
 #define VCE_V2_0_STACK_SIZE(64 * 1024)
-- 
2.25.1

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

[PATCH 17/19] drm/radeon/si_dpm: Move 'vce_v1_0_enable_mgcg()'s prototype to shared header

2020-11-11 Thread Lee Jones

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/radeon/vce_v1_0.c:102:6: warning: no previous prototype for 
‘vce_v1_0_enable_mgcg’ [-Wmissing-prototypes]
 102 | void vce_v1_0_enable_mgcg(struct radeon_device *rdev, bool enable)
 | ^~~~

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/radeon/si_dpm.c  |  3 +--
 drivers/gpu/drm/radeon/trinity_dpm.c |  2 +-
 drivers/gpu/drm/radeon/vce.h | 34 
 drivers/gpu/drm/radeon/vce_v1_0.c|  1 +
 4 files changed, 37 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/vce.h

diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index b4581392fbce9..cd07b06301b44 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -35,6 +35,7 @@
 #include "si_dpm.h"
 #include "si.h"
 #include "sid.h"
+#include "vce.h"
 
 #define MC_CG_ARB_FREQ_F0   0x0a
 #define MC_CG_ARB_FREQ_F1   0x0b
@@ -1721,8 +1722,6 @@ static const struct si_powertune_data 
powertune_data_hainan =
true
 };
 
-extern void vce_v1_0_enable_mgcg(struct radeon_device *rdev, bool enable);
-
 static int si_populate_voltage_value(struct radeon_device *rdev,
 const struct atom_voltage_table *table,
 u16 value, SISLANDS_SMC_VOLTAGE_VALUE 
*voltage);
diff --git a/drivers/gpu/drm/radeon/trinity_dpm.c 
b/drivers/gpu/drm/radeon/trinity_dpm.c
index e005c18aac00e..08ea1c864cb23 100644
--- a/drivers/gpu/drm/radeon/trinity_dpm.c
+++ b/drivers/gpu/drm/radeon/trinity_dpm.c
@@ -29,6 +29,7 @@
 #include "radeon_asic.h"
 #include "trinity_dpm.h"
 #include "trinityd.h"
+#include "vce.h"
 
 #define TRINITY_MAX_DEEPSLEEP_DIVIDER_ID 5
 #define TRINITY_MINIMUM_ENGINE_CLOCK 800
@@ -293,7 +294,6 @@ static const u32 trinity_override_mgpg_sequences[] =
0x0204, 0x,
 };
 
-extern void vce_v1_0_enable_mgcg(struct radeon_device *rdev, bool enable);
 static void trinity_program_clk_gating_hw_sequence(struct radeon_device *rdev,
   const u32 *seq, u32 count);
 static void trinity_override_dynamic_mg_powergating(struct radeon_device 
*rdev);
diff --git a/drivers/gpu/drm/radeon/vce.h b/drivers/gpu/drm/radeon/vce.h
new file mode 100644
index 0..1eb4f5715202e
--- /dev/null
+++ b/drivers/gpu/drm/radeon/vce.h
@@ -0,0 +1,34 @@
+/* vce.h -- Private header for radeon driver -*- linux-c -*-
+ *
+ * Copyright 2013 Advanced Micro Devices, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ */
+
+#ifndef __VCE_H__
+#define __VCE_H__
+
+struct radeon_device;
+
+void vce_v1_0_enable_mgcg(struct radeon_device *rdev, bool enable);
+
+#endif /* __VCE_H__ */
diff --git a/drivers/gpu/drm/radeon/vce_v1_0.c 
b/drivers/gpu/drm/radeon/vce_v1_0.c
index bd75bbcf5bf63..70c5da2141d75 100644
--- a/drivers/gpu/drm/radeon/vce_v1_0.c
+++ b/drivers/gpu/drm/radeon/vce_v1_0.c
@@ -30,6 +30,7 @@
 #include "radeon.h"
 #include "radeon_asic.h"
 #include "sid.h"
+#include "vce.h"
 
 #define VCE_V1_0_FW_SIZE   (256 * 1024)
 #define VCE_V1_0_STACK_SIZE(64 * 1024)
-- 
2.25.1

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

[PATCH 12/19] drm/radeon/evergreen: Move 'si_get_csb_*()'s prototypes to shared header

2020-11-11 Thread Lee Jones

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/radeon/si.c:5678:5: warning: no previous prototype for 
‘si_get_csb_size’ [-Wmissing-prototypes]
 5678 | u32 si_get_csb_size(struct radeon_device *rdev)
 | ^~~
 drivers/gpu/drm/radeon/si.c:5710:6: warning: no previous prototype for 
‘si_get_csb_buffer’ [-Wmissing-prototypes]
 5710 | void si_get_csb_buffer(struct radeon_device *rdev, volatile u32 *buffer)
 | ^

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/radeon/evergreen.c | 3 +--
 drivers/gpu/drm/radeon/si.h| 2 ++
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 28830f4ef95e3..d8ee80ad4ea44 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -41,6 +41,7 @@
 #include "radeon_asic.h"
 #include "radeon_audio.h"
 #include "radeon_ucode.h"
+#include "si.h"
 
 #define DC_HPDx_CONTROL(x)(DC_HPD1_CONTROL + (x * 0xc))
 #define DC_HPDx_INT_CONTROL(x)(DC_HPD1_INT_CONTROL + (x * 0xc))
@@ -218,8 +219,6 @@ void evergreen_pcie_gen2_enable(struct radeon_device *rdev);
 void evergreen_program_aspm(struct radeon_device *rdev);
 void cik_init_cp_pg_table(struct radeon_device *rdev);
 
-extern u32 si_get_csb_size(struct radeon_device *rdev);
-extern void si_get_csb_buffer(struct radeon_device *rdev, volatile u32 
*buffer);
 extern u32 cik_get_csb_size(struct radeon_device *rdev);
 extern void cik_get_csb_buffer(struct radeon_device *rdev, volatile u32 
*buffer);
 
diff --git a/drivers/gpu/drm/radeon/si.h b/drivers/gpu/drm/radeon/si.h
index f483a64d17050..310c58376f927 100644
--- a/drivers/gpu/drm/radeon/si.h
+++ b/drivers/gpu/drm/radeon/si.h
@@ -32,5 +32,7 @@ u32 si_gpu_check_soft_reset(struct radeon_device *rdev);
 void si_vram_gtt_location(struct radeon_device *rdev, struct radeon_mc *mc);
 void si_rlc_reset(struct radeon_device *rdev);
 void si_init_uvd_internal_cg(struct radeon_device *rdev);
+u32 si_get_csb_size(struct radeon_device *rdev);
+void si_get_csb_buffer(struct radeon_device *rdev, volatile u32 *buffer);
 
 #endif /* __SI_H__ */
-- 
2.25.1

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

[PATCH 19/19] drm/radeon/evergreen_cs: Move 'r600_dma_cs_next_reloc()'s prototype to shared header

2020-11-11 Thread Lee Jones

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/radeon/r600_cs.c:2343:5: warning: no previous prototype for 
‘r600_dma_cs_next_reloc’ [-Wmissing-prototypes]
 2343 | int r600_dma_cs_next_reloc(struct radeon_cs_parser *p,
 | ^~

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/radeon/evergreen_cs.c | 3 +--
 drivers/gpu/drm/radeon/r600.h | 4 
 drivers/gpu/drm/radeon/r600_cs.c  | 1 +
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 53b75cf201958..0de79f3a7e3ff 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -28,6 +28,7 @@
 
 #include "radeon.h"
 #include "radeon_asic.h"
+#include "r600.h"
 #include "evergreend.h"
 #include "evergreen_reg_safe.h"
 #include "cayman_reg_safe.h"
@@ -37,8 +38,6 @@
 
 #define REG_SAFE_BM_SIZE ARRAY_SIZE(evergreen_reg_safe_bm)
 
-int r600_dma_cs_next_reloc(struct radeon_cs_parser *p,
-  struct radeon_bo_list **cs_reloc);
 struct evergreen_cs_track {
u32 group_size;
u32 nbanks;
diff --git a/drivers/gpu/drm/radeon/r600.h b/drivers/gpu/drm/radeon/r600.h
index a259976a95913..21fe44198a966 100644
--- a/drivers/gpu/drm/radeon/r600.h
+++ b/drivers/gpu/drm/radeon/r600.h
@@ -29,7 +29,9 @@
 #define __R600_H__
 
 struct r600_audio_pin;
+struct radeon_bo_list;
 struct radeon_crtc;
+struct radeon_cs_parser;
 struct radeon_device;
 struct radeon_hdmi_acr;
 
@@ -50,4 +52,6 @@ void r600_hdmi_update_acr(struct drm_encoder *encoder, long 
offset,
 void r600_set_vbi_packet(struct drm_encoder *encoder, u32 offset);
 void r600_hdmi_enable(struct drm_encoder *encoder, bool enable);
 
+int r600_dma_cs_next_reloc(struct radeon_cs_parser *p,
+  struct radeon_bo_list **cs_reloc);
 #endif /* __R600_H__ */
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index f20b619466816..dc68e538d5a97 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -29,6 +29,7 @@
 
 #include "radeon.h"
 #include "radeon_asic.h"
+#include "r600.h"
 #include "r600d.h"
 #include "r600_reg_safe.h"
 
-- 
2.25.1

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

[PATCH 05/19] drm/radeon/radeon_encoders: Move 'radeon_atom_backlight_init's prototype to shared header

2020-11-11 Thread Lee Jones

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/radeon/atombios_encoders.c:186:6: warning: no previous 
prototype for ‘radeon_atom_backlight_init’ [-Wmissing-prototypes]
 186 | void radeon_atom_backlight_init(struct radeon_encoder *radeon_encoder,
 | ^~

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/radeon/radeon_atombios.h | 4 
 drivers/gpu/drm/radeon/radeon_encoders.c | 6 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_atombios.h 
b/drivers/gpu/drm/radeon/radeon_atombios.h
index a895a7002c3d3..fd03755e6fa2c 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.h
+++ b/drivers/gpu/drm/radeon/radeon_atombios.h
@@ -28,14 +28,18 @@
 #ifndef __RADEON_ATOMBIOS_H__
 #define __RADEON_ATOMBIOS_H__
 
+struct drm_connector;
 struct drm_device;
 struct drm_display_mode;
 struct radeon_device;
+struct radeon_encoder;
 
 bool radeon_atom_get_tv_timings(struct radeon_device *rdev, int index,
struct drm_display_mode *mode);
 void radeon_add_atom_encoder(struct drm_device *dev, uint32_t encoder_enum,
 uint32_t supported_device, u16 caps);
+void radeon_atom_backlight_init(struct radeon_encoder *radeon_encoder,
+   struct drm_connector *drm_connector);
 
 
 #endif /* __RADEON_ATOMBIOS_H__ */
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c 
b/drivers/gpu/drm/radeon/radeon_encoders.c
index b60a373d3ead3..46549d5179ee9 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -31,14 +31,10 @@
 #include 
 
 #include "radeon.h"
+#include "radeon_atombios.h"
 #include "radeon_legacy_encoders.h"
 #include "atom.h"
 
-extern void
-radeon_atom_backlight_init(struct radeon_encoder *radeon_encoder,
-  struct drm_connector *drm_connector);
-
-
 static uint32_t radeon_encoder_clones(struct drm_encoder *encoder)
 {
struct drm_device *dev = encoder->dev;
-- 
2.25.1

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

[PATCH 09/19] drm/radeon/cik: Move 'si_*()'s prototypes to shared header

2020-11-11 Thread Lee Jones

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/radeon/si.c:4186:6: warning: no previous prototype for 
‘si_vram_gtt_location’ [-Wmissing-prototypes]
 4186 | void si_vram_gtt_location(struct radeon_device *rdev,
 | ^~~~
 drivers/gpu/drm/radeon/si.c:5186:6: warning: no previous prototype for 
‘si_init_uvd_internal_cg’ [-Wmissing-prototypes]
 5186 | void si_init_uvd_internal_cg(struct radeon_device *rdev)
 | ^~~
 drivers/gpu/drm/radeon/si.c:5801:6: warning: no previous prototype for 
‘si_rlc_reset’ [-Wmissing-prototypes]
 5801 | void si_rlc_reset(struct radeon_device *rdev)
 | ^~~~

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/radeon/cik.c | 4 +---
 drivers/gpu/drm/radeon/si.h  | 4 
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index af08d6f1be53e..0330ee86a372b 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -40,6 +40,7 @@
 #include "radeon_asic.h"
 #include "radeon_audio.h"
 #include "radeon_ucode.h"
+#include "si.h"
 
 #define SH_MEM_CONFIG_GFX_DEFAULT \
ALIGNMENT_MODE(SH_MEM_ALIGNMENT_MODE_UNALIGNED)
@@ -127,9 +128,6 @@ MODULE_FIRMWARE("radeon/mullins_mec.bin");
 MODULE_FIRMWARE("radeon/mullins_rlc.bin");
 MODULE_FIRMWARE("radeon/mullins_sdma.bin");
 
-extern void si_vram_gtt_location(struct radeon_device *rdev, struct radeon_mc 
*mc);
-extern void si_rlc_reset(struct radeon_device *rdev);
-extern void si_init_uvd_internal_cg(struct radeon_device *rdev);
 static u32 cik_get_cu_active_bitmap(struct radeon_device *rdev, u32 se, u32 
sh);
 extern int cik_sdma_resume(struct radeon_device *rdev);
 extern void cik_sdma_enable(struct radeon_device *rdev, bool enable);
diff --git a/drivers/gpu/drm/radeon/si.h b/drivers/gpu/drm/radeon/si.h
index a1751ae560f02..f483a64d17050 100644
--- a/drivers/gpu/drm/radeon/si.h
+++ b/drivers/gpu/drm/radeon/si.h
@@ -25,8 +25,12 @@
 #define __SI_H__
 
 struct radeon_device;
+struct radeon_mc;
 
 int si_mc_load_microcode(struct radeon_device *rdev);
 u32 si_gpu_check_soft_reset(struct radeon_device *rdev);
+void si_vram_gtt_location(struct radeon_device *rdev, struct radeon_mc *mc);
+void si_rlc_reset(struct radeon_device *rdev);
+void si_init_uvd_internal_cg(struct radeon_device *rdev);
 
 #endif /* __SI_H__ */
-- 
2.25.1

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

[PATCH 11/19] drm/radeon/radeon_audio: Move 'dce6_*()'s prototypes to shared header

2020-11-11 Thread Lee Jones

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/radeon/dce6_afmt.c:32:5: warning: no previous prototype for 
‘dce6_endpoint_rreg’ [-Wmissing-prototypes]
 32 | u32 dce6_endpoint_rreg(struct radeon_device *rdev,
 | ^~
 drivers/gpu/drm/radeon/dce6_afmt.c:46:6: warning: no previous prototype for 
‘dce6_endpoint_wreg’ [-Wmissing-prototypes]
 46 | void dce6_endpoint_wreg(struct radeon_device *rdev,
 | ^~
 drivers/gpu/drm/radeon/dce6_afmt.c:110:6: warning: no previous prototype for 
‘dce6_afmt_select_pin’ [-Wmissing-prototypes]
 110 | void dce6_afmt_select_pin(struct drm_encoder *encoder)
 | ^~~~
 drivers/gpu/drm/radeon/dce6_afmt.c:123:6: warning: no previous prototype for 
‘dce6_afmt_write_latency_fields’ [-Wmissing-prototypes]
 123 | void dce6_afmt_write_latency_fields(struct drm_encoder *encoder,
 | ^~
 drivers/gpu/drm/radeon/dce6_afmt.c:152:6: warning: no previous prototype for 
‘dce6_afmt_hdmi_write_speaker_allocation’ [-Wmissing-prototypes]
 152 | void dce6_afmt_hdmi_write_speaker_allocation(struct drm_encoder *encoder,
 | ^~~
 drivers/gpu/drm/radeon/dce6_afmt.c:177:6: warning: no previous prototype for 
‘dce6_afmt_dp_write_speaker_allocation’ [-Wmissing-prototypes]
 177 | void dce6_afmt_dp_write_speaker_allocation(struct drm_encoder *encoder,
 | ^
 drivers/gpu/drm/radeon/dce6_afmt.c:202:6: warning: no previous prototype for 
‘dce6_afmt_write_sad_regs’ [-Wmissing-prototypes]
 202 | void dce6_afmt_write_sad_regs(struct drm_encoder *encoder,
 | ^~~~
 drivers/gpu/drm/radeon/dce6_afmt.c:268:6: warning: no previous prototype for 
‘dce6_hdmi_audio_set_dto’ [-Wmissing-prototypes]
 268 | void dce6_hdmi_audio_set_dto(struct radeon_device *rdev,
 | ^~~
 drivers/gpu/drm/radeon/dce6_afmt.c:287:6: warning: no previous prototype for 
‘dce6_dp_audio_set_dto’ [-Wmissing-prototypes]
 287 | void dce6_dp_audio_set_dto(struct radeo_device *rdev,
 | ^

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Slava Grigorev 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/radeon/dce6_afmt.c|  1 +
 drivers/gpu/drm/radeon/dce6_afmt.h| 52 +++
 drivers/gpu/drm/radeon/radeon_audio.c | 17 +
 3 files changed, 54 insertions(+), 16 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/dce6_afmt.h

diff --git a/drivers/gpu/drm/radeon/dce6_afmt.c 
b/drivers/gpu/drm/radeon/dce6_afmt.c
index eec5d7a627388..4a1d5447eac17 100644
--- a/drivers/gpu/drm/radeon/dce6_afmt.c
+++ b/drivers/gpu/drm/radeon/dce6_afmt.c
@@ -22,6 +22,7 @@
  */
 #include 
 
+#include "dce6_afmt.h"
 #include "radeon.h"
 #include "radeon_audio.h"
 #include "sid.h"
diff --git a/drivers/gpu/drm/radeon/dce6_afmt.h 
b/drivers/gpu/drm/radeon/dce6_afmt.h
new file mode 100644
index 0..176a538664a27
--- /dev/null
+++ b/drivers/gpu/drm/radeon/dce6_afmt.h
@@ -0,0 +1,52 @@
+/* dce6_afmt.h -- Private header for radeon driver -*- linux-c -*-
+ *
+ * Copyright 2013 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#ifndef __DCE6_AFMT_H__
+#define __DCE6_AFMT_H__
+
+struct cea_sad;
+struct drm_connector;
+struct drm_display_mode;
+struct drm_encoder;
+struct radeon_crtc;
+struct radeon_device;
+
+u32 dce6_endpoint_rreg(struct radeon_device *rdev, u32 offset, u32 reg);
+void dce6_endpoint_wreg(struct radeon_device *rdev, u32 offset, u32 reg, u32 
v);
+void dce6_afmt_write_sad_regs(struct drm_encoder *encoder,
+ struct cea_sad *sads, int sad_count);
+void dce6_afmt_hdmi_write_speaker_allocation(struct drm_encoder *encoder,
+u8 *sadb, int sad_count);
+void

[PATCH 15/19] drm/radeon/ci_dpm: Move 'si_*()'s prototypes to shared header

2020-11-11 Thread Lee Jones

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/radeon/si_dpm.c:3802:4: warning: no previous prototype for 
‘si_get_ddr3_mclk_frequency_ratio’ [-Wmissing-prototypes]
 3802 | u8 si_get_ddr3_mclk_frequency_ratio(u32 memory_clock)
 | ^~~~
 drivers/gpu/drm/radeon/si_dpm.c:3815:4: warning: no previous prototype for 
‘si_get_mclk_frequency_ratio’ [-Wmissing-prototypes]
 3815 | u8 si_get_mclk_frequency_ratio(u32 memory_clock, bool strobe_mode)
 | ^~~
 drivers/gpu/drm/radeon/si_dpm.c:3897:6: warning: no previous prototype for 
‘si_trim_voltage_table_to_fit_state_table’ [-Wmissing-prototypes]
 3897 | void si_trim_voltage_table_to_fit_state_table(struct radeon_device 
*rdev,
 | ^~~~

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/radeon/ci_dpm.c | 6 +-
 drivers/gpu/drm/radeon/si_dpm.h | 5 +
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index a9fc0a552736c..0dfb0ed9af89d 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -33,6 +33,7 @@
 #include "radeon.h"
 #include "radeon_asic.h"
 #include "radeon_ucode.h"
+#include "si_dpm.h"
 
 #define MC_CG_ARB_FREQ_F0   0x0a
 #define MC_CG_ARB_FREQ_F1   0x0b
@@ -153,11 +154,6 @@ static const struct ci_pt_config_reg didt_config_ci[] =
 extern u8 rv770_get_memory_module_index(struct radeon_device *rdev);
 extern int ni_copy_and_switch_arb_sets(struct radeon_device *rdev,
   u32 arb_freq_src, u32 arb_freq_dest);
-extern u8 si_get_ddr3_mclk_frequency_ratio(u32 memory_clock);
-extern u8 si_get_mclk_frequency_ratio(u32 memory_clock, bool strobe_mode);
-extern void si_trim_voltage_table_to_fit_state_table(struct radeon_device 
*rdev,
-u32 max_voltage_steps,
-struct atom_voltage_table 
*voltage_table);
 static int ci_get_std_voltage_value_sidd(struct radeon_device *rdev,
 struct atom_voltage_table_entry 
*voltage_table,
 u16 *std_voltage_hi_sidd, u16 
*std_voltage_lo_sidd);
diff --git a/drivers/gpu/drm/radeon/si_dpm.h b/drivers/gpu/drm/radeon/si_dpm.h
index 1032a68be792b..aa857906ef93d 100644
--- a/drivers/gpu/drm/radeon/si_dpm.h
+++ b/drivers/gpu/drm/radeon/si_dpm.h
@@ -234,5 +234,10 @@ struct si_power_info {
 #define SISLANDS_CGULVPARAMETER_DFLT0x00040035
 #define SISLANDS_CGULVCONTROL_DFLT  0x1f007550
 
+u8 si_get_ddr3_mclk_frequency_ratio(u32 memory_clock);
+u8 si_get_mclk_frequency_ratio(u32 memory_clock, bool strobe_mode);
+void si_trim_voltage_table_to_fit_state_table(struct radeon_device *rdev,
+ u32 max_voltage_steps,
+ struct atom_voltage_table 
*voltage_table);
 
 #endif
-- 
2.25.1

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

[PATCH 07/19] drm/radeon/si_dpm: Move 'si_mc_load_microcode()'s prototype to shared header

2020-11-11 Thread Lee Jones

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/radeon/si.c:1570:5: warning: no previous prototype for 
‘si_mc_load_microcode’ [-Wmissing-prototypes]

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/radeon/si.c |  1 +
 drivers/gpu/drm/radeon/si.h | 31 +++
 drivers/gpu/drm/radeon/si_dpm.c |  2 +-
 3 files changed, 33 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/radeon/si.h

diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index d0407145c07b5..88731b79c8f57 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -39,6 +39,7 @@
 #include "radeon_audio.h"
 #include "radeon_ucode.h"
 #include "si_blit_shaders.h"
+#include "si.h"
 #include "sid.h"
 
 
diff --git a/drivers/gpu/drm/radeon/si.h b/drivers/gpu/drm/radeon/si.h
new file mode 100644
index 0..0a5018ef166e2
--- /dev/null
+++ b/drivers/gpu/drm/radeon/si.h
@@ -0,0 +1,31 @@
+/* si.h -- Private header for radeon driver -*- linux-c -*-
+ *
+ * Copyright 2011 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef __SI_H__
+#define __SI_H__
+
+struct radeon_device;
+
+int si_mc_load_microcode(struct radeon_device *rdev);
+
+#endif /* __SI_H__ */
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index c68ab2fb1ac23..32b697965c064 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -32,6 +32,7 @@
 #include "radeon_asic.h"
 #include "ni_dpm.h"
 #include "si_dpm.h"
+#include "si.h"
 #include "sid.h"
 
 #define MC_CG_ARB_FREQ_F0   0x0a
@@ -1721,7 +1722,6 @@ static const struct si_powertune_data 
powertune_data_hainan =
 
 struct evergreen_power_info *evergreen_get_pi(struct radeon_device *rdev);
 
-extern int si_mc_load_microcode(struct radeon_device *rdev);
 extern void vce_v1_0_enable_mgcg(struct radeon_device *rdev, bool enable);
 
 static int si_populate_voltage_value(struct radeon_device *rdev,
-- 
2.25.1

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

[PATCH 16/19] drm/radeon/cik: Move 'Move 'cik_sdma_*()'s prototypes to shared header

2020-11-11 Thread Lee Jones

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/radeon/cik_sdma.c:331:6: warning: no previous prototype for 
‘cik_sdma_enable’ [-Wmissing-prototypes]
 331 | void cik_sdma_enable(struct radeon_device *rdev, bool enable)
 | ^~~
 drivers/gpu/drm/radeon/cik_sdma.c:528:5: warning: no previous prototype for 
‘cik_sdma_resume’ [-Wmissing-prototypes]
 528 | int cik_sdma_resume(struct radeon_device *rdev)
 | ^~~
 drivers/gpu/drm/radeon/cik_sdma.c:557:6: warning: no previous prototype for 
‘cik_sdma_fini’ [-Wmissing-prototypes]
 557 | void cik_sdma_fini(struct radeon_device *rdev)
 | ^

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/radeon/cik.c | 3 ---
 drivers/gpu/drm/radeon/cik.h | 3 +++
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 0330ee86a372b..4520ec4c7b2e2 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -129,9 +129,6 @@ MODULE_FIRMWARE("radeon/mullins_rlc.bin");
 MODULE_FIRMWARE("radeon/mullins_sdma.bin");
 
 static u32 cik_get_cu_active_bitmap(struct radeon_device *rdev, u32 se, u32 
sh);
-extern int cik_sdma_resume(struct radeon_device *rdev);
-extern void cik_sdma_enable(struct radeon_device *rdev, bool enable);
-extern void cik_sdma_fini(struct radeon_device *rdev);
 extern void vce_v2_0_enable_mgcg(struct radeon_device *rdev, bool enable);
 static void cik_rlc_stop(struct radeon_device *rdev);
 static void cik_pcie_gen3_enable(struct radeon_device *rdev);
diff --git a/drivers/gpu/drm/radeon/cik.h b/drivers/gpu/drm/radeon/cik.h
index 420207d19de52..d1bf541da5923 100644
--- a/drivers/gpu/drm/radeon/cik.h
+++ b/drivers/gpu/drm/radeon/cik.h
@@ -34,4 +34,7 @@ void cik_init_cp_pg_table(struct radeon_device *rdev);
 u32 cik_get_csb_size(struct radeon_device *rdev);
 void cik_get_csb_buffer(struct radeon_device *rdev, volatile u32 *buffer);
 
+int cik_sdma_resume(struct radeon_device *rdev);
+void cik_sdma_enable(struct radeon_device *rdev, bool enable);
+void cik_sdma_fini(struct radeon_device *rdev);
 #endif /* __CIK_H__ */
-- 
2.25.1

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

[PATCH 01/19] drm/radeon/evergreen_dma: Move 'evergreen_gpu_check_soft_reset()'s prototype to shared header

2020-11-11 Thread Lee Jones

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/radeon/evergreen.c:3825:5: warning: no previous prototype for 
‘evergreen_gpu_check_soft_reset’ [-Wmissing-prototypes]
 3825 | u32 evergreen_gpu_check_soft_reset(struct radeon_device *rdev)
 | ^~

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/radeon/evergreen.h | 1 +
 drivers/gpu/drm/radeon/evergreen_dma.c | 3 +--
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.h 
b/drivers/gpu/drm/radeon/evergreen.h
index 30c9ca99ced90..eb46ac7776951 100644
--- a/drivers/gpu/drm/radeon/evergreen.h
+++ b/drivers/gpu/drm/radeon/evergreen.h
@@ -47,5 +47,6 @@ int sumo_rlc_init(struct radeon_device *rdev);
 void evergreen_gpu_pci_config_reset(struct radeon_device *rdev);
 u32 evergreen_get_number_of_dram_channels(struct radeon_device *rdev);
 void evergreen_print_gpu_status_regs(struct radeon_device *rdev);
+u32 evergreen_gpu_check_soft_reset(struct radeon_device *rdev);
 
 #endif /* __RADEON_EVERGREEN_H__ */
diff --git a/drivers/gpu/drm/radeon/evergreen_dma.c 
b/drivers/gpu/drm/radeon/evergreen_dma.c
index 767857d4a8c5c..52c79da1ecf57 100644
--- a/drivers/gpu/drm/radeon/evergreen_dma.c
+++ b/drivers/gpu/drm/radeon/evergreen_dma.c
@@ -24,10 +24,9 @@
 
 #include "radeon.h"
 #include "radeon_asic.h"
+#include "evergreen.h"
 #include "evergreend.h"
 
-u32 evergreen_gpu_check_soft_reset(struct radeon_device *rdev);
-
 /**
  * evergreen_dma_fence_ring_emit - emit a fence on the DMA ring
  *
-- 
2.25.1

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

[PATCH 13/19] drm/radeon/cik_sdma: Move 'amdgpu_cik_gpu_check_soft_reset()'s prototype to shared header

2020-11-11 Thread Lee Jones

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/radeon/cik.c:4845:5: warning: no previous prototype for 
‘cik_gpu_check_soft_reset’ [-Wmissing-prototypes]
 4845 | u32 cik_gpu_check_soft_reset(struct radeon_device *rdev)
 | ^~~~

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/radeon/cik.h  | 1 +
 drivers/gpu/drm/radeon/cik_sdma.c | 3 +--
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.h b/drivers/gpu/drm/radeon/cik.h
index 297b3c1ff804f..6630b9da9e7aa 100644
--- a/drivers/gpu/drm/radeon/cik.h
+++ b/drivers/gpu/drm/radeon/cik.h
@@ -29,5 +29,6 @@ void cik_enter_rlc_safe_mode(struct radeon_device *rdev);
 void cik_exit_rlc_safe_mode(struct radeon_device *rdev);
 int ci_mc_load_microcode(struct radeon_device *rdev);
 void cik_update_cg(struct radeon_device *rdev, u32 block, bool enable);
+u32 cik_gpu_check_soft_reset(struct radeon_device *rdev);
 
 #endif /* __CIK_H__ */
diff --git a/drivers/gpu/drm/radeon/cik_sdma.c 
b/drivers/gpu/drm/radeon/cik_sdma.c
index 3c709ebe8d1ab..919b14845c3c7 100644
--- a/drivers/gpu/drm/radeon/cik_sdma.c
+++ b/drivers/gpu/drm/radeon/cik_sdma.c
@@ -27,14 +27,13 @@
 #include "radeon_ucode.h"
 #include "radeon_asic.h"
 #include "radeon_trace.h"
+#include "cik.h"
 #include "cikd.h"
 
 /* sdma */
 #define CIK_SDMA_UCODE_SIZE 1050
 #define CIK_SDMA_UCODE_VERSION 64
 
-u32 cik_gpu_check_soft_reset(struct radeon_device *rdev);
-
 /*
  * sDMA - System DMA
  * Starting with CIK, the GPU has new asynchronous
-- 
2.25.1

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

[PATCH 02/19] drm/radeon/r600: Move 'evergreen_rlc_resume()'s prototype to shared header

2020-11-11 Thread Lee Jones

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/radeon/evergreen.c:4380:5: warning: no previous prototype for 
‘evergreen_rlc_resume’ [-Wmissing-prototypes]
 4380 | int evergreen_rlc_resume(struct radeon_device *rdev)
 | ^~~~

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/radeon/evergreen.h | 1 +
 drivers/gpu/drm/radeon/r600.c  | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.h 
b/drivers/gpu/drm/radeon/evergreen.h
index eb46ac7776951..f8d772e612a48 100644
--- a/drivers/gpu/drm/radeon/evergreen.h
+++ b/drivers/gpu/drm/radeon/evergreen.h
@@ -48,5 +48,6 @@ void evergreen_gpu_pci_config_reset(struct radeon_device 
*rdev);
 u32 evergreen_get_number_of_dram_channels(struct radeon_device *rdev);
 void evergreen_print_gpu_status_regs(struct radeon_device *rdev);
 u32 evergreen_gpu_check_soft_reset(struct radeon_device *rdev);
+int evergreen_rlc_resume(struct radeon_device *rdev);
 
 #endif /* __RADEON_EVERGREEN_H__ */
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 94e8815e5067d..b44e0c607b1b1 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -39,6 +39,7 @@
 
 #include "atom.h"
 #include "avivod.h"
+#include "evergreen.h"
 #include "r600.h"
 #include "r600d.h"
 #include "rv770.h"
@@ -113,7 +114,6 @@ static void r600_gpu_init(struct radeon_device *rdev);
 void r600_fini(struct radeon_device *rdev);
 void r600_irq_disable(struct radeon_device *rdev);
 static void r600_pcie_gen2_enable(struct radeon_device *rdev);
-extern int evergreen_rlc_resume(struct radeon_device *rdev);
 
 /*
  * Indirect registers accessor
-- 
2.25.1

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

[PATCH 03/19] drm/radeon/ni_dma: Move 'cayman_gpu_check_soft_reset()'s prototype to shared header

2020-11-11 Thread Lee Jones

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/radeon/ni.c:1733:5: warning: no previous prototype for 
‘cayman_gpu_check_soft_reset’ [-Wmissing-prototypes]
 1733 | u32 cayman_gpu_check_soft_reset(struct radeon_device *rdev)
 | ^~~

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/radeon/ni.h | 1 +
 drivers/gpu/drm/radeon/ni_dma.c | 3 +--
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ni.h b/drivers/gpu/drm/radeon/ni.h
index d63be1c88c0f1..9a5f31a05e68f 100644
--- a/drivers/gpu/drm/radeon/ni.h
+++ b/drivers/gpu/drm/radeon/ni.h
@@ -34,5 +34,6 @@ void cayman_cp_int_cntl_setup(struct radeon_device *rdev,
  int ring, u32 cp_int_cntl);
 void cayman_vm_decode_fault(struct radeon_device *rdev,
u32 status, u32 addr);
+u32 cayman_gpu_check_soft_reset(struct radeon_device *rdev);
 
 #endif /* __NI_H__ */
diff --git a/drivers/gpu/drm/radeon/ni_dma.c b/drivers/gpu/drm/radeon/ni_dma.c
index c56136848360e..bd515ad4fe4cc 100644
--- a/drivers/gpu/drm/radeon/ni_dma.c
+++ b/drivers/gpu/drm/radeon/ni_dma.c
@@ -25,10 +25,9 @@
 #include "radeon.h"
 #include "radeon_asic.h"
 #include "radeon_trace.h"
+#include "ni.h"
 #include "nid.h"
 
-u32 cayman_gpu_check_soft_reset(struct radeon_device *rdev);
-
 /*
  * DMA
  * Starting with R600, the GPU has an asynchronous
-- 
2.25.1

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

[PATCH 14/19] drm/radeon/evergreen: Move 'cik_*()'s prototypes to shared header

2020-11-11 Thread Lee Jones

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/radeon/cik.c:6413:6: warning: no previous prototype for 
‘cik_init_cp_pg_table’ [-Wmissing-prototypes]
 6413 | void cik_init_cp_pg_table(struct radeon_device *rdev)
 | ^~~~
 drivers/gpu/drm/radeon/cik.c:6670:5: warning: no previous prototype for 
‘cik_get_csb_size’ [-Wmissing-prototypes]
 6670 | u32 cik_get_csb_size(struct radeon_device *rdev)
 | ^~~~
 drivers/gpu/drm/radeon/cik.c:6702:6: warning: no previous prototype for 
‘cik_get_csb_buffer’ [-Wmissing-prototypes]
 6702 | void cik_get_csb_buffer(struct radeon_device *rdev, volatile u32 
*buffer)
 | ^~

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/radeon/cik.h   | 3 +++
 drivers/gpu/drm/radeon/evergreen.c | 5 +
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.h b/drivers/gpu/drm/radeon/cik.h
index 6630b9da9e7aa..420207d19de52 100644
--- a/drivers/gpu/drm/radeon/cik.h
+++ b/drivers/gpu/drm/radeon/cik.h
@@ -30,5 +30,8 @@ void cik_exit_rlc_safe_mode(struct radeon_device *rdev);
 int ci_mc_load_microcode(struct radeon_device *rdev);
 void cik_update_cg(struct radeon_device *rdev, u32 block, bool enable);
 u32 cik_gpu_check_soft_reset(struct radeon_device *rdev);
+void cik_init_cp_pg_table(struct radeon_device *rdev);
+u32 cik_get_csb_size(struct radeon_device *rdev);
+void cik_get_csb_buffer(struct radeon_device *rdev, volatile u32 *buffer);
 
 #endif /* __CIK_H__ */
diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index d8ee80ad4ea44..f95b588354274 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -31,6 +31,7 @@
 
 #include "atom.h"
 #include "avivod.h"
+#include "cik.h"
 #include "ni.h"
 #include "rv770.h"
 #include "evergreen.h"
@@ -217,10 +218,6 @@ static void evergreen_gpu_init(struct radeon_device *rdev);
 void evergreen_fini(struct radeon_device *rdev);
 void evergreen_pcie_gen2_enable(struct radeon_device *rdev);
 void evergreen_program_aspm(struct radeon_device *rdev);
-void cik_init_cp_pg_table(struct radeon_device *rdev);
-
-extern u32 cik_get_csb_size(struct radeon_device *rdev);
-extern void cik_get_csb_buffer(struct radeon_device *rdev, volatile u32 
*buffer);
 
 static const u32 evergreen_golden_registers[] =
 {
-- 
2.25.1

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

[PATCH 08/19] drm/radeon/si_dma: Move 'si_gpu_check_soft_reset()'s prototype to shared header

2020-11-11 Thread Lee Jones

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/radeon/si.c:3768:5: warning: no previous prototype for 
‘si_gpu_check_soft_reset’ [-Wmissing-prototypes]
 3768 | u32 si_gpu_check_soft_reset(struct radeon_device *rdev)
 | ^~~

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/radeon/si.h | 1 +
 drivers/gpu/drm/radeon/si_dma.c | 3 +--
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/si.h b/drivers/gpu/drm/radeon/si.h
index 0a5018ef166e2..a1751ae560f02 100644
--- a/drivers/gpu/drm/radeon/si.h
+++ b/drivers/gpu/drm/radeon/si.h
@@ -27,5 +27,6 @@
 struct radeon_device;
 
 int si_mc_load_microcode(struct radeon_device *rdev);
+u32 si_gpu_check_soft_reset(struct radeon_device *rdev);
 
 #endif /* __SI_H__ */
diff --git a/drivers/gpu/drm/radeon/si_dma.c b/drivers/gpu/drm/radeon/si_dma.c
index d2fa302a5be9f..645897d1bfc31 100644
--- a/drivers/gpu/drm/radeon/si_dma.c
+++ b/drivers/gpu/drm/radeon/si_dma.c
@@ -25,10 +25,9 @@
 #include "radeon.h"
 #include "radeon_asic.h"
 #include "radeon_trace.h"
+#include "si.h"
 #include "sid.h"
 
-u32 si_gpu_check_soft_reset(struct radeon_device *rdev);
-
 /**
  * si_dma_is_lockup - Check if the DMA engine is locked up
  *
-- 
2.25.1

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

[PATCH 00/19] [Set 5] Rid W=1 warnings from GPU

2020-11-11 Thread Lee Jones

This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.

This finishes cleaning up Radeon.  AMD next!

Lee Jones (19):
  drm/radeon/evergreen_dma: Move 'evergreen_gpu_check_soft_reset()'s
prototype to shared header
  drm/radeon/r600: Move 'evergreen_rlc_resume()'s prototype to shared
header
  drm/radeon/ni_dma: Move 'cayman_gpu_check_soft_reset()'s prototype to
shared header
  drm/radeon/radeon_atombios: Move 'radeon_add_atom_encoder()'s
prototype to shared header
  drm/radeon/radeon_encoders: Move 'radeon_atom_backlight_init's
prototype to shared header
  drm/radeon/ci_dpm: Move 'ci_*()'s prototypes to shared header
  drm/radeon/si_dpm: Move 'si_mc_load_microcode()'s prototype to shared
header
  drm/radeon/si_dma: Move 'si_gpu_check_soft_reset()'s prototype to
shared header
  drm/radeon/cik: Move 'si_*()'s prototypes to shared header
  drm/radeon/btc_dpm: Move 'evergreen_get_pi's prototype to shared
header
  drm/radeon/radeon_audio: Move 'dce6_*()'s prototypes to shared header
  drm/radeon/evergreen: Move 'si_get_csb_*()'s prototypes to shared
header
  drm/radeon/cik_sdma: Move 'amdgpu_cik_gpu_check_soft_reset()'s
prototype to shared header
  drm/radeon/evergreen: Move 'cik_*()'s prototypes to shared header
  drm/radeon/ci_dpm: Move 'si_*()'s prototypes to shared header
  drm/radeon/cik: Move 'Move 'cik_sdma_*()'s prototypes to shared header
  drm/radeon/si_dpm: Move 'vce_v1_0_enable_mgcg()'s prototype to shared
header
  drm/radeon/cik: Move 'vce_v2_0_enable_mgcg()'s prototype to shared
header
  drm/radeon/evergreen_cs: Move 'r600_dma_cs_next_reloc()'s prototype to
shared header

 drivers/gpu/drm/radeon/btc_dpm.c |  3 +-
 drivers/gpu/drm/radeon/ci_dpm.c  | 13 +-
 drivers/gpu/drm/radeon/cik.c | 10 ++---
 drivers/gpu/drm/radeon/cik.h | 40 ++
 drivers/gpu/drm/radeon/cik_sdma.c|  3 +-
 drivers/gpu/drm/radeon/cypress_dpm.c |  3 +-
 drivers/gpu/drm/radeon/dce6_afmt.c   |  1 +
 drivers/gpu/drm/radeon/dce6_afmt.h   | 52 
 drivers/gpu/drm/radeon/evergreen.c   |  8 +---
 drivers/gpu/drm/radeon/evergreen.h   |  4 ++
 drivers/gpu/drm/radeon/evergreen_cs.c|  3 +-
 drivers/gpu/drm/radeon/evergreen_dma.c   |  3 +-
 drivers/gpu/drm/radeon/ni.h  |  1 +
 drivers/gpu/drm/radeon/ni_dma.c  |  3 +-
 drivers/gpu/drm/radeon/ni_dpm.c  |  3 +-
 drivers/gpu/drm/radeon/r600.c|  2 +-
 drivers/gpu/drm/radeon/r600.h|  4 ++
 drivers/gpu/drm/radeon/r600_cs.c |  1 +
 drivers/gpu/drm/radeon/radeon_atombios.c |  4 --
 drivers/gpu/drm/radeon/radeon_atombios.h |  8 
 drivers/gpu/drm/radeon/radeon_audio.c| 17 +---
 drivers/gpu/drm/radeon/radeon_encoders.c |  6 +--
 drivers/gpu/drm/radeon/rv770_dpm.c   |  1 +
 drivers/gpu/drm/radeon/si.c  |  1 +
 drivers/gpu/drm/radeon/si.h  | 38 +
 drivers/gpu/drm/radeon/si_dma.c  |  3 +-
 drivers/gpu/drm/radeon/si_dpm.c  |  8 ++--
 drivers/gpu/drm/radeon/si_dpm.h  |  5 +++
 drivers/gpu/drm/radeon/trinity_dpm.c |  2 +-
 drivers/gpu/drm/radeon/vce.h | 35 
 drivers/gpu/drm/radeon/vce_v1_0.c|  1 +
 drivers/gpu/drm/radeon/vce_v2_0.c|  1 +
 32 files changed, 215 insertions(+), 72 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/cik.h
 create mode 100644 drivers/gpu/drm/radeon/dce6_afmt.h
 create mode 100644 drivers/gpu/drm/radeon/si.h
 create mode 100644 drivers/gpu/drm/radeon/vce.h

Cc: Alex Deucher 
Cc: amd-...@lists.freedesktop.org
Cc: "Christian König" 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-me...@vger.kernel.org
Cc: Slava Grigorev 
Cc: Sumit Semwal 
-- 
2.25.1

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

[PATCH 10/19] drm/radeon/btc_dpm: Move 'evergreen_get_pi's prototype to shared header

2020-11-11 Thread Lee Jones

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/radeon/rv770_dpm.c:62:30: warning: no previous prototype for 
‘evergreen_get_pi’ [-Wmissing-prototypes]
 62 | struct evergreen_power_info *evergreen_get_pi(struct radeon_device *rdev)
 | ^~~~

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/radeon/btc_dpm.c | 3 +--
 drivers/gpu/drm/radeon/cypress_dpm.c | 3 +--
 drivers/gpu/drm/radeon/evergreen.h   | 2 ++
 drivers/gpu/drm/radeon/ni_dpm.c  | 3 +--
 drivers/gpu/drm/radeon/rv770_dpm.c   | 1 +
 drivers/gpu/drm/radeon/si_dpm.c  | 3 +--
 6 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/radeon/btc_dpm.c b/drivers/gpu/drm/radeon/btc_dpm.c
index 018949668536e..4e64ed38c439f 100644
--- a/drivers/gpu/drm/radeon/btc_dpm.c
+++ b/drivers/gpu/drm/radeon/btc_dpm.c
@@ -29,6 +29,7 @@
 #include "btc_dpm.h"
 #include "btcd.h"
 #include "cypress_dpm.h"
+#include "evergreen.h"
 #include "r600_dpm.h"
 #include "rv770.h"
 #include "radeon.h"
@@ -49,8 +50,6 @@
 #ifndef BTC_MGCG_SEQUENCE
 #define BTC_MGCG_SEQUENCE  300
 
-struct evergreen_power_info *evergreen_get_pi(struct radeon_device *rdev);
-
 extern int ni_mc_load_microcode(struct radeon_device *rdev);
 
 //* BARTS **//
diff --git a/drivers/gpu/drm/radeon/cypress_dpm.c 
b/drivers/gpu/drm/radeon/cypress_dpm.c
index 6d3690bcca2d2..fdddbbaecbb74 100644
--- a/drivers/gpu/drm/radeon/cypress_dpm.c
+++ b/drivers/gpu/drm/radeon/cypress_dpm.c
@@ -26,6 +26,7 @@
 
 #include "atom.h"
 #include "cypress_dpm.h"
+#include "evergreen.h"
 #include "evergreend.h"
 #include "r600_dpm.h"
 #include "rv770.h"
@@ -44,8 +45,6 @@
 #define MC_CG_SEQ_YCLK_SUSPEND  0x04
 #define MC_CG_SEQ_YCLK_RESUME   0x0a
 
-struct evergreen_power_info *evergreen_get_pi(struct radeon_device *rdev);
-
 static void cypress_enable_bif_dynamic_pcie_gen2(struct radeon_device *rdev,
 bool enable)
 {
diff --git a/drivers/gpu/drm/radeon/evergreen.h 
b/drivers/gpu/drm/radeon/evergreen.h
index f8d772e612a48..a829deb8b078a 100644
--- a/drivers/gpu/drm/radeon/evergreen.h
+++ b/drivers/gpu/drm/radeon/evergreen.h
@@ -29,6 +29,7 @@
 #define __RADEON_EVERGREEN_H__
 
 struct evergreen_mc_save;
+struct evergreen_power_info;
 struct radeon_device;
 
 bool evergreen_is_display_hung(struct radeon_device *rdev);
@@ -49,5 +50,6 @@ u32 evergreen_get_number_of_dram_channels(struct 
radeon_device *rdev);
 void evergreen_print_gpu_status_regs(struct radeon_device *rdev);
 u32 evergreen_gpu_check_soft_reset(struct radeon_device *rdev);
 int evergreen_rlc_resume(struct radeon_device *rdev);
+struct evergreen_power_info *evergreen_get_pi(struct radeon_device *rdev);
 
 #endif /* __RADEON_EVERGREEN_H__ */
diff --git a/drivers/gpu/drm/radeon/ni_dpm.c b/drivers/gpu/drm/radeon/ni_dpm.c
index d39bbd9793cc2..dd5ef64937230 100644
--- a/drivers/gpu/drm/radeon/ni_dpm.c
+++ b/drivers/gpu/drm/radeon/ni_dpm.c
@@ -26,6 +26,7 @@
 #include 
 
 #include "atom.h"
+#include "evergreen.h"
 #include "ni_dpm.h"
 #include "nid.h"
 #include "r600_dpm.h"
@@ -720,8 +721,6 @@ static const u32 cayman_sysls_enable[] =
 };
 #define CAYMAN_SYSLS_ENABLE_LENGTH sizeof(cayman_sysls_enable) / (3 * 
sizeof(u32))
 
-struct evergreen_power_info *evergreen_get_pi(struct radeon_device *rdev);
-
 extern int ni_mc_load_microcode(struct radeon_device *rdev);
 
 struct ni_power_info *ni_get_pi(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/rv770_dpm.c 
b/drivers/gpu/drm/radeon/rv770_dpm.c
index badd8ac6e038f..ef2f1a048cfed 100644
--- a/drivers/gpu/drm/radeon/rv770_dpm.c
+++ b/drivers/gpu/drm/radeon/rv770_dpm.c
@@ -30,6 +30,7 @@
 #include "rv770_dpm.h"
 #include "cypress_dpm.h"
 #include "atom.h"
+#include "evergreen.h"
 #include 
 
 #define MC_CG_ARB_FREQ_F0   0x0a
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index 32b697965c064..b4581392fbce9 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -26,6 +26,7 @@
 #include 
 
 #include "atom.h"
+#include "evergreen.h"
 #include "r600_dpm.h"
 #include "rv770.h"
 #include "radeon.h"
@@ -1720,8 +1721,6 @@ static const struct si_powertune_data 
powertune_data_hainan =
true
 };
 
-struct evergreen_power_info *evergreen_get_pi(struct radeon_device *rdev);
-
 extern void vce_v1_0_enable_mgcg(struct radeon_device *rdev, bool enable);
 
 static int si_populate_voltage_value(struct radeon_device *rdev,
-- 
2.25.1

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

[PATCH 04/19] drm/radeon/radeon_atombios: Move 'radeon_add_atom_encoder()'s prototype to shared header

2020-11-11 Thread Lee Jones

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/radeon/atombios_encoders.c:2721:1: warning: no previous 
prototype for ‘radeon_add_atom_encoder’ [-Wmissing-prototypes]
 2721 | radeon_add_atom_encoder(struct drm_device *dev,
 | ^~~

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/radeon/radeon_atombios.c | 4 
 drivers/gpu/drm/radeon/radeon_atombios.h | 4 
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
b/drivers/gpu/drm/radeon/radeon_atombios.c
index cc80651b25773..be96d9b64e43b 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -37,10 +37,6 @@
 #include "radeon_atombios.h"
 #include "radeon_legacy_encoders.h"
 
-extern void
-radeon_add_atom_encoder(struct drm_device *dev, uint32_t encoder_enum,
-   uint32_t supported_device, u16 caps);
-
 union atom_supported_devices {
struct _ATOM_SUPPORTED_DEVICES_INFO info;
struct _ATOM_SUPPORTED_DEVICES_INFO_2 info_2;
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.h 
b/drivers/gpu/drm/radeon/radeon_atombios.h
index b7c76920feb7d..a895a7002c3d3 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.h
+++ b/drivers/gpu/drm/radeon/radeon_atombios.h
@@ -28,10 +28,14 @@
 #ifndef __RADEON_ATOMBIOS_H__
 #define __RADEON_ATOMBIOS_H__
 
+struct drm_device;
 struct drm_display_mode;
 struct radeon_device;
 
 bool radeon_atom_get_tv_timings(struct radeon_device *rdev, int index,
struct drm_display_mode *mode);
+void radeon_add_atom_encoder(struct drm_device *dev, uint32_t encoder_enum,
+uint32_t supported_device, u16 caps);
+
 
 #endif /* __RADEON_ATOMBIOS_H__ */
-- 
2.25.1

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

[PATCH 06/19] drm/radeon/ci_dpm: Move 'ci_*()'s prototypes to shared header

2020-11-11 Thread Lee Jones

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/radeon/cik.c:1868:5: warning: no previous prototype for 
‘ci_mc_load_microcode’ [-Wmissing-prototypes]
 1868 | int ci_mc_load_microcode(struct radeon_device *rdev)
 | ^~~~
 drivers/gpu/drm/radeon/cik.c:5847:6: warning: no previous prototype for 
‘cik_enter_rlc_safe_mode’ [-Wmissing-prototypes]
 5847 | void cik_enter_rlc_safe_mode(struct radeon_device *rdev)
 | ^~~
 drivers/gpu/drm/radeon/cik.c:5868:6: warning: no previous prototype for 
‘cik_exit_rlc_safe_mode’ [-Wmissing-prototypes]
 5868 | void cik_exit_rlc_safe_mode(struct radeon_device *rdev)
 | ^~
 drivers/gpu/drm/radeon/cik.c:6286:6: warning: no previous prototype for 
‘cik_update_cg’ [-Wmissing-prototypes]
 6286 | void cik_update_cg(struct radeon_device *rdev,
 | ^

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/radeon/ci_dpm.c |  7 +--
 drivers/gpu/drm/radeon/cik.c|  1 +
 drivers/gpu/drm/radeon/cik.h| 33 +
 3 files changed, 35 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/cik.h

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 8324aca5fd006..a9fc0a552736c 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -27,6 +27,7 @@
 
 #include "atom.h"
 #include "ci_dpm.h"
+#include "cik.h"
 #include "cikd.h"
 #include "r600_dpm.h"
 #include "radeon.h"
@@ -157,12 +158,6 @@ extern u8 si_get_mclk_frequency_ratio(u32 memory_clock, 
bool strobe_mode);
 extern void si_trim_voltage_table_to_fit_state_table(struct radeon_device 
*rdev,
 u32 max_voltage_steps,
 struct atom_voltage_table 
*voltage_table);
-extern void cik_enter_rlc_safe_mode(struct radeon_device *rdev);
-extern void cik_exit_rlc_safe_mode(struct radeon_device *rdev);
-extern int ci_mc_load_microcode(struct radeon_device *rdev);
-extern void cik_update_cg(struct radeon_device *rdev,
- u32 block, bool enable);
-
 static int ci_get_std_voltage_value_sidd(struct radeon_device *rdev,
 struct atom_voltage_table_entry 
*voltage_table,
 u16 *std_voltage_hi_sidd, u16 
*std_voltage_lo_sidd);
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 377c3f0c9d316..af08d6f1be53e 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -32,6 +32,7 @@
 #include "atom.h"
 #include "evergreen.h"
 #include "cik_blit_shaders.h"
+#include "cik.h"
 #include "cikd.h"
 #include "clearstate_ci.h"
 #include "r600.h"
diff --git a/drivers/gpu/drm/radeon/cik.h b/drivers/gpu/drm/radeon/cik.h
new file mode 100644
index 0..297b3c1ff804f
--- /dev/null
+++ b/drivers/gpu/drm/radeon/cik.h
@@ -0,0 +1,33 @@
+/* cik.h -- Private header for radeon driver -*- linux-c -*-
+ * Copyright 2012 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef __CIK_H__
+#define __CIK_H__
+
+struct radeon_device;
+
+void cik_enter_rlc_safe_mode(struct radeon_device *rdev);
+void cik_exit_rlc_safe_mode(struct radeon_device *rdev);
+int ci_mc_load_microcode(struct radeon_device *rdev);
+void cik_update_cg(struct radeon_device *rdev, u32 block, bool enable);
+
+#endif /* __CIK_H__ */
-- 
2.25.1

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

Re: [PATCH v2 1/2] drm: convert drm_atomic_uapi.c to new debug helpers

2020-11-11 Thread Sam Ravnborg

Hi Simon,
On Wed, Nov 11, 2020 at 09:07:36AM +, Simon Ser wrote:
> Migrate from DRM_DEBUG_ATOMIC to drm_dbg_atomic.
> 
> Signed-off-by: Simon Ser 
> Cc: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: Sam Ravnborg 
> Cc: Ville Syrjala 

Thanks for doing this. I had not been shy about using longer lines as
the hard limit these days are 100 - but thats just an observation.

Reviewed-by: Sam Ravnborg 

Note: I expect you will commit the patch

Sam

> ---
>  drivers/gpu/drm/drm_atomic_uapi.c | 113 +-
>  1 file changed, 66 insertions(+), 47 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index ef82009035e6..efab3d518891 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -85,13 +85,15 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state 
> *state,
>  
>   drm_mode_copy(>mode, mode);
>   state->enable = true;
> - DRM_DEBUG_ATOMIC("Set [MODE:%s] for [CRTC:%d:%s] state %p\n",
> -  mode->name, crtc->base.id, crtc->name, state);
> + drm_dbg_atomic(crtc->dev,
> +"Set [MODE:%s] for [CRTC:%d:%s] state %p\n",
> +mode->name, crtc->base.id, crtc->name, state);
>   } else {
>   memset(>mode, 0, sizeof(state->mode));
>   state->enable = false;
> - DRM_DEBUG_ATOMIC("Set [NOMODE] for [CRTC:%d:%s] state %p\n",
> -  crtc->base.id, crtc->name, state);
> + drm_dbg_atomic(crtc->dev,
> +"Set [NOMODE] for [CRTC:%d:%s] state %p\n",
> +crtc->base.id, crtc->name, state);
>   }
>  
>   return 0;
> @@ -128,31 +130,35 @@ int drm_atomic_set_mode_prop_for_crtc(struct 
> drm_crtc_state *state,
>   int ret;
>  
>   if (blob->length != sizeof(struct drm_mode_modeinfo)) {
> - DRM_DEBUG_ATOMIC("[CRTC:%d:%s] bad mode blob length: 
> %zu\n",
> -  crtc->base.id, crtc->name,
> -  blob->length);
> + drm_dbg_atomic(crtc->dev,
> +"[CRTC:%d:%s] bad mode blob length: 
> %zu\n",
> +crtc->base.id, crtc->name,
> +blob->length);
>   return -EINVAL;
>   }
>  
>   ret = drm_mode_convert_umode(crtc->dev,
>>mode, blob->data);
>   if (ret) {
> - DRM_DEBUG_ATOMIC("[CRTC:%d:%s] invalid mode (ret=%d, 
> status=%s):\n",
> -  crtc->base.id, crtc->name,
> -  ret, 
> drm_get_mode_status_name(state->mode.status));
> + drm_dbg_atomic(crtc->dev,
> +"[CRTC:%d:%s] invalid mode (ret=%d, 
> status=%s):\n",
> +crtc->base.id, crtc->name,
> +ret, 
> drm_get_mode_status_name(state->mode.status));
>   drm_mode_debug_printmodeline(>mode);
>   return -EINVAL;
>   }
>  
>   state->mode_blob = drm_property_blob_get(blob);
>   state->enable = true;
> - DRM_DEBUG_ATOMIC("Set [MODE:%s] for [CRTC:%d:%s] state %p\n",
> -  state->mode.name, crtc->base.id, crtc->name,
> -  state);
> + drm_dbg_atomic(crtc->dev,
> +"Set [MODE:%s] for [CRTC:%d:%s] state %p\n",
> +state->mode.name, crtc->base.id, crtc->name,
> +state);
>   } else {
>   state->enable = false;
> - DRM_DEBUG_ATOMIC("Set [NOMODE] for [CRTC:%d:%s] state %p\n",
> -  crtc->base.id, crtc->name, state);
> + drm_dbg_atomic(crtc->dev,
> +"Set [NOMODE] for [CRTC:%d:%s] state %p\n",
> +crtc->base.id, crtc->name, state);
>   }
>  
>   return 0;
> @@ -202,12 +208,14 @@ drm_atomic_set_crtc_for_plane(struct drm_plane_state 
> *plane_state,
>   }
>  
>   if (crtc)
> - DRM_DEBUG_ATOMIC("Link [PLANE:%d:%s] state %p to 
> [CRTC:%d:%s]\n",
> -  plane->base.id, plane->name, plane_state,
> -  crtc->base.id, crtc->name);
> + drm_dbg_atomic(plane->dev,
> +"Link [PLANE:%d:%s] state %p to [CRTC:%d:%s]\n",
> +plane->base.id, plane->name, plane_state,
> +crtc->base.id, crtc->name);
>   else
> -

Re: [PATCH v2 2/2] drm: add debug logs for drm_mode_atomic_ioctl errors

2020-11-11 Thread Sam Ravnborg

On Wed, Nov 11, 2020 at 09:07:39AM +, Simon Ser wrote:
> Be nice to user-space and log what happened when returning EINVAL in
> drm_mode_atomic_ioctl.
> 
> v2:
> 
> - Migrate to drm_dbg_atomic (Sam)
> - Add debug log for arg->reserved (Ville)
> - Drop redundant "atomic" word in log messages (Ville)
> 
> Signed-off-by: Simon Ser 
> Cc: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: Sam Ravnborg 
> Cc: Ville Syrjala 
Reviewed-by: Sam Ravnborg 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 28/56] drm/omap: dsi: untangle ulps ops from enable/disable

2020-11-11 Thread Tomi Valkeinen

On 09/11/2020 11:57, Laurent Pinchart wrote:
> Hi Tomi and Sebastian,
> 
> Thank you for the patch.
> 
> On Thu, Nov 05, 2020 at 02:03:05PM +0200, Tomi Valkeinen wrote:
>> From: Sebastian Reichel 
>>
>> Create a custom function pointer for ULPS and use it instead of
>> reusing disable/enable functions for ULPS mode switch. This allows
>> us to use the common disable/enable functions pointers for DSI.
>>
>> Signed-off-by: Sebastian Reichel 
>> Signed-off-by: Tomi Valkeinen 
>> ---
>>  .../gpu/drm/omapdrm/displays/panel-dsi-cm.c   |  8 ++--
>>  drivers/gpu/drm/omapdrm/dss/dsi.c | 42 ++-
>>  drivers/gpu/drm/omapdrm/dss/omapdss.h |  5 +--
>>  3 files changed, 38 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c 
>> b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
>> index 4be0c9dbcc43..78247dcb1848 100644
>> --- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
>> +++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
>> @@ -233,7 +233,7 @@ static int dsicm_enter_ulps(struct panel_drv_data *ddata)
>>  if (r)
>>  goto err;
>>  
>> -src->ops->dsi.disable(src, false, true);
>> +src->ops->dsi.ulps(src, true);
>>  
>>  ddata->ulps_enabled = true;
>>  
>> @@ -258,7 +258,7 @@ static int dsicm_exit_ulps(struct panel_drv_data *ddata)
>>  if (!ddata->ulps_enabled)
>>  return 0;
>>  
>> -src->ops->enable(src);
>> +src->ops->dsi.ulps(src, false);
>>  ddata->dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
>>  
>>  r = _dsicm_enable_te(ddata, ddata->te_enabled);
>> @@ -586,7 +586,7 @@ static int dsicm_power_on(struct panel_drv_data *ddata)
>>  
>>  dsicm_hw_reset(ddata);
>>  
>> -src->ops->dsi.disable(src, true, false);
>> +src->ops->disable(src);
>>  err_regulators:
>>  r = regulator_bulk_disable(DCS_REGULATOR_SUPPLY_NUM, ddata->supplies);
>>  if (r)
>> @@ -612,7 +612,7 @@ static void dsicm_power_off(struct panel_drv_data *ddata)
>>  dsicm_hw_reset(ddata);
>>  }
>>  
>> -src->ops->dsi.disable(src, true, false);
>> +src->ops->disable(src);
>>  
>>  r = regulator_bulk_disable(DCS_REGULATOR_SUPPLY_NUM, ddata->supplies);
>>  if (r)
>> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
>> b/drivers/gpu/drm/omapdrm/dss/dsi.c
>> index d54b743c2b48..937362ade4b4 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
>> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
>> @@ -4055,13 +4055,10 @@ static void dsi_display_uninit_dsi(struct dsi_data 
>> *dsi, bool disconnect_lanes,
>>  }
>>  }
>>  
>> -static void dsi_display_enable(struct omap_dss_device *dssdev)
>> +static void dsi_display_ulps_enable(struct dsi_data *dsi)
>>  {
>> -struct dsi_data *dsi = to_dsi_data(dssdev);
>>  int r;
>>  
>> -DSSDBG("dsi_display_enable\n");
>> -
>>  WARN_ON(!dsi_bus_is_locked(dsi));
>>  
>>  mutex_lock(>lock);
>> @@ -4084,16 +4081,19 @@ static void dsi_display_enable(struct 
>> omap_dss_device *dssdev)
>>  dsi_runtime_put(dsi);
>>  err_get_dsi:
>>  mutex_unlock(>lock);
>> -DSSDBG("dsi_display_enable FAILED\n");
>> +DSSDBG("dsi_display_ulps_enable FAILED\n");
>>  }
>>  
>> -static void dsi_display_disable(struct omap_dss_device *dssdev,
>> -bool disconnect_lanes, bool enter_ulps)
>> +static void dsi_display_enable(struct omap_dss_device *dssdev)
>>  {
>>  struct dsi_data *dsi = to_dsi_data(dssdev);
>> +DSSDBG("dsi_display_enable\n");
>> +dsi_display_ulps_enable(dsi);
>> +}
>>  
>> -DSSDBG("dsi_display_disable\n");
>> -
>> +static void dsi_display_ulps_disable(struct dsi_data *dsi,
>> +bool disconnect_lanes, bool enter_ulps)
>> +{
>>  WARN_ON(!dsi_bus_is_locked(dsi));
>>  
>>  mutex_lock(>lock);
>> @@ -4110,6 +4110,27 @@ static void dsi_display_disable(struct 
>> omap_dss_device *dssdev,
>>  mutex_unlock(>lock);
>>  }
>>  
>> +static void dsi_display_disable(struct omap_dss_device *dssdev)
>> +{
>> +struct dsi_data *dsi = to_dsi_data(dssdev);
>> +
>> +DSSDBG("dsi_display_disable\n");
>> +
>> +dsi_display_ulps_disable(dsi, true, false);
>> +}
>> +
>> +static void dsi_ulps(struct omap_dss_device *dssdev, bool enable)
>> +{
>> +struct dsi_data *dsi = to_dsi_data(dssdev);
>> +
>> +DSSDBG("dsi_ulps\n");
>> +
>> +if (enable)
>> +dsi_display_ulps_disable(dsi, false, true);
>> +else
>> +dsi_display_ulps_enable(dsi);
> 
> The names are fairly confusing. I would expect
> dsi_display_ulps_disable() to disable ULPS mode.

It is fairly confusing naming. It's actually something like 
dsi_display_displaye_featuring_ulps.
I'll rename those to

_dsi_display_disable and _dsi_display_enable. So they're just lower level 
enable/disable functions,
which also handle ulps.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___

Re: Why is atomic_disable callback's plane->state->crtc sometimes null?

2020-11-11 Thread Kevin Brace

Hi Ville,

I was able to find a satisfactory workaround.
What I was trying to do is to get a pointer to "struct drm_device" via crtc 
pointer.
I switched to getting it from "struct drm_plane".
On a separate note, I will look into using drm_atomic_get_new_plane_state() and 
drm_atomic_get_old_plane_state() in my code soon.

Regards,

Kevin Brace
Brace Computer Labortory blog
https://bracecomputerlab.com


> Sent: Monday, November 09, 2020 at 9:26 AM
> From: "Ville Syrjälä" 
> To: "Kevin Brace" 
> Cc: "dri-devel" 
> Subject: Re: Why is atomic_disable callback's plane->state->crtc sometimes 
> null?
>
> On Tue, Nov 03, 2020 at 12:50:43AM +0100, Kevin Brace wrote:
> > Hi,
> > 
> > First, I will like to thank those who gave me hints on how to proceed with 
> > getting rid of an unwanted double allocation of visible portion of the 
> > frame buffer.
> > 
> > https://lists.freedesktop.org/archives/dri-devel/2020-October/283452.html
> > 
> > I may repost the question later to the mailing list based on the feedback I 
> > received.
> > After a few more days of trying, I finally got my prototype OpenChrome 
> > DRM atomic modesetting code barely working for both primary and cursor 
> > planes (cursor plane was not working previously).
> > I finally figured out what was causing the freeze, and in fact, I am 
> > writing this e-mail from the very computer that has the experimental code 
> > running.
> > The code itself is still quite unstable that standby resume is not working 
> > and VT (Virtual Terminal) is broken, but X Server is working fine just with 
> > a few minor weird artifact lines on the right and bottom edges of the 
> > screen.
> > Anyway, the question I have here (and I am assuming that Daniel Vetter will 
> > give me an explanation) is that I noticed that for cursor plane's 
> > atomic_disable callback, plane->state->crtc is null or sometimes null.
> > Why is this?
> 
> It can be NULL if the user set it to NULL. That's how you disable
> a plane: crtc=NULL + fb=NULL.
> 
> Also you shouldn't really use plane->state directly anymore.
> Instead you should rather use for_each_{new,old,oldnew}_plane_in_state()
> and/or drm_atomic_get_{new,old}_plane_state().
> 
> -- 
> Ville Syrjälä
> Intel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 27/56] drm/omap: dsi: do bus locking in host driver

2020-11-11 Thread Tomi Valkeinen

On 09/11/2020 15:27, Sebastian Reichel wrote:
> Hi,
> 
> On Mon, Nov 09, 2020 at 12:08:33PM +0200, Tomi Valkeinen wrote:
>> On 09/11/2020 11:52, Laurent Pinchart wrote:
>>> Hi Tomi,
>>>
>>> Thank you for the patch.
>>>
>>> On Thu, Nov 05, 2020 at 02:03:04PM +0200, Tomi Valkeinen wrote:
 From: Sebastian Reichel 

 This moves the bus locking into the host driver and unexports
 the custom API in preparation for drm_panel support.

 Signed-off-by: Sebastian Reichel 
 Signed-off-by: Tomi Valkeinen 
>>
>> 
>>
  static int dsicm_update(struct omap_dss_device *dssdev,
 @@ -739,7 +704,6 @@ static int dsicm_update(struct omap_dss_device *dssdev,
dev_dbg(>dsi->dev, "update %d, %d, %d x %d\n", x, y, w, h);
  
mutex_lock(>lock);
 -  src->ops->dsi.bus_lock(src);
  
r = dsicm_wake_up(ddata);
if (r)
 @@ -761,11 +725,9 @@ static int dsicm_update(struct omap_dss_device 
 *dssdev,
if (r)
goto err;
  
 -  /* note: no bus_unlock here. unlock is src framedone_cb */
 -  mutex_unlock(>lock);
 +  /* note: no unlock here. unlock is src framedone_cb */
>>>
>>> This change isn't described in the commit message. Could you explain why
>>> it's needed ? Locking a mutex in a function and unlocking it elsewhere
>>> always scares me.
>>
>> Good catch. I don't know why it is needed. I don't think it is, as
>> the dsi driver handles the bus lock.
>>
>> Sebastian, what was the reason for this lock?
>>
>> Note that this goes away in the series, and there's no such lock
>> in the end.
> 
> It's not really a change. What this patch basically does is to fold
> src->ops->dsi.bus_lock(src) into mutex_lock(>lock), so that
> there is only a single locking mechanism. This function previously
> had a matching pair of mutex_lock/unlock for ddata->lock, but the
> bus was not locked paired. So after conversion the lock must not be
> free'd here.
> 
> My understanding is, that this is because the bus must not be used
> until the update has been done.

So as I said, I think keeping ddata->lock is not correct. This code also goes 
away some patches
later. So I'll drop the "keep ddata->lock" part.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 25/56] drm/omap: dsi: move TE GPIO handling into core

2020-11-11 Thread Tomi Valkeinen

On 09/11/2020 11:19, Laurent Pinchart wrote:
> Hi Tomi and Sebastian,
> 
> Thank you for the patch.
> 
> On Thu, Nov 05, 2020 at 02:03:02PM +0200, Tomi Valkeinen wrote:
>> From: Sebastian Reichel 
>>
>> In preparation for removing custom DSS calls from the DSI
>> panel driver, this moves support for external tearing event
>> GPIOs into the DSI host driver. This way tearing events are
>> always handled in the core resulting in simplification of
>> the panel drivers.
>>
>> The TE GPIO acquisition follows works in the same way as the
>> exynos DSI implementation.
>>
>> Signed-off-by: Sebastian Reichel 
>> Signed-off-by: Tomi Valkeinen 
>> ---
>>  .../gpu/drm/omapdrm/displays/panel-dsi-cm.c   | 101 +
>>  drivers/gpu/drm/omapdrm/dss/dsi.c | 138 --
>>  2 files changed, 133 insertions(+), 106 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c 
>> b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
>> index 8890ee2ba830..43f63b5a120b 100644
>> --- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
>> +++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
>> @@ -54,7 +54,6 @@ struct panel_drv_data {
>>  
>>  /* panel HW configuration from DT or platform data */
>>  struct gpio_desc *reset_gpio;
>> -struct gpio_desc *ext_te_gpio;
>>  
>>  struct regulator_bulk_data supplies[DCS_REGULATOR_SUPPLY_NUM];
>>  
>> @@ -68,10 +67,6 @@ struct panel_drv_data {
>>  
>>  bool te_enabled;
>>  
>> -atomic_t do_update;
>> -
>> -struct delayed_work te_timeout_work;
>> -
>>  bool intro_printed;
>>  
>>  struct workqueue_struct *workqueue;
>> @@ -83,8 +78,6 @@ struct panel_drv_data {
>>  
>>  #define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
>>  
>> -static irqreturn_t dsicm_te_isr(int irq, void *data);
>> -static void dsicm_te_timeout_work_callback(struct work_struct *work);
>>  static int _dsicm_enable_te(struct panel_drv_data *ddata, bool enable);
>>  
>>  static int dsicm_panel_reset(struct panel_drv_data *ddata);
>> @@ -240,9 +233,6 @@ static int dsicm_enter_ulps(struct panel_drv_data *ddata)
>>  if (r)
>>  goto err;
>>  
>> -if (ddata->ext_te_gpio)
>> -disable_irq(gpiod_to_irq(ddata->ext_te_gpio));
>> -
>>  src->ops->dsi.disable(src, false, true);
>>  
>>  ddata->ulps_enabled = true;
>> @@ -271,15 +261,12 @@ static int dsicm_exit_ulps(struct panel_drv_data 
>> *ddata)
>>  src->ops->enable(src);
>>  ddata->dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
>>  
>> -r = _dsicm_enable_te(ddata, true);
>> +r = _dsicm_enable_te(ddata, ddata->te_enabled);
>>  if (r) {
>>  dev_err(>dsi->dev, "failed to re-enable TE");
>>  goto err2;
>>  }
>>  
>> -if (ddata->ext_te_gpio)
>> -enable_irq(gpiod_to_irq(ddata->ext_te_gpio));
>> -
>>  dsicm_queue_ulps_work(ddata);
>>  
>>  ddata->ulps_enabled = false;
>> @@ -290,11 +277,8 @@ static int dsicm_exit_ulps(struct panel_drv_data *ddata)
>>  dev_err(>dsi->dev, "failed to exit ULPS");
>>  
>>  r = dsicm_panel_reset(ddata);
>> -if (!r) {
>> -if (ddata->ext_te_gpio)
>> -enable_irq(gpiod_to_irq(ddata->ext_te_gpio));
>> +if (!r)
>>  ddata->ulps_enabled = false;
>> -}
>>  
>>  dsicm_queue_ulps_work(ddata);
>>  
>> @@ -745,43 +729,6 @@ static void dsicm_framedone_cb(int err, void *data)
>>  src->ops->dsi.bus_unlock(src);
>>  }
>>  
>> -static irqreturn_t dsicm_te_isr(int irq, void *data)
>> -{
>> -struct panel_drv_data *ddata = data;
>> -struct omap_dss_device *src = ddata->src;
>> -int old;
>> -int r;
>> -
>> -old = atomic_cmpxchg(>do_update, 1, 0);
>> -
>> -if (old) {
>> -cancel_delayed_work(>te_timeout_work);
>> -
>> -r = src->ops->dsi.update(src, ddata->dsi->channel, 
>> dsicm_framedone_cb,
>> -ddata);
>> -if (r)
>> -goto err;
>> -}
>> -
>> -return IRQ_HANDLED;
>> -err:
>> -dev_err(>dsi->dev, "start update failed\n");
>> -src->ops->dsi.bus_unlock(src);
>> -return IRQ_HANDLED;
>> -}
>> -
>> -static void dsicm_te_timeout_work_callback(struct work_struct *work)
>> -{
>> -struct panel_drv_data *ddata = container_of(work, struct panel_drv_data,
>> -te_timeout_work.work);
>> -struct omap_dss_device *src = ddata->src;
>> -
>> -dev_err(>dsi->dev, "TE not received for 250ms!\n");
>> -
>> -atomic_set(>do_update, 0);
>> -src->ops->dsi.bus_unlock(src);
>> -}
>> -
>>  static int dsicm_update(struct omap_dss_device *dssdev,
>>  u16 x, u16 y, u16 w, u16 h)
>>  {
>> @@ -809,16 +756,10 @@ static int dsicm_update(struct omap_dss_device *dssdev,
>>  if (r)
>>  goto err;
>>  
>> -if (ddata->te_enabled && ddata->ext_te_gpio) {
>> -schedule_delayed_work(>te_timeout_work,
>> -

[Bug 209457] AMDGPU resume fail with RX 580 GPU

2020-11-11 Thread bugzilla-daemon

https://bugzilla.kernel.org/show_bug.cgi?id=209457

--- Comment #16 from fawz (f...@negentropy.io) ---
Created attachment 293629
  --> https://bugzilla.kernel.org/attachment.cgi?id=293629=edit
dmesg output when booting with kernel 5.9, suspending, then resuming

-- 
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 209457] AMDGPU resume fail with RX 580 GPU

2020-11-11 Thread bugzilla-daemon

https://bugzilla.kernel.org/show_bug.cgi?id=209457

--- Comment #15 from fawz (f...@negentropy.io) ---
Hi all,

I'm not sure if I'm experiencing the same bug, but the outcome and some of the
log messages seem to be the same. 

For me, resuming from suspend is broken with kernel 5.9.0-2 and works when I
boot with 5.7.0-1, keeping the rest of my system the same. I'm on debian sid.

For SEO, in dmesg I see messages like

nov. 11 17:27:35 [  202.045603] amdgpu: [powerplay] 
nov. 11 17:27:35 failed to send message 146 ret is 0

nov. 11 17:27:35 [  203.073392] [drm:uvd_v4_2_start [amdgpu]] *ERROR* UVD
not responding, trying to reset the VCPU!!!

nov. 11 17:27:35 [  216.242177] amdgpu :01:00.0:
[drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring uvd test failed (-110)
nov. 11 17:27:35 [  216.242245] [drm:amdgpu_device_ip_resume_phase2 [amdgpu]]
*ERROR* resume of IP block  failed -110
nov. 11 17:27:35 [  216.242312] [drm:amdgpu_device_resume [amdgpu]] *ERROR*
amdgpu_device_ip_resume failed (-110).

   nov. 11 17:27:44 [  224.963014] [drm] Fence fallback timer expired on ring
sdma0


My hardware:

- CPU: AMD FX-6200 Six-Core Processor
- VGA: [AMD/ATI] Hawaii PRO [Radeon R9 290/390]
- Motherboard: GA-990FXA-UD3 Firmware F9

Software
- debian sid
- firmware-amd-graphics: 20200918-1
- libdrm-amdgpu1: 2.4.102-1
- mesa: 20.2.1-1


To reiterate, just booting into kernel 5.7 instead of 5.9, resume from suspend
will work, keeping the above software the same.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] drm: add debug logs for drm_mode_atomic_ioctl errors

2020-11-11 Thread Simon Ser

On Wednesday, November 11, 2020 5:48 PM, Daniel Vetter  wrote:

> Submission bikeshed: Patch 1&2 aren't threaded. I thought git send-email
> gets that right by default nowadays ...

Yeah, it's a bug in my SMTP server I haven't bothered to write a patch
for yet. Sorry about that.

> Anyway, on both patches: Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch

Thanks for the review!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 209457] AMDGPU resume fail with RX 580 GPU

2020-11-11 Thread bugzilla-daemon

https://bugzilla.kernel.org/show_bug.cgi?id=209457

fawz (f...@negentropy.io) changed:

   What|Removed |Added

 CC||f...@negentropy.io

--- Comment #14 from fawz (f...@negentropy.io) ---
Hi all,

I'm not sure if I'm experiencing the same bug, but the outcome and some of the
log messages seem to be the same. 

For me, resuming from suspend is broken with kernel 5.9.0-2 and works when I
boot with 5.7.0-1, keeping the rest of my system the same. I'm on debian sid.

For SEO, in dmesg I see messages like

nov. 11 17:27:35 [  202.045603] amdgpu: [powerplay] 
nov. 11 17:27:35 failed to send message 146 ret is 0

nov. 11 17:27:35 [  203.073392] [drm:uvd_v4_2_start [amdgpu]] *ERROR* UVD
not responding, trying to reset the VCPU!!!

nov. 11 17:27:35 [  216.242177] amdgpu :01:00.0:
[drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring uvd test failed (-110)
nov. 11 17:27:35 [  216.242245] [drm:amdgpu_device_ip_resume_phase2 [amdgpu]]
*ERROR* resume of IP block  failed -110
nov. 11 17:27:35 [  216.242312] [drm:amdgpu_device_resume [amdgpu]] *ERROR*
amdgpu_device_ip_resume failed (-110).

   nov. 11 17:27:44 [  224.963014] [drm] Fence fallback timer expired on ring
sdma0


My hardware:

- CPU: AMD FX-6200 Six-Core Processor
- VGA: [AMD/ATI] Hawaii PRO [Radeon R9 290/390]
- Motherboard: GA-990FXA-UD3 Firmware F9

Software
- debian sid
- firmware-amd-graphics: 20200918-1
- libdrm-amdgpu1: 2.4.102-1
- mesa: 20.2.1-1


To reiterate, just booting into kernel 5.7 instead of 5.9, resume from suspend
will work, keeping the above software the same.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] drm: add debug logs for drm_mode_atomic_ioctl errors

2020-11-11 Thread Daniel Vetter

On Wed, Nov 11, 2020 at 09:07:39AM +, Simon Ser wrote:
> Be nice to user-space and log what happened when returning EINVAL in
> drm_mode_atomic_ioctl.
> 
> v2:
> 
> - Migrate to drm_dbg_atomic (Sam)
> - Add debug log for arg->reserved (Ville)
> - Drop redundant "atomic" word in log messages (Ville)
> 
> Signed-off-by: Simon Ser 
> Cc: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: Sam Ravnborg 
> Cc: Ville Syrjala 

Submission bikeshed: Patch 1&2 aren't threaded. I thought git send-email
gets that right by default nowadays ...

Anyway, on both patches: Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_atomic_uapi.c | 23 ++-
>  1 file changed, 18 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index efab3d518891..9df7f2a170e3 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -1330,22 +1330,35 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>* though this may be a bit overkill, since legacy userspace
>* wouldn't know how to call this ioctl)
>*/
> - if (!file_priv->atomic)
> + if (!file_priv->atomic) {
> + drm_dbg_atomic(dev,
> +"commit failed: atomic cap not enabled\n");
>   return -EINVAL;
> + }
>  
> - if (arg->flags & ~DRM_MODE_ATOMIC_FLAGS)
> + if (arg->flags & ~DRM_MODE_ATOMIC_FLAGS) {
> + drm_dbg_atomic(dev, "commit failed: invalid flag\n");
>   return -EINVAL;
> + }
>  
> - if (arg->reserved)
> + if (arg->reserved) {
> + drm_dbg_atomic(dev, "commit failed: reserved field set\n");
>   return -EINVAL;
> + }
>  
> - if (arg->flags & DRM_MODE_PAGE_FLIP_ASYNC)
> + if (arg->flags & DRM_MODE_PAGE_FLIP_ASYNC) {
> + drm_dbg_atomic(dev,
> +"commit failed: invalid flag 
> DRM_MODE_PAGE_FLIP_ASYNC\n");
>   return -EINVAL;
> + }
>  
>   /* can't test and expect an event at the same time. */
>   if ((arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) &&
> - (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
> + (arg->flags & DRM_MODE_PAGE_FLIP_EVENT)) {
> + drm_dbg_atomic(dev,
> +"commit failed: page-flip event requested with 
> test-only commit\n");
>   return -EINVAL;
> + }
>  
>   state = drm_atomic_state_alloc(dev);
>   if (!state)
> -- 
> 2.29.2
> 
> 

-- 
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 v3 35/56] drm/omap: dsi: implement check timings

2020-11-11 Thread Tomi Valkeinen

On 09/11/2020 12:47, Laurent Pinchart wrote:
> Hi Tomi and Sebastian,
> 
> Thank you for the patch.
> 
> On Thu, Nov 05, 2020 at 02:03:12PM +0200, Tomi Valkeinen wrote:
>> From: Sebastian Reichel 
>>
>> Implement check timings, which will check if its possible to
> 
> s/its/it's/
> 
>> configure the clocks for the provided mode using the same code
>> as the set_config() hook.
>>
>> Signed-off-by: Sebastian Reichel 
>> Signed-off-by: Tomi Valkeinen 
>> ---
>>  drivers/gpu/drm/omapdrm/dss/dsi.c | 70 +++
>>  1 file changed, 44 insertions(+), 26 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
>> b/drivers/gpu/drm/omapdrm/dss/dsi.c
>> index a1a867a7d91d..f643321434e9 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
>> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
>> @@ -280,6 +280,11 @@ struct dsi_isr_tables {
>>  struct dsi_isr_data isr_table_cio[DSI_MAX_NR_ISRS];
>>  };
>>  
>> +struct dsi_lp_clock_info {
>> +unsigned long lp_clk;
>> +u16 lp_clk_div;
>> +};
>> +
>>  struct dsi_clk_calc_ctx {
>>  struct dsi_data *dsi;
>>  struct dss_pll *pll;
>> @@ -294,16 +299,12 @@ struct dsi_clk_calc_ctx {
>>  
>>  struct dss_pll_clock_info dsi_cinfo;
>>  struct dispc_clock_info dispc_cinfo;
>> +struct dsi_lp_clock_info user_lp_cinfo;
> 
> Any reason for the user_ prefix here ?

No, I'll drop it.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal

2020-11-11 Thread Andrey Grodzovsky



On 11/11/20 11:06 AM, Greg KH wrote:

On Wed, Nov 11, 2020 at 10:45:53AM -0500, Andrey Grodzovsky wrote:

On 11/11/20 10:34 AM, Greg KH wrote:

On Wed, Nov 11, 2020 at 10:13:13AM -0500, Andrey Grodzovsky wrote:

On 11/10/20 12:59 PM, Greg KH wrote:

On Tue, Nov 10, 2020 at 12:54:21PM -0500, Andrey Grodzovsky wrote:

Hi, back to this after a long context switch for some higher priority stuff.

So here I was able eventually to drop all this code and this change here 
https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.freedesktop.org%2F~agrodzov%2Flinux%2Fcommit%2F%3Fh%3Damd-staging-drm-next-device-unplug%26id%3D61852c8a59b4dd89d637693552c73175b9f2ccd6data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C3e019e2780114b696b4f08d8865bac36%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637407075579242822%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=E%2FIZmVeJDvHiY2xSaaPaay4mXN49EbhSJaJ4zlt6WKk%3Dreserved=0
was enough for me. Seems like while device_remove_file can handle the use
case where the file and the parent directory already gone,
sysfs_remove_group goes down in flames in that case
due to kobj->sd being unset on device removal.

A driver shouldn't ever have to remove individual sysfs groups, the
driver core/bus logic should do it for them automatically.

And whenever a driver calls a sysfs_* call, that's a hint that something
is not working properly.


Do you mean that while the driver creates the groups and files explicitly
from it's different subsystems it should not explicitly remove each
one of them because all of them should be removed at once (and
recursively) when the device is being removed ?

Individual drivers should never add groups/files in sysfs, the driver
core should do it properly for you if you have everything set up
properly.  And yes, the driver core will automatically remove them as
well.

Please use the default groups attribute for your bus/subsystem and this
will happen automagically.

Googling for default groups attributes i found this - 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linuxfoundation.org%2Fblog%2F2013%2F06%2Fhow-to-create-a-sysfs-file-correctly%2Fdata=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C3e019e2780114b696b4f08d8865bac36%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637407075579252818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=AVhdi%2BcKeFXM8CBv%2BhRNTCYX2XSS8oo0so6mB%2BPuEfk%3Dreserved=0

Odd, mirror of the original article:

https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkroah.com%2Flog%2Fblog%2F2013%2F06%2F26%2Fhow-to-create-a-sysfs-file-correctly%2Fdata=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C3e019e2780114b696b4f08d8865bac36%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637407075579252818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=lGMd3PJOWIlKUpvbV3Zz%2FvbBIRwz6%2BlJ%2BS%2BiVcXxuzM%3Dreserved=0


Would this be what you suggest for us ? Specifically for our case the struct
device's  groups  seems the right solution as different devices
might have slightly diffreent sysfs attributes.

That's what the is_visable() callback in your attribute group is for, to
tell the kernel if an individual sysfs attribute should be created or
not.


I see, this looks like a good improvement to our current way of managing sysfs. 
Since this
change is somewhat fundamental and requires good testing I prefer to deal with 
it separately from my current

work on device unplug and so I will put it on TODO right after finishing this 
work.

Andrey




thanks,

greg k-h

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

Re: [PATCH v10 6/6] dma-buf: Document that dma-buf size is fixed

2020-11-11 Thread Daniel Vetter

On Tue, Nov 10, 2020 at 01:41:17PM -0800, Jianxin Xiong wrote:
> The fact that the size of dma-buf is invariant over the lifetime of the
> buffer is mentioned in the comment of 'dma_buf_ops.mmap', but is not
> documented at where the info is defined. Add the missing documentation.
> 
> Signed-off-by: Jianxin Xiong 

Applied to drm-misc-next, thanks for your patch. For the preceeding
dma-buf patch I'll wait for more review/acks before I apply it. Ack from
Jason might also be good, since looks like this dma_virt_ops is only used
in rdma.
-Daniel

> ---
>  include/linux/dma-buf.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index 9dcd569..92da98b 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -272,7 +272,7 @@ struct dma_buf_ops {
>  
>  /**
>   * struct dma_buf - shared buffer object
> - * @size: size of the buffer
> + * @size: size of the buffer; invariant over the lifetime of the buffer.
>   * @file: file pointer used for sharing buffers across, and for refcounting.
>   * @attachments: list of dma_buf_attachment that denotes all devices 
> attached,
>   *   protected by dma_resv lock.
> @@ -404,7 +404,7 @@ struct dma_buf_attachment {
>   * @exp_name:name of the exporter - useful for debugging.
>   * @owner:   pointer to exporter module - used for refcounting kernel module
>   * @ops: Attach allocator-defined dma buf ops to the new buffer
> - * @size:Size of the buffer
> + * @size:Size of the buffer - invariant over the lifetime of the buffer
>   * @flags:   mode flags for the file
>   * @resv:reservation-object, NULL to allocate default one
>   * @priv:Attach private data of allocator to this buffer
> -- 
> 1.8.3.1
> 
> ___
> 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] drm/nouveau: Fix out-of-bounds access when deferencing MMU type

2020-11-11 Thread Ruhl, Michael J

>-Original Message-
>From: Thomas Zimmermann 
>Sent: Wednesday, November 11, 2020 7:08 AM
>To: Ruhl, Michael J ; bske...@redhat.com;
>airl...@linux.ie; dan...@ffwll.ch; christian.koe...@amd.com
>Cc: nouv...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>Maarten Lankhorst ; Maxime Ripard
>; Dave Airlie ; Gerd Hoffmann
>; Alex Deucher ;
>VMware Graphics ; Roland
>Scheidegger ; Huang Rui ;
>Felix Kuehling ; Hawking Zhang
>; Jason Gunthorpe ; Likun Gao
>; virtualizat...@lists.linux-foundation.org; spice-
>de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
>Subject: Re: [PATCH] drm/nouveau: Fix out-of-bounds access when
>deferencing MMU type
>
>Hi
>
>Am 10.11.20 um 16:27 schrieb Ruhl, Michael J:
>>
>>
>>> -Original Message-
>>> From: Thomas Zimmermann 
>>> Sent: Tuesday, November 10, 2020 8:37 AM
>>> To: bske...@redhat.com; airl...@linux.ie; dan...@ffwll.ch; Ruhl, Michael J
>>> ; christian.koe...@amd.com
>>> Cc: nouv...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>Thomas
>>> Zimmermann ; Maarten Lankhorst
>>> ; Maxime Ripard
>>> ; Dave Airlie ; Gerd Hoffmann
>>> ; Alex Deucher ;
>>> VMware Graphics ; Roland
>>> Scheidegger ; Huang Rui ;
>>> Felix Kuehling ; Hawking Zhang
>>> ; Jason Gunthorpe ; Likun
>Gao
>>> ; virtualizat...@lists.linux-foundation.org; spice-
>>> de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
>>> Subject: [PATCH] drm/nouveau: Fix out-of-bounds access when
>deferencing
>>> MMU type
>>>
>>> The value of struct drm_device.ttm.type_vram can become -1 for
>unknown
>>> types of memory (see nouveau_ttm_init()). This leads to an out-of-bounds
>>> error when accessing struct nvif_mmu.type[]:
>>
>> Would this make more sense to just set the type_vram = 0 instead of -1?
>
>From what I understand, these indices refer to an internal type of MMU,
>rsp the MMU's capabilities. However, my hardware (pre-NV50) does not
>have an MMU at all.

Yeah, and upon further review I see that my comment was completely wrong
(value vs. index).

A better suggestion would have been, create an entry in the array that means,
"unsupported type" with a value of 0, but...

>I agree that it would be nice to have a cleaner design that incorporates
>this case, but resolving that would apparently require more than a bugfix.

I agree.  The -1 index is a special case for the platform path
(platform != NV_DEVICE_INFO_V0_SOC).  This is a fix for the issue, but not
a complete solution.

If you need it:
Reviewed-by: Michael J. Ruhl 

Thanks,
Mike

>Best regards
>Thomas
>
>>
>> Mike
>>
>>>
>>>  [   18.304116]
>>>
>===
>>> ===
>>>  [   18.311649] BUG: KASAN: slab-out-of-bounds in
>>> nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
>>>  [   18.320415] Read of size 1 at addr 88810ffac1fe by task systemd-
>>> udevd/342
>>>  [   18.327681]
>>>  [   18.329208] CPU: 1 PID: 342 Comm: systemd-udevd Tainted: GE
>>> 5.10.0-rc2-1-default+ #581
>>>  [   18.338681] Hardware name: Dell Inc. OptiPlex 9020/0N4YC8, BIOS A24
>>> 10/24/2018
>>>  [   18.346032] Call Trace:
>>>  [   18.348536]  dump_stack+0xae/0xe5
>>>  [   18.351919]  print_address_description.constprop.0+0x17/0xf0
>>>  [   18.357787]  ? nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
>>>  [   18.363818]  __kasan_report.cold+0x20/0x38
>>>  [   18.368099]  ? nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
>>>  [   18.374133]  kasan_report+0x3a/0x50
>>>  [   18.377789]  nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
>>>  <...>
>>>  [   18.767690] Allocated by task 342:
>>>  [   18.773087]  kasan_save_stack+0x1b/0x40
>>>  [   18.778890]  __kasan_kmalloc.constprop.0+0xbf/0xd0
>>>  [   18.785646]  __kmalloc_track_caller+0x1be/0x390
>>>  [   18.792165]  kstrdup_const+0x46/0x70
>>>  [   18.797686]  kobject_set_name_vargs+0x2f/0xb0
>>>  [   18.803992]  kobject_init_and_add+0x9d/0xf0
>>>  [   18.810117]  ttm_mem_global_init+0x12c/0x210 [ttm]
>>>  [   18.816853]  ttm_bo_global_init+0x4a/0x160 [ttm]
>>>  [   18.823420]  ttm_bo_device_init+0x39/0x220 [ttm]
>>>  [   18.830046]  nouveau_ttm_init+0x2c3/0x830 [nouveau]
>>>  [   18.836929]  nouveau_drm_device_init+0x1b4/0x3f0 [nouveau]
>>>  <...>
>>>  [   19.105336]
>>>
>===
>>> ===
>>>
>>> Fix this error, by not using type_vram as an index if it's negative.
>>> Assume default values instead.
>>>
>>> The error was seen on Nvidia G72 hardware.
>>>
>>> Signed-off-by: Thomas Zimmermann 
>>> Fixes: 1cf65c45183a ("drm/ttm: add caching state to ttm_bus_placement")
>>> Cc: Christian König 
>>> Cc: Michael J. Ruhl 
>>> Cc: Maarten Lankhorst 
>>> Cc: Maxime Ripard 
>>> Cc: Thomas Zimmermann 
>>> Cc: David Airlie 
>>> Cc: Daniel Vetter 
>>> Cc: Ben Skeggs 
>>> Cc: Dave Airlie 
>>> Cc: Gerd Hoffmann 
>>> Cc: Alex Deucher 
>>> Cc: "Christian König" 
>>> Cc: VMware Graphics 
>>> Cc: Roland Scheidegger 
>>> Cc: Huang Rui 
>>> Cc: Felix Kuehling 
>>> Cc: Hawking Zhang 
>>> Cc:

Re: [PATCH v3 50/56] drm/omap: dsi: simplify pin config

2020-11-11 Thread Tomi Valkeinen

On 09/11/2020 13:09, Laurent Pinchart wrote:
> Hi Tomi and Sebastian,
> 
> Thank you for the patch.
> 
> On Thu, Nov 05, 2020 at 02:03:27PM +0200, Tomi Valkeinen wrote:
>> From: Sebastian Reichel 
>>
>> Simplify DSI pin config, which always originates from DT
>> nowadays. With the code being fully contained in the DSI
>> encoder, we can drop the public structure.
>>
>> Since the function is no longer exposed, it now directly
>> takes the private DSI data pointer. This drop a pointless
> 
> s/drop/drops/
> 
>> conversion and means the pins can be configured earlier.
>>
>> Signed-off-by: Sebastian Reichel 
>> Signed-off-by: Tomi Valkeinen 
>> ---
>>  drivers/gpu/drm/omapdrm/dss/dsi.c | 33 +--
>>  drivers/gpu/drm/omapdrm/dss/omapdss.h | 15 
>>  2 files changed, 11 insertions(+), 37 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
>> b/drivers/gpu/drm/omapdrm/dss/dsi.c
>> index f47d7e3bb631..76e4f607d8cf 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
>> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
>> @@ -3568,12 +3568,9 @@ static void dsi_proto_timings(struct dsi_data *dsi)
>>  }
>>  }
>>  
>> -static int dsi_configure_pins(struct omap_dss_device *dssdev,
>> -const struct omap_dsi_pin_config *pin_cfg)
>> +static int dsi_configure_pins(struct dsi_data *dsi,
>> +int num_pins, const u32 *pins)
>>  {
>> -struct dsi_data *dsi = to_dsi_data(dssdev);
>> -int num_pins;
>> -const int *pins;
>>  struct dsi_lane_config lanes[DSI_MAX_NR_LANES];
>>  int num_lanes;
>>  int i;
>> @@ -3586,9 +3583,6 @@ static int dsi_configure_pins(struct omap_dss_device 
>> *dssdev,
>>  DSI_LANE_DATA4,
>>  };
>>  
>> -num_pins = pin_cfg->num_pins;
>> -pins = pin_cfg->pins;
>> -
>>  if (num_pins < 4 || num_pins > dsi->num_lanes_supported * 2
>>  || num_pins % 2 != 0)
>>  return -EINVAL;
>> @@ -3600,7 +3594,7 @@ static int dsi_configure_pins(struct omap_dss_device 
>> *dssdev,
>>  
>>  for (i = 0; i < num_pins; i += 2) {
>>  u8 lane, pol;
>> -int dx, dy;
>> +u32 dx, dy;
> 
> Is this change needed ?

The pins array is now u32, so the above is correct. However, a bit below we 
check if dx < 0, which
doesn't make sense anymore, so I'll drop that check.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal

2020-11-11 Thread Greg KH

On Wed, Nov 11, 2020 at 10:45:53AM -0500, Andrey Grodzovsky wrote:
> 
> On 11/11/20 10:34 AM, Greg KH wrote:
> > On Wed, Nov 11, 2020 at 10:13:13AM -0500, Andrey Grodzovsky wrote:
> > > On 11/10/20 12:59 PM, Greg KH wrote:
> > > > On Tue, Nov 10, 2020 at 12:54:21PM -0500, Andrey Grodzovsky wrote:
> > > > > Hi, back to this after a long context switch for some higher priority 
> > > > > stuff.
> > > > > 
> > > > > So here I was able eventually to drop all this code and this change 
> > > > > here 
> > > > > https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.freedesktop.org%2F~agrodzov%2Flinux%2Fcommit%2F%3Fh%3Damd-staging-drm-next-device-unplug%26id%3D61852c8a59b4dd89d637693552c73175b9f2ccd6data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C9fbfecac94a340dfb68408d886571609%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637407055896651058%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Ye8HJR1vidppcOBnlOgVu5GwKD2%2Bb5ztHbiI%2BubKKT0%3Dreserved=0
> > > > > was enough for me. Seems like while device_remove_file can handle the 
> > > > > use
> > > > > case where the file and the parent directory already gone,
> > > > > sysfs_remove_group goes down in flames in that case
> > > > > due to kobj->sd being unset on device removal.
> > > > A driver shouldn't ever have to remove individual sysfs groups, the
> > > > driver core/bus logic should do it for them automatically.
> > > > 
> > > > And whenever a driver calls a sysfs_* call, that's a hint that something
> > > > is not working properly.
> > > 
> > > 
> > > Do you mean that while the driver creates the groups and files explicitly
> > > from it's different subsystems it should not explicitly remove each
> > > one of them because all of them should be removed at once (and
> > > recursively) when the device is being removed ?
> > Individual drivers should never add groups/files in sysfs, the driver
> > core should do it properly for you if you have everything set up
> > properly.  And yes, the driver core will automatically remove them as
> > well.
> > 
> > Please use the default groups attribute for your bus/subsystem and this
> > will happen automagically.
> 
> Googling for default groups attributes i found this - 
> https://www.linuxfoundation.org/blog/2013/06/how-to-create-a-sysfs-file-correctly/

Odd, mirror of the original article:

http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/

> Would this be what you suggest for us ? Specifically for our case the struct
> device's  groups  seems the right solution as different devices
> might have slightly diffreent sysfs attributes.

That's what the is_visable() callback in your attribute group is for, to
tell the kernel if an individual sysfs attribute should be created or
not.

thanks,

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

Re: [PATCH v3 37/56] drm/omap: panel-dsi-cm: support unbinding

2020-11-11 Thread Tomi Valkeinen

On 09/11/2020 12:49, Laurent Pinchart wrote:
> Hi Tomi and Sebastian,
> 
> On Thu, Nov 05, 2020 at 02:03:14PM +0200, Tomi Valkeinen wrote:
>> From: Sebastian Reichel 
>>
>> Now, that the driver implements the common DRM panel API
>> the unbind no longer needs to be suppressed.
>>
>> Signed-off-by: Sebastian Reichel 
>> Signed-off-by: Tomi Valkeinen 
> 
> Acked-by: Laurent Pinchart 
> 
> I'd be curious to know what happens when you try to unbind through sysfs
> though...

I'm sure it crashes. The same happens if you unload the modules in wrong order 
(unload panel first,
then omapdrm). I haven't looked at this yet, it's low priority issue...

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 30/56] drm/omap: dsi: move panel refresh function to host

2020-11-11 Thread Laurent Pinchart

Hi Tomi,

On Wed, Nov 11, 2020 at 05:34:52PM +0200, Tomi Valkeinen wrote:
> On 09/11/2020 12:10, Laurent Pinchart wrote:
> > On Thu, Nov 05, 2020 at 02:03:07PM +0200, Tomi Valkeinen wrote:
> >> From: Sebastian Reichel 
> >>
> >> This moves the panel refresh/update function from the panel
> >> driver into the DSI host driver to prepare for common drm_panel
> >> support.
> >>
> >> Signed-off-by: Sebastian Reichel 
> >> Signed-off-by: Tomi Valkeinen 
> >> ---
> >>  .../gpu/drm/omapdrm/displays/panel-dsi-cm.c   |  68 
> >>  drivers/gpu/drm/omapdrm/dss/dsi.c | 101 --
> >>  drivers/gpu/drm/omapdrm/dss/omapdss.h |  13 +--
> >>  drivers/gpu/drm/omapdrm/omap_crtc.c   |  11 +-
> >>  4 files changed, 97 insertions(+), 96 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c 
> >> b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> >> index 030a8fa140db..1582960f9e90 100644
> >> --- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> >> +++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> >> @@ -177,27 +177,6 @@ static int dsicm_get_id(struct panel_drv_data *ddata, 
> >> u8 *id1, u8 *id2, u8 *id3)
> >>return 0;
> >>  }
> >>  
> >> -static int dsicm_set_update_window(struct panel_drv_data *ddata,
> >> -  u16 x, u16 y, u16 w, u16 h)
> >> -{
> >> -  struct mipi_dsi_device *dsi = ddata->dsi;
> >> -  int r;
> >> -  u16 x1 = x;
> >> -  u16 x2 = x + w - 1;
> >> -  u16 y1 = y;
> >> -  u16 y2 = y + h - 1;
> >> -
> >> -  r = mipi_dsi_dcs_set_column_address(dsi, x1, x2);
> >> -  if (r < 0)
> >> -  return r;
> >> -
> >> -  r = mipi_dsi_dcs_set_page_address(dsi, y1, y2);
> >> -  if (r < 0)
> >> -  return r;
> >> -
> >> -  return 0;
> >> -}
> >> -
> > 
> > I can't tell whether this is common to all command-mode panels, or if
> > there could be a need for panel-specific update procedures, so I can't
> > really ack this patch.
> 
> I can't say either, but all the command mode panels I know need and support 
> this. And, afaik, we
> have only the single cmd mode panel driver which we add in this series.

Now that I think about it again, isn't it a layering violation ?
Shouldn't the DSI host handle DSI commands transfers, with the panel
driver taking care of specific DSI commands ?

If keeping this code in the panel driver causes lots of rebase conflicts
I'm fine fixing this on top, but it looks like it belongs to the panel
driver.

> >>  static int dsicm_bl_update_status(struct backlight_device *dev)
> >>  {
> >>struct panel_drv_data *ddata = dev_get_drvdata(>dev);
> >> @@ -470,48 +449,6 @@ static void dsicm_disable(struct omap_dss_device 
> >> *dssdev)
> >>mutex_unlock(>lock);
> >>  }
> >>  
> >> -static void dsicm_framedone_cb(int err, void *data)
> >> -{
> >> -  struct panel_drv_data *ddata = data;
> >> -
> >> -  dev_dbg(>dsi->dev, "framedone, err %d\n", err);
> >> -  mutex_unlock(>lock);
> >> -}
> >> -
> >> -static int dsicm_update(struct omap_dss_device *dssdev,
> >> -  u16 x, u16 y, u16 w, u16 h)
> >> -{
> >> -  struct panel_drv_data *ddata = to_panel_data(dssdev);
> >> -  struct omap_dss_device *src = ddata->src;
> >> -  int r;
> >> -
> >> -  dev_dbg(>dsi->dev, "update %d, %d, %d x %d\n", x, y, w, h);
> >> -
> >> -  mutex_lock(>lock);
> >> -
> >> -  if (!ddata->enabled) {
> >> -  r = 0;
> >> -  goto err;
> >> -  }
> >> -
> >> -  /* XXX no need to send this every frame, but dsi break if not done */
> >> -  r = dsicm_set_update_window(ddata, 0, 0, ddata->vm.hactive,
> >> -  ddata->vm.vactive);
> >> -  if (r)
> >> -  goto err;
> >> -
> >> -  r = src->ops->dsi.update(src, ddata->dsi->channel, dsicm_framedone_cb,
> >> -  ddata);
> >> -  if (r)
> >> -  goto err;
> >> -
> >> -  /* note: no unlock here. unlock is src framedone_cb */
> >> -  return 0;
> >> -err:
> >> -  mutex_unlock(>lock);
> >> -  return r;
> >> -}
> >> -
> >>  static int _dsicm_enable_te(struct panel_drv_data *ddata, bool enable)
> >>  {
> >>struct mipi_dsi_device *dsi = ddata->dsi;
> >> @@ -572,10 +509,6 @@ static const struct omap_dss_device_ops dsicm_ops = {
> >>.check_timings  = dsicm_check_timings,
> >>  };
> >>  
> >> -static const struct omap_dss_driver dsicm_dss_driver = {
> >> -  .update = dsicm_update,
> >> -};
> >> -
> >>  static int dsicm_probe_of(struct mipi_dsi_device *dsi)
> >>  {
> >>struct device_node *node = dsi->dev.of_node;
> >> @@ -658,7 +591,6 @@ static int dsicm_probe(struct mipi_dsi_device *dsi)
> >>dssdev = >dssdev;
> >>dssdev->dev = dev;
> >>dssdev->ops = _ops;
> >> -  dssdev->driver = _dss_driver;
> >>dssdev->type = OMAP_DISPLAY_TYPE_DSI;
> >>dssdev->display = true;
> >>dssdev->owner = THIS_MODULE;
> >> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> >> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> >> index 0f264654792d..0aa0d21cf896 100644
> >> ---

Re: [PATCH v2 5/6] drm/tidss: Move to newer connector model

2020-11-11 Thread Tomi Valkeinen

On 09/11/2020 19:06, Nikhil Devshatwar wrote:
> To be able to support connector operations across multiple
> bridges, it is recommended that the connector should be
> created by the SoC driver instead of the bridges.
> 
> Modify the tidss modesetting initialization sequence to
> create the connector and attach bridges with flag
> DRM_BRIDGE_ATTACH_NO_CONNECTOR
> 
> Signed-off-by: Nikhil Devshatwar 
> ---
>  drivers/gpu/drm/tidss/tidss_drv.h |  3 +++
>  drivers/gpu/drm/tidss/tidss_kms.c | 19 ++-
>  2 files changed, 21 insertions(+), 1 deletion(-)
> 

Reviewed-by: Tomi Valkeinen 

You're missing Laurent's r-by, which he gave earlier.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/6] drm/tidss: Set bus_format correctly from bridge/connector

2020-11-11 Thread Tomi Valkeinen

On 09/11/2020 19:05, Nikhil Devshatwar wrote:
> When there is a chain of bridges attached to the encoder,
> the bus_format should be ideally set from the input format of the
> first bridge in the chain.
> 
> Use the bridge state to get the negotiated bus_format.
> If the bridge does not support format negotiation, error out
> and fail.
> 
> Signed-off-by: Nikhil Devshatwar 
> ---
>  drivers/gpu/drm/tidss/tidss_encoder.c | 22 ++
>  1 file changed, 14 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tidss/tidss_encoder.c 
> b/drivers/gpu/drm/tidss/tidss_encoder.c
> index e278a9c89476..ba5b6fccabe7 100644
> --- a/drivers/gpu/drm/tidss/tidss_encoder.c
> +++ b/drivers/gpu/drm/tidss/tidss_encoder.c
> @@ -22,6 +22,7 @@ static int tidss_encoder_atomic_check(struct drm_encoder 
> *encoder,
>   struct drm_device *ddev = encoder->dev;
>   struct tidss_crtc_state *tcrtc_state = to_tidss_crtc_state(crtc_state);
>   struct drm_display_info *di = _state->connector->display_info;
> + struct drm_bridge_state *bstate;
>   struct drm_bridge *bridge;
>   bool bus_flags_set = false;
>  
> @@ -41,17 +42,22 @@ static int tidss_encoder_atomic_check(struct drm_encoder 
> *encoder,
>   break;
>   }
>  
> - if (!di->bus_formats || di->num_bus_formats == 0)  {
> - dev_err(ddev->dev, "%s: No bus_formats in connected display\n",
> - __func__);
> - return -EINVAL;
> - }
> -
> - // XXX any cleaner way to set bus format and flags?
> - tcrtc_state->bus_format = di->bus_formats[0];
>   if (!bus_flags_set)
>   tcrtc_state->bus_flags = di->bus_flags;
>  
> + /* Copy the bus_format from the input_bus_format of first bridge */
> + bridge = drm_bridge_chain_get_first_bridge(encoder);
> + bstate = drm_atomic_get_new_bridge_state(crtc_state->state, bridge);
> + if (bstate)
> + tcrtc_state->bus_format = bstate->input_bus_cfg.format;
> +
> + if (tcrtc_state->bus_format == 0 ||
> + tcrtc_state->bus_format == MEDIA_BUS_FMT_FIXED) {
> +
> + dev_err(ddev->dev, "Bridge connected to the encoder did not 
> specify media bus format\n");
> + return -EINVAL;
> + }
> +
>   return 0;

We should also take the bus flags from the bridge state (next bridge's 
input_bus_cfg.flags).

And... If I read this right, we always fail if there's no bstate. So we could 
just do "if (!bstate)
fail;"

And if we always expect to have bstate, and get bus flags and formats from 
there, we don't need the
current drm_for_each_bridge_in_chain() loop or taking bus_flags from display 
info.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal

2020-11-11 Thread Andrey Grodzovsky



On 11/11/20 10:34 AM, Greg KH wrote:

On Wed, Nov 11, 2020 at 10:13:13AM -0500, Andrey Grodzovsky wrote:

On 11/10/20 12:59 PM, Greg KH wrote:

On Tue, Nov 10, 2020 at 12:54:21PM -0500, Andrey Grodzovsky wrote:

Hi, back to this after a long context switch for some higher priority stuff.

So here I was able eventually to drop all this code and this change here 
https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.freedesktop.org%2F~agrodzov%2Flinux%2Fcommit%2F%3Fh%3Damd-staging-drm-next-device-unplug%26id%3D61852c8a59b4dd89d637693552c73175b9f2ccd6data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C9fbfecac94a340dfb68408d886571609%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637407055896651058%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Ye8HJR1vidppcOBnlOgVu5GwKD2%2Bb5ztHbiI%2BubKKT0%3Dreserved=0
was enough for me. Seems like while device_remove_file can handle the use
case where the file and the parent directory already gone,
sysfs_remove_group goes down in flames in that case
due to kobj->sd being unset on device removal.

A driver shouldn't ever have to remove individual sysfs groups, the
driver core/bus logic should do it for them automatically.

And whenever a driver calls a sysfs_* call, that's a hint that something
is not working properly.



Do you mean that while the driver creates the groups and files explicitly
from it's different subsystems it should not explicitly remove each
one of them because all of them should be removed at once (and
recursively) when the device is being removed ?

Individual drivers should never add groups/files in sysfs, the driver
core should do it properly for you if you have everything set up
properly.  And yes, the driver core will automatically remove them as
well.

Please use the default groups attribute for your bus/subsystem and this
will happen automagically.


Googling for default groups attributes i found this - 
https://www.linuxfoundation.org/blog/2013/06/how-to-create-a-sysfs-file-correctly/
Would this be what you suggest for us ? Specifically for our case the struct 
device's  groups  seems the right solution as different devices

might have slightly diffreent sysfs attributes.

Andrey




thanks,

greg k-h

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

Re: [PATCH v2 3/6] drm/bridge: mhdp8546: Add minimal format negotiation

2020-11-11 Thread Tomi Valkeinen

On 09/11/2020 19:05, Nikhil Devshatwar wrote:
> With new connector model, mhdp bridge will not create the connector and
> SoC driver will rely on format negotiation to setup the encoder format.
> 
> Support minimal format negotiations hooks in the drm_bridge_funcs.
> Complete format negotiation can be added based on EDID data.
> This patch adds the minimal required support to avoid failure
> after moving to new connector model.
> 
> Signed-off-by: Nikhil Devshatwar 
> ---
>  .../drm/bridge/cadence/cdns-mhdp8546-core.c   | 25 +++
>  1 file changed, 25 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c 
> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> index d0c65610ebb5..2cd809eed827 100644
> --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> @@ -2078,6 +2078,30 @@ cdns_mhdp_bridge_atomic_reset(struct drm_bridge 
> *bridge)
>   return _mhdp_state->base;
>  }
>  
> +static u32 *cdns_mhdp_get_input_bus_fmts(struct drm_bridge *bridge,
> +   struct drm_bridge_state *bridge_state,
> +   struct drm_crtc_state *crtc_state,
> +   struct drm_connector_state *conn_state,
> +   u32 output_fmt,
> +   unsigned int *num_input_fmts)
> +{
> + u32 *input_fmts;
> + u32 default_bus_format = MEDIA_BUS_FMT_RGB121212_1X36;
> +
> + *num_input_fmts = 0;
> +
> + if (output_fmt != MEDIA_BUS_FMT_FIXED)
> + return NULL;
> +
> + input_fmts = kzalloc(sizeof(*input_fmts), GFP_KERNEL);
> + if (!input_fmts)
> + return NULL;
> +
> + *num_input_fmts = 1;
> + input_fmts[0] = default_bus_format;
> + return input_fmts;
> +}
> +
>  static int cdns_mhdp_atomic_check(struct drm_bridge *bridge,
> struct drm_bridge_state *bridge_state,
> struct drm_crtc_state *crtc_state,
> @@ -2142,6 +2166,7 @@ static const struct drm_bridge_funcs 
> cdns_mhdp_bridge_funcs = {
>   .atomic_duplicate_state = cdns_mhdp_bridge_atomic_duplicate_state,
>   .atomic_destroy_state = cdns_mhdp_bridge_atomic_destroy_state,
>   .atomic_reset = cdns_mhdp_bridge_atomic_reset,
> + .atomic_get_input_bus_fmts = cdns_mhdp_get_input_bus_fmts,
>   .detect = cdns_mhdp_bridge_detect,
>   .get_edid = cdns_mhdp_bridge_get_edid,
>   .hpd_enable = cdns_mhdp_bridge_hpd_enable,
> 

Reviewed-by: Tomi Valkeinen 

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/6] drm/bridge: tfp410: Support format negotiation hooks

2020-11-11 Thread Tomi Valkeinen

On 09/11/2020 19:05, Nikhil Devshatwar wrote:
> With new connector model, tfp410 will not create the connector and
> SoC driver will rely on format negotiation to setup the encoder format.
> 
> Support format negotiations hooks in the drm_bridge_funcs.
> Use helper functions for state management.
> 
> Output format is expected to be MEDIA_BUS_FMT_FIXED
> Input format is the one selected by the bridge from DT properties.
> 
> Signed-off-by: Nikhil Devshatwar 
> ---
>  drivers/gpu/drm/bridge/ti-tfp410.c | 33 ++
>  1 file changed, 33 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c 
> b/drivers/gpu/drm/bridge/ti-tfp410.c
> index ba3fa2a9b8a4..f56dbe246e57 100644
> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -204,12 +204,45 @@ static enum drm_mode_status tfp410_mode_valid(struct 
> drm_bridge *bridge,
>   return MODE_OK;
>  }
>  
> +static u32 *tfp410_get_input_bus_fmts(struct drm_bridge *bridge,
> +   struct drm_bridge_state *bridge_state,
> +   struct drm_crtc_state *crtc_state,
> +   struct drm_connector_state *conn_state,
> +   u32 output_fmt,
> +   unsigned int *num_input_fmts)
> +{
> + struct tfp410 *dvi = drm_bridge_to_tfp410(bridge);
> + u32 *input_fmts;
> +
> + *num_input_fmts = 0;
> +
> + /*
> +  * Output of tfp410 is DVI, which is TMDS.
> +  * There is no media format defined for this
> +  * Using MEDIA_BUS_FMT_FIXED for now
> +  */

Please fix the missing punctiation marks.

Reviewed-by: Tomi Valkeinen 

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/6] drm: bridge: Propagate the bus flags from bridge->timings

2020-11-11 Thread Tomi Valkeinen

On 09/11/2020 19:05, Nikhil Devshatwar wrote:
> bus_flags can be specified by a bridge in the timings.
> If the bridge provides it, Override the bus_flags when propagating
> from next bridge.
> 
> Signed-off-by: Nikhil Devshatwar 
> ---
>  drivers/gpu/drm/drm_bridge.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 64f0effb52ac..2bbd6ffe82ce 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -975,6 +975,14 @@ drm_atomic_bridge_propagate_bus_flags(struct drm_bridge 
> *bridge,
>* duplicate the "dummy propagation" logic.
>*/
>   bridge_state->input_bus_cfg.flags = output_flags;
> +
> + /*
> +  * If the bus flags are provided in timing, use those even if the next
> +  * bridge specifies something
> +  */
> + if (bridge->timings && bridge->timings->input_bus_flags)
> + bridge_state->input_bus_cfg.flags =
> + bridge->timings->input_bus_flags;
>  }

I think the comment could be more clear. Maybe something like:

If legacy bus flags are provided in bridge->timings, use those as input flags 
instead of propagating
the output flags.

Other than that:

Reviewed-by: Tomi Valkeinen 

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal

2020-11-11 Thread Greg KH

On Wed, Nov 11, 2020 at 10:13:13AM -0500, Andrey Grodzovsky wrote:
> 
> On 11/10/20 12:59 PM, Greg KH wrote:
> > On Tue, Nov 10, 2020 at 12:54:21PM -0500, Andrey Grodzovsky wrote:
> > > Hi, back to this after a long context switch for some higher priority 
> > > stuff.
> > > 
> > > So here I was able eventually to drop all this code and this change here 
> > > https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.freedesktop.org%2F~agrodzov%2Flinux%2Fcommit%2F%3Fh%3Damd-staging-drm-next-device-unplug%26id%3D61852c8a59b4dd89d637693552c73175b9f2ccd6data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C7ae9e5798c7648d6dbb908d885a22c58%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637406278875513811%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=aoFIsBxpLC9tBZw3E%2B8IJlNqFSq6uRgEvvciaZ6B1iw%3Dreserved=0
> > > was enough for me. Seems like while device_remove_file can handle the use
> > > case where the file and the parent directory already gone,
> > > sysfs_remove_group goes down in flames in that case
> > > due to kobj->sd being unset on device removal.
> > A driver shouldn't ever have to remove individual sysfs groups, the
> > driver core/bus logic should do it for them automatically.
> > 
> > And whenever a driver calls a sysfs_* call, that's a hint that something
> > is not working properly.
> 
> 
> 
> Do you mean that while the driver creates the groups and files explicitly
> from it's different subsystems it should not explicitly remove each
> one of them because all of them should be removed at once (and
> recursively) when the device is being removed ?

Individual drivers should never add groups/files in sysfs, the driver
core should do it properly for you if you have everything set up
properly.  And yes, the driver core will automatically remove them as
well.

Please use the default groups attribute for your bus/subsystem and this
will happen automagically.

thanks,

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

Re: [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal

2020-11-11 Thread Andrey Grodzovsky




On 11/10/20 12:59 PM, Greg KH wrote:

On Tue, Nov 10, 2020 at 12:54:21PM -0500, Andrey Grodzovsky wrote:

Hi, back to this after a long context switch for some higher priority stuff.

So here I was able eventually to drop all this code and this change here 
https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.freedesktop.org%2F~agrodzov%2Flinux%2Fcommit%2F%3Fh%3Damd-staging-drm-next-device-unplug%26id%3D61852c8a59b4dd89d637693552c73175b9f2ccd6data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C7ae9e5798c7648d6dbb908d885a22c58%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637406278875513811%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=aoFIsBxpLC9tBZw3E%2B8IJlNqFSq6uRgEvvciaZ6B1iw%3Dreserved=0
was enough for me. Seems like while device_remove_file can handle the use
case where the file and the parent directory already gone,
sysfs_remove_group goes down in flames in that case
due to kobj->sd being unset on device removal.

A driver shouldn't ever have to remove individual sysfs groups, the
driver core/bus logic should do it for them automatically.

And whenever a driver calls a sysfs_* call, that's a hint that something
is not working properly.




Do you mean that while the driver creates the groups and files explicitly from 
it's different
subsystems it should not explicitly remove each one of them because all of them 
should

be removed at once (and recursively) when the device is being removed ?

Andrey




Also, run your patch above through checkpatch.pl before submitting it :)

thanks,

greg k-h

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

Re: [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema

2020-11-11 Thread Laurent Pinchart

Hi Rob,

On Wed, Nov 11, 2020 at 08:25:40AM -0600, Rob Herring wrote:
> On Wed, Nov 11, 2020 at 8:00 AM Laurent Pinchart wrote:
> > On Mon, Nov 02, 2020 at 02:36:54PM -0600, Rob Herring wrote:
> > > From: Sameer Pujar 
> > >
> > > Convert device tree bindings of graph to YAML format. Currently graph.txt
> > > doc is referenced in multiple files and all of these need to use schema
> > > references. For now graph.txt is updated to refer to graph.yaml.
> > >
> > > For users of the graph binding, they should reference to the graph
> > > schema from either 'ports' or 'port' property:
> > >
> > > properties:
> > >   ports:
> > > type: object
> > > $ref: graph.yaml#/properties/ports
> > >
> > > properties:
> > >   port@0:
> > > description: What data this port has
> > >
> > >   ...
> > >
> > > Or:
> > >
> > > properties:
> > >   port:
> > > description: What data this port has
> > > type: object
> > > $ref: graph.yaml#/properties/port
> >
> > Sounds like a good approach.
> >
> > > Signed-off-by: Sameer Pujar 
> > > Acked-by: Philipp Zabel 
> > > Signed-off-by: Rob Herring 
> > > ---
> > > v3:
> > >  - Move port 'reg' to port@* and make required
> > >  - Make remote-endpoint required
> > >  - Add 'additionalProperties: true' now required
> > >  - Fix yamllint warnings
> > >
> > >  Documentation/devicetree/bindings/graph.txt  | 129 +---
> > >  Documentation/devicetree/bindings/graph.yaml | 199 +++
> > >  2 files changed, 200 insertions(+), 128 deletions(-)
> > >  create mode 100644 Documentation/devicetree/bindings/graph.yaml
> 
> [...]
> 
> > > diff --git a/Documentation/devicetree/bindings/graph.yaml 
> > > b/Documentation/devicetree/bindings/graph.yaml
> > > new file mode 100644
> > > index ..b56720c5a13e
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/graph.yaml
> > > @@ -0,0 +1,199 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/graph.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Common bindings for device graphs
> > > +
> > > +description: |
> > > +  The hierarchical organisation of the device tree is well suited to 
> > > describe
> > > +  control flow to devices, but there can be more complex connections 
> > > between
> > > +  devices that work together to form a logical compound device, 
> > > following an
> > > +  arbitrarily complex graph.
> > > +  There already is a simple directed graph between devices tree nodes 
> > > using
> > > +  phandle properties pointing to other nodes to describe connections that
> > > +  can not be inferred from device tree parent-child relationships. The 
> > > device
> > > +  tree graph bindings described herein abstract more complex devices 
> > > that can
> > > +  have multiple specifiable ports, each of which can be linked to one or 
> > > more
> > > +  ports of other devices.
> > > +
> > > +  These common bindings do not contain any information about the 
> > > direction or
> > > +  type of the connections, they just map their existence. Specific 
> > > properties
> > > +  may be described by specialized bindings depending on the type of 
> > > connection.
> > > +
> > > +  To see how this binding applies to video pipelines, for example, see
> > > +  Documentation/devicetree/bindings/media/video-interfaces.txt.
> > > +  Here the ports describe data interfaces, and the links between them are
> > > +  the connecting data buses. A single port with multiple connections can
> > > +  correspond to multiple devices being connected to the same physical 
> > > bus.
> > > +
> > > +maintainers:
> > > +  - Philipp Zabel 
> > > +
> > > +select: false
> > > +
> > > +properties:
> > > +  port:
> > > +type: object
> > > +description:
> > > +  If there is more than one endpoint node or 'reg' property present 
> > > in
> > > +  endpoint nodes then '#address-cells' and '#size-cells' properties 
> > > are
> > > +  required.
> > > +
> > > +properties:
> > > +  "#address-cells":
> > > +const: 1
> > > +
> > > +  "#size-cells":
> > > +const: 0
> > > +
> > > +patternProperties:
> > > +  "^endpoint(@[0-9a-f]+)?$":
> > > +type: object
> > > +properties:
> > > +  reg:
> > > +maxItems: 1
> > > +
> > > +  remote-endpoint:
> > > +description: |
> > > +  phandle to an 'endpoint' subnode of a remote device node.
> > > +$ref: /schemas/types.yaml#/definitions/phandle
> > > +
> > > +required:
> > > +  - remote-endpoint
> >
> > As noted elsewhere, this shouldn't be required.
> >
> > Should we set additionalProperties: false here ?
> 
> No, we've got a bunch of properties that get added to endpoint nodes.
> There's a few cases where 'port' nodes have properties too.

I meant the port node, which I wasn't aware needed additional

Re: [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema

2020-11-11 Thread Rob Herring

On Wed, Nov 11, 2020 at 8:00 AM Laurent Pinchart
 wrote:
>
> Hi Rob and Sameer,
>
> Thank you for the patch.
>
> On Mon, Nov 02, 2020 at 02:36:54PM -0600, Rob Herring wrote:
> > From: Sameer Pujar 
> >
> > Convert device tree bindings of graph to YAML format. Currently graph.txt
> > doc is referenced in multiple files and all of these need to use schema
> > references. For now graph.txt is updated to refer to graph.yaml.
> >
> > For users of the graph binding, they should reference to the graph
> > schema from either 'ports' or 'port' property:
> >
> > properties:
> >   ports:
> > type: object
> > $ref: graph.yaml#/properties/ports
> >
> > properties:
> >   port@0:
> > description: What data this port has
> >
> >   ...
> >
> > Or:
> >
> > properties:
> >   port:
> > description: What data this port has
> > type: object
> > $ref: graph.yaml#/properties/port
>
> Sounds like a good approach.
>
> > Signed-off-by: Sameer Pujar 
> > Acked-by: Philipp Zabel 
> > Signed-off-by: Rob Herring 
> > ---
> > v3:
> >  - Move port 'reg' to port@* and make required
> >  - Make remote-endpoint required
> >  - Add 'additionalProperties: true' now required
> >  - Fix yamllint warnings
> >
> >  Documentation/devicetree/bindings/graph.txt  | 129 +---
> >  Documentation/devicetree/bindings/graph.yaml | 199 +++
> >  2 files changed, 200 insertions(+), 128 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/graph.yaml

[...]

> > diff --git a/Documentation/devicetree/bindings/graph.yaml 
> > b/Documentation/devicetree/bindings/graph.yaml
> > new file mode 100644
> > index ..b56720c5a13e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/graph.yaml
> > @@ -0,0 +1,199 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/graph.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Common bindings for device graphs
> > +
> > +description: |
> > +  The hierarchical organisation of the device tree is well suited to 
> > describe
> > +  control flow to devices, but there can be more complex connections 
> > between
> > +  devices that work together to form a logical compound device, following 
> > an
> > +  arbitrarily complex graph.
> > +  There already is a simple directed graph between devices tree nodes using
> > +  phandle properties pointing to other nodes to describe connections that
> > +  can not be inferred from device tree parent-child relationships. The 
> > device
> > +  tree graph bindings described herein abstract more complex devices that 
> > can
> > +  have multiple specifiable ports, each of which can be linked to one or 
> > more
> > +  ports of other devices.
> > +
> > +  These common bindings do not contain any information about the direction 
> > or
> > +  type of the connections, they just map their existence. Specific 
> > properties
> > +  may be described by specialized bindings depending on the type of 
> > connection.
> > +
> > +  To see how this binding applies to video pipelines, for example, see
> > +  Documentation/devicetree/bindings/media/video-interfaces.txt.
> > +  Here the ports describe data interfaces, and the links between them are
> > +  the connecting data buses. A single port with multiple connections can
> > +  correspond to multiple devices being connected to the same physical bus.
> > +
> > +maintainers:
> > +  - Philipp Zabel 
> > +
> > +select: false
> > +
> > +properties:
> > +  port:
> > +type: object
> > +description:
> > +  If there is more than one endpoint node or 'reg' property present in
> > +  endpoint nodes then '#address-cells' and '#size-cells' properties are
> > +  required.
> > +
> > +properties:
> > +  "#address-cells":
> > +const: 1
> > +
> > +  "#size-cells":
> > +const: 0
> > +
> > +patternProperties:
> > +  "^endpoint(@[0-9a-f]+)?$":
> > +type: object
> > +properties:
> > +  reg:
> > +maxItems: 1
> > +
> > +  remote-endpoint:
> > +description: |
> > +  phandle to an 'endpoint' subnode of a remote device node.
> > +$ref: /schemas/types.yaml#/definitions/phandle
> > +
> > +required:
> > +  - remote-endpoint
>
> As noted elsewhere, this shouldn't be required.
>
> Should we set additionalProperties: false here ?

No, we've got a bunch of properties that get added to endpoint nodes.
There's a few cases where 'port' nodes have properties too.

> > +  ports:
> > +type: object
> > +description: |
> > +  If there is more than one port node or 'reg' property present in port
> > +  nodes then '#address-cells' and '#size-cells' properties are 
> > required.
> > +  In such cases all port nodes can be grouped under 'ports' 
> > independently
> > +  from any other child device nodes a device might have.

Re: [PATCH 2/2] drm/mediatek: Use struct dma_buf_map in GEM vmap ops

2020-11-11 Thread Chun-Kuang Hu

Hi, Thomas:

Thomas Zimmermann  於 2020年11月9日 週一 下午6:32寫道：
>
> Fixes a build failure with mediatek.
>
> This change was supposed to be part of commit 49a3f51dfeee ("drm/gem:
> Use struct dma_buf_map in GEM vmap ops and convert GEM backends"), but
> mediatek was forgotten.

Acked-by: Chun-Kuang Hu 

>
> Signed-off-by: Thomas Zimmermann 
> Fixes: 49a3f51dfeee ("drm/gem: Use struct dma_buf_map in GEM vmap ops and 
> convert GEM backends")
> Cc: Thomas Zimmermann 
> Cc: Christian König 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Dave Airlie 
> Cc: Lucas Stach 
> Cc: Russell King 
> Cc: Christian Gmeiner 
> Cc: Qiang Yu 
> Cc: Ben Skeggs 
> Cc: Rob Herring 
> Cc: Tomeu Vizoso 
> Cc: Steven Price 
> Cc: Alyssa Rosenzweig 
> Cc: Gerd Hoffmann 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: Sandy Huang 
> Cc: "Heiko Stübner" 
> Cc: Hans de Goede 
> Cc: Sean Paul 
> Cc: Eric Anholt 
> Cc: Rodrigo Siqueira 
> Cc: Melissa Wen 
> Cc: Haneen Mohammed 
> Cc: Oleksandr Andrushchenko 
> Cc: Sumit Semwal 
> Cc: Emil Velikov 
> Cc: Marek Szyprowski 
> Cc: Arunpravin 
> Cc: Huang Rui 
> Cc: Luben Tuikov 
> Cc: Madhav Chauhan 
> Cc: Nirmoy Das 
> Cc: Jason Gunthorpe 
> Cc: Sam Ravnborg 
> Cc: Chris Wilson 
> Cc: dri-devel@lists.freedesktop.org
> Cc: etna...@lists.freedesktop.org
> Cc: l...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: spice-de...@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: xen-de...@lists.xenproject.org
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_gem.c | 20 
>  drivers/gpu/drm/mediatek/mtk_drm_gem.h |  4 ++--
>  2 files changed, 14 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> index cdd1a6e61564..28a2ee1336ef 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> @@ -240,23 +240,25 @@ struct drm_gem_object 
> *mtk_gem_prime_import_sg_table(struct drm_device *dev,
> return _gem->base;
>  }
>
> -void *mtk_drm_gem_prime_vmap(struct drm_gem_object *obj)
> +int mtk_drm_gem_prime_vmap(struct drm_gem_object *obj, struct dma_buf_map 
> *map)
>  {
> struct mtk_drm_gem_obj *mtk_gem = to_mtk_gem_obj(obj);
> -   struct sg_table *sgt;
> +   struct sg_table *sgt = NULL;
> unsigned int npages;
>
> if (mtk_gem->kvaddr)
> -   return mtk_gem->kvaddr;
> +   goto out;
>
> sgt = mtk_gem_prime_get_sg_table(obj);
> if (IS_ERR(sgt))
> -   return NULL;
> +   return PTR_ERR(sgt);
>
> npages = obj->size >> PAGE_SHIFT;
> mtk_gem->pages = kcalloc(npages, sizeof(*mtk_gem->pages), GFP_KERNEL);
> -   if (!mtk_gem->pages)
> -   goto out;
> +   if (!mtk_gem->pages) {
> +   kfree(sgt);
> +   return -ENOMEM;
> +   }
>
> drm_prime_sg_to_page_addr_arrays(sgt, mtk_gem->pages, NULL, npages);
>
> @@ -265,13 +267,15 @@ void *mtk_drm_gem_prime_vmap(struct drm_gem_object *obj)
>
>  out:
> kfree(sgt);
> +   dma_buf_map_set_vaddr(map, mtk_gem->kvaddr);
>
> -   return mtk_gem->kvaddr;
> +   return 0;
>  }
>
> -void mtk_drm_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
> +void mtk_drm_gem_prime_vunmap(struct drm_gem_object *obj, struct dma_buf_map 
> *map)
>  {
> struct mtk_drm_gem_obj *mtk_gem = to_mtk_gem_obj(obj);
> +   void *vaddr = map->vaddr;
>
> if (!mtk_gem->pages)
> return;
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.h 
> b/drivers/gpu/drm/mediatek/mtk_drm_gem.h
> index ff9f976d9807..6da5ccb4b933 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_gem.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.h
> @@ -45,7 +45,7 @@ int mtk_drm_gem_mmap_buf(struct drm_gem_object *obj,
>  struct sg_table *mtk_gem_prime_get_sg_table(struct drm_gem_object *obj);
>  struct drm_gem_object *mtk_gem_prime_import_sg_table(struct drm_device *dev,
> struct dma_buf_attachment *attach, struct sg_table 
> *sg);
> -void *mtk_drm_gem_prime_vmap(struct drm_gem_object *obj);
> -void mtk_drm_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
> +int mtk_drm_gem_prime_vmap(struct drm_gem_object *obj, struct dma_buf_map 
> *map);
> +void mtk_drm_gem_prime_vunmap(struct drm_gem_object *obj, struct dma_buf_map 
> *map);
>
>  #endif
> --
> 2.29.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel

2020-11-11 Thread Tomi Valkeinen

On 11/11/2020 09:48, H. Nikolaus Schaller wrote:
> 
>> Am 11.11.2020 um 07:40 schrieb Tomi Valkeinen :
>>
>> On 10/11/2020 23:04, H. Nikolaus Schaller wrote:
>>>
 Am 10.11.2020 um 17:52 schrieb Tomi Valkeinen :

 On 10/11/2020 18:49, H. Nikolaus Schaller wrote:

 I guess you have the same issue. It goes to dsi_bridge_mode_valid, then 
 __dsi_calc_config, and stays
 there finding good clocks.
>>>
>>
>> drm_display_mode.clock is in kHz, but the panel driver writes Hz 
>> (w677l_PIXELCLOCK) to it.
> 
> Ok, fixing this removes the stuck thread issue. Thanks for pointing this out!
> 
>> But
>> there's more after fixing that. The DSI gets configured in bridge's modeset, 
>> which I think is before
>> w677l_prepare where the panel already sends DSI commands. Also, the dsi 
>> driver fails to lock the
>> PLL, so possibly the clock calcs are still wrong.
> 
> What I now get is
> 
> [  131.035006] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] 
> *ERROR* [CRTC:55:crtc-0] flip_done timed out
> [  141.272174] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] 
> *ERROR* [CONNECTOR:54:DSI-1] flip_done timed out
> 
> I think for further experiments we could hack the device tree to compatible = 
> "orisetech,otm8009a";
> and configure for panel-orisetech-otm8009a.ko. Since this panel driver is 
> known to work elsewhere
> we could exclude panel driver issues for the moment. To be safe we can modify 
> otm8009a_dcs_write_buf()
> to just print what it would be doing.

I pushed some quick fixes/hacks to:

git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git 5.11/dsi

At least I get the DSI PLL configured, and kmstest --flip works with 60 fps.
I'm pretty sure the panel won't work yet, though.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 3/3] dt-bindings: panel: common: Add reference to graph schema

2020-11-11 Thread Laurent Pinchart

Hi Rob,

Thank you for the patch.

On Mon, Nov 02, 2020 at 02:36:56PM -0600, Rob Herring wrote:
> Now that we have a graph schema, reference it from the common panel
> schema.
> 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> Cc: Laurent Pinchart 
> Signed-off-by: Rob Herring 

Reviewed-by: Laurent Pinchart 

> ---
> v3: new patch
> 
>  .../devicetree/bindings/display/panel/panel-common.yaml| 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/panel-common.yaml 
> b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> index cd6dc5461721..a3a72c574213 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> @@ -68,16 +68,15 @@ properties:
> 
># Connectivity
>port:
> -type: object
> +$ref: /schemas/graph.yaml#/properties/port
> 
>ports:
> -type: object
> +$ref: /schemas/graph.yaml#/properties/ports
>  description:
>Panels receive video data through one or multiple connections. While
>the nature of those connections is specific to the panel type, the
>connectivity is expressed in a standard fashion using ports as 
> specified
> -  in the device graph bindings defined in
> -  Documentation/devicetree/bindings/graph.txt.
> +  in the device graph bindings.
> 
>ddc-i2c-bus:
>  $ref: /schemas/types.yaml#/definitions/phandle

-- 
Regards,

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

Re: [PATCH v3 2/3] dt-bindings: usb-connector: Add reference to graph schema

2020-11-11 Thread Laurent Pinchart

Hi Rob,

Thank you for the patch.

On Mon, Nov 02, 2020 at 02:36:55PM -0600, Rob Herring wrote:
> Now that we have a graph schema, reference it from the usb-connector
> schema.
> 
> Signed-off-by: Rob Herring 

Reviewed-by: Laurent Pinchart 

> ---
> v3: new patch
> 
>  .../devicetree/bindings/connector/usb-connector.yaml   | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml 
> b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> index 728f82db073d..64f2e1246ddb 100644
> --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> @@ -125,11 +125,13 @@ properties:
>power dual role.
> 
>ports:
> -description: OF graph bindings (specified in bindings/graph.txt) that 
> model
> -  any data bus to the connector unless the bus is between parent node and
> -  the connector. Since a single connector can have multiple data buses 
> every
> -  bus has an assigned OF graph port number as described below.
> +$ref: /schemas/graph.yaml#/properties/ports
>  type: object
> +description: OF graph bindings modeling any data bus to the connector
> +  unless the bus is between parent node and the connector. Since a single
> +  connector can have multiple data buses every bus has an assigned OF 
> graph
> +  port number as described below.
> +
>  properties:
>port@0:
>  type: object

-- 
Regards,

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

Re: [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema

2020-11-11 Thread Laurent Pinchart

Hi Rob and Sameer,

Thank you for the patch.

On Mon, Nov 02, 2020 at 02:36:54PM -0600, Rob Herring wrote:
> From: Sameer Pujar 
> 
> Convert device tree bindings of graph to YAML format. Currently graph.txt
> doc is referenced in multiple files and all of these need to use schema
> references. For now graph.txt is updated to refer to graph.yaml.
> 
> For users of the graph binding, they should reference to the graph
> schema from either 'ports' or 'port' property:
> 
> properties:
>   ports:
> type: object
> $ref: graph.yaml#/properties/ports
> 
> properties:
>   port@0:
> description: What data this port has
> 
>   ...
> 
> Or:
> 
> properties:
>   port:
> description: What data this port has
> type: object
> $ref: graph.yaml#/properties/port

Sounds like a good approach.

> Signed-off-by: Sameer Pujar 
> Acked-by: Philipp Zabel 
> Signed-off-by: Rob Herring 
> ---
> v3:
>  - Move port 'reg' to port@* and make required
>  - Make remote-endpoint required
>  - Add 'additionalProperties: true' now required
>  - Fix yamllint warnings
> 
>  Documentation/devicetree/bindings/graph.txt  | 129 +---
>  Documentation/devicetree/bindings/graph.yaml | 199 +++
>  2 files changed, 200 insertions(+), 128 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/graph.yaml
> 
> diff --git a/Documentation/devicetree/bindings/graph.txt 
> b/Documentation/devicetree/bindings/graph.txt
> index 0415e2c53ba0..b7818d61cef7 100644
> --- a/Documentation/devicetree/bindings/graph.txt
> +++ b/Documentation/devicetree/bindings/graph.txt
> @@ -1,128 +1 @@
> -Common bindings for device graphs
> -
> -General concept
> 
> -
> -The hierarchical organisation of the device tree is well suited to describe
> -control flow to devices, but there can be more complex connections between
> -devices that work together to form a logical compound device, following an
> -arbitrarily complex graph.
> -There already is a simple directed graph between devices tree nodes using
> -phandle properties pointing to other nodes to describe connections that
> -can not be inferred from device tree parent-child relationships. The device
> -tree graph bindings described herein abstract more complex devices that can
> -have multiple specifiable ports, each of which can be linked to one or more
> -ports of other devices.
> -
> -These common bindings do not contain any information about the direction or
> -type of the connections, they just map their existence. Specific properties
> -may be described by specialized bindings depending on the type of connection.
> -
> -To see how this binding applies to video pipelines, for example, see
> -Documentation/devicetree/bindings/media/video-interfaces.txt.
> -Here the ports describe data interfaces, and the links between them are
> -the connecting data buses. A single port with multiple connections can
> -correspond to multiple devices being connected to the same physical bus.
> -
> -Organisation of ports and endpoints
> 
> -
> -Ports are described by child 'port' nodes contained in the device node.
> -Each port node contains an 'endpoint' subnode for each remote device port
> -connected to this port. If a single port is connected to more than one
> -remote device, an 'endpoint' child node must be provided for each link.
> -If more than one port is present in a device node or there is more than one
> -endpoint at a port, or a port node needs to be associated with a selected
> -hardware interface, a common scheme using '#address-cells', '#size-cells'
> -and 'reg' properties is used to number the nodes.
> -
> -device {
> -...
> -#address-cells = <1>;
> -#size-cells = <0>;
> -
> -port@0 {
> - #address-cells = <1>;
> - #size-cells = <0>;
> - reg = <0>;
> -
> -endpoint@0 {
> - reg = <0>;
> - ...
> - };
> -endpoint@1 {
> - reg = <1>;
> - ...
> - };
> -};
> -
> -port@1 {
> - reg = <1>;
> -
> - endpoint { ... };
> - };
> -};
> -
> -All 'port' nodes can be grouped under an optional 'ports' node, which
> -allows to specify #address-cells, #size-cells properties for the 'port'
> -nodes independently from any other child device nodes a device might
> -have.
> -
> -device {
> -...
> -ports {
> -#address-cells = <1>;
> -#size-cells = <0>;
> -
> -port@0 {
> -...
> -endpoint@0 { ... };
> -endpoint@1 { ... };
> -};
> -
> -port@1 { ... };
> -};
> -};
> -
> -Links between endpoints
> 
> -
> -Each endpoint should contain a 'remote-endpoint' phandle property that points
> -to the

Re: [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema

2020-11-11 Thread Rob Herring

On Wed, Nov 11, 2020 at 3:52 AM Sameer Pujar  wrote:
>
> Hi Rob,
>
> > From: Sameer Pujar 
> >
> > Convert device tree bindings of graph to YAML format. Currently graph.txt
> > doc is referenced in multiple files and all of these need to use schema
> > references. For now graph.txt is updated to refer to graph.yaml.
> >
> > For users of the graph binding, they should reference to the graph
> > schema from either 'ports' or 'port' property:
> >
> > properties:
> >ports:
> >  type: object
> >  $ref: graph.yaml#/properties/ports
> >
> >  properties:
> >port@0:
> >  description: What data this port has
> >
> >...
> >
> > Or:
> >
> > properties:
> >port:
> >  description: What data this port has
> >  type: object
> >  $ref: graph.yaml#/properties/port
> >
> > Signed-off-by: Sameer Pujar 
> > Acked-by: Philipp Zabel 
> > Signed-off-by: Rob Herring 
> > ---
> > v3:
> >   - Move port 'reg' to port@* and make required
> >   - Make remote-endpoint required
> >   - Add 'additionalProperties: true' now required
> >   - Fix yamllint warnings
> >
> >   Documentation/devicetree/bindings/graph.txt  | 129 +---
> >   Documentation/devicetree/bindings/graph.yaml | 199 +++
> >   2 files changed, 200 insertions(+), 128 deletions(-)
> >   create mode 100644 Documentation/devicetree/bindings/graph.yaml
> >
> ...
> > diff --git a/Documentation/devicetree/bindings/graph.yaml 
> > b/Documentation/devicetree/bindings/graph.yaml
> > new file mode 100644
> > index ..b56720c5a13e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/graph.yaml
> > @@ -0,0 +1,199 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/graph.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Common bindings for device graphs
> > +
> > +description: |
> > +  The hierarchical organisation of the device tree is well suited to 
> > describe
> > +  control flow to devices, but there can be more complex connections 
> > between
> > +  devices that work together to form a logical compound device, following 
> > an
> > +  arbitrarily complex graph.
> > +  There already is a simple directed graph between devices tree nodes using
> > +  phandle properties pointing to other nodes to describe connections that
> > +  can not be inferred from device tree parent-child relationships. The 
> > device
> > +  tree graph bindings described herein abstract more complex devices that 
> > can
> > +  have multiple specifiable ports, each of which can be linked to one or 
> > more
> > +  ports of other devices.
> > +
> > +  These common bindings do not contain any information about the direction 
> > or
> > +  type of the connections, they just map their existence. Specific 
> > properties
> > +  may be described by specialized bindings depending on the type of 
> > connection.
> > +
> > +  To see how this binding applies to video pipelines, for example, see
> > +  Documentation/devicetree/bindings/media/video-interfaces.txt.
> > +  Here the ports describe data interfaces, and the links between them are
> > +  the connecting data buses. A single port with multiple connections can
> > +  correspond to multiple devices being connected to the same physical bus.
> > +
> > +maintainers:
> > +  - Philipp Zabel 
> > +
> > +select: false
> > +
> > +properties:
> > +  port:
> > +type: object
> > +description:
> > +  If there is more than one endpoint node or 'reg' property present in
> > +  endpoint nodes then '#address-cells' and '#size-cells' properties are
> > +  required.
> > +
> > +properties:
> > +  "#address-cells":
> > +const: 1
> > +
> > +  "#size-cells":
> > +const: 0
> > +
> > +patternProperties:
> > +  "^endpoint(@[0-9a-f]+)?$":
> > +type: object
> > +properties:
> > +  reg:
> > +maxItems: 1
> > +
> > +  remote-endpoint:
> > +description: |
> > +  phandle to an 'endpoint' subnode of a remote device node.
> > +$ref: /schemas/types.yaml#/definitions/phandle
> > +
> > +required:
> > +  - remote-endpoint
>
> Does 'remote-endpoint' have to be a required property?
> In case of pluggable modules, the remote-endpoint may not be available
> unless the module is plugged in. In other words, device-2 in below
> example may not always be available, but still device-1 endpoint
> configuration and usage may be required?

No, I've dropped it. I noticed the same thing converting some of the
schema over to use this.

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

[PATCH v2] dt-bindings: display: mcde: Convert to YAML schema

2020-11-11 Thread Linus Walleij

This moves the MCDE bindings over to using the YAML schema
to describe the ST-Ericsson MCDE display controller,
making use of the generic DSI controller schema.

We also add the "port" node, we will use this when adding
LCD panels using the direct parallel interface DPI instead
of DSI.

Cc: devicet...@vger.kernel.org
Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Cut the description on the interrupts.
- Drop maxItems: 3 on clocks and clock-names: implicit from
  the number of listed items.
- Tag the DSI ports with unevaluatedProperties: false
- Tag the MCDE as such with additionalProperties: true
- It was a bit hard to test this because of the code base
  being out of phase with the validation tools but it seems
  to check out.
---
 .../devicetree/bindings/display/ste,mcde.txt  | 104 ---
 .../devicetree/bindings/display/ste,mcde.yaml | 166 ++
 2 files changed, 166 insertions(+), 104 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/display/ste,mcde.txt
 create mode 100644 Documentation/devicetree/bindings/display/ste,mcde.yaml

diff --git a/Documentation/devicetree/bindings/display/ste,mcde.txt 
b/Documentation/devicetree/bindings/display/ste,mcde.txt
deleted file mode 100644
index 4c33c692bd5f..
--- a/Documentation/devicetree/bindings/display/ste,mcde.txt
+++ /dev/null
@@ -1,104 +0,0 @@
-ST-Ericsson Multi Channel Display Engine MCDE
-
-The ST-Ericsson MCDE is a display controller with support for compositing
-and displaying several channels memory resident graphics data on DSI or
-LCD displays or bridges. It is used in the ST-Ericsson U8500 platform.
-
-Required properties:
-
-- compatible: must be:
-  "ste,mcde"
-- reg: register base for the main MCDE control registers, should be
-  0x1000 in size
-- interrupts: the interrupt line for the MCDE
-- epod-supply: a phandle to the EPOD regulator
-- vana-supply: a phandle to the analog voltage regulator
-- clocks: an array of the MCDE clocks in this strict order:
-  MCDECLK (main MCDE clock), LCDCLK (LCD clock), PLLDSI
-  (HDMI clock), DSI0ESCLK (DSI0 energy save clock),
-  DSI1ESCLK (DSI1 energy save clock), DSI2ESCLK (DSI2 energy
-  save clock)
-- clock-names: must be the following array:
-  "mcde", "lcd", "hdmi"
-  to match the required clock inputs above.
-- #address-cells: should be <1> (for the DSI hosts that will be children)
-- #size-cells: should be <1> (for the DSI hosts that will be children)
-- ranges: this should always be stated
-
-Required subnodes:
-
-The devicetree must specify subnodes for the DSI host adapters.
-These must have the following characteristics:
-
-- compatible: must be:
-  "ste,mcde-dsi"
-- reg: must specify the register range for the DSI host
-- vana-supply: phandle to the VANA voltage regulator
-- clocks: phandles to the high speed and low power (energy save) clocks
-  the high speed clock is not present on the third (dsi2) block, so it
-  should only have the "lp" clock
-- clock-names: "hs" for the high speed clock and "lp" for the low power
-  (energy save) clock
-- #address-cells: should be <1>
-- #size-cells: should be <0>
-
-Display panels and bridges will appear as children on the DSI hosts, and
-the displays are connected to the DSI hosts using the common binding
-for video transmitter interfaces; see
-Documentation/devicetree/bindings/media/video-interfaces.txt
-
-If a DSI host is unused (not connected) it will have no children defined.
-
-Example:
-
-mcde@a035 {
-   compatible = "ste,mcde";
-   reg = <0xa035 0x1000>;
-   interrupts = ;
-   epod-supply = <_b2r2_mcde_reg>;
-   vana-supply = <_ldo_ana_reg>;
-   clocks = <_clk PRCMU_MCDECLK>, /* Main MCDE clock */
-<_clk PRCMU_LCDCLK>, /* LCD clock */
-<_clk PRCMU_PLLDSI>; /* HDMI clock */
-   clock-names = "mcde", "lcd", "hdmi";
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges;
-
-   dsi0: dsi@a0351000 {
-   compatible = "ste,mcde-dsi";
-   reg = <0xa0351000 0x1000>;
-   vana-supply = <_ldo_ana_reg>;
-   clocks = <_clk PRCMU_DSI0CLK>, <_clk 
PRCMU_DSI0ESCCLK>;
-   clock-names = "hs", "lp";
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   panel {
-   compatible = "samsung,s6d16d0";
-   reg = <0>;
-   vdd1-supply = <_ldo_aux1_reg>;
-   reset-gpios = < 1 GPIO_ACTIVE_LOW>;
-   };
-
-   };
-   dsi1: dsi@a0352000 {
-   compatible = "ste,mcde-dsi";
-   reg = <0xa0352000 0x1000>;
-   vana-supply = <_ldo_ana_reg>;
-   clocks = <_clk PRCMU_DSI1CLK>, <_clk 
PRCMU_DSI1ESCCLK>;
-   clock-names = "hs", "lp";
-   #address-cells = <1>;
-   #size-cells = <0>;
-   };
-   dsi2: dsi@a0353000 {
-   compatible = "ste,mcde-dsi";
-

Re: [PATCH] drm: rcar-du: Fix the return check of of_parse_phandle and of_find_device_by_node

2020-11-11 Thread Kieran Bingham

Hi Wang Xiaojun,

On 11/11/2020 03:14, Wang Xiaojun wrote:
> of_parse_phandle and of_find_device_by_node may return NULL
> which cannot be checked by IS_ERR.

Indeed, both of these functions return either NULL or the correct value,
and no an errno.

> 
> Signed-off-by: Wang Xiaojun 
> Reported-by: Hulk Robot 

Fixes: 8de707aeb452 ("drm: rcar-du: kms: Initialize CMM instances")

Reviewed-by: Kieran Bingham 

> ---
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 72dda446355f..fcfddf7ad3f3 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -700,10 +700,10 @@ static int rcar_du_cmm_init(struct rcar_du_device *rcdu)
>   int ret;
>  
>   cmm = of_parse_phandle(np, "renesas,cmms", i);
> - if (IS_ERR(cmm)) {
> + if (!cmm) {
>   dev_err(rcdu->dev,
>   "Failed to parse 'renesas,cmms' property\n");
> - return PTR_ERR(cmm);
> + return -ENODEV;
>   }
>  
>   if (!of_device_is_available(cmm)) {
> @@ -713,10 +713,10 @@ static int rcar_du_cmm_init(struct rcar_du_device *rcdu)
>   }
>  
>   pdev = of_find_device_by_node(cmm);
> - if (IS_ERR(pdev)) {
> + if (!pdev) {
>   dev_err(rcdu->dev, "No device found for CMM%u\n", i);
>   of_node_put(cmm);
> - return PTR_ERR(pdev);
> + return -ENODEV;
>   }
>  
>   of_node_put(cmm);
> 

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

Re: linux-next: build failure after merge of the drm-misc tree

2020-11-11 Thread Michael S. Tsirkin

On Wed, Nov 11, 2020 at 05:10:15PM +1100, Stephen Rothwell wrote:
> Hi Michael,
> 
> On Mon, 2 Nov 2020 05:19:06 -0500 "Michael S. Tsirkin"  
> wrote:
> >
> > On Mon, Nov 02, 2020 at 12:43:27PM +1100, Stephen Rothwell wrote:
> > > 
> > > After merging the drm-misc tree, today's linux-next build (arm
> > > multi_v7_defconfig) failed like this:
> > > 
> > > In file included from drivers/gpu/drm/nouveau/nouveau_ttm.c:26:
> > > include/linux/swiotlb.h: In function 'swiotlb_max_mapping_size':
> > > include/linux/swiotlb.h:99:9: error: 'SIZE_MAX' undeclared (first use in 
> > > this function)
> > >99 |  return SIZE_MAX;
> > >   | ^~~~
> > > include/linux/swiotlb.h:7:1: note: 'SIZE_MAX' is defined in header 
> > > ''; did you forget to '#include '?
> > > 6 | #include 
> > >   +++ |+#include 
> > > 7 | #include 
> > > include/linux/swiotlb.h:99:9: note: each undeclared identifier is 
> > > reported only once for each function it appears in
> > >99 |  return SIZE_MAX;
> > >   | ^~~~
> > > 
> > > Caused by commit
> > > 
> > >   abe420bfae52 ("swiotlb: Introduce swiotlb_max_mapping_size()")
> > > 
> > > but only exposed by commit
> > > 
> > >   4dbafbd30aef ("drm/nouveu: fix swiotlb include")
> > > 
> > > I applied the following fix for today:
> > > 
> > > From: Stephen Rothwell 
> > > Date: Mon, 2 Nov 2020 12:34:57 +1100
> > > Subject: [PATCH] swiotlb: using SIZE_MAX needs limits.h included
> > > 
> > > Fixes: abe420bfae52 ("swiotlb: Introduce swiotlb_max_mapping_size()")
> > > Signed-off-by: Stephen Rothwell   
> > 
> > Acked-by: Michael S. Tsirkin 
> > 
> > I guess it makes sense to pick this up for this release directly.
> > I'll merge this unless there are any objections.
> 
> Christoph is right that the include should not be conditional.  But I
> have not tested that that does not introduce some other problems.

If there's a problem it will be a build failure - I'll put
it in next for a while, this way we'll find out.

> -- 
> Cheers,
> Stephen Rothwell


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

Re: [PATCH] drm/nouveau: Fix out-of-bounds access when deferencing MMU type

2020-11-11 Thread Thomas Zimmermann

Hi

Am 10.11.20 um 16:27 schrieb Ruhl, Michael J:
> 
> 
>> -Original Message-
>> From: Thomas Zimmermann 
>> Sent: Tuesday, November 10, 2020 8:37 AM
>> To: bske...@redhat.com; airl...@linux.ie; dan...@ffwll.ch; Ruhl, Michael J
>> ; christian.koe...@amd.com
>> Cc: nouv...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Thomas
>> Zimmermann ; Maarten Lankhorst
>> ; Maxime Ripard
>> ; Dave Airlie ; Gerd Hoffmann
>> ; Alex Deucher ;
>> VMware Graphics ; Roland
>> Scheidegger ; Huang Rui ;
>> Felix Kuehling ; Hawking Zhang
>> ; Jason Gunthorpe ; Likun Gao
>> ; virtualizat...@lists.linux-foundation.org; spice-
>> de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
>> Subject: [PATCH] drm/nouveau: Fix out-of-bounds access when deferencing
>> MMU type
>>
>> The value of struct drm_device.ttm.type_vram can become -1 for unknown
>> types of memory (see nouveau_ttm_init()). This leads to an out-of-bounds
>> error when accessing struct nvif_mmu.type[]:
> 
> Would this make more sense to just set the type_vram = 0 instead of -1?

From what I understand, these indices refer to an internal type of MMU,
rsp the MMU's capabilities. However, my hardware (pre-NV50) does not
have an MMU at all.

I agree that it would be nice to have a cleaner design that incorporates
this case, but resolving that would apparently require more than a bugfix.

Best regards
Thomas

> 
> Mike
> 
>>
>>  [   18.304116]
>> ===
>> ===
>>  [   18.311649] BUG: KASAN: slab-out-of-bounds in
>> nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
>>  [   18.320415] Read of size 1 at addr 88810ffac1fe by task systemd-
>> udevd/342
>>  [   18.327681]
>>  [   18.329208] CPU: 1 PID: 342 Comm: systemd-udevd Tainted: GE
>> 5.10.0-rc2-1-default+ #581
>>  [   18.338681] Hardware name: Dell Inc. OptiPlex 9020/0N4YC8, BIOS A24
>> 10/24/2018
>>  [   18.346032] Call Trace:
>>  [   18.348536]  dump_stack+0xae/0xe5
>>  [   18.351919]  print_address_description.constprop.0+0x17/0xf0
>>  [   18.357787]  ? nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
>>  [   18.363818]  __kasan_report.cold+0x20/0x38
>>  [   18.368099]  ? nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
>>  [   18.374133]  kasan_report+0x3a/0x50
>>  [   18.377789]  nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
>>  <...>
>>  [   18.767690] Allocated by task 342:
>>  [   18.773087]  kasan_save_stack+0x1b/0x40
>>  [   18.778890]  __kasan_kmalloc.constprop.0+0xbf/0xd0
>>  [   18.785646]  __kmalloc_track_caller+0x1be/0x390
>>  [   18.792165]  kstrdup_const+0x46/0x70
>>  [   18.797686]  kobject_set_name_vargs+0x2f/0xb0
>>  [   18.803992]  kobject_init_and_add+0x9d/0xf0
>>  [   18.810117]  ttm_mem_global_init+0x12c/0x210 [ttm]
>>  [   18.816853]  ttm_bo_global_init+0x4a/0x160 [ttm]
>>  [   18.823420]  ttm_bo_device_init+0x39/0x220 [ttm]
>>  [   18.830046]  nouveau_ttm_init+0x2c3/0x830 [nouveau]
>>  [   18.836929]  nouveau_drm_device_init+0x1b4/0x3f0 [nouveau]
>>  <...>
>>  [   19.105336]
>> ===
>> ===
>>
>> Fix this error, by not using type_vram as an index if it's negative.
>> Assume default values instead.
>>
>> The error was seen on Nvidia G72 hardware.
>>
>> Signed-off-by: Thomas Zimmermann 
>> Fixes: 1cf65c45183a ("drm/ttm: add caching state to ttm_bus_placement")
>> Cc: Christian König 
>> Cc: Michael J. Ruhl 
>> Cc: Maarten Lankhorst 
>> Cc: Maxime Ripard 
>> Cc: Thomas Zimmermann 
>> Cc: David Airlie 
>> Cc: Daniel Vetter 
>> Cc: Ben Skeggs 
>> Cc: Dave Airlie 
>> Cc: Gerd Hoffmann 
>> Cc: Alex Deucher 
>> Cc: "Christian König" 
>> Cc: VMware Graphics 
>> Cc: Roland Scheidegger 
>> Cc: Huang Rui 
>> Cc: Felix Kuehling 
>> Cc: Hawking Zhang 
>> Cc: Jason Gunthorpe 
>> Cc: Likun Gao 
>> Cc: dri-devel@lists.freedesktop.org
>> Cc: nouv...@lists.freedesktop.org
>> Cc: virtualizat...@lists.linux-foundation.org
>> Cc: spice-de...@lists.freedesktop.org
>> Cc: amd-...@lists.freedesktop.org
>> ---
>> drivers/gpu/drm/nouveau/nouveau_bo.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>> b/drivers/gpu/drm/nouveau/nouveau_bo.c
>> index 8133377d865d..fe15299d417e 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>> @@ -1142,9 +1142,12 @@ nouveau_ttm_io_mem_reserve(struct
>> ttm_bo_device *bdev, struct ttm_resource *reg)
>>  struct nvkm_device *device = nvxx_device(>client.device);
>>  struct nouveau_mem *mem = nouveau_mem(reg);
>>  struct nvif_mmu *mmu = >client.mmu;
>> -const u8 type = mmu->type[drm->ttm.type_vram].type;
>> +u8 type = 0;
>>  int ret;
>>
>> +if (drm->ttm.type_vram >= 0)
>> +type = mmu->type[drm->ttm.type_vram].type;
>> +
>>  mutex_lock(>ttm.io_reserve_mutex);
>> retry:
>>  switch (reg->mem_type) {
>> --
>> 2.29.2
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software

Re: [PATCH v1 11/30] drm/tegra: dc: Support OPP and SoC core voltage scaling

2020-11-11 Thread Mark Brown

On Wed, Nov 11, 2020 at 12:23:41AM +0300, Dmitry Osipenko wrote:
> 10.11.2020 23:32, Mark Brown пишет:

> >>> + if (!device_property_present(dc->dev, "core-supply"))
> >>> + return;

> >> This is a potentially heavy operation, so I think we should avoid that
> >> here. How about you use devm_regulator_get_optional() in ->probe()? That
> >> returns -ENODEV if no regulator was specified, in which case you can set
> >> dc->core_reg = NULL and use that as the condition here.

> > Or enumerate the configurable voltages after getting the regulator and
> > handle that appropriately which would be more robust in case there's
> > missing or unusual constraints.

> I already changed that code to use regulator_get_optional() for v2.

That doesn't look entirely appropriate given that the core does most
likely require some kind of power to operate.

> Regarding the enumerating supported voltage.. I think this should be
> done by the OPP core, but regulator core doesn't work well if
> regulator_get() is invoked more than one time for the same device, at
> least there is a loud debugfs warning about an already existing

I don't understand why this would be an issue - if nothing else the core
could just offer an interface to trigger the check.

> directory for a regulator. It's easy to check whether the debug
> directory exists before creating it, like thermal framework does it for
> example, but then there were some other more difficult issues.. I don't
> recall what they were right now. Perhaps will be easier to simply get a
> error from regulator_set_voltage() for now because it shouldn't ever
> happen in practice, unless device-tree has wrong constraints.

The constraints might not be wrong, there might be some board which has
a constraint somewhere for 


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

Re: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel

2020-11-11 Thread Tomi Valkeinen

On 10/11/2020 23:04, H. Nikolaus Schaller wrote:
> 
>> Am 10.11.2020 um 17:52 schrieb Tomi Valkeinen :
>>
>> On 10/11/2020 18:49, H. Nikolaus Schaller wrote:
>>
>> I guess you have the same issue. It goes to dsi_bridge_mode_valid, then 
>> __dsi_calc_config, and stays
>> there finding good clocks.
> 
> Yes, I could trace it down to exactly this point.
> 
> So the culprit is somehow the panel driver. Because it asks for clocks that 
> the PLL driver does not want to provide...
> Or is it the victim?
> 
> Here is what dmesg reports with even more printk():
> 
> [  276.970635] drm_helper_probe_single_connector_modes 12 count=1
> [  277.003509] drm_mode_validate_pipeline 2 ret=0 status=0
> [  277.038678] drm_bridge_chain_mode_valid: 
> func=dsi_bridge_mode_valid+0x0/0xa0 [omapdrm]
> [  277.047199] dsi_bridge_mode_valid
> [  277.050786] __dsi_calc_config
> [  277.057270] dsi_vm_calc
> [  277.073251] dss_pll_calc_a clkin=1920 pll_min=1555386656 
> pll_max=1555410656 func=dsi_vm_calc_pll_cb+0x0/0x48 [omapdrm]
> [  277.084975] dss_pll_calc_a pll_hw_max=18 fint_hw_min=15 
> fint_hw_max=5200
> [  277.093637] dss_pll_calc_a n_start=1 n_inc=1 n_stop=128 pll_max'=1555410656
> [  277.101062] dss_pll_calc_a n=1 clkin=1920 fint=1920
> [  277.107152] dss_pll_calc_a m_start=41 m_inc=1 m_stop=40
> 
> Ok, we have to wait quite a while until the for(m;;) loop ends, because 
> m_stop < m_start and m_inc is positive.
> 
> So something in the formulae in dss_pll_calc_a() does not fit or has 
> unintended rounding effects.
> Or the values reported by w677l_get_modes() do not fit anything.
> 
> I think these findings and ideas should help to find a fix.

drm_display_mode.clock is in kHz, but the panel driver writes Hz 
(w677l_PIXELCLOCK) to it. But
there's more after fixing that. The DSI gets configured in bridge's modeset, 
which I think is before
w677l_prepare where the panel already sends DSI commands. Also, the dsi driver 
fails to lock the
PLL, so possibly the clock calcs are still wrong.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 00/16] drm/exynos: Convert driver to drm bridge

2020-11-11 Thread Michael Tretter

On Wed, 11 Nov 2020 12:11:15 +0900, Inki Dae wrote:
> 20. 11. 11. 오후 12:04에 Inki Dae 이(가) 쓴 글:
> > 20. 11. 10. 오후 5:13에 Michael Tretter 이(가) 쓴 글:
> >> On Mon, 09 Nov 2020 12:15:39 +0900, Inki Dae wrote:
> >>> 20. 9. 11. 오후 10:53에 Michael Tretter 이(가) 쓴 글:
>  This is v2 of the series to convert the Exynos MIPI DSI driver into a drm
>  bridge and make it usable with other drivers. Although the driver is
>  converted, it still supports the component framework API to stay 
>  compliant
>  with the Exynos DRM driver.
> 
>  The Exynos MIPI DSI Phy is also found on the i.MX8M Mini. However, on the
>  i.MX8M Mini, the bridge is driven by an LCDIF display controller instead 
>  of
>  the Exynos Decon. The driver for the LCDIF does not use the component
>  framework, but uses drm bridges.
> 
>  I don't have any Exynos SoC to actually test the series. I build a dummy 
>  to
>  test the bridge with a component driver, to make sure that at least the
>  initialization is working. Furthermore, tested the driver as a bridge 
>  with a
>  few additional unfinished patches on the i.MX8M Mini EVK. However, 
>  somebody
>  should verify that the driver is still working on Exynos hardware.
> 
>  I also changed the order of the patches to first make the driver more 
>  platform
>  independent (patches 2 to 8), then convert to a drm bridge driver 
>  (patches 10
> >>>
> >>> Just a fundamental question, A MIPI-DSI(Display Serial Interface) bus 
> >>> device
> >>> would be one of an encoder type of devices not bridge such as DSI to LVDS
> >>> and LVDS to DSI bridge devices, and also image enhancer and image 
> >>> compressor
> >>> in case of Exynos.
> >>
> >> I don't understand, why the MIPI-DSI bus device would be an encoder type 
> >> and
> >> DSI to LVDS or MIPI-DSI to HDMI would be bridges. For example, the device 
> >> tree
> >> documentation for the DSIM states that the DSIM receives RGB video as input
> >> and produces MIPI-DSI as output. Thus, the DSIM is basically a parallel 
> >> RGB to
> > 
> > MIPI-DSI receives RGB video as input and encodes it to MIPI packet and then 
> > transfers the packet to MIPI panel.
> > And finally, MIPI panel decodes the packet and updates it - RGB data - on 
> > its SRAM.
> > 
> > MIPI-DSI driver programs how the RGB video should be made as MIPI packet. 
> > For more detail, you could refer to MIPI-DSI spec.
> > This would be why we handle MIPI-DSI driver as an encoder like other ARM 
> > SoC DRM drivers did.
> > 
> >> MIPI-DSI bridge and the encoder is the LCD controller that encodes the 
> >> video
> >> data as parallel RGB.
> >>
> >> On the i.MX8MM, the LCDIF is already the encoder. On Exynos, the series
> >> implements the encoder in the platform glue, but in the end the encoder can
> >> probably be moved to the DECON.
> > 
> > As you know, Display controller can transfer RGB video to various devices 
> > such as RGB panel, CPU panel, LVDS panel via LVDS bridge, MIPI panel via 
> > MIPI-DSI bus device, and so on like below,
> > 
> > Display Controller --> RGB panel or CPU panel.
> > Display Controller --> LVDS bridge --> LVDS panel.
> > Display Controller --> MIPI DSI bus device --> MIPI Panel.
> > ...
> > 
> > Display controller drivers such as FIMD and DECON series in case of Exynos 
> > don't create an encoder driver-internally instead of it depends on Display 
> > pipeline configuration - what kind of Display panel is used.
> > In fact, if the Display pipeline uses RGB panel or CPU panel without 
> > Display bus device such as MIPI-DSI, then FIMD and DECON drivers create an 
> > encoder for it internally - just we separated the code to consider other 
> > type of panels.

What happens if I add a MIPI-DSI --> HDMI bridge to the Display pipeline? Then
the Pipeline is

Display Controller --> MIPI DSI bus device --> HDMI bridge --> HDMI Panel

If the type of the Display panel decides which part of the pipeline provides
the encoder, the HDMI bridge driver would be responsible for creating the
encoder, right? Thus, the MIPI-DSI driver would not be responsible for
creating the encoder and would also get the encoder from another driver.
Therefore, I prefer to think of the Display Controller as the encoder and
other bridges are just bridges.

BTW, this is exactly the Display pipeline that is used on the i.MX8MM EVK.

> > 
> > On the I.MX8MM, could you share how to handle an encoder if some board has 
> > only MIPI-DSI panel, and in this case, where is an encoder for it created? 
> > I looked into I.MX8MM DRM driver but didn't find MIPI-DSI driver.
> > Seems that they support only parallel display, HDMI and LVDS panel.
> 
> One more thing, If I saw correctly, the LVDS driver of IMX DRM - lmx_ldb - 
> creates an encoder internally like MIPI-DSI driver of Exynos DRM did.

Yes, but the IMX DRM driver is not used on the i.MX8MM. The i.MX8MM uses the
LCDIF display controller instead of the IPU of

Re: [PATCH v1 11/30] drm/tegra: dc: Support OPP and SoC core voltage scaling

2020-11-11 Thread Dan Carpenter

On Tue, Nov 10, 2020 at 09:29:45PM +0100, Thierry Reding wrote:
> > +   err = dev_pm_opp_of_add_table(dc->dev);
> > +   if (err) {
> > +   dev_err(dc->dev, "failed to add OPP table: %d\n", err);
> > +   goto put_hw;
> > +   }
> > +
> > +   err = devm_add_action(dc->dev, tegra_dc_deinit_opp_table, dc);
> > +   if (err)
> > +   goto remove_table;
> 
> Do these functions return positive values? If not, I'd prefer if this
> check was more explicit (i.e. err < 0) for consistency with the rest of
> this code.
> 

Isn't it the other way around?  It's only when the check is explicitly
for "if (ret < 0)" that we have to wonder about positives. If the codes
says "if (ret)" then we know that it doesn't return positive values and
every non-zero is an error.

In the kernel "if (ret)" is way more popular than "if (ret < 0)":

$ git grep 'if (\(ret\|rc\|err\))' | wc -l
92927
$ git grep 'if (\(ret\|rc\|err\) < 0)' | wc -l
36577

And some of those are places where "ret" can be positive so we are
forced to use the "if (ret < 0)" format.

Checking for "if (ret)" is easier from a static analysis perspective.
If it's one style is used consistently then they're the same but when
there is a mismatch the "if (ret < 0) " will trigger a false positive
and the "if (ret) " will not.

int var;

ret = frob();
if (ret < 0)
return ret;

Smatch thinks positive returns are not handled so it complains that
"var can be uninitialized".

regards,
dan carpenter

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

Re: [PATCH v8 11/26] memory: tegra124-emc: Make driver modular

2020-11-11 Thread Krzysztof Kozlowski

On Wed, Nov 11, 2020 at 12:17:37PM +0300, Dmitry Osipenko wrote:
> 11.11.2020 12:04, Krzysztof Kozlowski пишет:
> >> -obj-$(CONFIG_TEGRA124_EMC)+= clk-tegra124-emc.o
> >> +obj-$(CONFIG_ARCH_TEGRA_124_SOC)  += clk-tegra124-emc.o
> >> +obj-$(CONFIG_ARCH_TEGRA_132_SOC)  += clk-tegra124-emc.o
> > How is it related to modularization? It looks like different issue is
> > fixed here.
> 
> The CONFIG_TEGRA124_EMC now could be 'm', while the clock code must be
> built-in. The TEGRA124 EMC driver is used by T124 and T132 SoCs.\

Mhmm,  the CONFIG_TEGRA124_EMC depends on ARCH_TEGRA_124_SOC so on the
config !ARCH_TEGRA_124_SOC && ARCH_TEGRA_132_SOC this was not
selected. Now it will be selected.

> 
> ...
> >> diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
> >> index 6b565f6b5f66..2da7c93c1a6c 100644
> >> --- a/drivers/clk/tegra/clk.h
> >> +++ b/drivers/clk/tegra/clk.h
> >> @@ -881,18 +881,6 @@ void tegra_super_clk_gen5_init(void __iomem *clk_base,
> >>void __iomem *pmc_base, struct tegra_clk *tegra_clks,
> >>struct tegra_clk_pll_params *pll_params);
> >>  
> >> -#ifdef CONFIG_TEGRA124_EMC
> >> -struct clk *tegra_clk_register_emc(void __iomem *base, struct device_node 
> >> *np,
> >> - spinlock_t *lock);
> >> -#else
> >> -static inline struct clk *tegra_clk_register_emc(void __iomem *base,
> >> -   struct device_node *np,
> >> -   spinlock_t *lock)
> >> -{
> >> -  return NULL;
> >> -}
> >> -#endif
> > Why clock changes are so tightly coupled with making an EMC driver
> > modular? Usually this should be a separate change - you adjust any
> > dependencies to accept late or deferred probing, exported symbols,
> > loosen the coupling between drivers, etc. and then you convert something
> > to module.
> 
> Because the clock and EMC driver were not separated from each other
> previously. The clock part can't be modularized easily and probably
> shouldn't.
> 
> I'm not sure whether it's actually possible to split this patch without
> taking a closer a look.
> 
> I'm also doubt that it would really worth the effort for a 100 lines of
> a changed code.

Indeed, the clk and emc drivers are so tightly coupled that anyway it
would be big patch to change the interfaces followed up a small one
making emc module. OK.

Best regards,
Krzysztof

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

[Bug 210123] drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] - flip_done time out with vmwgfx

2020-11-11 Thread bugzilla-daemon

https://bugzilla.kernel.org/show_bug.cgi?id=210123

--- Comment #2 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to Stefan Mayr from comment #1)
> #208373 seems simliar but for us it started with an older kernel version

It's about amdgpu, unlikely to be directly related.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: add debug logs for drm_mode_atomic_ioctl errors

2020-11-11 Thread Simon Ser

On Tuesday, November 10, 2020 6:39 PM, Sam Ravnborg  wrote:

> You could consider migrating to drm_dbg_atomic() and friends while
> touching this - so we get one more core file migrated.
> You have a drm_device so the code is fine with the new drm_ based
> logging.

That's a good point! Sent a v2.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/2] drm: add debug logs for drm_mode_atomic_ioctl errors

2020-11-11 Thread Simon Ser

Be nice to user-space and log what happened when returning EINVAL in
drm_mode_atomic_ioctl.

v2:

- Migrate to drm_dbg_atomic (Sam)
- Add debug log for arg->reserved (Ville)
- Drop redundant "atomic" word in log messages (Ville)

Signed-off-by: Simon Ser 
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: Sam Ravnborg 
Cc: Ville Syrjala 
---
 drivers/gpu/drm/drm_atomic_uapi.c | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index efab3d518891..9df7f2a170e3 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1330,22 +1330,35 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
 * though this may be a bit overkill, since legacy userspace
 * wouldn't know how to call this ioctl)
 */
-   if (!file_priv->atomic)
+   if (!file_priv->atomic) {
+   drm_dbg_atomic(dev,
+  "commit failed: atomic cap not enabled\n");
return -EINVAL;
+   }
 
-   if (arg->flags & ~DRM_MODE_ATOMIC_FLAGS)
+   if (arg->flags & ~DRM_MODE_ATOMIC_FLAGS) {
+   drm_dbg_atomic(dev, "commit failed: invalid flag\n");
return -EINVAL;
+   }
 
-   if (arg->reserved)
+   if (arg->reserved) {
+   drm_dbg_atomic(dev, "commit failed: reserved field set\n");
return -EINVAL;
+   }
 
-   if (arg->flags & DRM_MODE_PAGE_FLIP_ASYNC)
+   if (arg->flags & DRM_MODE_PAGE_FLIP_ASYNC) {
+   drm_dbg_atomic(dev,
+  "commit failed: invalid flag 
DRM_MODE_PAGE_FLIP_ASYNC\n");
return -EINVAL;
+   }
 
/* can't test and expect an event at the same time. */
if ((arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) &&
-   (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
+   (arg->flags & DRM_MODE_PAGE_FLIP_EVENT)) {
+   drm_dbg_atomic(dev,
+  "commit failed: page-flip event requested with 
test-only commit\n");
return -EINVAL;
+   }
 
state = drm_atomic_state_alloc(dev);
if (!state)
-- 
2.29.2


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

[PATCH v2 1/2] drm: convert drm_atomic_uapi.c to new debug helpers

2020-11-11 Thread Simon Ser

Migrate from DRM_DEBUG_ATOMIC to drm_dbg_atomic.

Signed-off-by: Simon Ser 
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: Sam Ravnborg 
Cc: Ville Syrjala 
---
 drivers/gpu/drm/drm_atomic_uapi.c | 113 +-
 1 file changed, 66 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index ef82009035e6..efab3d518891 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -85,13 +85,15 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state 
*state,
 
drm_mode_copy(>mode, mode);
state->enable = true;
-   DRM_DEBUG_ATOMIC("Set [MODE:%s] for [CRTC:%d:%s] state %p\n",
-mode->name, crtc->base.id, crtc->name, state);
+   drm_dbg_atomic(crtc->dev,
+  "Set [MODE:%s] for [CRTC:%d:%s] state %p\n",
+  mode->name, crtc->base.id, crtc->name, state);
} else {
memset(>mode, 0, sizeof(state->mode));
state->enable = false;
-   DRM_DEBUG_ATOMIC("Set [NOMODE] for [CRTC:%d:%s] state %p\n",
-crtc->base.id, crtc->name, state);
+   drm_dbg_atomic(crtc->dev,
+  "Set [NOMODE] for [CRTC:%d:%s] state %p\n",
+  crtc->base.id, crtc->name, state);
}
 
return 0;
@@ -128,31 +130,35 @@ int drm_atomic_set_mode_prop_for_crtc(struct 
drm_crtc_state *state,
int ret;
 
if (blob->length != sizeof(struct drm_mode_modeinfo)) {
-   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] bad mode blob length: 
%zu\n",
-crtc->base.id, crtc->name,
-blob->length);
+   drm_dbg_atomic(crtc->dev,
+  "[CRTC:%d:%s] bad mode blob length: 
%zu\n",
+  crtc->base.id, crtc->name,
+  blob->length);
return -EINVAL;
}
 
ret = drm_mode_convert_umode(crtc->dev,
 >mode, blob->data);
if (ret) {
-   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] invalid mode (ret=%d, 
status=%s):\n",
-crtc->base.id, crtc->name,
-ret, 
drm_get_mode_status_name(state->mode.status));
+   drm_dbg_atomic(crtc->dev,
+  "[CRTC:%d:%s] invalid mode (ret=%d, 
status=%s):\n",
+  crtc->base.id, crtc->name,
+  ret, 
drm_get_mode_status_name(state->mode.status));
drm_mode_debug_printmodeline(>mode);
return -EINVAL;
}
 
state->mode_blob = drm_property_blob_get(blob);
state->enable = true;
-   DRM_DEBUG_ATOMIC("Set [MODE:%s] for [CRTC:%d:%s] state %p\n",
-state->mode.name, crtc->base.id, crtc->name,
-state);
+   drm_dbg_atomic(crtc->dev,
+  "Set [MODE:%s] for [CRTC:%d:%s] state %p\n",
+  state->mode.name, crtc->base.id, crtc->name,
+  state);
} else {
state->enable = false;
-   DRM_DEBUG_ATOMIC("Set [NOMODE] for [CRTC:%d:%s] state %p\n",
-crtc->base.id, crtc->name, state);
+   drm_dbg_atomic(crtc->dev,
+  "Set [NOMODE] for [CRTC:%d:%s] state %p\n",
+  crtc->base.id, crtc->name, state);
}
 
return 0;
@@ -202,12 +208,14 @@ drm_atomic_set_crtc_for_plane(struct drm_plane_state 
*plane_state,
}
 
if (crtc)
-   DRM_DEBUG_ATOMIC("Link [PLANE:%d:%s] state %p to 
[CRTC:%d:%s]\n",
-plane->base.id, plane->name, plane_state,
-crtc->base.id, crtc->name);
+   drm_dbg_atomic(plane->dev,
+  "Link [PLANE:%d:%s] state %p to [CRTC:%d:%s]\n",
+  plane->base.id, plane->name, plane_state,
+  crtc->base.id, crtc->name);
else
-   DRM_DEBUG_ATOMIC("Link [PLANE:%d:%s] state %p to [NOCRTC]\n",
-plane->base.id, plane->name, plane_state);
+   drm_dbg_atomic(plane->dev,
+  "Link [PLANE:%d:%s] state %p to [NOCRTC]\n",
+  plane->base.id, plane->name, plane_state);
 
return 0;
 }
@@ -230,12

Re: [PATCH v8 11/26] memory: tegra124-emc: Make driver modular

2020-11-11 Thread Krzysztof Kozlowski

On Wed, Nov 11, 2020 at 04:14:41AM +0300, Dmitry Osipenko wrote:
> Add modularization support to the Tegra124 EMC driver, which now can be
> compiled as a loadable kernel module.
> 
> Note that EMC clock must be registered at clk-init time, otherwise PLLM
> will be disabled as unused clock at boot time if EMC driver is compiled
> as a module. Hence add a prepare/complete callbacks. similarly to what is
> done for the Tegra20/30 EMC drivers.
> 
> Tested-by: Nicolas Chauvet 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/clk/tegra/Makefile   |  3 +-
>  drivers/clk/tegra/clk-tegra124-emc.c | 41 
>  drivers/clk/tegra/clk-tegra124.c | 27 --
>  drivers/clk/tegra/clk.h  | 16 +++
>  drivers/memory/tegra/Kconfig |  2 +-
>  drivers/memory/tegra/tegra124-emc.c  | 31 ++---
>  include/linux/clk/tegra.h|  8 ++
>  include/soc/tegra/emc.h  | 16 ---
>  8 files changed, 96 insertions(+), 48 deletions(-)
>  delete mode 100644 include/soc/tegra/emc.h
> 
> diff --git a/drivers/clk/tegra/Makefile b/drivers/clk/tegra/Makefile
> index eec2313fd37e..53b76133e905 100644
> --- a/drivers/clk/tegra/Makefile
> +++ b/drivers/clk/tegra/Makefile
> @@ -22,7 +22,8 @@ obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += 
> clk-tegra20-emc.o
>  obj-$(CONFIG_ARCH_TEGRA_114_SOC) += clk-tegra114.o
>  obj-$(CONFIG_ARCH_TEGRA_124_SOC) += clk-tegra124.o
>  obj-$(CONFIG_TEGRA_CLK_DFLL) += clk-tegra124-dfll-fcpu.o
> -obj-$(CONFIG_TEGRA124_EMC)   += clk-tegra124-emc.o
> +obj-$(CONFIG_ARCH_TEGRA_124_SOC) += clk-tegra124-emc.o
> +obj-$(CONFIG_ARCH_TEGRA_132_SOC) += clk-tegra124-emc.o

How is it related to modularization? It looks like different issue is
fixed here.

>  obj-$(CONFIG_ARCH_TEGRA_132_SOC) += clk-tegra124.o
>  obj-y+= cvb.o
>  obj-$(CONFIG_ARCH_TEGRA_210_SOC) += clk-tegra210.o
> diff --git a/drivers/clk/tegra/clk-tegra124-emc.c 
> b/drivers/clk/tegra/clk-tegra124-emc.c
> index 745f9faa98d8..bdf6f4a51617 100644
> --- a/drivers/clk/tegra/clk-tegra124-emc.c
> +++ b/drivers/clk/tegra/clk-tegra124-emc.c
> @@ -11,7 +11,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -21,7 +23,6 @@
>  #include 
>  
>  #include 
> -#include 
>  
>  #include "clk.h"
>  
> @@ -80,6 +81,9 @@ struct tegra_clk_emc {
>   int num_timings;
>   struct emc_timing *timings;
>   spinlock_t *lock;
> +
> + tegra124_emc_prepare_timing_change_cb *prepare_timing_change;
> + tegra124_emc_complete_timing_change_cb *complete_timing_change;
>  };
>  
>  /* Common clock framework callback implementations */
> @@ -176,6 +180,9 @@ static struct tegra_emc *emc_ensure_emc_driver(struct 
> tegra_clk_emc *tegra)
>   if (tegra->emc)
>   return tegra->emc;
>  
> + if (!tegra->prepare_timing_change || !tegra->complete_timing_change)
> + return NULL;
> +
>   if (!tegra->emc_node)
>   return NULL;
>  
> @@ -241,7 +248,7 @@ static int emc_set_timing(struct tegra_clk_emc *tegra,
>  
>   div = timing->parent_rate / (timing->rate / 2) - 2;
>  
> - err = tegra_emc_prepare_timing_change(emc, timing->rate);
> + err = tegra->prepare_timing_change(emc, timing->rate);
>   if (err)
>   return err;
>  
> @@ -259,7 +266,7 @@ static int emc_set_timing(struct tegra_clk_emc *tegra,
>  
>   spin_unlock_irqrestore(tegra->lock, flags);
>  
> - tegra_emc_complete_timing_change(emc, timing->rate);
> + tegra->complete_timing_change(emc, timing->rate);
>  
>   clk_hw_reparent(>hw, __clk_get_hw(timing->parent));
>   clk_disable_unprepare(tegra->prev_parent);
> @@ -473,8 +480,8 @@ static const struct clk_ops tegra_clk_emc_ops = {
>   .get_parent = emc_get_parent,
>  };
>  
> -struct clk *tegra_clk_register_emc(void __iomem *base, struct device_node 
> *np,
> -spinlock_t *lock)
> +struct clk *tegra124_clk_register_emc(void __iomem *base, struct device_node 
> *np,
> +   spinlock_t *lock)
>  {
>   struct tegra_clk_emc *tegra;
>   struct clk_init_data init;
> @@ -538,3 +545,27 @@ struct clk *tegra_clk_register_emc(void __iomem *base, 
> struct device_node *np,
>  
>   return clk;
>  };
> +
> +void tegra124_clk_set_emc_callbacks(tegra124_emc_prepare_timing_change_cb 
> *prep_cb,
> + tegra124_emc_complete_timing_change_cb 
> *complete_cb)
> +{
> + struct clk *clk = __clk_lookup("emc");
> + struct tegra_clk_emc *tegra;
> + struct clk_hw *hw;
> +
> + if (clk) {
> + hw = __clk_get_hw(clk);
> + tegra = container_of(hw, struct tegra_clk_emc, hw);
> +
> + tegra->prepare_timing_change = prep_cb;
> + tegra->complete_timing_change = complete_cb;
> + }
> +}
>

Re: [PATCH v8 10/26] memory: tegra30-emc: Factor out clk initialization

2020-11-11 Thread Krzysztof Kozlowski

On Wed, Nov 11, 2020 at 09:51:15AM +0100, Krzysztof Kozlowski wrote:
> On Wed, Nov 11, 2020 at 04:14:40AM +0300, Dmitry Osipenko wrote:
> > Factor out clk initialization and make it resource-managed. This makes
> > easier to follow code and will help to make further changes cleaner.
> > 
> > Signed-off-by: Dmitry Osipenko 
> > ---
> >  drivers/memory/tegra/tegra30-emc.c | 70 --
> >  1 file changed, 47 insertions(+), 23 deletions(-)
> > 
> > diff --git a/drivers/memory/tegra/tegra30-emc.c 
> > b/drivers/memory/tegra/tegra30-emc.c
> > index d27df842a667..1df42e212d73 100644
> > --- a/drivers/memory/tegra/tegra30-emc.c
> > +++ b/drivers/memory/tegra/tegra30-emc.c
> > @@ -1550,6 +1550,49 @@ static int tegra_emc_opp_table_init(struct tegra_emc 
> > *emc)
> > return err;
> >  }
> >  
> > +static void devm_tegra_emc_unset_callback(void *data)
> > +{
> > +   tegra20_clk_set_emc_round_callback(NULL, NULL);
> > +}
> > +
> > +static void devm_tegra_emc_unreg_clk_notifier(void *data)
> > +{
> > +   struct tegra_emc *emc = data;
> > +
> > +   clk_notifier_unregister(emc->clk, >clk_nb);
> > +}
> > +
> > +static int tegra_emc_init_clk(struct tegra_emc *emc)
> > +{
> > +   int err;
> > +
> > +   tegra20_clk_set_emc_round_callback(emc_round_rate, emc);
> > +
> > +   err = devm_add_action_or_reset(emc->dev, devm_tegra_emc_unset_callback,
> > +  NULL);
> > +   if (err)
> > +   return err;
> > +
> > +   emc->clk = devm_clk_get(emc->dev, NULL);
> > +   if (IS_ERR(emc->clk)) {
> > +   dev_err(emc->dev, "failed to get EMC clock: %pe\n", emc->clk);
> > +   return PTR_ERR(emc->clk);
> > +   }
> > +
> > +   err = clk_notifier_register(emc->clk, >clk_nb);
> > +   if (err) {
> > +   dev_err(emc->dev, "failed to register clk notifier: %d\n", err);
> > +   return err;
> > +   }
> > +
> > +   err = devm_add_action_or_reset(emc->dev,
> > +  devm_tegra_emc_unreg_clk_notifier, emc);
> > +   if (err)
> > +   return err;
> > +
> > +   return 0;
> > +}
> > +
> >  static int tegra_emc_probe(struct platform_device *pdev)
> >  {
> > struct device_node *np;
> > @@ -1599,25 +1642,13 @@ static int tegra_emc_probe(struct platform_device 
> > *pdev)
> > return err;
> > }
> >  
> > -   tegra20_clk_set_emc_round_callback(emc_round_rate, emc);
> > -
> > -   emc->clk = devm_clk_get(>dev, "emc");
> > -   if (IS_ERR(emc->clk)) {
> > -   err = PTR_ERR(emc->clk);
> > -   dev_err(>dev, "failed to get emc clock: %d\n", err);
> > -   goto unset_cb;
> > -   }
> > -
> > -   err = clk_notifier_register(emc->clk, >clk_nb);
> > -   if (err) {
> > -   dev_err(>dev, "failed to register clk notifier: %d\n",
> > -   err);
> > -   goto unset_cb;
> > -   }
> > +   err = tegra_emc_init_clk(emc);
> > +   if (err)
> > +   return err;
> >  
> > err = tegra_emc_opp_table_init(emc);
> > if (err)
> > -   goto unreg_notifier;
> > +   return err;
> >  
> > platform_set_drvdata(pdev, emc);
> > tegra_emc_rate_requests_init(emc);
> > @@ -1632,13 +1663,6 @@ static int tegra_emc_probe(struct platform_device 
> > *pdev)
> > try_module_get(THIS_MODULE);
> >  
> > return 0;
> > -
> > -unreg_notifier:
> > -   clk_notifier_unregister(emc->clk, >clk_nb);
> 
> You added this code in patch #8, so adding-and-removing a piece of code

Correction: you added this in patch #9.

Best regards,
Krzysztof


> is a nice hint that this patch should be before. Don't add new code
> which later you simplify. Move all bugfixes and all simplifications to
> beginning of patchset.
> 
> That's quite similar case to v6 where you put bugfixes in the middle
> of patchset.
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 10/26] memory: tegra30-emc: Factor out clk initialization

2020-11-11 Thread Krzysztof Kozlowski

On Wed, Nov 11, 2020 at 04:14:40AM +0300, Dmitry Osipenko wrote:
> Factor out clk initialization and make it resource-managed. This makes
> easier to follow code and will help to make further changes cleaner.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/memory/tegra/tegra30-emc.c | 70 --
>  1 file changed, 47 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/memory/tegra/tegra30-emc.c 
> b/drivers/memory/tegra/tegra30-emc.c
> index d27df842a667..1df42e212d73 100644
> --- a/drivers/memory/tegra/tegra30-emc.c
> +++ b/drivers/memory/tegra/tegra30-emc.c
> @@ -1550,6 +1550,49 @@ static int tegra_emc_opp_table_init(struct tegra_emc 
> *emc)
>   return err;
>  }
>  
> +static void devm_tegra_emc_unset_callback(void *data)
> +{
> + tegra20_clk_set_emc_round_callback(NULL, NULL);
> +}
> +
> +static void devm_tegra_emc_unreg_clk_notifier(void *data)
> +{
> + struct tegra_emc *emc = data;
> +
> + clk_notifier_unregister(emc->clk, >clk_nb);
> +}
> +
> +static int tegra_emc_init_clk(struct tegra_emc *emc)
> +{
> + int err;
> +
> + tegra20_clk_set_emc_round_callback(emc_round_rate, emc);
> +
> + err = devm_add_action_or_reset(emc->dev, devm_tegra_emc_unset_callback,
> +NULL);
> + if (err)
> + return err;
> +
> + emc->clk = devm_clk_get(emc->dev, NULL);
> + if (IS_ERR(emc->clk)) {
> + dev_err(emc->dev, "failed to get EMC clock: %pe\n", emc->clk);
> + return PTR_ERR(emc->clk);
> + }
> +
> + err = clk_notifier_register(emc->clk, >clk_nb);
> + if (err) {
> + dev_err(emc->dev, "failed to register clk notifier: %d\n", err);
> + return err;
> + }
> +
> + err = devm_add_action_or_reset(emc->dev,
> +devm_tegra_emc_unreg_clk_notifier, emc);
> + if (err)
> + return err;
> +
> + return 0;
> +}
> +
>  static int tegra_emc_probe(struct platform_device *pdev)
>  {
>   struct device_node *np;
> @@ -1599,25 +1642,13 @@ static int tegra_emc_probe(struct platform_device 
> *pdev)
>   return err;
>   }
>  
> - tegra20_clk_set_emc_round_callback(emc_round_rate, emc);
> -
> - emc->clk = devm_clk_get(>dev, "emc");
> - if (IS_ERR(emc->clk)) {
> - err = PTR_ERR(emc->clk);
> - dev_err(>dev, "failed to get emc clock: %d\n", err);
> - goto unset_cb;
> - }
> -
> - err = clk_notifier_register(emc->clk, >clk_nb);
> - if (err) {
> - dev_err(>dev, "failed to register clk notifier: %d\n",
> - err);
> - goto unset_cb;
> - }
> + err = tegra_emc_init_clk(emc);
> + if (err)
> + return err;
>  
>   err = tegra_emc_opp_table_init(emc);
>   if (err)
> - goto unreg_notifier;
> + return err;
>  
>   platform_set_drvdata(pdev, emc);
>   tegra_emc_rate_requests_init(emc);
> @@ -1632,13 +1663,6 @@ static int tegra_emc_probe(struct platform_device 
> *pdev)
>   try_module_get(THIS_MODULE);
>  
>   return 0;
> -
> -unreg_notifier:
> - clk_notifier_unregister(emc->clk, >clk_nb);

You added this code in patch #8, so adding-and-removing a piece of code
is a nice hint that this patch should be before. Don't add new code
which later you simplify. Move all bugfixes and all simplifications to
beginning of patchset.

That's quite similar case to v6 where you put bugfixes in the middle
of patchset.

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

Re: [PATCH 0/5] add KERN_LEVEL to printk

2020-11-11 Thread Thomas Zimmermann

Hi

Am 11.11.20 um 09:31 schrieb Bernard Zhao:
> Hi:
> 
> When call printk, set the KERN_LEVEL is suggested by the community.
> This patch sereies add KERN_* level to printk which do not set
> this level.

I have no say on the msm driver, but IMHO a much better change would be
a conversion to drm_dbg(), drm_err(), etc.

Best regards
Thomas

> 
> Bernard Zhao (5):
>   adreno/a2xx_gpu.c: add KERN_LEVEL to printk
>   adreno/a3xx_gpu.c: add KERN_LEVEL to printk
>   adreno/a4xx_gpu.c: add KERN_LEVEL to printk
>   adreno/a5xx_gpu.c: add KERN_LEVEL to printk
>   adreno/adreno_gpu.c: add KERN_LEVEL to printk
> 
>  drivers/gpu/drm/msm/adreno/a2xx_gpu.c   |  4 ++--
>  drivers/gpu/drm/msm/adreno/a3xx_gpu.c   |  4 ++--
>  drivers/gpu/drm/msm/adreno/a4xx_gpu.c   |  6 +++---
>  drivers/gpu/drm/msm/adreno/a5xx_gpu.c   |  2 +-
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 12 ++--
>  5 files changed, 14 insertions(+), 14 deletions(-)
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

86 matches

Mail list logo