[Bug 111040] it is not working

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=111040

Bug ID: 111040
   Summary: it is not working
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/other
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: sriramyapar...@gmail.com

steps to reproduce

actual result



expected result

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

Re: [PATCH 1/4] drm/vram: Set GEM object functions for PRIME

[Gerd Hoffmann]

  Hi,

> > But the new and the old ones are identical, right?  So why add/remove?
> > Why not just rename them?
> 
> Hmm, OK. Does that somehow make a difference (e.g., easier backporting
> or maintenance)?

Easier patch review (it is obvious then you only change the way the
functions are hooked up, not the actual code).  A bit less code churn.

cheers,
  Gerd

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

Reminder: 1 open syzbot bug in drm subsystem

[Eric Biggers]

[This email was generated by a script.  Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]

Of the currently open syzbot reports against the upstream kernel, I've manually
marked 1 of them as possibly being a bug in the drm subsystem.

If you believe this bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status

If you believe I misattributed this bug to the drm subsystem, please let me
know, and if possible forward the report to the correct people or mailing list.

Here is the bug:


Title:  WARNING in vkms_vblank_simulate
Last occurred:  0 days ago
Reported:   140 days ago
Branches:   Mainline and others
Dashboard link: 
https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
Original thread:
https://lkml.kernel.org/lkml/11c9310581a57...@google.com/T/#u

This bug has a C reproducer.

This bug was bisected to:

commit 09ef09b4ab95dc405ad4171ec2cd8a4ff5227108
Author: Shayenne Moura 
Date:   Wed Feb 6 20:08:13 2019 +

  drm/vkms: WARN when hrtimer_forward_now fails

The original thread for this bug received 1 reply, 112 days ago.

If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com

If you send any email or patch for this bug, please consider replying to the
original thread.  For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/11c9310581a57...@google.com

Re: [Intel-gfx] [PATCH v3 3/4] drm/connector: Split out orientation quirk detection

[dbasehore .]

On Mon, Jun 24, 2019 at 6:24 AM Ville Syrjälä
 wrote:
>
> On Fri, Jun 21, 2019 at 08:41:04PM -0700, Derek Basehore wrote:
> > Not every platform needs quirk detection for panel orientation, so
> > split the drm_connector_init_panel_orientation_property into two
> > functions. One for platforms without the need for quirks, and the
> > other for platforms that need quirks.
> >
> > Signed-off-by: Derek Basehore 
> > ---
> >  drivers/gpu/drm/drm_connector.c | 45 -
> >  drivers/gpu/drm/i915/intel_dp.c |  4 +--
> >  drivers/gpu/drm/i915/vlv_dsi.c  |  5 ++--
> >  include/drm/drm_connector.h |  2 ++
> >  4 files changed, 39 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_connector.c 
> > b/drivers/gpu/drm/drm_connector.c
> > index e17586aaa80f..c4b01adf927a 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1894,31 +1894,23 @@ 
> > EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
> >   * drm_connector_init_panel_orientation_property -
> >   *   initialize the connecters panel_orientation property
> >   * @connector: connector for which to init the panel-orientation property.
> > - * @width: width in pixels of the panel, used for panel quirk detection
> > - * @height: height in pixels of the panel, used for panel quirk detection
> >   *
> >   * This function should only be called for built-in panels, after setting
> >   * connector->display_info.panel_orientation first (if known).
> >   *
> > - * This function will check for platform specific (e.g. DMI based) quirks
> > - * overriding display_info.panel_orientation first, then if 
> > panel_orientation
> > - * is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
> > - * "panel orientation" property to the connector.
> > + * This function will check if the panel_orientation is not
> > + * DRM_MODE_PANEL_ORIENTATION_UNKNOWN. If not, it will attach the "panel
> > + * orientation" property to the connector.
> >   *
> >   * Returns:
> >   * Zero on success, negative errno on failure.
> >   */
> >  int drm_connector_init_panel_orientation_property(
> > - struct drm_connector *connector, int width, int height)
> > + struct drm_connector *connector)
> >  {
> >   struct drm_device *dev = connector->dev;
> >   struct drm_display_info *info = >display_info;
> >   struct drm_property *prop;
> > - int orientation_quirk;
> > -
> > - orientation_quirk = drm_get_panel_orientation_quirk(width, height);
> > - if (orientation_quirk != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
> > - info->panel_orientation = orientation_quirk;
> >
> >   if (info->panel_orientation == DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
> >   return 0;
> > @@ -1941,6 +1933,35 @@ int drm_connector_init_panel_orientation_property(
> >  }
> >  EXPORT_SYMBOL(drm_connector_init_panel_orientation_property);
> >
> > +/**
> > + * drm_connector_init_panel_orientation_property_quirk -
> > + *   initialize the connecters panel_orientation property with a quirk
> > + *   override
> > + * @connector: connector for which to init the panel-orientation property.
> > + * @width: width in pixels of the panel, used for panel quirk detection
> > + * @height: height in pixels of the panel, used for panel quirk detection
> > + *
> > + * This function will check for platform specific (e.g. DMI based) quirks
> > + * overriding display_info.panel_orientation first, then if 
> > panel_orientation
> > + * is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
> > + * "panel orientation" property to the connector.
> > + *
> > + * Returns:
> > + * Zero on success, negative errno on failure.
> > + */
> > +int drm_connector_init_panel_orientation_property_quirk(
> > + struct drm_connector *connector, int width, int height)
> > +{
> > + int orientation_quirk;
> > +
> > + orientation_quirk = drm_get_panel_orientation_quirk(width, height);
> > + if (orientation_quirk != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
> > + connector->display_info.panel_orientation = orientation_quirk;
> > +
> > + return drm_connector_init_panel_orientation_property(connector);
> > +}
> > +EXPORT_SYMBOL(drm_connector_init_panel_orientation_property_quirk);
> > +
> >  int drm_connector_set_obj_prop(struct drm_mode_object *obj,
> >   struct drm_property *property,
> >   uint64_t value)
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index b099a9dc28fd..7d4e61cf5463 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -7282,8 +7282,8 @@ static bool intel_edp_init_connector(struct intel_dp 
> > *intel_dp,
> >   intel_panel_setup_backlight(connector, pipe);
> >
> >   if (fixed_mode)
> > - drm_connector_init_panel_orientation_property(
> > - connector, fixed_mode->hdisplay, 
> > 

Re: [PATCH v5 09/12] drm/virtio: rework virtio_gpu_object_create fencing

[Chia-I Wu]

On Mon, Jul 1, 2019 at 11:04 AM Gurchetan Singh
 wrote:
>
>
>
> On Fri, Jun 28, 2019 at 5:14 AM Gerd Hoffmann  wrote:
> >
> > Use gem reservation helpers and direct reservation_object_* calls
> > instead of ttm.
> >
> > v5: fix fencing (Chia-I Wu).
> > v3: Due to using the gem reservation object it is initialized and ready
> > for use before calling ttm_bo_init, so we can also drop the tricky fence
> > logic which checks whenever the command is in flight still.  We can
> > simply fence our object before submitting the virtio command and be done
> > with it.
> >
> > Signed-off-by: Gerd Hoffmann 
> > Acked-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/virtio/virtgpu_drv.h|  2 +
> >  drivers/gpu/drm/virtio/virtgpu_object.c | 55 ++---
> >  drivers/gpu/drm/virtio/virtgpu_vq.c |  4 ++
> >  3 files changed, 27 insertions(+), 34 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
> > b/drivers/gpu/drm/virtio/virtgpu_drv.h
> > index 356d27132388..c4b266b6f731 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> > @@ -267,6 +267,7 @@ void virtio_gpu_free_vbufs(struct virtio_gpu_device 
> > *vgdev);
> >  void virtio_gpu_cmd_create_resource(struct virtio_gpu_device *vgdev,
> > struct virtio_gpu_object *bo,
> > struct virtio_gpu_object_params *params,
> > +   struct virtio_gpu_object_array *objs,
> > struct virtio_gpu_fence *fence);
> >  void virtio_gpu_cmd_unref_resource(struct virtio_gpu_device *vgdev,
> >uint32_t resource_id);
> > @@ -329,6 +330,7 @@ void
> >  virtio_gpu_cmd_resource_create_3d(struct virtio_gpu_device *vgdev,
> >   struct virtio_gpu_object *bo,
> >   struct virtio_gpu_object_params *params,
> > + struct virtio_gpu_object_array *objs,
> >   struct virtio_gpu_fence *fence);
> >  void virtio_gpu_ctrl_ack(struct virtqueue *vq);
> >  void virtio_gpu_cursor_ack(struct virtqueue *vq);
> > diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c 
> > b/drivers/gpu/drm/virtio/virtgpu_object.c
> > index 82bfbf983fd2..fa0ea22c68b0 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_object.c
> > +++ b/drivers/gpu/drm/virtio/virtgpu_object.c
> > @@ -97,7 +97,9 @@ int virtio_gpu_object_create(struct virtio_gpu_device 
> > *vgdev,
> >  struct virtio_gpu_object **bo_ptr,
> >  struct virtio_gpu_fence *fence)
> >  {
> > +   struct virtio_gpu_object_array *objs = NULL;
> > struct virtio_gpu_object *bo;
> > +   struct ww_acquire_ctx ticket;
> > size_t acc_size;
> > int ret;
> >
> > @@ -123,12 +125,29 @@ int virtio_gpu_object_create(struct virtio_gpu_device 
> > *vgdev,
> > }
> > bo->dumb = params->dumb;
> >
> > +   if (fence) {
> > +   objs = virtio_gpu_array_alloc(1);
> > +   objs->objs[0] = >gem_base;
> > +   drm_gem_object_get(objs->objs[0]);
>
> So we take a reference every-time create/submit_cmd are fenced?  Why don't we 
> take a reference during {virtio_gpu_cmd_transfer_from_host_3d, 
> virtio_gpu_transfer_to_host_ioctl}?
Yeah, I had the same question in another thread.
>
> Does the GEM common code wait on the reservation object before calling 
> virtio_gpu_gem_object_close?  If not, would it make sense to wait on the 
> reservation object with MAX_SCHEDULE_TIMEOUT in virtio_gpu_free_object?
virtio_gpu_gem_object_close is called when this process (this
drm_file) does not need the object.  It is fine if there are still
pending operations.

virtio_gpu_free_object is called when the last reference is gone.  It
should be a critical error if there are still pending operations.

>
> > +
> > +   ret = drm_gem_lock_reservations(objs->objs, objs->nents,
> > +   );
> > +   if (ret == 0)
> > +   
> > reservation_object_add_excl_fence(objs->objs[0]->resv,
> > + >f);
> > +   }
> > +
> > if (params->virgl) {
> > -   virtio_gpu_cmd_resource_create_3d(vgdev, bo, params, fence);
> > +   virtio_gpu_cmd_resource_create_3d(vgdev, bo, params,
> > + objs, fence);
> > } else {
> > -   virtio_gpu_cmd_create_resource(vgdev, bo, params, fence);
> > +   virtio_gpu_cmd_create_resource(vgdev, bo, params,
> > +  objs, fence);
> > }
> >
> > +   if (fence)
> > +   drm_gem_unlock_reservations(objs->objs, objs->nents, 
> > );
> > +
> > virtio_gpu_init_ttm_placement(bo);
> > ret 

[Bug 108309] Raven Ridge 2700U system lock-up on multiple games

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108309

Francisco Pina Martins  changed:

   What|Removed |Added

 CC||f.pinamart...@gmail.com

--- Comment #11 from Francisco Pina Martins  ---
Created attachment 144687
  --> https://bugs.freedesktop.org/attachment.cgi?id=144687=edit
Journalctl, from starting Steam to Magic Sysrq shutdown

I can also confirm this issue, with the same error message in the log.
I can reproduce the issue every single time by trying to start a new game in
"Cities: Skylines".

System information:

```
AMD Ryzen 5 2400G

Linux ZenBox 5.1.15-arch1-1-ARCH #1 SMP PREEMPT Tue Jun 25 04:49:39 UTC 2019
x86_64 GNU/Linux

mesa-19.1.1-1
```

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

Re: [PATCH v6 0/5] DMA-BUF Heaps (destaging ION)

[John Stultz]

On Mon, Jul 1, 2019 at 2:45 PM Laura Abbott  wrote:
>
> On 6/24/19 3:49 PM, John Stultz wrote:
> > Here is another pass at the dma-buf heaps patchset Andrew and I
> > have been working on which tries to destage a fair chunk of ION
> > functionality.
> >
>
> I've gotten bogged down with both work and personal tasks
> so I haven't had a chance to look too closely but, once again,
> I'm happy to see this continue to move forward.
>
> > The patchset implements per-heap devices which can be opened
> > directly and then an ioctl is used to allocate a dmabuf from the
> > heap.
> >
> > The interface is similar, but much simpler then IONs, only
> > providing an ALLOC ioctl.
> >
> > Also, I've provided relatively simple system and cma heaps.
> >
> > I've booted and tested these patches with AOSP on the HiKey960
> > using the kernel tree here:
> >
> > https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap
> >
> > And the userspace changes here:
> >https://android-review.googlesource.com/c/device/linaro/hikey/+/909436
> >
> > Compared to ION, this patchset is missing the system-contig,
> > carveout and chunk heaps, as I don't have a device that uses
> > those, so I'm unable to do much useful validation there.
> > Additionally we have no upstream users of chunk or carveout,
> > and the system-contig has been deprecated in the common/andoid-*
> > kernels, so this should be ok.
> >
> > I've also removed the stats accounting for now, since any such
> > accounting should be implemented by dma-buf core or the heaps
> > themselves.
> >
> >
> > New in v6:
> > * Number of cleanups and error path fixes suggested by Brian Starkey,
> >many thanks for his close review and suggestions!
> >
> >
> > Outstanding concerns:
> > * Need to better understand various secure heap implementations.
> >Some concern that heap private flags will be needed, but its
> >also possible that dma-buf heaps can't solve everyone's needs,
> >in which case, a vendor's secure buffer driver can implement
> >their own dma-buf exporter. So I'm not too worried here.
> >
>
> syzbot found a DoS with Ion which I ACKed a fix for.
> https://lore.kernel.org/lkml/03763360-a7de-de87-eb90-ba7838143...@i-love.sakura.ne.jp/
> This series doesn't have the page pooling so that particular bug may
> not be applicable but given this is not the first time I've
> seen Ion used as a DoS mechanism, it would be good to think about
> putting in some basic checks.

Yea, there's no shrinker right now (and my WIP page pool
implementation steals the network core's pagepool, which is statically
sized).

But the check in the alloc code seems reasonable so I can add it to
what I have. Appreciate the suggestion!

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

Re: [PATCH v6 0/5] DMA-BUF Heaps (destaging ION)

[Laura Abbott]

On 6/24/19 3:49 PM, John Stultz wrote:

Here is another pass at the dma-buf heaps patchset Andrew and I
have been working on which tries to destage a fair chunk of ION
functionality.



I've gotten bogged down with both work and personal tasks
so I haven't had a chance to look too closely but, once again,
I'm happy to see this continue to move forward.


The patchset implements per-heap devices which can be opened
directly and then an ioctl is used to allocate a dmabuf from the
heap.

The interface is similar, but much simpler then IONs, only
providing an ALLOC ioctl.

Also, I've provided relatively simple system and cma heaps.

I've booted and tested these patches with AOSP on the HiKey960
using the kernel tree here:
   
https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap

And the userspace changes here:
   https://android-review.googlesource.com/c/device/linaro/hikey/+/909436

Compared to ION, this patchset is missing the system-contig,
carveout and chunk heaps, as I don't have a device that uses
those, so I'm unable to do much useful validation there.
Additionally we have no upstream users of chunk or carveout,
and the system-contig has been deprecated in the common/andoid-*
kernels, so this should be ok.

I've also removed the stats accounting for now, since any such
accounting should be implemented by dma-buf core or the heaps
themselves.


New in v6:
* Number of cleanups and error path fixes suggested by Brian Starkey,
   many thanks for his close review and suggestions!


Outstanding concerns:
* Need to better understand various secure heap implementations.
   Some concern that heap private flags will be needed, but its
   also possible that dma-buf heaps can't solve everyone's needs,
   in which case, a vendor's secure buffer driver can implement
   their own dma-buf exporter. So I'm not too worried here.



syzbot found a DoS with Ion which I ACKed a fix for.
https://lore.kernel.org/lkml/03763360-a7de-de87-eb90-ba7838143...@i-love.sakura.ne.jp/
This series doesn't have the page pooling so that particular bug may
not be applicable but given this is not the first time I've
seen Ion used as a DoS mechanism, it would be good to think about
putting in some basic checks.

Thanks,
Laura


Thoughts and feedback would be greatly appreciated!

thanks
-john

Cc: Laura Abbott 
Cc: Benjamin Gaignard 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Pratik Patel 
Cc: Brian Starkey 
Cc: Vincent Donnefort 
Cc: Sudipto Paul 
Cc: Andrew F. Davis 
Cc: Christoph Hellwig 
Cc: Chenbo Feng 
Cc: Alistair Strachan 
Cc: dri-devel@lists.freedesktop.org

Andrew F. Davis (1):
   dma-buf: Add dma-buf heaps framework

John Stultz (4):
   dma-buf: heaps: Add heap helpers
   dma-buf: heaps: Add system heap to dmabuf heaps
   dma-buf: heaps: Add CMA heap to dmabuf heaps
   kselftests: Add dma-heap test

  MAINTAINERS   |  18 ++
  drivers/dma-buf/Kconfig   |  10 +
  drivers/dma-buf/Makefile  |   2 +
  drivers/dma-buf/dma-heap.c| 249 +
  drivers/dma-buf/heaps/Kconfig |  14 +
  drivers/dma-buf/heaps/Makefile|   4 +
  drivers/dma-buf/heaps/cma_heap.c  | 169 +++
  drivers/dma-buf/heaps/heap-helpers.c  | 262 ++
  drivers/dma-buf/heaps/heap-helpers.h  |  54 
  drivers/dma-buf/heaps/system_heap.c   | 121 
  include/linux/dma-heap.h  |  59 
  include/uapi/linux/dma-heap.h |  55 
  tools/testing/selftests/dmabuf-heaps/Makefile |   9 +
  .../selftests/dmabuf-heaps/dmabuf-heap.c  | 234 
  14 files changed, 1260 insertions(+)
  create mode 100644 drivers/dma-buf/dma-heap.c
  create mode 100644 drivers/dma-buf/heaps/Kconfig
  create mode 100644 drivers/dma-buf/heaps/Makefile
  create mode 100644 drivers/dma-buf/heaps/cma_heap.c
  create mode 100644 drivers/dma-buf/heaps/heap-helpers.c
  create mode 100644 drivers/dma-buf/heaps/heap-helpers.h
  create mode 100644 drivers/dma-buf/heaps/system_heap.c
  create mode 100644 include/linux/dma-heap.h
  create mode 100644 include/uapi/linux/dma-heap.h
  create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile
  create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c



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

Re: [PATCH][next] drm/vmwgfx: remove redundant assignment to sub_res

[Deepak Singh Rawat]

Hi Colin,

Reviewed-by: Deepak Rawat 

Thanks,
Deepak


On Mon, 2019-06-24 at 23:44 +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Variable sub_res is initialized to a value that is never read and it
> is re-assigned later in a for-loop.  The initialization is redundant
> and can be removed.
> 
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> index 862ca44680ca..3257ba689d93 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> @@ -1914,7 +1914,7 @@ static void
> vmw_surface_tex_dirty_range_add(struct vmw_resource *res,
>   } else {
>   /* Dirty range covers multiple sub-resources */
>   struct svga3dsurface_loc loc_min, loc_max;
> - u32 sub_res = loc1.sub_resource;
> + u32 sub_res;
>  
>   svga3dsurface_max_loc(cache, loc1.sub_resource,
> _max);
>   vmw_subres_dirty_add(dirty, , _max);

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

Re: Why is Thunderbolt 3 limited to 2.5 GT/s on Linux?

[Mika Westerberg]

On Fri, Jun 28, 2019 at 04:53:02PM +0200, Timur Kristóf wrote:
> On Fri, 2019-06-28 at 17:14 +0300, Mika Westerberg wrote:
> > On Fri, Jun 28, 2019 at 03:33:56PM +0200, Timur Kristóf wrote:
> > > I have two more questions:
> > > 
> > > 1. What is the best way to test that the virtual link is indeed
> > > capable
> > > of 40 Gbit / sec? So far I've been unable to figure out how to
> > > measure
> > > its maximum throughput.
> > 
> > I don't think there is any good way to test it but the Thunderbolt
> > gen 3
> > link is pretty much always 40 Gb/s (20 Gb/s x 2) from which the
> > bandwidth is shared dynamically between different tunnels (virtual
> > links).
> 
> That's unfortunate, I would have expected there to be some sort of PCIe
> speed test utility.
> 
> Now that I gave it a try, I can measure ~20 Gbit/sec when I run Gnome
> Wayland on this system (which forces the eGPU to send the framebuffer
> back and forth all the time - for two 4K monitors). But it still
> doesn't give me 40 Gbit/sec.

How do you measure that? Is there a DP stream also? As I said the
bandwidth is dynamically shared between the consumers so you probably do
not get the full bandwidth for PCIe only because it needs to reserve
something for possible DP streams and so on.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Why is Thunderbolt 3 limited to 2.5 GT/s on Linux?

[Mika Westerberg]

On Mon, Jul 01, 2019 at 10:46:34AM -0400, Alex Deucher wrote:
> > 2. As far as I understood what Mika said, there isn't really a 2.5 GT/s
> > limitation there, since the virtual link should be running at 40 Gb/s
> > regardless of the reported speed of that device. Would it be possible
> > to run the AMD GPU at 8 GT/s in this case?
> 
> If there is really a faster link here then we need some way to pass
> that information to the drivers.  We rely on the information from the
> upstream bridges and the pcie core helper functions.

I think you may use "pci_dev->is_thunderbolt" in the GPU driver and then
just use whatever the real PCI link speed & width is between the GPU and
the downstream port it connects to.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Why is Thunderbolt 3 limited to 2.5 GT/s on Linux?

[Timur Kristóf]

> > > > Like I said the device really is limited to 2.5 GT/s even
> > > > though it
> > > > should be able to do 8 GT/s.
> > > 
> > > There is Thunderbolt link between the host router (your host
> > > system)
> > > and
> > > the eGPU box. That link is not limited to 2.5 GT/s so even if the
> > > slot
> > > claims it is PCI gen1 the actual bandwidth can be much higher
> > > because
> > > of
> > > the virtual link.
> > 
> > Not sure I understand correctly, are you saying that TB3 can do 40
> > Gbit/sec even though the kernel thinks it can only do 8 Gbit / sec?
> > 
> > I haven't found a good way to measure the maximum PCIe throughput
> > between the CPU and GPU, but I did take a look at AMD's sysfs
> > interface
> > at /sys/class/drm/card1/device/pcie_bw which while running the
> > bottlenecked game. The highest throughput I saw there was only 2.43
> > Gbit /sec.
> > 
> > One more thought. I've also looked at
> > /sys/class/drm/card1/device/pp_dpm_pcie - which tells me that
> > amdgpu
> > thinks it is running on a 2.5GT/s x8 link (as opposed to the
> > expected 8
> > GT/s x4). Can this be a problem?
> 
> We limit the speed of the link the the driver to the max speed of any
> upstream links.  So if there are any links upstream limited to 2.5
> GT/s, it doesn't make sense to clock the local link up to faster
> speeds.
> 
> Alex

Hi Alex,

I have two concerns about it:

1. Why does amdgpu think that the link has 8 lanes, when it only has 4?

2. As far as I understood what Mika said, there isn't really a 2.5 GT/s
limitation there, since the virtual link should be running at 40 Gb/s
regardless of the reported speed of that device. Would it be possible
to run the AMD GPU at 8 GT/s in this case?

Best regards,
Tim

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

Re: Why is Thunderbolt 3 limited to 2.5 GT/s on Linux?

[Timur Kristóf]

> > 
> > That's unfortunate, I would have expected there to be some sort of
> > PCIe
> > speed test utility.
> > 
> > Now that I gave it a try, I can measure ~20 Gbit/sec when I run
> > Gnome
> > Wayland on this system (which forces the eGPU to send the
> > framebuffer
> > back and forth all the time - for two 4K monitors). But it still
> > doesn't give me 40 Gbit/sec.
> 
> How do you measure that? Is there a DP stream also? As I said the
> bandwidth is dynamically shared between the consumers so you probably
> do
> not get the full bandwidth for PCIe only because it needs to reserve
> something for possible DP streams and so on.

I'm measuring it using AMD's pcie_bw sysfs interface which shows how
many packets were sent and received by the GPU, and the max packet
size. So it's not an exact measurement but a good estimate.

AFAIK there is no DP stream. Only the eGPU is connected to the TB3 port
and nothing else. The graphics card inside the TB3 enclosure does have
a DP connector which is in use, but I assume that's not what you mean.

It also doesn't seem to make a difference whether or not anything is
plugged into the USB ports provided by the eGPU. (Some online posts
suggest that not using those ports would allow higher throughput to the
eGPU, but I don't see that it would make any difference here.)

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

Re: [PATCH v3 01/22] drm: Include ddc adapter pointer in struct drm_connector

[Andrzej Pietrasiewicz]

Hi Thomas,

Thank you for your comments. Please see inline.

W dniu 30.06.2019 o 10:12, Thomas Zimmermann pisze:

Hi

I like the idea, but would prefer a more structured approach.

Setting connector->ddc before calling drm_sysfs_connector_add() seems
error prone. The dependency is not really clear from the code or interfaces.

The other thing is that drivers I mostly work on, ast and mgag200, have
code like this:

   struct ast_i2c_chan {
struct i2c_adapter adapter;
struct drm_device *dev;
struct i2c_algo_bit_data bit;
   };

   struct ast_connector {
struct drm_connector base;
struct ast_i2c_chan *i2c;
   };

It already encodes the connection between connector and ddc adapter.

I suggest to introduce struct drm_i2c_adapter

   struct drm_i2c_adapter {
struct i2c_adapter base;
struct drm_connector *connector;
   };

and convert drivers over to it. Ast would look like this:

   struct ast_i2c_chan {
struct drm_i2c_adapter adapter;
struct i2c_algo_bit_data bit;
   };



There are few flavors of these drivers. In some of them
the i2c_adapter for ddc is allocated and initialized by
the driver, which must provide a place in memory to hold
the adapter. ast is an example of this approach.

But there are others, such as for example exynos_hdmi.c.
It gets its ddc adapter with of_find_i2c_adapter_by_node()
and merely stores a pointer to it, while not managing the
memory needed to hold the i2c_adapter.

Do you have any idea how to accommodate these various
flavors of drivers in the scheme you propose?

Andrzej


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

Re: Why is Thunderbolt 3 limited to 2.5 GT/s on Linux?

[Timur Kristóf]

On Mon, 2019-07-01 at 16:54 +0200, Michel Dänzer wrote:
> On 2019-06-28 2:21 p.m., Timur Kristóf wrote:
> > I haven't found a good way to measure the maximum PCIe throughput
> > between the CPU and GPU,
> 
> amdgpu.benchmark=3
> 
> on the kernel command line will measure throughput for various
> transfer
> sizes during driver initialization.

Thanks, I will definitely try that.
Is this the only way to do this, or is there a way to benchmark it
after it already booted?

> > but I did take a look at AMD's sysfs interface at
> > /sys/class/drm/card1/device/pcie_bw which while running the
> > bottlenecked
> > game. The highest throughput I saw there was only 2.43 Gbit /sec.
> 
> PCIe bandwidth generally isn't a bottleneck for games, since they
> don't
> constantly transfer large data volumes across PCIe, but store them in
> the GPU's local VRAM, which is connected at much higher bandwidth.

There are reasons why I think the problem is the bandwidth:
1. The same issues don't happen when the GPU is not used with a TB3
enclosure.
2. In case of radeonsi, the problem was mitigated once Marek's SDMA
patch was merged, which hugely reduces the PCIe bandwidth use.
3. In less optimized cases (for example D9VK), the problem is still
very noticable.

Best regards,
Tim

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

Re: [PATCH 2/7] drm/dp_mst: Register AUX devices for MST ports

[Lyude Paul]

On Thu, 2019-06-27 at 22:21 +, Li, Sun peng (Leo) wrote:
> Sorry for the late response! just jumping back on this now.
> 
> On 2019-05-16 5:40 p.m., Lyude Paul wrote:
> > [CAUTION: External Email]
> > 
> > So a couple of things:
> > 
> > On Thu, 2019-05-16 at 11:17 -0400, sunpeng...@amd.com wrote:
> > > From: Ville Syrjälä 
> > > 
> > > All available downstream ports - physical and logical - are exposed for
> > > each MST device. They are listed in /dev/, following the same naming
> > > scheme as SST devices by appending an incremental ID.
> > > 
> > > Although all downstream ports are exposed, only some will work as
> > > expected. Consider the following topology:
> > > 
> > > +-+
> > > |  ASIC   |
> > > +-+
> > >Conn-0|
> > >  |
> > > +v+
> > >+| MST HUB |+
> > >|+-+|
> > >|   |
> > >|Port-1   Port-2|
> > >  +-v-+   +-v-+
> > >  |  MST  |   |  SST  |
> > >  |  Display  |   |  Display  |
> > >  +---+   +---+
> > >|Port-1
> > >x
> > > 
> > >   MST Path  | MST Device
> > >   --+--
> > >   sst:0 | MST Hub
> > >   mst:0-1   | MST Display
> > >   mst:0-1-1 | MST Display's disconnected DP out
> > >   mst:0-1-8 | MST Display's internal sink
> > >   mst:0-2   | SST Display
> > > 
> > > On certain MST displays, the upstream physical port will ACK DPCD reads.
> > > However, reads on the local logical port to the internal sink will
> > > *NAK*. i.e. reading mst:0-1 ACKs, but mst:0-1-8 NAKs.
> > > 
> > > There may also be duplicates. Some displays will return the same GUID
> > > when reading DPCD from both mst:0-1 and mst:0-1-8.
> > > 
> > > There are some device-dependent behavior as well. The MST hub used
> > > during testing will actually *ACK* read requests on a disconnected
> > > physical port, whereas the MST displays will NAK.
> > > 
> > > In light of these discrepancies, it's simpler to expose all downstream
> > > ports - both physical and logical - and let the user decide what to use.
> > > 
> > > Cc: Lyude Paul 
> > > Signed-off-by: Ville Syrjälä 
> > > Signed-off-by: Leo Li 
> > > ---
> > >   drivers/gpu/drm/drm_dp_aux_dev.c  |  14 -
> > >   drivers/gpu/drm/drm_dp_mst_topology.c | 103
> > > +
> > > -
> > >   include/drm/drm_dp_helper.h   |   4 ++
> > >   include/drm/drm_dp_mst_helper.h   |   6 ++
> > >   4 files changed, 112 insertions(+), 15 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_dp_aux_dev.c
> > > b/drivers/gpu/drm/drm_dp_aux_dev.c
> > > index 6d84611..01c02b9 100644
> > > --- a/drivers/gpu/drm/drm_dp_aux_dev.c
> > > +++ b/drivers/gpu/drm/drm_dp_aux_dev.c
> > > @@ -34,6 +34,7 @@
> > >   #include 
> > >   #include 
> > >   #include 
> > > +#include 
> > >   #include 
> > >   #include 
> > > 
> > > @@ -114,6 +115,7 @@ static ssize_t name_show(struct device *dev,
> > > 
> > >return res;
> > >   }
> > > +
> > >   static DEVICE_ATTR_RO(name);
> > > 
> > >   static struct attribute *drm_dp_aux_attrs[] = {
> > > @@ -160,7 +162,11 @@ static ssize_t auxdev_read_iter(struct kiocb *iocb,
> > > struct iov_iter *to)
> > >break;
> > >}
> > > 
> > > - res = drm_dp_dpcd_read(aux_dev->aux, pos, buf, todo);
> > > + if (aux_dev->aux->is_remote)
> > > + res = drm_dp_mst_dpcd_read(aux_dev->aux, pos, buf,
> > > todo);
> > > + else
> > > + res = drm_dp_dpcd_read(aux_dev->aux, pos, buf,
> > > todo);
> > > +
> > 
> > It's still not at all clear to me why we're trying to avoid specifying
> > actual
> > callbacks for the aux device. We should remove this part entirely, remove
> > the
> > is_remote entry from struct drm_dp_aux, and then just specify our own hook
> > in
> > struct drm_dp_aux->transfer().
> > 
> 
> I'm not sure if this would work well. The existing policy does retries
> around the ->transfer() call. Using the same hook will cause a nested
> retry - once when calling remote_aux->transfer, and another when calling
> real_aux->transfer. The difference is the scope of the retry. The former
> replays the entire aux transaction, while the latter replays just the
> failed sideband packet. I think having the retry at the packet level
> makes more sense. Either way, it shouldn't happen in a nested manner.
> 
> In general, we need a way to determine whether a message needs to be
> sent via sideband. I'm not sure if there's a better way than setting a
> 'is_remote' flag?

oh-this is a very good point actually! I suppose we would certainly want to be
able to retry on a packet level instead. Since that's the case, I think going
with the current is_remote solution should be fine then. 

Re: [PATCH] drm/msm/mdp5: Use drm_device for creating gem address space

[Jeffrey Hugo]

On Mon, Jul 1, 2019 at 1:45 PM Rob Clark  wrote:
>
> On Mon, Jul 1, 2019 at 10:39 AM Jeffrey Hugo  wrote:
> >
> > Creating the msm gem address space requires a reference to the dev where
> > the iommu is located.  The driver currently assumes this is the same as
> > the platform device, which breaks when the iommu is outside of the
> > platform device.  Use the drm_device instead, which happens to always have
> > a reference to the proper device.
> >
> > Signed-off-by: Jeffrey Hugo 
> > ---
> >  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
> > b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > index 4a60f5fca6b0..1347a5223918 100644
> > --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > @@ -702,7 +702,7 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
> > mdelay(16);
> >
> > if (config->platform.iommu) {
> > -   aspace = msm_gem_address_space_create(>dev,
> > +   aspace = msm_gem_address_space_create(dev->dev,
> > config->platform.iommu, "mdp5");
>
> hmm, do you have a tree somewhere with your dt files?  This makes me
> think the display iommu is hooked up somewhere differently compared
> to, say, msm8916.dtsi

I'll post something somewhere and forward it to you.

Re: [PATCH] drm/msm/mdp5: Use eariler mixers when possible

[Rob Clark]

On Mon, Jul 1, 2019 at 10:41 AM Jeffrey Hugo  wrote:
>
> When assigning a mixer, we will iterate through the entire list looking for
> a suitable match.  This results in selecting the last match.  We should
> stop at the first match, since lower numbered mixers will typically have
> more capabilities, and are likely to be what the bootloader used, if we
> are looking to reuse the bootloader config in future.

I think for matching bootloader config, we need to read it out of the
hw and do it the hard way, rather than making assumptions.

For picking hwpipe for a plane, I made an effort to pick the available
hwpipe w/ the *least* capabilities that fit the requirements (ie.
scaling/yuv/etc) in order to leave the more capable hwpipe available
for future use.  Not sure if same approach would make sense for
mixers?  But not sure if picking something that bootloader probably
also would have picked is a great argument.

I do have some (now ancient) code from db410/mdp5 to read out he hw
state.. I *think* that might have post-dated dynamically picking
mixers.  (The older mdp5 on db410c also had to deal with figuring out
SMP block config, iirc.. thankfully newer mdp5 doesn't have to deal
with that.)

BR,
-R

>
> Signed-off-by: Jeffrey Hugo 
> ---
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_mixer.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_mixer.c 
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_mixer.c
> index 954db683ae44..1638042ad974 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_mixer.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_mixer.c
> @@ -96,6 +96,17 @@ int mdp5_mixer_assign(struct drm_atomic_state *s, struct 
> drm_crtc *crtc,
>  */
> if (!(*mixer) || cur->caps & MDP_LM_CAP_PAIR)
> *mixer = cur;
> +
> +   /*
> +* We have everything we could want, exit early.
> +* We have a valid mixer, that mixer pairs with another if we
> +* need that ability in future, and we have a right mixer if
> +* needed.
> +* Later LMs could be less optimal
> +*/
> +   if (*mixer && (*mixer)->caps & MDP_LM_CAP_PAIR &&
> +   ((r_mixer && *r_mixer) || !r_mixer))
> +   break;
> }
>
> if (!(*mixer))
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/3] drm: Add helper to compare edids.

[Lyude Paul]

Sorry for the late response! I like the idea here and I've brought up edid
comparison a couple times. Hopefully this isn't overkill, but I had a little
more in mind then just a helper like this (and I've had this on my mind for a
while!

When it comes to suspend/resume reprobing, I think there's more work then just
comparing edids that are redundant. I think most drivers have connectors that
fall into one of the following classes:

 * Always "in-sync" with events, e.g. event handling does not stop just
   because the device is suspended. This is actually true in some cases for
   nouveau and amdgpu, where both drivers can rely on ACPI firmware to send
   events while the device is suspended.
 * Only in-sync with events while the device is awake. Of course, that's the
   whole reason for these patches!

From what I understand based on previous discussions with some other intel
engineers back when they were trying to make the i915 suspend/resume process
faster, hotplug probing can be a pretty significant timesink in some cases.
Additionally, it's not always nessecarily everywhere if some connectors are
able to stay in sync, and that might be a benefit.

Additionally, I think there's a number of other parts of the process that I
would imagine every driver would end up needing to implement. A couple rather
simple examples: skipping edid comparisons for disconnected or newly-connected
connectors, assuming that failure to read an EDID on a connected connector
that could have it's EDID read before suspend means we have to consider said
connector to be changed, etc. So why not add helpers to handle all of this
boilerplate as well?

An idea I had at one point would be to add the ability to mark when a driver
believes a DRM connector has gone "out of sync" like I mentioned above. A
simple example: on laptops I've observed with nouveau that supported ACPI
hotplug events, ACPI hotplug events only ever seemed to come if a connector
was plugged in - not if a connector was removed. If we use this logic during
the runtime resume, we could ascertain that unless an ACPI hotplug event was
received before we resumed that we can actually skip reprobing any connectors
that were disconnected at runtime suspend and only probe the ones that were
connected.

So, maybe we could have helpers like this:

/* Inform DRM that we've disabled our primary means of receiving HPD
 * events.
 */
drm_connector_suspend_hpd()

/* A helper that goes through and performs basic connector reprobing and
 * EDID comparisons on connectors marked with
 * drm_connector_reprobe_on_hpd_resume(). Fires off an HPD event if any
 * connector changes are found/returns an int/etc. etc. whatever.
 *
 * To be called by the driver *after* it has re-enabled HPD detection
 * for all of it's connectors.
 */
drm_connector_resume_hpd()

/* Indicate to DRM that the given connector no longer has HPD, and will need
 * to be reprobed on resume
 */
drm_connector_reprobe_on_hpd_resume()

/* Convienence function to indicate to DRM that all connectors have lost
 * their primary means to receive HPD events, and will need to be
 * reprobed on resume. Useful for scenarios like S3 suspend.
 */
drm_connector_reprobe_all_on_hpd_resume()

I think this would also fit in nicely with the new hotplug uevent ideas
that have been floating around recently, since we could then use these
helpers to compress all of the connector changes that happened over a
s/r cycle into a single event (or, no event!)

On Fri, 2019-06-28 at 11:24 +0300, Stanislav Lisovskiy wrote:
> Many drivers would benefit from using
> drm helper to compare edid, rather
> than bothering with own implementation.
> 
> v2: Added documentation for this function.
> 
> Signed-off-by: Stanislav Lisovskiy 
> ---
>  drivers/gpu/drm/drm_edid.c | 33 +
>  include/drm/drm_edid.h |  9 +
>  2 files changed, 42 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 9d8f2b952004..eaad5155fbdd 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1361,6 +1361,39 @@ static bool drm_edid_is_zero(const u8 *in_edid, int
> length)
>   return true;
>  }
>  
> +/**
> + * drm_edid_are_equal - compare two edid blobs.
> + * @edid1: pointer to first blob
> + * @edid2: pointer to second blob
> + * This helper can be used during probing to determine if
> + * edid had changed.
> + */
> +bool drm_edid_are_equal(struct edid *edid1, struct edid *edid2)
> +{
> + int edid1_len, edid2_len;
> + bool edid1_present = edid1 != NULL;
> + bool edid2_present = edid2 != NULL;
> +
> + if (edid1_present != edid2_present)
> + return false;
> +
> + if (edid1) {
> +
> + edid1_len = EDID_LENGTH * (1 + edid1->extensions);
> + edid2_len = EDID_LENGTH * (1 + edid2->extensions);
> +
> + if (edid1_len != edid2_len)
> + return false;
> +
> + if (memcmp(edid1, edid2, 

Re: [PATCH] drm/msm/mdp5: Add msm8998 support

[Rob Clark]

On Mon, Jul 1, 2019 at 10:45 AM Jeffrey Hugo  wrote:
>
> Add support for MDP5 version v3.0 found on msm8998.
>
> Signed-off-by: Jeffrey Hugo 
> ---
>
> 8998 support could probably be MDP5 or DPU.  This MDP5 support works,
> but may not support all of the features that 8998 supports.  However,
> DPU seems to only support 845 (MDP v4.0) with fundamental assumptions
> about the base level a features supported, some of which 8998 does not
> infact support, so DPU would likely need significant re-writes to
> support 8998.  I'm not sure the effort is worth it since MDP5 needs so
> little effort to support 8998.

yeah, the dividing line between mdp5 and dpu is not bright.. it has
changed significantly since the first mdp5 things to the point where a
break was probably justified, but the evolution has been spread over
time.  I think it's fine to go w/ the easy route

Reviewed-by: Rob Clark 

>
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 132 ++-
>  1 file changed, 128 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c 
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
> index dd1daf0e305a..fb4762cec4f1 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
> @@ -630,7 +630,115 @@ const struct mdp5_cfg_hw msm8917_config = {
> .max_clk = 32000,
>  };
>
> -static const struct mdp5_cfg_handler cfg_handlers[] = {
> +const struct mdp5_cfg_hw msm8998_config = {
> +   .name = "msm8998",
> +   .mdp = {
> +   .count = 1,
> +   .caps = MDP_CAP_DSC |
> +   MDP_CAP_CDM |
> +   MDP_CAP_SRC_SPLIT |
> +   0,
> +   },
> +   .ctl = {
> +   .count = 5,
> +   .base = { 0x01000, 0x01200, 0x01400, 0x01600, 0x01800 },
> +   .flush_hw_mask = 0xf7ff,
> +   },
> +   .pipe_vig = {
> +   .count = 4,
> +   .base = { 0x04000, 0x06000, 0x08000, 0x0a000 },
> +   .caps = MDP_PIPE_CAP_HFLIP  |
> +   MDP_PIPE_CAP_VFLIP  |
> +   MDP_PIPE_CAP_SCALE  |
> +   MDP_PIPE_CAP_CSC|
> +   MDP_PIPE_CAP_DECIMATION |
> +   MDP_PIPE_CAP_SW_PIX_EXT |
> +   0,
> +   },
> +   .pipe_rgb = {
> +   .count = 4,
> +   .base = { 0x14000, 0x16000, 0x18000, 0x1a000 },
> +   .caps = MDP_PIPE_CAP_HFLIP  |
> +   MDP_PIPE_CAP_VFLIP  |
> +   MDP_PIPE_CAP_SCALE  |
> +   MDP_PIPE_CAP_DECIMATION |
> +   MDP_PIPE_CAP_SW_PIX_EXT |
> +   0,
> +   },
> +   .pipe_dma = {
> +   .count = 2, /* driver supports max of 2 currently */
> +   .base = { 0x24000, 0x26000, 0x28000, 0x2a000 },
> +   .caps = MDP_PIPE_CAP_HFLIP  |
> +   MDP_PIPE_CAP_VFLIP  |
> +   MDP_PIPE_CAP_SW_PIX_EXT |
> +   0,
> +   },
> +   .pipe_cursor = {
> +   .count = 2,
> +   .base = { 0x34000, 0x36000 },
> +   .caps = MDP_PIPE_CAP_HFLIP  |
> +   MDP_PIPE_CAP_VFLIP  |
> +   MDP_PIPE_CAP_SW_PIX_EXT |
> +   MDP_PIPE_CAP_CURSOR |
> +   0,
> +   },
> +
> +   .lm = {
> +   .count = 6,
> +   .base = { 0x44000, 0x45000, 0x46000, 0x47000, 0x48000, 
> 0x49000 },
> +   .instances = {
> +   { .id = 0, .pp = 0, .dspp = 0,
> + .caps = MDP_LM_CAP_DISPLAY |
> + MDP_LM_CAP_PAIR, },
> +   { .id = 1, .pp = 1, .dspp = 1,
> + .caps = MDP_LM_CAP_DISPLAY, },
> +   { .id = 2, .pp = 2, .dspp = -1,
> + .caps = MDP_LM_CAP_DISPLAY |
> + MDP_LM_CAP_PAIR, },
> +   { .id = 3, .pp = -1, .dspp = -1,
> + .caps = MDP_LM_CAP_WB, },
> +   { .id = 4, .pp = -1, .dspp = -1,
> + .caps = MDP_LM_CAP_WB, },
> +   { .id = 5, .pp = 3, .dspp = -1,
> + .caps = MDP_LM_CAP_DISPLAY, },
> +},
> +   .nb_stages = 8,
> +   .max_width = 2560,
> +   .max_height = 0x,
> +   },
> +   .dspp = {
> +   .count = 2,
> +   .base = { 0x54000, 0x56000 },
> +   },
> +   .ad = {
> +   .count = 3,
> +   .base = { 0x78000, 0x78800, 0x79000 },
> +   },
> + 

Re: [PATCH] drm/msm/mdp5: Use drm_device for creating gem address space

[Rob Clark]

On Mon, Jul 1, 2019 at 10:39 AM Jeffrey Hugo  wrote:
>
> Creating the msm gem address space requires a reference to the dev where
> the iommu is located.  The driver currently assumes this is the same as
> the platform device, which breaks when the iommu is outside of the
> platform device.  Use the drm_device instead, which happens to always have
> a reference to the proper device.
>
> Signed-off-by: Jeffrey Hugo 
> ---
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> index 4a60f5fca6b0..1347a5223918 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> @@ -702,7 +702,7 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
> mdelay(16);
>
> if (config->platform.iommu) {
> -   aspace = msm_gem_address_space_create(>dev,
> +   aspace = msm_gem_address_space_create(dev->dev,
> config->platform.iommu, "mdp5");

hmm, do you have a tree somewhere with your dt files?  This makes me
think the display iommu is hooked up somewhere differently compared
to, say, msm8916.dtsi

BR,
-R

> if (IS_ERR(aspace)) {
> ret = PTR_ERR(aspace);
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/5] drm/msm/dsi: get the clocks into OFF state at init

[Rob Clark]

On Mon, Jul 1, 2019 at 12:07 PM Jeffrey Hugo  wrote:
>
> On 7/1/2019 12:58 PM, Rob Clark wrote:
> > On Mon, Jul 1, 2019 at 11:37 AM Jeffrey Hugo  wrote:
> >>
> >> On 6/30/2019 9:01 AM, Rob Clark wrote:
> >>> From: Rob Clark 
> >>>
> >>> Do an extra enable/disable cycle at init, to get the clks into disabled
> >>> state in case bootloader left them enabled.
> >>>
> >>> In case they were already enabled, the clk_prepare_enable() has no real
> >>> effect, other than getting the enable_count/prepare_count into the right
> >>> state so that we can disable clocks in the correct order.  This way we
> >>> avoid having stuck clocks when we later want to do a modeset and set the
> >>> clock rates.
> >>>
> >>> Signed-off-by: Rob Clark 
> >>> ---
> >>>drivers/gpu/drm/msm/dsi/dsi_host.c | 18 +++---
> >>>drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c |  1 +
> >>>2 files changed, 16 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c 
> >>> b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
> >>> index aabab6311043..d0172d8db882 100644
> >>> --- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
> >>> +++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
> >>> @@ -354,6 +354,7 @@ static int dsi_pll_10nm_lock_status(struct 
> >>> dsi_pll_10nm *pll)
> >>>if (rc)
> >>>pr_err("DSI PLL(%d) lock failed, status=0x%08x\n",
> >>>   pll->id, status);
> >>> +rc = 0; // HACK, this will fail if PLL already running..
> >>
> >> Umm, why?  Is this intentional?
> >>
> >
> > I need to sort out a proper solution for this.. but PLL lock will fail
> > if the clk is already running (which, in that case, is fine since it
> > is already running and locked), which will cause the clk_enable to
> > fail..
> >
> > I guess there is some way that I can check that clk is already running
> > and skip this check..
>
>
> I'm sorry, but this makes no sense to me.  What clock are we talking
> about here?
>
> If the pll is locked, the the lock check should just drop through.  If
> the pll cannot lock, you have an issue.  I'm confused as to how any of
> the downstream clocks can actually be running if the pll isn't locked.
>
> I feel like we are not yet on the same page about what situation you
> seem to be in.  Can you describe in exacting detail?

yeah, I'd expect the lock bit to still be set (since the display is
obviously running at that point)..  but I didn't really debug it yet,
I just hacked that in so the clk_enable didn't fail, so that we could
get correct enable/prepare_counts in order to do the
clk_disable_unprepare()..

BR,
-R

Re: [PATCH 4/5] drm/msm/dsi: get the clocks into OFF state at init

[Jeffrey Hugo]

On 7/1/2019 12:58 PM, Rob Clark wrote:

On Mon, Jul 1, 2019 at 11:37 AM Jeffrey Hugo  wrote:


On 6/30/2019 9:01 AM, Rob Clark wrote:

From: Rob Clark 

Do an extra enable/disable cycle at init, to get the clks into disabled
state in case bootloader left them enabled.

In case they were already enabled, the clk_prepare_enable() has no real
effect, other than getting the enable_count/prepare_count into the right
state so that we can disable clocks in the correct order.  This way we
avoid having stuck clocks when we later want to do a modeset and set the
clock rates.

Signed-off-by: Rob Clark 
---
   drivers/gpu/drm/msm/dsi/dsi_host.c | 18 +++---
   drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c |  1 +
   2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c 
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
index aabab6311043..d0172d8db882 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
@@ -354,6 +354,7 @@ static int dsi_pll_10nm_lock_status(struct dsi_pll_10nm 
*pll)
   if (rc)
   pr_err("DSI PLL(%d) lock failed, status=0x%08x\n",
  pll->id, status);
+rc = 0; // HACK, this will fail if PLL already running..


Umm, why?  Is this intentional?



I need to sort out a proper solution for this.. but PLL lock will fail
if the clk is already running (which, in that case, is fine since it
is already running and locked), which will cause the clk_enable to
fail..

I guess there is some way that I can check that clk is already running
and skip this check..



I'm sorry, but this makes no sense to me.  What clock are we talking 
about here?


If the pll is locked, the the lock check should just drop through.  If 
the pll cannot lock, you have an issue.  I'm confused as to how any of 
the downstream clocks can actually be running if the pll isn't locked.


I feel like we are not yet on the same page about what situation you 
seem to be in.  Can you describe in exacting detail?

Re: [PATCH 1/5] clk: inherit clocks enabled by bootloader

[Rob Clark]

On Mon, Jul 1, 2019 at 11:25 AM Eric Anholt  wrote:
>
> Rob Clark  writes:
>
> > From: Rob Clark 
> >
> > The goal here is to support inheriting a display setup by bootloader,
> > although there may also be some non-display related use-cases.
> >
> > Rough idea is to add a flag for clks and power domains that might
> > already be enabled when kernel starts, and which should not be
> > disabled at late_initcall if the kernel thinks they are "unused".
> >
> > If bootloader is enabling display, and kernel is using efifb before
> > real display driver is loaded (potentially from kernel module after
> > userspace starts, in a typical distro kernel), we don't want to kill
> > the clocks and power domains that are used by the display before
> > userspace starts.
> >
> > Signed-off-by: Rob Clark 
>
> Raspberry Pi is carrying downstream hacks to do similar stuff, and it
> would be great to see CCF finally support this.

yeah, both this and the multiple-possible-panel thing are a big source
of downstream hacks on basically every android device too.. :-/

it certainly would be nice to have upstream solutions for these
problems to give downstream hacks a reason not to exist

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

Re: [linux-sunxi] Re: [PATCH v10 04/11] drm/sun4i: tcon: Compute DCLK dividers based on format, lanes

[Jagan Teki]

On Tue, Jun 25, 2019 at 8:07 PM Maxime Ripard  wrote:
>
> On Mon, Jun 24, 2019 at 09:32:11PM +0530, Jagan Teki wrote:
> > On Mon, Jun 24, 2019 at 6:34 PM Maxime Ripard  
> > wrote:
> > >
> > > On Fri, Jun 14, 2019 at 05:33:23PM +0530, Jagan Teki wrote:
> > > > On Thu, Jun 13, 2019 at 7:28 PM Maxime Ripard 
> > > >  wrote:
> > > > >
> > > > > On Wed, Jun 05, 2019 at 01:11:44PM +0530, Jagan Teki wrote:
> > > > > > On Tue, Jun 4, 2019 at 8:00 PM Maxime Ripard 
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Fri, May 24, 2019 at 03:37:36PM +0530, Jagan Teki wrote:
> > > > > > > > On Fri, May 24, 2019 at 2:18 AM Maxime Ripard 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > On Mon, May 20, 2019 at 02:33:11PM +0530, Jagan Teki wrote:
> > > > > > > > > > pll-video => pll-mipi => tcon0 => tcon0-pixel-clock is the 
> > > > > > > > > > typical
> > > > > > > > > > MIPI clock topology in Allwinner DSI controller.
> > > > > > > > > >
> > > > > > > > > > TCON dotclock driver is computing the desired DCLK divider 
> > > > > > > > > > based on
> > > > > > > > > > panel pixel clock along with input DCLK min, max divider 
> > > > > > > > > > values from
> > > > > > > > > > tcon driver and that would eventually set the pll-mipi 
> > > > > > > > > > clock rate.
> > > > > > > > > >
> > > > > > > > > > The current code is passing dsi min and max divider value 
> > > > > > > > > > as 4 via
> > > > > > > > > > tcon driver which would ended-up triggering below vblank 
> > > > > > > > > > wait timed out
> > > > > > > > > > warning on "bananapi,s070wv20-ct16" panel.
> > > > > > > > > >
> > > > > > > > > >  WARNING: CPU: 0 PID: 31 at 
> > > > > > > > > > drivers/gpu/drm/drm_atomic_helper.c:1429 
> > > > > > > > > > drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0
> > > > > > > > > >  [CRTC:46:crtc-0] vblank wait timed out
> > > > > > > > > >  Modules linked in:
> > > > > > > > > >  CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted 
> > > > > > > > > > 5.1.0-next-20190514-00025-g5186cdf10757-dirty #6
> > > > > > > > > >  Hardware name: Allwinner sun8i Family
> > > > > > > > > >  Workqueue: events deferred_probe_work_func
> > > > > > > > > >  [] (unwind_backtrace) from [] 
> > > > > > > > > > (show_stack+0x10/0x14)
> > > > > > > > > >  [] (show_stack) from [] 
> > > > > > > > > > (dump_stack+0x84/0x98)
> > > > > > > > > >  [] (dump_stack) from [] 
> > > > > > > > > > (__warn+0xfc/0x114)
> > > > > > > > > >  [] (__warn) from [] 
> > > > > > > > > > (warn_slowpath_fmt+0x44/0x68)
> > > > > > > > > >  [] (warn_slowpath_fmt) from [] 
> > > > > > > > > > (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0)
> > > > > > > > > >  [] (drm_atomic_helper_wait_for_vblanks.part.1) 
> > > > > > > > > > from [] 
> > > > > > > > > > (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c)
> > > > > > > > > >  [] (drm_atomic_helper_commit_tail_rpm) from 
> > > > > > > > > > [] (commit_tail+0x40/0x6c)
> > > > > > > > > >  [] (commit_tail) from [] 
> > > > > > > > > > (drm_atomic_helper_commit+0xbc/0x128)
> > > > > > > > > >  [] (drm_atomic_helper_commit) from [] 
> > > > > > > > > > (restore_fbdev_mode_atomic+0x1cc/0x1dc)
> > > > > > > > > >  [] (restore_fbdev_mode_atomic) from [] 
> > > > > > > > > > (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0)
> > > > > > > > > >  [] (drm_fb_helper_restore_fbdev_mode_unlocked) 
> > > > > > > > > > from [] (drm_fb_helper_set_par+0x30/0x54)
> > > > > > > > > >  [] (drm_fb_helper_set_par) from [] 
> > > > > > > > > > (fbcon_init+0x560/0x5ac)
> > > > > > > > > >  [] (fbcon_init) from [] 
> > > > > > > > > > (visual_init+0xbc/0x104)
> > > > > > > > > >  [] (visual_init) from [] 
> > > > > > > > > > (do_bind_con_driver+0x1b0/0x390)
> > > > > > > > > >  [] (do_bind_con_driver) from [] 
> > > > > > > > > > (do_take_over_console+0x13c/0x1c4)
> > > > > > > > > >  [] (do_take_over_console) from [] 
> > > > > > > > > > (do_fbcon_takeover+0x74/0xcc)
> > > > > > > > > >  [] (do_fbcon_takeover) from [] 
> > > > > > > > > > (notifier_call_chain+0x44/0x84)
> > > > > > > > > >  [] (notifier_call_chain) from [] 
> > > > > > > > > > (__blocking_notifier_call_chain+0x48/0x60)
> > > > > > > > > >  [] (__blocking_notifier_call_chain) from 
> > > > > > > > > > [] (blocking_notifier_call_chain+0x18/0x20)
> > > > > > > > > >  [] (blocking_notifier_call_chain) from 
> > > > > > > > > > [] (register_framebuffer+0x1e0/0x2f8)
> > > > > > > > > >  [] (register_framebuffer) from [] 
> > > > > > > > > > (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c)
> > > > > > > > > >  [] (__drm_fb_helper_initial_config_and_unlock) 
> > > > > > > > > > from [] (drm_fbdev_client_hotplug+0xe8/0x1b8)
> > > > > > > > > >  [] (drm_fbdev_client_hotplug) from [] 
> > > > > > > > > > (drm_fbdev_generic_setup+0x88/0x118)
> > > > > > > > > >  [] (drm_fbdev_generic_setup) from [] 
> > > > > > > > > > (sun4i_drv_bind+0x128/0x160)
> > > > > > > > > >  [] (sun4i_drv_bind) from [] 
> > > > > > > > > > (try_to_bring_up_master+0x164/0x1a0)
> > > > > > > > > 

Re: [PATCH 4/5] drm/msm/dsi: get the clocks into OFF state at init

[Rob Clark]

On Mon, Jul 1, 2019 at 11:37 AM Jeffrey Hugo  wrote:
>
> On 6/30/2019 9:01 AM, Rob Clark wrote:
> > From: Rob Clark 
> >
> > Do an extra enable/disable cycle at init, to get the clks into disabled
> > state in case bootloader left them enabled.
> >
> > In case they were already enabled, the clk_prepare_enable() has no real
> > effect, other than getting the enable_count/prepare_count into the right
> > state so that we can disable clocks in the correct order.  This way we
> > avoid having stuck clocks when we later want to do a modeset and set the
> > clock rates.
> >
> > Signed-off-by: Rob Clark 
> > ---
> >   drivers/gpu/drm/msm/dsi/dsi_host.c | 18 +++---
> >   drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c |  1 +
> >   2 files changed, 16 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c 
> > b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
> > index aabab6311043..d0172d8db882 100644
> > --- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
> > +++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
> > @@ -354,6 +354,7 @@ static int dsi_pll_10nm_lock_status(struct dsi_pll_10nm 
> > *pll)
> >   if (rc)
> >   pr_err("DSI PLL(%d) lock failed, status=0x%08x\n",
> >  pll->id, status);
> > +rc = 0; // HACK, this will fail if PLL already running..
>
> Umm, why?  Is this intentional?
>

I need to sort out a proper solution for this.. but PLL lock will fail
if the clk is already running (which, in that case, is fine since it
is already running and locked), which will cause the clk_enable to
fail..

I guess there is some way that I can check that clk is already running
and skip this check..

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

Re: [PATCH 5/5] drm/bridge: ti-sn65dsi86: support booloader enabled display

[Jeffrey Hugo]

On 6/30/2019 9:01 AM, Rob Clark wrote:

From: Rob Clark 

Request the enable gpio ASIS to avoid disabling bridge during probe, if
already enabled.  And if already enabled, defer enabling runpm until
attach to avoid cutting off the power to the bridge.

Once we get to attach, we know panel and drm driver are probed
successfully, so at this point it i s safe to enable runpm and reset the


is?


bridge.  If we do it earlier, we kill efifb (in the case that panel or
drm driver do not probe successfully, giving the user no way to see what
is going on.


Where should the missing ")" be?

Re: [PATCH 4/5] drm/msm/dsi: get the clocks into OFF state at init

[Jeffrey Hugo]

On 6/30/2019 9:01 AM, Rob Clark wrote:

From: Rob Clark 

Do an extra enable/disable cycle at init, to get the clks into disabled
state in case bootloader left them enabled.

In case they were already enabled, the clk_prepare_enable() has no real
effect, other than getting the enable_count/prepare_count into the right
state so that we can disable clocks in the correct order.  This way we
avoid having stuck clocks when we later want to do a modeset and set the
clock rates.

Signed-off-by: Rob Clark 
---
  drivers/gpu/drm/msm/dsi/dsi_host.c | 18 +++---
  drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c |  1 +
  2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c 
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
index aabab6311043..d0172d8db882 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
@@ -354,6 +354,7 @@ static int dsi_pll_10nm_lock_status(struct dsi_pll_10nm 
*pll)
if (rc)
pr_err("DSI PLL(%d) lock failed, status=0x%08x\n",
   pll->id, status);
+rc = 0; // HACK, this will fail if PLL already running..


Umm, why?  Is this intentional?


--
Jeffrey Hugo
Qualcomm Datacenter Technologies as an affiliate of Qualcomm 
Technologies, Inc.

Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [Freedreno] [PATCH 3/5] drm/msm/dsi: split clk rate setting and enable

[Jeffrey Hugo]

On Sun, Jun 30, 2019 at 9:03 AM Rob Clark  wrote:
>
> From: Rob Clark 
>
> Prep work for the following patch.
>
> Signed-off-by: Rob Clark 

Reviewed-by: Jeffrey Hugo 

Re: [PATCH 1/5] clk: inherit clocks enabled by bootloader

[Eric Anholt]

Rob Clark  writes:

> From: Rob Clark 
>
> The goal here is to support inheriting a display setup by bootloader,
> although there may also be some non-display related use-cases.
>
> Rough idea is to add a flag for clks and power domains that might
> already be enabled when kernel starts, and which should not be
> disabled at late_initcall if the kernel thinks they are "unused".
>
> If bootloader is enabling display, and kernel is using efifb before
> real display driver is loaded (potentially from kernel module after
> userspace starts, in a typical distro kernel), we don't want to kill
> the clocks and power domains that are used by the display before
> userspace starts.
>
> Signed-off-by: Rob Clark 

Raspberry Pi is carrying downstream hacks to do similar stuff, and it
would be great to see CCF finally support this.


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

Re: [Freedreno] [PATCH 2/5] genpd/gdsc: inherit display powerdomain from bootloader

[Jeffrey Hugo]

On Sun, Jun 30, 2019 at 9:02 AM Rob Clark  wrote:
>
> From: Rob Clark 
>
> Mark power domains that may be enabled by bootloader, and which should
> not be disabled until a driver takes them over.
>
> This keeps efifb alive until the real driver can be probed.  In a distro
> kernel, the driver will most likely built as a module, and not probed
> until we get to userspace (after late_initcall)
>
> Signed-off-by: Rob Clark 

Reviewed-by: Jeffrey Hugo 

Re: [PATCH v5 09/12] drm/virtio: rework virtio_gpu_object_create fencing

[Gurchetan Singh]

On Fri, Jun 28, 2019 at 5:14 AM Gerd Hoffmann  wrote:
>
> Use gem reservation helpers and direct reservation_object_* calls
> instead of ttm.
>
> v5: fix fencing (Chia-I Wu).
> v3: Due to using the gem reservation object it is initialized and ready
> for use before calling ttm_bo_init, so we can also drop the tricky fence
> logic which checks whenever the command is in flight still.  We can
> simply fence our object before submitting the virtio command and be done
> with it.
>
> Signed-off-by: Gerd Hoffmann 
> Acked-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/virtio/virtgpu_drv.h|  2 +
>  drivers/gpu/drm/virtio/virtgpu_object.c | 55 ++---
>  drivers/gpu/drm/virtio/virtgpu_vq.c |  4 ++
>  3 files changed, 27 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index 356d27132388..c4b266b6f731 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -267,6 +267,7 @@ void virtio_gpu_free_vbufs(struct virtio_gpu_device
*vgdev);
>  void virtio_gpu_cmd_create_resource(struct virtio_gpu_device *vgdev,
> struct virtio_gpu_object *bo,
> struct virtio_gpu_object_params
*params,
> +   struct virtio_gpu_object_array *objs,
> struct virtio_gpu_fence *fence);
>  void virtio_gpu_cmd_unref_resource(struct virtio_gpu_device *vgdev,
>uint32_t resource_id);
> @@ -329,6 +330,7 @@ void
>  virtio_gpu_cmd_resource_create_3d(struct virtio_gpu_device *vgdev,
>   struct virtio_gpu_object *bo,
>   struct virtio_gpu_object_params *params,
> + struct virtio_gpu_object_array *objs,
>   struct virtio_gpu_fence *fence);
>  void virtio_gpu_ctrl_ack(struct virtqueue *vq);
>  void virtio_gpu_cursor_ack(struct virtqueue *vq);
> diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
b/drivers/gpu/drm/virtio/virtgpu_object.c
> index 82bfbf983fd2..fa0ea22c68b0 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_object.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_object.c
> @@ -97,7 +97,9 @@ int virtio_gpu_object_create(struct virtio_gpu_device
*vgdev,
>  struct virtio_gpu_object **bo_ptr,
>  struct virtio_gpu_fence *fence)
>  {
> +   struct virtio_gpu_object_array *objs = NULL;
> struct virtio_gpu_object *bo;
> +   struct ww_acquire_ctx ticket;
> size_t acc_size;
> int ret;
>
> @@ -123,12 +125,29 @@ int virtio_gpu_object_create(struct
virtio_gpu_device *vgdev,
> }
> bo->dumb = params->dumb;
>
> +   if (fence) {
> +   objs = virtio_gpu_array_alloc(1);
> +   objs->objs[0] = >gem_base;
> +   drm_gem_object_get(objs->objs[0]);

So we take a reference every-time create/submit_cmd are fenced?  Why don't
we take a reference during {virtio_gpu_cmd_transfer_from_host_3d,
virtio_gpu_transfer_to_host_ioctl}?

Does the GEM common code wait on the reservation object before calling
virtio_gpu_gem_object_close?  If not, would it make sense to wait on the
reservation object with MAX_SCHEDULE_TIMEOUT in virtio_gpu_free_object?

> +
> +   ret = drm_gem_lock_reservations(objs->objs, objs->nents,
> +   );
> +   if (ret == 0)
> +
reservation_object_add_excl_fence(objs->objs[0]->resv,
> + >f);
> +   }
> +
> if (params->virgl) {
> -   virtio_gpu_cmd_resource_create_3d(vgdev, bo, params,
fence);
> +   virtio_gpu_cmd_resource_create_3d(vgdev, bo, params,
> + objs, fence);
> } else {
> -   virtio_gpu_cmd_create_resource(vgdev, bo, params, fence);
> +   virtio_gpu_cmd_create_resource(vgdev, bo, params,
> +  objs, fence);
> }
>
> +   if (fence)
> +   drm_gem_unlock_reservations(objs->objs, objs->nents,
);
> +
> virtio_gpu_init_ttm_placement(bo);
> ret = ttm_bo_init(>mman.bdev, >tbo, params->size,
>   ttm_bo_type_device, >placement, 0,
> @@ -139,38 +158,6 @@ int virtio_gpu_object_create(struct
virtio_gpu_device *vgdev,
> if (ret != 0)
> return ret;
>
> -   if (fence) {
> -   struct virtio_gpu_fence_driver *drv = >fence_drv;
> -   struct list_head validate_list;
> -   struct ttm_validate_buffer mainbuf;
> -   struct ww_acquire_ctx ticket;
> -   unsigned long irq_flags;
> -   bool signaled;
> -
> -   INIT_LIST_HEAD(_list);
> -   memset(, 0, 

Re: [Freedreno] [PATCH 1/5] clk: inherit clocks enabled by bootloader

[Jeffrey Hugo]

On Sun, Jun 30, 2019 at 9:02 AM Rob Clark  wrote:
>
> From: Rob Clark 
>
> The goal here is to support inheriting a display setup by bootloader,
> although there may also be some non-display related use-cases.
>
> Rough idea is to add a flag for clks and power domains that might
> already be enabled when kernel starts, and which should not be
> disabled at late_initcall if the kernel thinks they are "unused".
>
> If bootloader is enabling display, and kernel is using efifb before
> real display driver is loaded (potentially from kernel module after
> userspace starts, in a typical distro kernel), we don't want to kill
> the clocks and power domains that are used by the display before
> userspace starts.
>
> Signed-off-by: Rob Clark 

Seems sane to me.  I'm curious what Stephen Boyd thinks.
I'll try to give it a spin on one of the 835 laptops.

Reviewed-by: Jeffrey Hugo 

[PATCH] drm/msm/mdp5: Add msm8998 support

[Jeffrey Hugo]

Add support for MDP5 version v3.0 found on msm8998.

Signed-off-by: Jeffrey Hugo 
---

8998 support could probably be MDP5 or DPU.  This MDP5 support works,
but may not support all of the features that 8998 supports.  However,
DPU seems to only support 845 (MDP v4.0) with fundamental assumptions
about the base level a features supported, some of which 8998 does not
infact support, so DPU would likely need significant re-writes to
support 8998.  I'm not sure the effort is worth it since MDP5 needs so
little effort to support 8998.

 drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 132 ++-
 1 file changed, 128 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
index dd1daf0e305a..fb4762cec4f1 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
@@ -630,7 +630,115 @@ const struct mdp5_cfg_hw msm8917_config = {
.max_clk = 32000,
 };
 
-static const struct mdp5_cfg_handler cfg_handlers[] = {
+const struct mdp5_cfg_hw msm8998_config = {
+   .name = "msm8998",
+   .mdp = {
+   .count = 1,
+   .caps = MDP_CAP_DSC |
+   MDP_CAP_CDM |
+   MDP_CAP_SRC_SPLIT |
+   0,
+   },
+   .ctl = {
+   .count = 5,
+   .base = { 0x01000, 0x01200, 0x01400, 0x01600, 0x01800 },
+   .flush_hw_mask = 0xf7ff,
+   },
+   .pipe_vig = {
+   .count = 4,
+   .base = { 0x04000, 0x06000, 0x08000, 0x0a000 },
+   .caps = MDP_PIPE_CAP_HFLIP  |
+   MDP_PIPE_CAP_VFLIP  |
+   MDP_PIPE_CAP_SCALE  |
+   MDP_PIPE_CAP_CSC|
+   MDP_PIPE_CAP_DECIMATION |
+   MDP_PIPE_CAP_SW_PIX_EXT |
+   0,
+   },
+   .pipe_rgb = {
+   .count = 4,
+   .base = { 0x14000, 0x16000, 0x18000, 0x1a000 },
+   .caps = MDP_PIPE_CAP_HFLIP  |
+   MDP_PIPE_CAP_VFLIP  |
+   MDP_PIPE_CAP_SCALE  |
+   MDP_PIPE_CAP_DECIMATION |
+   MDP_PIPE_CAP_SW_PIX_EXT |
+   0,
+   },
+   .pipe_dma = {
+   .count = 2, /* driver supports max of 2 currently */
+   .base = { 0x24000, 0x26000, 0x28000, 0x2a000 },
+   .caps = MDP_PIPE_CAP_HFLIP  |
+   MDP_PIPE_CAP_VFLIP  |
+   MDP_PIPE_CAP_SW_PIX_EXT |
+   0,
+   },
+   .pipe_cursor = {
+   .count = 2,
+   .base = { 0x34000, 0x36000 },
+   .caps = MDP_PIPE_CAP_HFLIP  |
+   MDP_PIPE_CAP_VFLIP  |
+   MDP_PIPE_CAP_SW_PIX_EXT |
+   MDP_PIPE_CAP_CURSOR |
+   0,
+   },
+
+   .lm = {
+   .count = 6,
+   .base = { 0x44000, 0x45000, 0x46000, 0x47000, 0x48000, 0x49000 
},
+   .instances = {
+   { .id = 0, .pp = 0, .dspp = 0,
+ .caps = MDP_LM_CAP_DISPLAY |
+ MDP_LM_CAP_PAIR, },
+   { .id = 1, .pp = 1, .dspp = 1,
+ .caps = MDP_LM_CAP_DISPLAY, },
+   { .id = 2, .pp = 2, .dspp = -1,
+ .caps = MDP_LM_CAP_DISPLAY |
+ MDP_LM_CAP_PAIR, },
+   { .id = 3, .pp = -1, .dspp = -1,
+ .caps = MDP_LM_CAP_WB, },
+   { .id = 4, .pp = -1, .dspp = -1,
+ .caps = MDP_LM_CAP_WB, },
+   { .id = 5, .pp = 3, .dspp = -1,
+ .caps = MDP_LM_CAP_DISPLAY, },
+},
+   .nb_stages = 8,
+   .max_width = 2560,
+   .max_height = 0x,
+   },
+   .dspp = {
+   .count = 2,
+   .base = { 0x54000, 0x56000 },
+   },
+   .ad = {
+   .count = 3,
+   .base = { 0x78000, 0x78800, 0x79000 },
+   },
+   .pp = {
+   .count = 4,
+   .base = { 0x7, 0x70800, 0x71000, 0x71800 },
+   },
+   .cdm = {
+   .count = 1,
+   .base = { 0x79200 },
+   },
+   .dsc = {
+   .count = 2,
+   .base = { 0x8, 0x80400 },
+   },
+   .intf = {
+   .base = { 0x6a000, 0x6a800, 0x6b000, 0x6b800, 0x6c000 },
+   .connect = {
+   [0] = INTF_eDP,
+   [1] = INTF_DSI,
+   [2] = INTF_DSI,
+

[PATCH] drm/msm/mdp5: Use eariler mixers when possible

[Jeffrey Hugo]

When assigning a mixer, we will iterate through the entire list looking for
a suitable match.  This results in selecting the last match.  We should
stop at the first match, since lower numbered mixers will typically have
more capabilities, and are likely to be what the bootloader used, if we
are looking to reuse the bootloader config in future.

Signed-off-by: Jeffrey Hugo 
---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_mixer.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_mixer.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_mixer.c
index 954db683ae44..1638042ad974 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_mixer.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_mixer.c
@@ -96,6 +96,17 @@ int mdp5_mixer_assign(struct drm_atomic_state *s, struct 
drm_crtc *crtc,
 */
if (!(*mixer) || cur->caps & MDP_LM_CAP_PAIR)
*mixer = cur;
+
+   /*
+* We have everything we could want, exit early.
+* We have a valid mixer, that mixer pairs with another if we
+* need that ability in future, and we have a right mixer if
+* needed.
+* Later LMs could be less optimal
+*/
+   if (*mixer && (*mixer)->caps & MDP_LM_CAP_PAIR &&
+   ((r_mixer && *r_mixer) || !r_mixer))
+   break;
}
 
if (!(*mixer))
-- 
2.17.1

[PATCH] drm/msm/mdp5: Use drm_device for creating gem address space

[Jeffrey Hugo]

Creating the msm gem address space requires a reference to the dev where
the iommu is located.  The driver currently assumes this is the same as
the platform device, which breaks when the iommu is outside of the
platform device.  Use the drm_device instead, which happens to always have
a reference to the proper device.

Signed-off-by: Jeffrey Hugo 
---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 4a60f5fca6b0..1347a5223918 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -702,7 +702,7 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
mdelay(16);
 
if (config->platform.iommu) {
-   aspace = msm_gem_address_space_create(>dev,
+   aspace = msm_gem_address_space_create(dev->dev,
config->platform.iommu, "mdp5");
if (IS_ERR(aspace)) {
ret = PTR_ERR(aspace);
-- 
2.17.1

Re: [PATCH v5 1/7] dt-bindings: Add panel-timing subnode to simple-panel

[Doug Anderson]

Hi,

On Sun, Jun 30, 2019 at 1:03 PM Sam Ravnborg  wrote:
>
> Hi Douglas.
>
> Some long overdue review feedback.
>
> On Mon, Apr 01, 2019 at 10:17:18AM -0700, Douglas Anderson wrote:
> > From: Sean Paul 
> >
> > This patch adds a new subnode to simple-panel allowing us to override
> > the typical timing expressed in the panel's display_timing.
> >
> > Changes in v2:
> >  - Split out the binding into a new patch (Rob)
> >  - display-timings is a new section (Rob)
> >  - Use the full display-timings subnode instead of picking the timing
> >out (Rob/Thierry)
> > Changes in v3:
> >  - Go back to using the timing subnode directly, but rename to
> >panel-timing (Rob)
> > Changes in v4:
> >  - Simplify desc. for when override should be used (Thierry/Laurent)
> >  - Removed Rob H review since it's been a year and wording changed
> > Changes in v5:
> >  - Removed bit about OS may ignore (Rob/Ezequiel)
> >
> > Cc: Doug Anderson 
> > Cc: Eric Anholt 
> > Cc: Heiko Stuebner 
> > Cc: Jeffy Chen 
> > Cc: Rob Herring 
> > Cc: Stéphane Marchesin 
> > Cc: Thierry Reding 
> > Cc: devicet...@vger.kernel.org
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: linux-rockc...@lists.infradead.org
> > Signed-off-by: Sean Paul 
> > Signed-off-by: Douglas Anderson 
> > ---
> >
> >  .../bindings/display/panel/simple-panel.txt   | 22 +++
> >  1 file changed, 22 insertions(+)
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/display/panel/simple-panel.txt 
> > b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> > index b2b872c710f2..93882268c0b9 100644
> > --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> > +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> > @@ -15,6 +15,16 @@ Optional properties:
> >(hot plug detect) signal, but the signal isn't hooked up so we should
> >hardcode the max delay from the panel spec when powering up the panel.
> >
> > +panel-timing subnode
> > +
> > +
> > +This optional subnode is for devices which require a mode differing
> > +from the panel's "typical" display timing.
> Meybe add here that it is expected that the panel has included timing
> in the driver itself, and not as part of DT.
> So what is specified here is a more precise variant, within the limits
> of what is specified for the panel.

See discussions previous versions of this patch.  Specifically you can
see v4 at  and v3
(posted by Sean) at .

Specifically: According to Rob H it is generally not required to
validate what's in device tree--it can be just blindly applied.  Thus
the bindings shouldn't really say anything about trying to reconcile
with the driver (especially since that's heavily relying on the
current driver implementation).

At the moment the driver still does validate things and we could
discuss removing that in a future patchset if it was deemed important
/ desirable.


> > +Format information on the panel-timing subnode can be found in
> > +display-timing.txt.
> display-timing defines otional properties:
> hsync-active, pixelclk-active, doublescan etc.
> It is not from the above obvious which properties from display-timings
> that can be specified for a panel-timing sub-node.
> Maybe because they can all be specified?
>
> Display-timing allows timings to be specified as a range.
> If it is also OK to specify a range for panle-timing then everythign is
> fine. But if the panel-timign subnode do not allow ranges this needs to
> be specified.

One thing to think about here is that the bindings are a bit divorced
from the real world.  Specifically the bindings should describe
hardware / what's possible and it's OK for bindings to describe things
that aren't yet supported in code.  You've gotta be really careful
here, of course, because it's easy to write ridiculous bindings if
there is no implementation backing them up, but in general that's
supposed to be the idea.

Here it seems like it should be possible to specify timings as a range
and that would be a sensible thing to do.  ...and we're already using
existing code to parse this node, specifically
of_get_display_timing().  If simple-panel can't (yet) handle
reconciling ranges specified in DT then presumably we shouldn't rely
on that yet.  ...but if it becomes useful then we can add it later.
...but it's OK to already have it in the bindings.

Did that make sense?  If I'm misunderstanding something about the
situation then please yell!  :-)

I will also note that perhaps we shouldn't nit-pick too much as per
Rob's comment in the cover letter [1] of v5 of the series.
Specifically he said this binding is going away anyway.

Summary: I think I have no actions here and this could go to drm-misc
with Theirry's Ack plus other tags.


[1] https://lore.kernel.org/patchwork/cover/1057038/
___
dri-devel mailing list

Re: [PATCH 1/4] gpu: Use dev_get_drvdata()

[Emil Velikov]

On Mon, 1 Jul 2019 at 13:37, Emil Velikov  wrote:
>
> Hi Fuqian,
>
> On Mon, 1 Jul 2019 at 08:13, Fuqian Huang  wrote:
> >
> > Using dev_get_drvdata directly.
> >
> > Signed-off-by: Fuqian Huang 
> > ---
> >  drivers/gpu/drm/msm/adreno/adreno_device.c  |  6 ++
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 13 +
> >  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c|  6 ++
> >  drivers/gpu/drm/msm/dsi/dsi_host.c  |  6 ++
> >  drivers/gpu/drm/msm/msm_drv.c   |  3 +--
> >  drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 15 +--
> >  drivers/gpu/drm/panfrost/panfrost_device.c  |  6 ++
> As far as i can see the patch is spot on, thanks for that.
>
> Can you split this in three since it covers 3 separate drivers.

Quick grep for "platform_get_drvdata(to_platform_device" showed a few
instances through various drivers - exynos, msm, etc.
If you can address those with v2 that would be great.

-Emil

Re: [PATCH v2 2/4] backlight: Expose brightness curve type through sysfs

[Matthias Kaehlcke]

Hi,

On Fri, Jun 28, 2019 at 09:34:52AM +0100, Daniel Thompson wrote:
> On Wed, Jun 26, 2019 at 04:56:11PM +0200, Pavel Machek wrote:
> > Hi!
> > 
> > > Export the type of the brightness curve via the new sysfs attribute
> > > 'scale'. The value of the attribute may be a simple string like
> > > 'linear' or 'non-linear', or a composite string similar to
> > > 'compatible' strings of the device tree. A composite string consists
> > > of different elements separated by commas, starting with the
> > > most-detailed description and ending with the least-detailed one. An
> > > example for a composite string is "cie-1931,perceptual,non-linear"
> > > This brightness curve was generated with the CIE 1931 algorithm, it
> > > is perceptually linear, but not actually linear in terms of the
> > > emitted light. If userspace doesn't know about 'cie-1931' or
> > > 'perceptual' it should at least be able to interpret the 'non-linear'
> > > part.
> > 
> > I'm not sure the comma-separated thing is a good idea. If it is, it should 
> > go to the Documentation, not to changelog.
> 
> So I viewed the comma-separated thing as allow us to describe facts about
> the scale used.
> 
> In particular I suspect that some controllers will be non-linear *and*
> non-perceptual and that some userspaces, particularly those that animate
> backlight changes, may care enough about the difference to ask us to add
> another fact to the set that describes that scale.
> 
> Having said that I do share your concern that the comma-separated list
> is overengineered and that all userspaces will end up implementing
> something like:
> 
> if (strstr("non-linear", scale) {
>   mode = PERCEPTUAL;
> } else if (strstr("unknown", scale) {
>   mode = use_existing_hueristic();
> } else {
>   mode = LINEAR;
> }

I agree that this is not unlikely ...

So let's just make it 'linear', 'non-linear' and 'unknown'?

> > > +What:/sys/class/backlight//scale
> > > +Date:June 2019
> > > +KernelVersion:   5.4
> > > +Contact: Daniel Thompson 
> > > +Description:
> > > + Description of the scale of the brightness curve. The
> > > + description consists of one or more elements separated by
> > > + commas, from the most detailed to the least detailed
> > > + description.
> > > +
> > > + Possible values are:
> > > +
> > > + unknown
> > > +   The scale of the brightness curve is unknown.
> > > +
> > > + linear
> > > +   The brightness changes linearly in terms of the emitted
> > > +   light, changes are perceived as non-linear by the human eye.
> > > +
> > > + non-linear
> > > +   The brightness changes non-linearly in terms of the emitted
> > > +   light, changes might be perceived as linear by the human eye.
> > 
> > non-linear is not too useful as described.
> 
> Agree.
> 
> The idea is that allows a userspace with simple backlight needs to
> simple map the brightness property directly to a slider using the
> approach above without worrying about perceptual or (possible future)
> logarithmic scales. Such an approach won't be perfect but it
> probably won't feel horrible for the user either.
> 
> Arguably the descriptions should move away from the raw factual
> approach and describe what advise the kernel of offering the
> userspace.

ok, I'll change it in the next revision

> > > + perceptual,non-linear
> > > +   The brightness changes non-linearly in terms of the emitted
> > > +   light, changes should be perceived as linear by the human eye.
> > > +
> > > + cie-1931,perceptual,non-linear
> > > +   The brightness curve was calculated with the CIE 1931
> > > +   algorithm. Brightness changes non-linearly in terms of the
> > > +   emitted light, changes should be perceived as linear by the
> > > +   human eye.
> > 
> > Is it useful to know difference between perceptual, and cie-1931?
> 
> Depends how assertive the userspaces are!
> 
> If they follow the "fix kernel bugs in the kernel" mantra rather than
> implement workarounds and heuristics then I suspect it would not be used
> much.
> 
> 
> > Would it be useful to export absolute values in some well-known units?
> > 
> > If I'm in dark room, I may want 100mW/m^2 of backlight... And it would
> > be nice if I could set same backlight intensity on all my devices
> > easily.
> 
> I'm a little sceptical that we could calibrate an absolute scale on
> enough devices for such a property to be useful. I think it would be
> "unknown" on almost every system.

I share your scepticism and would expect most devices to remain
"unknown"

Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing

[Doug Anderson]

Hi,

On Sun, Jun 30, 2019 at 1:22 PM Sam Ravnborg  wrote:
>
> > @@ -91,6 +92,8 @@ struct panel_simple {
> >   struct i2c_adapter *ddc;
> >
> >   struct gpio_desc *enable_gpio;
> > +
> > + struct drm_display_mode override_mode;
> I fail to see where this poiter is assigned.

In panel_simple_parse_override_mode().  Specifically:

drm_display_mode_from_videomode(, >override_mode);


> @@ -152,6 +162,44 @@ static int panel_simple_get_fixed_modes(struct 
> panel_simple *panel)
> >   num++;
> >   }
> >
> > + return num;
> > +}
> > +
> > +static int panel_simple_get_non_edid_modes(struct panel_simple *panel)
> > +{
> > + struct drm_connector *connector = panel->base.connector;
> > + struct drm_device *drm = panel->base.drm;
> > + struct drm_display_mode *mode;
> > + bool has_override = panel->override_mode.type;
> This looks suspicious.
> panel->override_mode.type is an unsigned int that may have a number of
> bits set.
> So the above code implicitly convert a .type != 0 to a true.
> This can be expressed in a much more reader friendly way.

You would suggest that I add a boolean field to a structure to
indicate whether an override mode is present?  I will certainly do
that if you're sure that's what you want, but my understanding of the
convention for much of the kernel is that you generally rely on
structures being zero-initialized and then (assuming that zero isn't a
valid value) it's safe to confirm they've been initialized by seeing
that they're non-zero.

In this case panel_simple_parse_override_mode() will _definitely_ set
a non-zero value for this field in the case that it ran to completion.
...and, even further, the end of that function has a WARN_ON() if it
doesn't.

Any chance you missed reading panel_simple_parse_override_mode() in
the original patch?


> And on top of this, I cannot see that panel->override_mode points to a
> valid instance of display_mode, at least not always.

override_mode isn't a pointer, right?  It's a structure straight in
the panel.  So all its fields will be initted to 0 by the kzalloc in
panel_simple_probe().  If the type is non-zero then we know
panel_simple_parse_override_mode() finished to completion.


> > @@ -268,7 +316,7 @@ static int panel_simple_get_modes(struct drm_panel 
> > *panel)
> >   }
> >
> >   /* add hard-coded panel modes */
> > - num += panel_simple_get_fixed_modes(p);
> > + num += panel_simple_get_non_edid_modes(p);
> >
> >   return num;
> >  }
> > @@ -299,10 +347,58 @@ static const struct drm_panel_funcs 
> > panel_simple_funcs = {
> >   .get_timings = panel_simple_get_timings,
> >  };
> >
> > +#define PANEL_SIMPLE_BOUNDS_CHECK(to_check, bounds, field) \
> > + (to_check->field.typ >= bounds->field.min && \
> > +  to_check->field.typ <= bounds->field.max)
> > +static void panel_simple_parse_override_mode(struct device *dev,
> > +  struct panel_simple *panel,
> > +  const struct display_timing *ot)
> > +{
> > + const struct panel_desc *desc = panel->desc;
> > + struct videomode vm;
> > + unsigned int i;
> > +
> > + if (WARN_ON(desc->num_modes)) {
> > + dev_err(dev, "Reject override mode: panel has a fixed 
> > mode\n");
> > + return;
> > + }
> > + if (WARN_ON(!desc->num_timings)) {
> > + dev_err(dev, "Reject override mode: no timings specified\n");
> > + return;
> > + }
> > +
> > + for (i = 0; i < panel->desc->num_timings; i++) {
> > + const struct display_timing *dt = >desc->timings[i];
> > +
> > + if (!PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hactive) ||
> > + !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hfront_porch) ||
> > + !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hback_porch) ||
> > + !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hsync_len) ||
> > + !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vactive) ||
> > + !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vfront_porch) ||
> > + !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vback_porch) ||
> > + !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vsync_len))
> > + continue;
> > +
> > + if (ot->flags != dt->flags)
> > + continue;
> The binding do not say anything about flags. Is this check really
> needed?

Flags here is an implementation detail of the Linux driver and the
bindings are supposed to be Linux-agnostic.  The bindings started out
talking about lots of stuff that happened in the driver and I was told
to take all those out.  ;-)

Specifically note that flags here holds whether we have specified a
positive or negative for hsync or vsync.  These are the "hsync-active"
and "vsync-active" properties of the panel bindings.  Take a look at
of_parse_display_timing().

...so to summarize the flags here is just a different set of
properties to check like the 

Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing

[Doug Anderson]

Hi,

On Sun, Jun 30, 2019 at 1:55 PM Sam Ravnborg  wrote:
>
> Hi Douglas.
>
> > > +
> > > +   /* Only add timings if override was not there or failed to validate */
> > > +   if (num == 0 && panel->desc->num_timings)
> > > +   num = panel_simple_get_timings_modes(panel);
> > > +
> > > +   /*
> > > +* Only add fixed modes if timings/override added no mode.
> >
> > This part I fail to understand.
> > If we have a panel where we in panel-simple have specified the timings,
> > and done so using display_timing so with proper {min, typ, max} then it
> > should be perfectly legal to specify a more precise variant in the DT
> > file.
> > Or what did I miss here?
>
> Got it now.
> If display_mode is used for timings this is what you call "fixed mode".
> Hmm, if I got confused someone else may also be confused by this naming.

The name "fixed mode" comes from the old code, though I guess in the
old code it used to refer to a mode that came from either the
display_timing or the display_mode.

How about if I call it "panel_simple_get_from_fixed_display_mode"?
...or if you have another suggestion feel free to chime in.

NOTE: Since this feedback is minor and this patch has been outstanding
for a while (and is blocking other work), I am assuming that the best
path forward is for Heiko to land this patch with Thierry's Ack and
I'll send a follow-up.  Please yell if you disagree.  I'll respond to
each of your emails separately and then wait for your response before
sending the follow-up series.


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

[Bug 107990] Got Dying Light working in Arch by changing Mesa's compile steps, how to get it working Out Of the Box?

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107990

John  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from John  ---
Yup that worked, thank you!

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

Re: [PATCH 1/4] gpu: Use dev_get_drvdata()

[Jordan Crouse]

On Mon, Jul 01, 2019 at 11:22:35AM +0800, Fuqian Huang wrote:
> Using dev_get_drvdata directly.

msm parts LGTM.  If you split the patches feel free to add my

Acked-by: Jordan Crouse 

> Signed-off-by: Fuqian Huang 
> ---
>  drivers/gpu/drm/msm/adreno/adreno_device.c  |  6 ++
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 13 +
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c|  6 ++
>  drivers/gpu/drm/msm/dsi/dsi_host.c  |  6 ++
>  drivers/gpu/drm/msm/msm_drv.c   |  3 +--
>  drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 15 +--
>  drivers/gpu/drm/panfrost/panfrost_device.c  |  6 ++
>  7 files changed, 19 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> index b3deb346a42b..fafd00d2574a 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -403,16 +403,14 @@ static const struct of_device_id dt_match[] = {
>  #ifdef CONFIG_PM
>  static int adreno_resume(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct msm_gpu *gpu = platform_get_drvdata(pdev);
> + struct msm_gpu *gpu = dev_get_drvdata(dev);
>  
>   return gpu->funcs->pm_resume(gpu);
>  }
>  
>  static int adreno_suspend(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct msm_gpu *gpu = platform_get_drvdata(pdev);
> + struct msm_gpu *gpu = dev_get_drvdata(dev);
>  
>   return gpu->funcs->pm_suspend(gpu);
>  }
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index ae885e5dd07d..6c6f8ca9380f 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -1025,16 +1025,15 @@ static int dpu_bind(struct device *dev, struct device 
> *master, void *data)
>  
>  static void dpu_unbind(struct device *dev, struct device *master, void *data)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
> + struct dpu_kms *dpu_kms = dev_get_drvdata(dev);
>   struct dss_module_power *mp = _kms->mp;
>  
>   msm_dss_put_clk(mp->clk_config, mp->num_clk);
> - devm_kfree(>dev, mp->clk_config);
> + devm_kfree(dev, mp->clk_config);
>   mp->num_clk = 0;
>  
>   if (dpu_kms->rpm_enabled)
> - pm_runtime_disable(>dev);
> + pm_runtime_disable(dev);
>  }
>  
>  static const struct component_ops dpu_ops = {
> @@ -1056,8 +1055,7 @@ static int dpu_dev_remove(struct platform_device *pdev)
>  static int __maybe_unused dpu_runtime_suspend(struct device *dev)
>  {
>   int rc = -1;
> - struct platform_device *pdev = to_platform_device(dev);
> - struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
> + struct dpu_kms *dpu_kms = dev_get_drvdata(dev);
>   struct drm_device *ddev;
>   struct dss_module_power *mp = _kms->mp;
>  
> @@ -1077,8 +1075,7 @@ static int __maybe_unused dpu_runtime_suspend(struct 
> device *dev)
>  static int __maybe_unused dpu_runtime_resume(struct device *dev)
>  {
>   int rc = -1;
> - struct platform_device *pdev = to_platform_device(dev);
> - struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
> + struct dpu_kms *dpu_kms = dev_get_drvdata(dev);
>   struct drm_encoder *encoder;
>   struct drm_device *ddev;
>   struct dss_module_power *mp = _kms->mp;
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> index 901009e1f219..25d1ebb32e73 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> @@ -1052,8 +1052,7 @@ static int mdp5_dev_remove(struct platform_device *pdev)
>  
>  static __maybe_unused int mdp5_runtime_suspend(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct mdp5_kms *mdp5_kms = platform_get_drvdata(pdev);
> + struct mdp5_kms *mdp5_kms = dev_get_drvdata(dev);
>  
>   DBG("");
>  
> @@ -1062,8 +1061,7 @@ static __maybe_unused int mdp5_runtime_suspend(struct 
> device *dev)
>  
>  static __maybe_unused int mdp5_runtime_resume(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct mdp5_kms *mdp5_kms = platform_get_drvdata(pdev);
> + struct mdp5_kms *mdp5_kms = dev_get_drvdata(dev);
>  
>   DBG("");
>  
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index dbf490176c2c..882f13725819 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -477,8 +477,7 @@ static void dsi_bus_clk_disable(struct msm_dsi_host 
> *msm_host)
>  
>  int msm_dsi_runtime_suspend(struct device *dev)
>  {
> - struct platform_device *pdev = 

Re: [PATCH 2/4] devicetree: Update led binding

[Dan Murphy]

JJ

On 7/1/19 10:14 AM, Jean-Jacques Hiblot wrote:

Update the led binding to describe the possibility to add a "compatible"
option to create a child-device, user of the LED.

Signed-off-by: Jean-Jacques Hiblot 
Cc: devicet...@vger.kernel.org
---
  Documentation/devicetree/bindings/leds/common.txt | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/leds/common.txt 
b/Documentation/devicetree/bindings/leds/common.txt
index 70876ac11367..2f7882528d97 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -11,6 +11,9 @@ have to be tightly coupled with the LED device binding. They 
are represented
  by child nodes of the parent LED device binding.
  
  Optional properties for child nodes:

+- compatible : driver name for a child-device. This child-device is the user
+   of the LED. It is created when the LED is registered and
+  destroyed when the LED is unregistered.


Can you update the example to show usage?

Dan



  - led-sources : List of device current outputs the LED is connected to. The
outputs are identified by the numbers that must be defined
in the LED device binding documentation.

[PATCH 0/4] Add a generic driver for LED-based backlight

[Jean-Jacques Hiblot]

This series aims to add a led-backlight driver, similar to pwm-backlight,
but using a LED class device underneath.

A few years ago (2015), Tomi Valkeinen posted a series implementing a
backlight driver on top of a LED device:
https://patchwork.kernel.org/patch/7293991/
https://patchwork.kernel.org/patch/7294001/
https://patchwork.kernel.org/patch/7293981/

The discussion stopped because Tomi lacked the time to work on it.

This series takes it from there and implements the binding that was
discussed in https://patchwork.kernel.org/patch/7293991/. In this new
binding the backlight device is a child of the LED controller instead of
being another platform device that uses a phandle to reference a LED.

Jean-Jacques Hiblot (2):
  leds: of: create a child device if the LED node contains a
"compatible" string
  devicetree: Update led binding

Tomi Valkeinen (2):
  backlight: add led-backlight driver
  devicetree: Add led-backlight binding

 .../devicetree/bindings/leds/common.txt   |   3 +
 .../video/backlight/led-backlight.txt |  39 
 drivers/leds/led-class.c  |  16 ++
 drivers/video/backlight/Kconfig   |   7 +
 drivers/video/backlight/Makefile  |   1 +
 drivers/video/backlight/led_bl.c  | 217 ++
 include/linux/leds.h  |  11 +
 7 files changed, 294 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/video/backlight/led-backlight.txt
 create mode 100644 drivers/video/backlight/led_bl.c

-- 
2.17.1

[PATCH 4/4] devicetree: Add led-backlight binding

[Jean-Jacques Hiblot]

From: Tomi Valkeinen 

Add DT binding for led-backlight.

Signed-off-by: Tomi Valkeinen 
Signed-off-by: Jean-Jacques Hiblot 
Cc: devicet...@vger.kernel.org
---
 .../video/backlight/led-backlight.txt | 39 +++
 1 file changed, 39 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/video/backlight/led-backlight.txt

diff --git 
a/Documentation/devicetree/bindings/video/backlight/led-backlight.txt 
b/Documentation/devicetree/bindings/video/backlight/led-backlight.txt
new file mode 100644
index ..216cd52d624a
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/backlight/led-backlight.txt
@@ -0,0 +1,39 @@
+led-backlight bindings
+
+The node of the backlight driver IS the node of the LED.
+
+Required properties:
+  - compatible: "led-backlight"
+  - brightness-levels: Array of distinct LED brightness levels. These
+  are in the range from 0 to 255, passed to the LED class driver.
+  - default-brightness-level: the default brightness level (index into the
+  array defined by the "brightness-levels" property)
+
+Optional properties:
+  - power-supply: regulator for supply voltage
+  - enable-gpios: contains a single GPIO specifier for the GPIO which enables
+  and disables the backlight (see GPIO binding[0])
+
+[0]: Documentation/devicetree/bindings/gpio/gpio.txt
+
+Example:
+
+led_ctrl {
+   red_led@1 {
+   label = "red";
+   reg = <1>;
+   }
+
+   backlight_led@2 {
+   function = LED_FUNCTION_BACKLIGHT;
+   reg = <2>;
+
+   compatible = "led-backlight";
+
+   brightness-levels = <0 4 8 16 32 64 128 255>;
+   default-brightness-level = <6>;
+
+   power-supply = <_bl_reg>;
+   enable-gpios = < 58 0>;
+   };
+};
-- 
2.17.1

[PATCH 3/4] backlight: add led-backlight driver

[Jean-Jacques Hiblot]

From: Tomi Valkeinen 

This patch adds a led-backlight driver (led_bl), which is mostly similar to
pwm_bl except the driver uses a LED class driver to adjust the brightness
in the HW.

Signed-off-by: Tomi Valkeinen 
Signed-off-by: Jean-Jacques Hiblot 
---
 drivers/video/backlight/Kconfig  |   7 +
 drivers/video/backlight/Makefile |   1 +
 drivers/video/backlight/led_bl.c | 217 +++
 3 files changed, 225 insertions(+)
 create mode 100644 drivers/video/backlight/led_bl.c

diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 8b081d61773e..585a1787618c 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -458,6 +458,13 @@ config BACKLIGHT_RAVE_SP
help
  Support for backlight control on RAVE SP device.
 
+config BACKLIGHT_LED
+   tristate "Generic LED based Backlight Driver"
+   depends on LEDS_CLASS && OF
+   help
+ If you have a LCD backlight adjustable by LED class driver, say Y
+ to enable this driver.
+
 endif # BACKLIGHT_CLASS_DEVICE
 
 endmenu
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 63c507c07437..2a67642966a5 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -57,3 +57,4 @@ obj-$(CONFIG_BACKLIGHT_TPS65217)  += tps65217_bl.o
 obj-$(CONFIG_BACKLIGHT_WM831X) += wm831x_bl.o
 obj-$(CONFIG_BACKLIGHT_ARCXCNN)+= arcxcnn_bl.o
 obj-$(CONFIG_BACKLIGHT_RAVE_SP)+= rave-sp-backlight.o
+obj-$(CONFIG_BACKLIGHT_LED)+= led_bl.o
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
new file mode 100644
index ..e699924cc2bc
--- /dev/null
+++ b/drivers/video/backlight/led_bl.c
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2015-2018 Texas Instruments Incorporated -  http://www.ti.com/
+ * Author: Tomi Valkeinen 
+ *
+ * Based on pwm_bl.c
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct led_bl_data {
+   struct device   *dev;
+   struct backlight_device *bl_dev;
+
+   unsigned int*levels;
+   boolenabled;
+   struct regulator*power_supply;
+   struct gpio_desc*enable_gpio;
+
+   struct led_classdev *led_cdev;
+
+   unsigned int max_brightness;
+   unsigned int default_brightness;
+};
+
+static void led_bl_set_brightness(struct led_bl_data *priv, int brightness)
+{
+   int err;
+
+   if (!priv->enabled) {
+   err = regulator_enable(priv->power_supply);
+   if (err < 0)
+   dev_err(priv->dev, "failed to enable power supply\n");
+
+   if (priv->enable_gpio)
+   gpiod_set_value_cansleep(priv->enable_gpio, 1);
+   }
+
+   led_set_brightness(priv->led_cdev, priv->levels[brightness]);
+
+   priv->enabled = true;
+}
+
+static void led_bl_power_off(struct led_bl_data *priv)
+{
+   if (!priv->enabled)
+   return;
+
+   led_set_brightness(priv->led_cdev, LED_OFF);
+
+   if (priv->enable_gpio)
+   gpiod_set_value_cansleep(priv->enable_gpio, 0);
+
+   regulator_disable(priv->power_supply);
+
+   priv->enabled = false;
+}
+
+static int led_bl_update_status(struct backlight_device *bl)
+{
+   struct led_bl_data *priv = bl_get_data(bl);
+   int brightness = bl->props.brightness;
+
+   if (bl->props.power != FB_BLANK_UNBLANK ||
+   bl->props.fb_blank != FB_BLANK_UNBLANK ||
+   bl->props.state & BL_CORE_FBBLANK)
+   brightness = 0;
+
+   if (brightness > 0)
+   led_bl_set_brightness(priv, brightness);
+   else
+   led_bl_power_off(priv);
+
+   return 0;
+}
+
+static const struct backlight_ops led_bl_ops = {
+   .update_status  = led_bl_update_status,
+};
+
+static int led_bl_parse_dt(struct device *dev,
+  struct led_bl_data *priv)
+{
+   struct device_node *node = dev->of_node;
+   int num_levels;
+   u32 *levels;
+   u32 value;
+   int ret;
+
+   if (!node)
+   return -ENODEV;
+
+   num_levels = of_property_count_u32_elems(node, "brightness-levels");
+   if (num_levels < 0)
+   return num_levels;
+
+   levels = devm_kzalloc(dev, sizeof(u32) * num_levels, GFP_KERNEL);
+   if (!levels)
+   return -ENOMEM;
+
+   ret = of_property_read_u32_array(node, "brightness-levels",
+levels,
+num_levels);
+   if (ret < 0)
+   return ret;
+
+   ret = of_property_read_u32(node, "default-brightness-level", );
+   if (ret < 0)
+   return ret;
+
+   if (value >= num_levels) {
+   dev_err(dev, "invalid default-brightness-level\n");
+   

[PATCH 1/4] leds: of: create a child device if the LED node contains a "compatible" string

[Jean-Jacques Hiblot]

This allows the LED core to probe a consumer device when the LED is
registered. In that way the LED can be seen like a minimalist bus that
can handle at most one device.
This is useful to manage simple devices, the purpose of which is
mostly to drive a LED.

One example would be a LED-controlled backlight. The device-tree would look
like the following:

tlc59116@40 {
compatible = "ti,tlc59108";
reg = <0x40>;

bl@2 {
label = "backlight";
reg = <0x2>;

compatible = "led-backlight";
brightness-levels = <0 243 245 247 248 249 251 252 255>;
default-brightness-level = <8>;
};
};

Signed-off-by: Jean-Jacques Hiblot 
---
 drivers/leds/led-class.c | 16 
 include/linux/leds.h | 11 +++
 2 files changed, 27 insertions(+)

diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index 4793e77808e2..abf0e63285b9 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -306,6 +307,17 @@ int of_led_classdev_register(struct device *parent, struct 
device_node *np,
 
mutex_unlock(_cdev->led_access);
 
+   /* Parse the LED's node in the device-tree and create the consumer
+* device if needed.
+*/
+   if (np) {
+   struct platform_device *pd;
+
+   pd = of_platform_device_create(np, NULL, led_cdev->dev);
+   if (pd)
+   led_cdev->consumer = >dev;
+   }
+
dev_dbg(parent, "Registered led device: %s\n",
led_cdev->name);
 
@@ -321,6 +333,10 @@ EXPORT_SYMBOL_GPL(of_led_classdev_register);
  */
 void led_classdev_unregister(struct led_classdev *led_cdev)
 {
+   /* destroy the consummer device before removing anything else */
+   if (led_cdev->consumer)
+   of_platform_device_destroy(led_cdev->consumer, NULL);
+
 #ifdef CONFIG_LEDS_TRIGGERS
down_write(_cdev->trigger_lock);
if (led_cdev->trigger)
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 9b2bf574a17a..63feb8495f3e 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -91,6 +91,12 @@ struct led_classdev {
int (*pattern_clear)(struct led_classdev *led_cdev);
 
struct device   *dev;
+   /*
+* The consumer device is a child device created by the LED core if the
+* appropriate information (ie "compatible" string) is available in the
+* device tree. Its life cycle follows the life cycle of the LED device.
+*/
+   struct device   *consumer;
const struct attribute_group**groups;
 
struct list_head node;  /* LED Device list */
@@ -141,6 +147,11 @@ extern void devm_led_classdev_unregister(struct device 
*parent,
 extern void led_classdev_suspend(struct led_classdev *led_cdev);
 extern void led_classdev_resume(struct led_classdev *led_cdev);
 
+static inline struct led_classdev *to_led_classdev(struct device *dev)
+{
+   return (struct led_classdev *) dev_get_drvdata(dev);
+}
+
 /**
  * led_blink_set - set blinking with software fallback
  * @led_cdev: the LED to start blinking
-- 
2.17.1

[PATCH 2/4] devicetree: Update led binding

[Jean-Jacques Hiblot]

Update the led binding to describe the possibility to add a "compatible"
option to create a child-device, user of the LED.

Signed-off-by: Jean-Jacques Hiblot 
Cc: devicet...@vger.kernel.org
---
 Documentation/devicetree/bindings/leds/common.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/leds/common.txt 
b/Documentation/devicetree/bindings/leds/common.txt
index 70876ac11367..2f7882528d97 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -11,6 +11,9 @@ have to be tightly coupled with the LED device binding. They 
are represented
 by child nodes of the parent LED device binding.
 
 Optional properties for child nodes:
+- compatible : driver name for a child-device. This child-device is the user
+   of the LED. It is created when the LED is registered and
+  destroyed when the LED is unregistered.
 - led-sources : List of device current outputs the LED is connected to. The
outputs are identified by the numbers that must be defined
in the LED device binding documentation.
-- 
2.17.1

Re: [PATCH 3/3] video: fbdev: don't print error message on framebuffer_alloc() failure

[Bartlomiej Zolnierkiewicz]

On 7/1/19 10:37 AM, Benjamin Tissoires wrote:
> Hi Bartlomiej,

Hi Benjamin,

> On Fri, Jun 14, 2019 at 4:52 PM Bartlomiej Zolnierkiewicz
>  wrote:
>>
>> framebuffer_alloc() can fail only on kzalloc() memory allocation
>> failure and since kzalloc() will print error message in such case
>> we can omit printing extra error message in drivers (which BTW is
>> what the majority of framebuffer_alloc() users is doing already).
>>
>> Cc: "Bruno Prémont" 
>> Cc: Jiri Kosina 
>> Cc: Benjamin Tissoires 
>> Signed-off-by: Bartlomiej Zolnierkiewicz 
>> ---
>>  drivers/hid/hid-picolcd_fb.c   |4 +---
>>  drivers/video/fbdev/amifb.c|4 +---
>>  drivers/video/fbdev/arkfb.c|4 +---
>>  drivers/video/fbdev/atmel_lcdfb.c  |4 +---
>>  drivers/video/fbdev/aty/aty128fb.c |5 ++---
>>  drivers/video/fbdev/aty/atyfb_base.c   |   10 --
>>  drivers/video/fbdev/aty/radeon_base.c  |2 --
>>  drivers/video/fbdev/chipsfb.c  |1 -
>>  drivers/video/fbdev/cirrusfb.c |5 +
>>  drivers/video/fbdev/da8xx-fb.c |1 -
>>  drivers/video/fbdev/efifb.c|1 -
>>  drivers/video/fbdev/grvga.c|4 +---
>>  drivers/video/fbdev/gxt4500.c  |5 ++---
>>  drivers/video/fbdev/hyperv_fb.c|4 +---
>>  drivers/video/fbdev/i740fb.c   |4 +---
>>  drivers/video/fbdev/imsttfb.c  |5 +
>>  drivers/video/fbdev/intelfb/intelfbdrv.c   |5 ++---
>>  drivers/video/fbdev/jz4740_fb.c|4 +---
>>  drivers/video/fbdev/mb862xx/mb862xxfbdrv.c |5 +
>>  drivers/video/fbdev/mbx/mbxfb.c|4 +---
>>  drivers/video/fbdev/omap/omapfb_main.c |2 --
>>  drivers/video/fbdev/omap2/omapfb/omapfb-main.c |6 +-
>>  drivers/video/fbdev/platinumfb.c   |5 ++---
>>  drivers/video/fbdev/pmag-aa-fb.c   |4 +---
>>  drivers/video/fbdev/pmag-ba-fb.c   |4 +---
>>  drivers/video/fbdev/pmagb-b-fb.c   |4 +---
>>  drivers/video/fbdev/pvr2fb.c   |6 +-
>>  drivers/video/fbdev/riva/fbdev.c   |1 -
>>  drivers/video/fbdev/s3c-fb.c   |4 +---
>>  drivers/video/fbdev/s3fb.c |4 +---
>>  drivers/video/fbdev/sh_mobile_lcdcfb.c |8 ++--
>>  drivers/video/fbdev/sm501fb.c  |4 +---
>>  drivers/video/fbdev/sm712fb.c  |1 -
>>  drivers/video/fbdev/smscufx.c  |4 +---
>>  drivers/video/fbdev/ssd1307fb.c|4 +---
>>  drivers/video/fbdev/sunxvr1000.c   |1 -
>>  drivers/video/fbdev/sunxvr2500.c   |1 -
>>  drivers/video/fbdev/sunxvr500.c|1 -
>>  drivers/video/fbdev/tgafb.c|4 +---
>>  drivers/video/fbdev/udlfb.c|4 +---
>>  drivers/video/fbdev/via/viafbdev.c |6 +-
>>  drivers/video/fbdev/vt8623fb.c |4 +---
>>  42 files changed, 40 insertions(+), 123 deletions(-)
>>
>> Index: b/drivers/hid/hid-picolcd_fb.c
>> ===
>> --- a/drivers/hid/hid-picolcd_fb.c
>> +++ b/drivers/hid/hid-picolcd_fb.c
>> @@ -522,10 +522,8 @@ int picolcd_init_framebuffer(struct pico
>> sizeof(struct fb_deferred_io) +
>> sizeof(struct picolcd_fb_data) +
>> PICOLCDFB_SIZE, dev);
>> -   if (info == NULL) {
>> -   dev_err(dev, "failed to allocate a framebuffer\n");
>> +   if (!info)
>> goto err_nomem;
>> -   }
> 
> It would have been better to split this change as the HID and fbdev
> are different trees.

Ah, there are no modifications to framebuffer_alloc() itself so changes
are independent. I should have noticed that earlier, sorry about that..

> However, I do not expect a conflict here (there hasn't been updates of
> hid-picolcd_fb.c in a while), so feel free to take this patch through
> the fbdev tree with my:
> Acked-By: Benjamin Tissoires 

Thank you!

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH 0/1] drm: panel-orientation-quirks: Add extra quirk table entry GPD MicroPC

[Hans de Goede]

Hi,

On 28-06-19 13:51, Maxime Ripard wrote:

On Fri, Jun 28, 2019 at 12:04:30PM +0200, Hans de Goede wrote:

Hi all,

On 24-06-19 17:40, Hans de Goede wrote:

Hi All,

Good news I have a contact inside GPD now and from now on their BIOS-es
will have proper sys_vendor and product_name DMI strings. This means that
we no longer need to do BIOS date matches and add a new BIOS date to
drm_panel_orientation_quirks.c for each BIOS update.

The second batch of GPD MicroPC-s being delivered to users already uses
these new strings, this patch adds a quirk for the 90 degree mounted
LCD panel using the new DMI strings.

It would be nice to get this into 5.2, but it is not that urgent, so
I believe that it is best to push this to drm-misc-next-fixes and then
it can get added to 5.2.y once it hits Torvald's tree.

If someone can give this a review (it is a trivial patch really) and
give me an Acked-by then I'll push this to drm-misc-next-fixes.


Maarten, Maxime, ping? Can I get an Acked-by (or Reviewed-by) for this
please so that I can push it to drm-misc-next-fixes ?


Acked-by: Maxime Ripard 


Thanks, pushed to drm-misc-next-fixes.

Regards,

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

Re: Why is Thunderbolt 3 limited to 2.5 GT/s on Linux?

[Michel Dänzer]

On 2019-06-28 2:21 p.m., Timur Kristóf wrote:
> 
> I haven't found a good way to measure the maximum PCIe throughput
> between the CPU and GPU,

amdgpu.benchmark=3

on the kernel command line will measure throughput for various transfer
sizes during driver initialization.


> but I did take a look at AMD's sysfs interface at
> /sys/class/drm/card1/device/pcie_bw which while running the bottlenecked
> game. The highest throughput I saw there was only 2.43 Gbit /sec.

PCIe bandwidth generally isn't a bottleneck for games, since they don't
constantly transfer large data volumes across PCIe, but store them in
the GPU's local VRAM, which is connected at much higher bandwidth.


-- 
Earthling Michel Dänzer   |  https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Why is Thunderbolt 3 limited to 2.5 GT/s on Linux?

[Alex Deucher]

On Mon, Jul 1, 2019 at 10:38 AM Timur Kristóf  wrote:
>
> > > > > Like I said the device really is limited to 2.5 GT/s even
> > > > > though it
> > > > > should be able to do 8 GT/s.
> > > >
> > > > There is Thunderbolt link between the host router (your host
> > > > system)
> > > > and
> > > > the eGPU box. That link is not limited to 2.5 GT/s so even if the
> > > > slot
> > > > claims it is PCI gen1 the actual bandwidth can be much higher
> > > > because
> > > > of
> > > > the virtual link.
> > >
> > > Not sure I understand correctly, are you saying that TB3 can do 40
> > > Gbit/sec even though the kernel thinks it can only do 8 Gbit / sec?
> > >
> > > I haven't found a good way to measure the maximum PCIe throughput
> > > between the CPU and GPU, but I did take a look at AMD's sysfs
> > > interface
> > > at /sys/class/drm/card1/device/pcie_bw which while running the
> > > bottlenecked game. The highest throughput I saw there was only 2.43
> > > Gbit /sec.
> > >
> > > One more thought. I've also looked at
> > > /sys/class/drm/card1/device/pp_dpm_pcie - which tells me that
> > > amdgpu
> > > thinks it is running on a 2.5GT/s x8 link (as opposed to the
> > > expected 8
> > > GT/s x4). Can this be a problem?
> >
> > We limit the speed of the link the the driver to the max speed of any
> > upstream links.  So if there are any links upstream limited to 2.5
> > GT/s, it doesn't make sense to clock the local link up to faster
> > speeds.
> >
> > Alex
>
> Hi Alex,
>
> I have two concerns about it:
>
> 1. Why does amdgpu think that the link has 8 lanes, when it only has 4?

Not sure.  We use pcie_bandwidth_available() on kernel 5.3 and newer
to determine the max speed and links when we set up the GPU.  For
older kernels use use an open coded version of it in the driver.

>
> 2. As far as I understood what Mika said, there isn't really a 2.5 GT/s
> limitation there, since the virtual link should be running at 40 Gb/s
> regardless of the reported speed of that device. Would it be possible
> to run the AMD GPU at 8 GT/s in this case?

If there is really a faster link here then we need some way to pass
that information to the drivers.  We rely on the information from the
upstream bridges and the pcie core helper functions.

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

Re: [PATCH 1/4] drm/vram: Set GEM object functions for PRIME

[Thomas Zimmermann]

Hi

Am 01.07.19 um 10:48 schrieb Gerd Hoffmann:
> On Mon, Jul 01, 2019 at 09:28:59AM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 01.07.19 um 08:32 schrieb Gerd Hoffmann:
>>> On Fri, Jun 28, 2019 at 02:26:56PM +0200, Thomas Zimmermann wrote:
 PRIME functionality is now provided via the callback functions in
 struct drm_gem_object_funcs. The driver-structure functions are obsolete.
 As a side effect of this patch, VRAM-based drivers get basic PRIME
 support automatically without having to set any flags or additional
 fields.
>>>
 +static void drm_gem_vram_object_free(struct drm_gem_object *gem)
 +static int drm_gem_vram_object_funcs_pin(struct drm_gem_object *gem)
 +static void drm_gem_vram_object_funcs_unpin(struct drm_gem_object *gem)
 +static void *drm_gem_vram_object_funcs_vmap(struct drm_gem_object *gem)
 +static void drm_gem_vram_object_funcs_vunmap(struct drm_gem_object *gem,
 +   void *vaddr)
>>>
 +static const struct drm_gem_object_funcs drm_gem_vram_object_funcs = {
 +  .free   = drm_gem_vram_object_free,
 +  .pin= drm_gem_vram_object_funcs_pin,
 +  .unpin  = drm_gem_vram_object_funcs_unpin,
 +  .vmap   = drm_gem_vram_object_funcs_vmap,
 +  .vunmap = drm_gem_vram_object_funcs_vunmap
 +};
>>>
>>> Why new functions?  Can't you just hook up the existing prime functions?
>>
>> The final patch will remove the existing functions, so drivers won't use
>> them accidentally.
> 
> But the new and the old ones are identical, right?  So why add/remove?
> Why not just rename them?

Hmm, OK. Does that somehow make a difference (e.g., easier backporting
or maintenance)?

> I'd also suggest to name them consistently (free has no _funcs, all
> others have).  I'd drop _funcs from all function names.

This inconsistency is actually an error in the patch. Thanks

Best regards
Thomas

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

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)



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

Re: [PATCH 1/4] dt-bindings: chosen: document panel-id binding

[Rob Clark]

On Mon, Jul 1, 2019 at 7:03 AM Rob Herring  wrote:
>
> On Sun, Jun 30, 2019 at 2:36 PM Rob Clark  wrote:
> >
> > From: Rob Clark 
> >
> > The panel-id property in chosen can be used to communicate which panel,
> > of multiple possibilities, is installed.
> >
> > Signed-off-by: Rob Clark 
> > ---
> >  Documentation/devicetree/bindings/chosen.txt | 69 
> >  1 file changed, 69 insertions(+)
>
> I need to update this file to say it's moved to the schema repository...
>
> But I don't think that will matter...
>
> > diff --git a/Documentation/devicetree/bindings/chosen.txt 
> > b/Documentation/devicetree/bindings/chosen.txt
> > index 45e79172a646..d502e6489b8b 100644
> > --- a/Documentation/devicetree/bindings/chosen.txt
> > +++ b/Documentation/devicetree/bindings/chosen.txt
> > @@ -68,6 +68,75 @@ on PowerPC "stdout" if "stdout-path" is not found.  
> > However, the
> >  "linux,stdout-path" and "stdout" properties are deprecated. New platforms
> >  should only use the "stdout-path" property.
> >
> > +panel-id
> > +
> > +
> > +For devices that have multiple possible display panels (multi-sourcing the
> > +display panels is common on laptops, phones, tablets), this allows the
> > +bootloader to communicate which panel is installed, e.g.
>
> How does the bootloader figure out which panel? Why can't the kernel
> do the same thing?

see jhugo's response, he has I guess more access to the bootloader than I

> > +
> > +/ {
> > +   chosen {
> > +   panel-id = <0xc4>;
> > +   };
> > +
> > +   ivo_panel {
> > +   compatible = "ivo,m133nwf4-r0";
> > +   power-supply = <_3v3>;
> > +   no-hpd;
> > +
> > +   ports {
> > +   port {
> > +   ivo_panel_in_edp: endpoint {
> > +   remote-endpoint = 
> > <_out_ivo>;
> > +   };
> > +   };
> > +   };
> > +   };
> > +
> > +   boe_panel {
> > +   compatible = "boe,nv133fhm-n61";
>
> Both panels are going to probe. So the bootloader needs to disable the
> not populated panel setting 'status' (or delete the node). If you do
> that, do you even need 'panel-id'?

I don't think we can rely on bootloader knowing a thing about DT on
these devices..

OTOH I don't really think it is a big problem for both panels to
probe.  But I suppose it might be possible to have something somewhere
in the kernel that realizes and disables the unused panels.

> > +   power-supply = <_3v3>;
> > +   no-hpd;
> > +
> > +   ports {
> > +   port {
> > +   boe_panel_in_edp: endpoint {
> > +   remote-endpoint = 
> > <_out_boe>;
> > +   };
> > +   };
> > +   };
> > +   };
> > +
> > +   display_or_bridge_device {
> > +
> > +   ports {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   ...
> > +
> > +   port@0 {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +   reg = <0>;
> > +
> > +   endpoint@c4 {
> > +   reg = <0xc4>;
>
> What does this number represent? It is supposed to be defined by the
> display_or_bridge_device, not a specific panel.

it matches /chosen/panel-id.. in this case I'm not sure how the
panel-id's are assigned, but for our purposes all that matters is that
they are assigned.

> We also need to consider how the DSI case with panels as children of
> the DSI controller would work and how this would work with multiple
> displays each having multiple panel options.

In the non-bridge case (panel hooked directly to dsi controller), the
dsi controller could use the same ports {} mechanism.

For multiple displays, we could extend, I suppose, /chosen/panel-id to
be an array of id's indexed by display.  I think this is the type of
extension we could do later when the use-case comes up.  Just having
this solved upstream for single display would already be a huge
advancement.  (You don't want to look at how this is solved downstream
for android phones.)

Btw, if you are curious how this works on windows/ACPI, the ACPI
tables have entries for each of the panels.  The kernel is expected to
take the panel-id from that EFI variable that jhugo mentioned, and
pass it to a _ROM method which returns the appropriate panel table.
(Not entirely sure how the orchestrate reading the EFI variable early,
since it does not appear to be available after ExitBootServices)

BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org

Re: [PATCH 00/12] ARM: davinci: da850-evm: remove more legacy GPIO calls

[Sekhar Nori]

Hi Lee, Daniel, Jingoo,

On 25/06/19 10:04 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski 
> 
> This is another small step on the path to liberating davinci from legacy
> GPIO API calls and shrinking the davinci GPIO driver by not having to
> support the base GPIO number anymore.
> 
> This time we're removing the legacy calls used indirectly by the LCDC
> fbdev driver.
> 
> The first three patches modify the GPIO backlight driver. The first
> of them adds the necessary functionality, the other two are just
> tweaks and cleanups.

Can you take the first three patches for v5.3 - if its not too late? I
think that will make it easy for rest of patches to make into subsequent
kernel releases.

> 
> Next two patches enable the GPIO backlight driver in
> davinci_all_defconfig.
> 
> Patch 6/12 models the backlight GPIO as an actual GPIO backlight device.
> 
> Patches 7-9 extend the fbdev driver with regulator support and convert
> the da850-evm board file to using it.
> 
> Last three patches are improvements to the da8xx fbdev driver since
> we're already touching it in this series.

Thanks,
Sekhar

Re: [PATCH v3 01/22] drm: Include ddc adapter pointer in struct drm_connector

[Thomas Zimmermann]

Hi

Am 01.07.19 um 15:27 schrieb Andrzej Pietrasiewicz:
> Hi Thomas,
> 
> Thank you for your comments. Please see inline.
> 
> W dniu 30.06.2019 o 10:12, Thomas Zimmermann pisze:
>> Hi
>>
>> I like the idea, but would prefer a more structured approach.
>>
>> Setting connector->ddc before calling drm_sysfs_connector_add() seems
>> error prone. The dependency is not really clear from the code or
>> interfaces.
>>
>> The other thing is that drivers I mostly work on, ast and mgag200, have
>> code like this:
>>
>>    struct ast_i2c_chan {
>> struct i2c_adapter adapter;
>> struct drm_device *dev;
>> struct i2c_algo_bit_data bit;
>>    };
>>
>>    struct ast_connector {
>> struct drm_connector base;
>> struct ast_i2c_chan *i2c;
>>    };
>>
>> It already encodes the connection between connector and ddc adapter.
>>
>> I suggest to introduce struct drm_i2c_adapter
>>
>>    struct drm_i2c_adapter {
>> struct i2c_adapter base;
>> struct drm_connector *connector;
>>    };
>>
>> and convert drivers over to it. Ast would look like this:
>>
>>    struct ast_i2c_chan {
>> struct drm_i2c_adapter adapter;
>> struct i2c_algo_bit_data bit;
>>    };
>>
> 
> There are few flavors of these drivers. In some of them
> the i2c_adapter for ddc is allocated and initialized by
> the driver, which must provide a place in memory to hold
> the adapter. ast is an example of this approach.
> 
> But there are others, such as for example exynos_hdmi.c.
> It gets its ddc adapter with of_find_i2c_adapter_by_node()
> and merely stores a pointer to it, while not managing the
> memory needed to hold the i2c_adapter.

I see.

> Do you have any idea how to accommodate these various
> flavors of drivers in the scheme you propose?

Something like

  struct drm_i2c_adapter {
struct i2c_adapter *adapter;
struct drm_connector *connector;
  };

with adapter either being allocated dynamically or acquired via
of_find_i2c_adapter_by_node(); with separate init and finish functions
for each variant. But it looks like over-abstraction to me. Without
prototyping the idea, I cannot say if it's worth the effort.

For something more simple, maybe just have a function to attach an i2c
adapter to a connector:

  drm_connector_attach_i2c_adapter(connector, i2c_adapter)

which sets the connector's ddc pointer and creates the sysfs entry if
the connector's entry is already present.

Best regards
Thomas

> Andrzej
> 
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] dt-bindings: chosen: document panel-id binding

[Jeffrey Hugo]

On 7/1/2019 8:03 AM, Rob Herring wrote:

On Sun, Jun 30, 2019 at 2:36 PM Rob Clark  wrote:


From: Rob Clark 

The panel-id property in chosen can be used to communicate which panel,
of multiple possibilities, is installed.

Signed-off-by: Rob Clark 
---
  Documentation/devicetree/bindings/chosen.txt | 69 
  1 file changed, 69 insertions(+)


I need to update this file to say it's moved to the schema repository...

But I don't think that will matter...


diff --git a/Documentation/devicetree/bindings/chosen.txt 
b/Documentation/devicetree/bindings/chosen.txt
index 45e79172a646..d502e6489b8b 100644
--- a/Documentation/devicetree/bindings/chosen.txt
+++ b/Documentation/devicetree/bindings/chosen.txt
@@ -68,6 +68,75 @@ on PowerPC "stdout" if "stdout-path" is not found.  However, 
the
  "linux,stdout-path" and "stdout" properties are deprecated. New platforms
  should only use the "stdout-path" property.

+panel-id
+
+
+For devices that have multiple possible display panels (multi-sourcing the
+display panels is common on laptops, phones, tablets), this allows the
+bootloader to communicate which panel is installed, e.g.


How does the bootloader figure out which panel? Why can't the kernel
do the same thing?


Its platform specific.  In the devices that Rob Clark seems interested
in, there are multiple mechanisms in place - read a gpio, enable the
DSI and send a specific command to the panel controller asking for its
panel id, or read some efuses.

The efuses may not be accessible by Linux.

The DSI solution is problematic because it causes a chicken and egg
situation where linux needs the DT to probe the DSI driver to query
the panel, in order to edit the DT to probe DSI/panel.

In the systems Rob Clark is interested in, the FW already provides a
specific EFI variable with the panel id encoded in it for HLOS to use
(although this is broken on some of the devices), but this is a
specific vendor's solution.

The FW/bootloader has probably already figured out the panel details
and brought up the display for a boot splash, bios menu, etc.  I'm not
sure it makes a lot of sense to define N mechanisms for linux to
figure out the same across every platform/vendor.




+
+/ {
+   chosen {
+   panel-id = <0xc4>;
+   };
+
+   ivo_panel {
+   compatible = "ivo,m133nwf4-r0";
+   power-supply = <_3v3>;
+   no-hpd;
+
+   ports {
+   port {
+   ivo_panel_in_edp: endpoint {
+   remote-endpoint = <_out_ivo>;
+   };
+   };
+   };
+   };
+
+   boe_panel {
+   compatible = "boe,nv133fhm-n61";


Both panels are going to probe. So the bootloader needs to disable the
not populated panel setting 'status' (or delete the node). If you do
that, do you even need 'panel-id'?


+   power-supply = <_3v3>;
+   no-hpd;
+
+   ports {
+   port {
+   boe_panel_in_edp: endpoint {
+   remote-endpoint = <_out_boe>;
+   };
+   };
+   };
+   };
+
+   display_or_bridge_device {
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ...
+
+   port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   endpoint@c4 {
+   reg = <0xc4>;


What does this number represent? It is supposed to be defined by the
display_or_bridge_device, not a specific panel.


Its the specific FW/bootloader defined panel id, that matches the
above defined panel-id property.



We also need to consider how the DSI case with panels as children of
the DSI controller would work and how this would work with multiple
displays each having multiple panel options.

Rob




--
Jeffrey Hugo
Qualcomm Datacenter Technologies as an affiliate of Qualcomm 
Technologies, Inc.

Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: Why is Thunderbolt 3 limited to 2.5 GT/s on Linux?

[Alex Deucher]

On Sun, Jun 30, 2019 at 2:27 PM Timur Kristóf  wrote:
>
>
> > > Sure, though in this case 3 of those downstream ports are not
> > > exposed
> > > by the hardware, so it's a bit surprising to see them there.
> >
> > They lead to other peripherals on the TBT host router such as the TBT
> > controller and xHCI. Also there are two downstream ports for
> > extension
> > from which you eGPU is using one.
>
> If you look at the device tree from my first email, you can see that
> both the GPU and the XHCI uses the same port: 04:04.0 - in fact I can
> even remove the other 3 ports from the system without any consequences.
>
> > > Like I said the device really is limited to 2.5 GT/s even though it
> > > should be able to do 8 GT/s.
> >
> > There is Thunderbolt link between the host router (your host system)
> > and
> > the eGPU box. That link is not limited to 2.5 GT/s so even if the
> > slot
> > claims it is PCI gen1 the actual bandwidth can be much higher because
> > of
> > the virtual link.
>
> Not sure I understand correctly, are you saying that TB3 can do 40
> Gbit/sec even though the kernel thinks it can only do 8 Gbit / sec?
>
> I haven't found a good way to measure the maximum PCIe throughput
> between the CPU and GPU, but I did take a look at AMD's sysfs interface
> at /sys/class/drm/card1/device/pcie_bw which while running the
> bottlenecked game. The highest throughput I saw there was only 2.43
> Gbit /sec.
>
> One more thought. I've also looked at
> /sys/class/drm/card1/device/pp_dpm_pcie - which tells me that amdgpu
> thinks it is running on a 2.5GT/s x8 link (as opposed to the expected 8
> GT/s x4). Can this be a problem?

We limit the speed of the link the the driver to the max speed of any
upstream links.  So if there are any links upstream limited to 2.5
GT/s, it doesn't make sense to clock the local link up to faster
speeds.

Alex

>
> >
> > > > > 3. Is it possible to manually set them to 8 GT/s?
> > > >
> > > > No idea.
> > > >
> > > > Are you actually seeing some performance issue because of this or
> > > > are
> > > > you just curious?
> > >
> > > Yes, I see a noticable performance hit: some games have very low
> > > frame
> > > rate while neither the CPU nor the GPU are fully utilized.
> >
> > Is that problem in Linux only or do you see the same issue in Windows
> > as
> > well?
>
>
> I admit I don't have Windows on this computer now and it has been some
> time since I last tried it, but when I did, I didn't see this problem.
>
> Best regards,
> Tim
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] dt-bindings: chosen: document panel-id binding

[Rob Herring]

On Sun, Jun 30, 2019 at 2:36 PM Rob Clark  wrote:
>
> From: Rob Clark 
>
> The panel-id property in chosen can be used to communicate which panel,
> of multiple possibilities, is installed.
>
> Signed-off-by: Rob Clark 
> ---
>  Documentation/devicetree/bindings/chosen.txt | 69 
>  1 file changed, 69 insertions(+)

I need to update this file to say it's moved to the schema repository...

But I don't think that will matter...

> diff --git a/Documentation/devicetree/bindings/chosen.txt 
> b/Documentation/devicetree/bindings/chosen.txt
> index 45e79172a646..d502e6489b8b 100644
> --- a/Documentation/devicetree/bindings/chosen.txt
> +++ b/Documentation/devicetree/bindings/chosen.txt
> @@ -68,6 +68,75 @@ on PowerPC "stdout" if "stdout-path" is not found.  
> However, the
>  "linux,stdout-path" and "stdout" properties are deprecated. New platforms
>  should only use the "stdout-path" property.
>
> +panel-id
> +
> +
> +For devices that have multiple possible display panels (multi-sourcing the
> +display panels is common on laptops, phones, tablets), this allows the
> +bootloader to communicate which panel is installed, e.g.

How does the bootloader figure out which panel? Why can't the kernel
do the same thing?

> +
> +/ {
> +   chosen {
> +   panel-id = <0xc4>;
> +   };
> +
> +   ivo_panel {
> +   compatible = "ivo,m133nwf4-r0";
> +   power-supply = <_3v3>;
> +   no-hpd;
> +
> +   ports {
> +   port {
> +   ivo_panel_in_edp: endpoint {
> +   remote-endpoint = 
> <_out_ivo>;
> +   };
> +   };
> +   };
> +   };
> +
> +   boe_panel {
> +   compatible = "boe,nv133fhm-n61";

Both panels are going to probe. So the bootloader needs to disable the
not populated panel setting 'status' (or delete the node). If you do
that, do you even need 'panel-id'?

> +   power-supply = <_3v3>;
> +   no-hpd;
> +
> +   ports {
> +   port {
> +   boe_panel_in_edp: endpoint {
> +   remote-endpoint = 
> <_out_boe>;
> +   };
> +   };
> +   };
> +   };
> +
> +   display_or_bridge_device {
> +
> +   ports {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   ...
> +
> +   port@0 {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   reg = <0>;
> +
> +   endpoint@c4 {
> +   reg = <0xc4>;

What does this number represent? It is supposed to be defined by the
display_or_bridge_device, not a specific panel.

We also need to consider how the DSI case with panels as children of
the DSI controller would work and how this would work with multiple
displays each having multiple panel options.

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

What is Direct Rendering Infrastructure (DRI)?

[Turritopsis Dohrnii Teo En Ming]

Good evening from Singapore,

May I know what is Direct Rendering Infrastructure (DRI)?

Thank you.

-BEGIN EMAIL SIGNATURE-

The Gospel for all Targeted Individuals (TIs):

[The New York Times] Microwave Weapons Are Prime Suspect in Ills of
U.S. Embassy Workers

Link: 
https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html



Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic
Qualifications as at 14 Feb 2019

[1] https://tdtemcerts.wordpress.com/

[2] https://tdtemcerts.blogspot.sg/

[3] https://www.scribd.com/user/270125049/Teo-En-Ming

-END EMAIL SIGNATURE-

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

Re: [PATCH] [v8, 2/2] drm/panel: Add Boe Himax8279d MIPI-DSI LCD panel

[Emil Velikov]

Hi Jerry,

On Thu, 25 Apr 2019 at 08:40, Jerry Han  wrote:
>
> Support Boe Himax8279d 8.0" 1200x1920 TFT LCD panel, it is a MIPI DSI
> panel.
>
> V8:
> - Modify communication address
>
> V7:
> - Add the information of the reviewer
> - Remove unnecessary delays, The udelay_range code gracefully returns
> without hitting the scheduler on a delay of 0. (Derek)
> - Merge the same data structures, like display_mode and off_cmds (Derek)
> - Optimize the processing of results returned by
> devm_gpiod_get_optional (Derek)
>
> V6:
> - Add the information of the reviewer (Sam)
> - Delete unnecessary header files #include  (Sam)
> - The config DRM_PANEL_BOE_HIMAX8279D appears twice. Drop one of them (Sam)
> - ADD static, set_gpios function is not used outside this module (Sam)
>
> V5:
> - Added changelog
>
> V4:
> - Frefix all function maes with boe_ (Sam)
> - Fsed "enable_gpio" replace "reset_gpio", Make it look clearer (Sam)
> - Sort include lines alphabetically (Sam)
> - Fixed entries in the makefile must be sorted alphabetically (Sam)
> - Add send_mipi_cmds function to avoid duplicating the code (Sam)
> - Add the necessary delay(reset_delay_t5) between reset and sending
> the initialization command (Rock wang)
>
> V3:
> - Remove unnecessary delays in sending initialization commands (Jitao Shi)
>
> V2:
> - Use SPDX identifier (Sam)
> - Use necessary header files replace drmP.h (Sam)
> - Delete unnecessary header files #include  (Sam)
> - Specifies a GPIOs array to control the reset timing,
> instead of reading "dsi-reset-sequence" data from DTS (Sam)
> - Delete backlight_disable() function when already disabled (Sam)
> - Use devm_of_find_backlight() replace of_find_backlight_by_node() (Sam)
> - Move the necessary data in the DTS to the current file,
> like porch, display_mode and Init code etc. (Sam)
> - Add compatible device "boe,himax8279d10p" (Sam)
>
> Signed-off-by: Jerry Han 
> Reviewed-by: Sam Ravnborg 
> Reviewed-by: Derek Basehore 
> Cc: Jitao Shi 
> Cc: Rock wang 
> ---
While the DT has landed, this patch is not merged it seems.
I think that Sam is waiting for a version which does not trigger so
many check-patch warnings.

That said, a couple of comments if I may.

> +   struct gpio_desc *enable_gpio;
> +   struct gpio_desc *pp33_gpio;
> +   struct gpio_desc *pp18_gpio;
DT claims that these gpios are required, yet one is using the optional gpio API.
Is the code off, or does the DT need fixing?


> +static int send_mipi_cmds(struct drm_panel *panel, const struct panel_cmd 
> *cmds)
> +{
> +   struct panel_info *pinfo = to_panel_info(panel);
> +   unsigned int i = 0;
> +   int err;
> +
> +   if (!cmds)
> +   return -EFAULT;
> +
> +   for (i = 0; cmds[i].len != 0; i++) {
> +   const struct panel_cmd *cmd = [i];
> +
> +   if (cmd->len == 2)
> +   err = mipi_dsi_dcs_write(pinfo->link,
> +   cmd->data[1], NULL, 0);
> +   else
> +   err = mipi_dsi_dcs_write(pinfo->link,
> +   cmd->data[1], cmd->data + 
> 2,
> +   cmd->len - 2);
> +
> +   if (err < 0)
> +   return err;
> +
> +   usleep_range((cmd->data[0]) * 1000,
> +   (1 + cmd->data[0]) * 1000);
> +   }
> +
This format seems semi-magical. Any particular reason why you're not
using the helpers?
In particular, enter/exit sleep mode and set display on/off.

Speaking of which - the 8inch display uses then, yet they are missing
for the 10inch one. Seems like there's a bug in there.

Plus we have some repeating patterns in the vendor/undocumented
commands - good reason to get those into separate hunks.
With the above in place, you can effectively drop the .off_cmd
callback and sleep field from the INIT_CMD arrays.

Hence, less code to debug and maintain ;-)

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

Re: [PATCH 1/4] gpu: Use dev_get_drvdata()

[Laurent Pinchart]

Hi Fuqian,

Thank you for the pach.

On Mon, Jul 01, 2019 at 11:22:35AM +0800, Fuqian Huang wrote:
> Using dev_get_drvdata directly.

This could be expanded a bit. Maybe

"Several drivers cast a struct device pointer to a struct
platform_device pointer only to then call platform_get_drvdata(). These
constructs can be simplified by using dev_get_drvdata() directly."

I would also replace the "gpu: " prefix with "drm: " in the subject
line. With these small issues addressed,

Reviewed-by: Laurent Pinchart 

> Signed-off-by: Fuqian Huang 
> ---
>  drivers/gpu/drm/msm/adreno/adreno_device.c  |  6 ++
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 13 +
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c|  6 ++
>  drivers/gpu/drm/msm/dsi/dsi_host.c  |  6 ++
>  drivers/gpu/drm/msm/msm_drv.c   |  3 +--
>  drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 15 +--
>  drivers/gpu/drm/panfrost/panfrost_device.c  |  6 ++
>  7 files changed, 19 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> index b3deb346a42b..fafd00d2574a 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -403,16 +403,14 @@ static const struct of_device_id dt_match[] = {
>  #ifdef CONFIG_PM
>  static int adreno_resume(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct msm_gpu *gpu = platform_get_drvdata(pdev);
> + struct msm_gpu *gpu = dev_get_drvdata(dev);
>  
>   return gpu->funcs->pm_resume(gpu);
>  }
>  
>  static int adreno_suspend(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct msm_gpu *gpu = platform_get_drvdata(pdev);
> + struct msm_gpu *gpu = dev_get_drvdata(dev);
>  
>   return gpu->funcs->pm_suspend(gpu);
>  }
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index ae885e5dd07d..6c6f8ca9380f 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -1025,16 +1025,15 @@ static int dpu_bind(struct device *dev, struct device 
> *master, void *data)
>  
>  static void dpu_unbind(struct device *dev, struct device *master, void *data)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
> + struct dpu_kms *dpu_kms = dev_get_drvdata(dev);
>   struct dss_module_power *mp = _kms->mp;
>  
>   msm_dss_put_clk(mp->clk_config, mp->num_clk);
> - devm_kfree(>dev, mp->clk_config);
> + devm_kfree(dev, mp->clk_config);
>   mp->num_clk = 0;
>  
>   if (dpu_kms->rpm_enabled)
> - pm_runtime_disable(>dev);
> + pm_runtime_disable(dev);
>  }
>  
>  static const struct component_ops dpu_ops = {
> @@ -1056,8 +1055,7 @@ static int dpu_dev_remove(struct platform_device *pdev)
>  static int __maybe_unused dpu_runtime_suspend(struct device *dev)
>  {
>   int rc = -1;
> - struct platform_device *pdev = to_platform_device(dev);
> - struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
> + struct dpu_kms *dpu_kms = dev_get_drvdata(dev);
>   struct drm_device *ddev;
>   struct dss_module_power *mp = _kms->mp;
>  
> @@ -1077,8 +1075,7 @@ static int __maybe_unused dpu_runtime_suspend(struct 
> device *dev)
>  static int __maybe_unused dpu_runtime_resume(struct device *dev)
>  {
>   int rc = -1;
> - struct platform_device *pdev = to_platform_device(dev);
> - struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
> + struct dpu_kms *dpu_kms = dev_get_drvdata(dev);
>   struct drm_encoder *encoder;
>   struct drm_device *ddev;
>   struct dss_module_power *mp = _kms->mp;
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> index 901009e1f219..25d1ebb32e73 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> @@ -1052,8 +1052,7 @@ static int mdp5_dev_remove(struct platform_device *pdev)
>  
>  static __maybe_unused int mdp5_runtime_suspend(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct mdp5_kms *mdp5_kms = platform_get_drvdata(pdev);
> + struct mdp5_kms *mdp5_kms = dev_get_drvdata(dev);
>  
>   DBG("");
>  
> @@ -1062,8 +1061,7 @@ static __maybe_unused int mdp5_runtime_suspend(struct 
> device *dev)
>  
>  static __maybe_unused int mdp5_runtime_resume(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct mdp5_kms *mdp5_kms = platform_get_drvdata(pdev);
> + struct mdp5_kms *mdp5_kms = dev_get_drvdata(dev);
>  
>   DBG("");
>  
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index 

Re: [PATCH v2 07/27] gpu: drm: remove memset after zalloc

[Emil Velikov]

Hi Fuqian,

On Fri, 28 Jun 2019 at 09:30, Fuqian Huang  wrote:
>
> zalloc has already zeroed the memory.
> so memset is unneeded.
>
> Signed-off-by: Fuqian Huang 
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c   | 2 --
>  drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c | 2 --
>  drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c| 2 --
>  drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c   | 2 --
>  drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c | 2 --
>  5 files changed, 10 deletions(-)
>
Thanks for fixing these. One nit pick: the commit message should start
with "drm/amdgpu:" as you can see from git log.
With that:

Reviewed-by: Emil Velikov 

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

Re: [PATCH 1/4] gpu: Use dev_get_drvdata()

[Emil Velikov]

Hi Fuqian,

On Mon, 1 Jul 2019 at 08:13, Fuqian Huang  wrote:
>
> Using dev_get_drvdata directly.
>
> Signed-off-by: Fuqian Huang 
> ---
>  drivers/gpu/drm/msm/adreno/adreno_device.c  |  6 ++
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 13 +
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c|  6 ++
>  drivers/gpu/drm/msm/dsi/dsi_host.c  |  6 ++
>  drivers/gpu/drm/msm/msm_drv.c   |  3 +--
>  drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 15 +--
>  drivers/gpu/drm/panfrost/panfrost_device.c  |  6 ++
As far as i can see the patch is spot on, thanks for that.

Can you split this in three since it covers 3 separate drivers.
For each one you can get a smaller CC list - patches with 20+ people
tend to get blocked :-(

We can pick the PANFROST entries from the get_maintainer.pl output,
and add them to the commit message.
Thus git send-email will parse the commit message and automatically CC
the people ;-)

Cc: Rob Herring  (supporter:ARM MALI PANFROST DRM DRIVER)
Cc: Tomeu Vizoso  (supporter:ARM MALI
PANFROST DRM DRIVER)
Cc: dri-devel@lists.freedesktop.org (open list:ARM MALI PANFROST DRM DRIVER)

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

Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I

[Andrzej Hajda]

On 01.07.2019 11:58, Maxime Ripard wrote:
> Hi!
>
> On Fri, Jun 28, 2019 at 12:39:32PM +0200, Andrzej Hajda wrote:
>> On 12.06.2019 17:20, Maxime Ripard wrote:
 I am not sure if I understand whole discussion here, but I also do not
 understand whole edp-connector thing.
>>> The context is this one:
>>> https://patchwork.freedesktop.org/patch/257352/?series=51182=1
>>> https://patchwork.freedesktop.org/patch/283012/?series=56163=1
>>> https://patchwork.freedesktop.org/patch/286468/?series=56776=2
>>>
>>> TL;DR: This bridge is being used on ARM laptops that can come with
>>> different eDP panels. Some of these panels require a regulator to be
>>> enabled for the panel to work, and this is obviously something that
>>> should be in the DT.
>>>
>>> However, we can't really describe the panel itself, since the vendor
>>> uses several of them and just relies on the eDP bus to do its job at
>>> retrieving the EDIDs. A generic panel isn't really working either
>>> since that would mean having a generic behaviour for all the panels
>>> connected to that bus, which isn't there either.
>>>
>>> The connector allows to expose this nicely.
>> As VESA presentation says[1] eDP is based on DP but is much more
>> flexible, it is up to integrator (!!!) how the connection, power
>> up/down, initialization sequence should be performed. Trying to cover
>> every such case in edp-connector seems to me similar to panel-simple
>> attempt failure. Moreover there is no such thing as physical standard
>> eDP connector. Till now I though DT connector should describe physical
>> connector on the device, now I am lost, are there some DT bindings
>> guidelines about definition of a connector?
> This might be semantics but I guess we're in some kind of grey area?
>
> Like, for eDP, if it's soldered I guess we could say that there's no
> connector. But what happens if for some other board, that signal is
> routed through a ribbon?
>
> You could argue that there's no physical connector in both cases, or
> that there's one in both, or one for the ribbon and no connector for
> the one soldered in.


This is not about ribbon vs soldering. It is about usage: this
connection is static across the whole life of the device (except
exceptional things: repair, non-standard usage, etc).

And "the real connector" is (at least for me) something where end-user
can connect/disconnect different things: USB, HDMI, ethernet, etc. And
obviously to be functional it should be somehow standardized. So even if
there could be some grey area, I do not see it here.


>
>> Maybe instead of edp-connector one would introduce integrator's specific
>> connector, for example with compatible "olimex,teres-edp-connector"
>> which should follow edp abstract connector rules? This will be at least
>> consistent with below presentation[1] - eDP requirements depends on
>> integrator. Then if olimex has standard way of dealing with panels
>> present in olimex/teres platforms the driver would then create
>> drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
>> Anyway it still looks fishy for me :), maybe because I am not
>> familiarized with details of these platforms.
> That makes sense yes


And what if some panel can be used with this pseudo-connecter and in
some different hw directly? Code duplication? DT overlays?


Regards

Andrzej


>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

[Bug 107877] deepin-desktop: xdg-email: no method available for opening 'mailto:'

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107877

Andre Klapper  changed:

   What|Removed |Added

URL|https://routerloginnet.tips |
   |/   |

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

linux-next: build failure after merge of the hmm tree

[Stephen Rothwell]

Hi all,

After merging the hmm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

mm/hmm.c: In function 'hmm_get_or_create':
mm/hmm.c:50:2: error: implicit declaration of function 
'lockdep_assert_held_exclusive'; did you mean 'lockdep_assert_held_once'? 
[-Werror=implicit-function-declaration]
  lockdep_assert_held_exclusive(>mmap_sem);
  ^
  lockdep_assert_held_once
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c: In function 
'amdgpu_ttm_tt_get_user_pages':
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:778:28: error: passing argument 2 of 
'hmm_range_register' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
  hmm_range_register(range, mm, start,
^~
In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:35:
include/linux/hmm.h:464:29: note: expected 'struct hmm_mirror *' but argument 
is of type 'struct mm_struct *'
  struct hmm_mirror *mirror,
  ~~~^~

Caused by commit

  e36acfe6c86d ("mm/hmm: Use hmm_mirror not mm as an argument for 
hmm_range_register")

interacting with commit

  66c45500bfdc ("drm/amdgpu: use new HMM APIs and helpers")

from the drm tree.

All I could do for now was to mark the AMDGPU driver broken.  Please
submit a merge for for me (and later Linus) to use.

-- 
Cheers,
Stephen Rothwell


pgp4RscFmvBxI.pgp
Description: OpenPGP digital signature

[Bug 111010] Cemu Shader Cache Corruption Displaying Solid Color After commit 11e16ca7ce0

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=111010

e88z4  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

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

Re: [PATCH v2 1/4] drm/mga: drop dependency on drm_os_linux.h

[Emil Velikov]

On Sun, 23 Jun 2019 at 11:36, Sam Ravnborg  wrote:

> -int mga_driver_fence_wait(struct drm_device *dev, unsigned int *sequence)
> +void mga_driver_fence_wait(struct drm_device *dev, unsigned int *sequence)
>  {
> drm_mga_private_t *dev_priv = (drm_mga_private_t *) dev->dev_private;
> unsigned int cur_fence;
> -   int ret = 0;
>
> /* Assume that the user has missed the current sequence number
>  * by about a day rather than she wants to wait for years
>  * using fences.
>  */
> -   DRM_WAIT_ON(ret, dev_priv->fence_queue, 3 * HZ,
> +   wait_event_timeout(dev_priv->fence_queue,
> (((cur_fence = atomic_read(_priv->last_fence_retired))
> - - *sequence) <= (1 << 23)));
> + - *sequence) <= (1 << 23)),
> +   msecs_to_jiffies(3000));
>
> *sequence = cur_fence;
> -
> -   return ret;
>  }
>
Most of the patch is a trivial substitution. This piece is not though :-\
For the future, please keep mechanical and functional changes in
separate patches.

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

Re: [PATCH v1 33/33] drm/hisilicon: drop use of drmP.h

[Emil Velikov]

On Sun, 30 Jun 2019 at 07:20, Sam Ravnborg  wrote:
>
> Drop the deprecated drmP.h header file.
>
> Made the header file selfcontained, and dropped unused header files.
> Fixed fallout in remaining files.
>
> Signed-off-by: Sam Ravnborg 
> Cc: Xinliang Liu 
> Cc: Rongrong Zou 
> Cc: Xinwei Kong 
> Cc: Chen Feng 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Gerd Hoffmann 
> Cc: Thomas Zimmermann 
> Cc: Sam Ravnborg 
> Cc: Allison Randal 
> Cc: Harry Wentland 
> Cc: Thomas Gleixner 
> Cc: Souptick Joarder 
> Cc: John Garry 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: Junwei Zhang 
> Cc: Greg Kroah-Hartman 
> Cc: Hans de Goede 
> Cc: CK Hu 
> Cc: Benjamin Gaignard 
> Cc: Laurent Pinchart 
> Cc: Jani Nikula 
> Cc: Emil Velikov 
> Cc: Eric Anholt 
> Cc: "Noralf Trønnes" 
> ---
> The list of cc: was too large to add all recipients to the cover letter.
> Please find cover letter here:
> https://lists.freedesktop.org/archives/dri-devel/2019-June/thread.html
> Search for "drm: drop use of drmp.h in drm-misc"
>
Speaking of long CC list, most patches are ok yet this has gone a bit crazy.
How did you manage to pull such a long list? The get_maintainer.pl
script shows a total of 17 for all of hibmc and kirin.

Either way, since you've built-tested these (and conflicts are a
matter of #include) for the lot:
Acked-by: Emil Velikov 

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

Re: [PATCH v2] drm/bridge: adv7511: Attach to DSI host at probe time

[Andrzej Hajda]

On 27.06.2019 17:18, Matt Redfearn wrote:
> In contrast to all of the DSI panel drivers in drivers/gpu/drm/panel
> which attach to the DSI host via mipi_dsi_attach() at probe time, the
> ADV7533 bridge device does not. Instead it defers this to the point that
> the upstream device connects to its bridge via drm_bridge_attach().
> The generic Synopsys MIPI DSI host driver does not register it's own
> drm_bridge until the MIPI DSI has attached. But it does not call
> drm_bridge_attach() on the downstream device until the upstream device
> has attached. This leads to a chicken and the egg failure and the DRM
> pipeline does not complete.
> Since all other mipi_dsi_device drivers call mipi_dsi_attach() in
> probe(), make the adv7533 mipi_dsi_device do the same. This ensures that
> the Synopsys MIPI DSI host registers it's bridge such that it is
> available for the upstream device to connect to.
>
> Signed-off-by: Matt Redfearn 

Queued to drm-misc-next.


Regards

Andrzej

>
> ---
>
> Changes in v2:
> Cleanup if adv7533_attach_dsi fails.
>
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index e7ddd3e3db9..807827bd910 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -874,9 +874,6 @@ static int adv7511_bridge_attach(struct drm_bridge 
> *bridge)
>_connector_helper_funcs);
>   drm_connector_attach_encoder(>connector, bridge->encoder);
>  
> - if (adv->type == ADV7533)
> - ret = adv7533_attach_dsi(adv);
> -
>   if (adv->i2c_main->irq)
>   regmap_write(adv->regmap, ADV7511_REG_INT_ENABLE(0),
>ADV7511_INT0_HPD);
> @@ -1222,8 +1219,17 @@ static int adv7511_probe(struct i2c_client *i2c, const 
> struct i2c_device_id *id)
>   drm_bridge_add(>bridge);
>  
>   adv7511_audio_init(dev, adv7511);
> +
> + if (adv7511->type == ADV7533) {
> + ret = adv7533_attach_dsi(adv7511);
> + if (ret)
> + goto err_remove_bridge;
> + }
> +
>   return 0;
>  
> +err_remove_bridge:
> + drm_bridge_remove(>bridge);
>  err_unregister_cec:
>   i2c_unregister_device(adv7511->i2c_cec);
>   if (adv7511->cec_clk)


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

Re: [PATCH] drm/bridge: tc358767: do a software reset if reset pin isn't connected

[Andrzej Hajda]

On 27.06.2019 10:59, Lucas Stach wrote:
> To get the chip into the expected state, even when the hardware reset pin
> isn't connected, do a software reset in this case. It isn't as thorough as
> the hardware reset, as the I2C communication block can not be reset for
> obvious reasons, but it's getting the chip into a defined state.
>
> Signed-off-by: Lucas Stach 

Queued to drm-misc-next.


Regards

Andrzej


> ---
>  drivers/gpu/drm/bridge/tc358767.c | 23 +++
>  1 file changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> b/drivers/gpu/drm/bridge/tc358767.c
> index 13ade28a36a8..1d5ba451e268 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -70,6 +70,13 @@
>  #define DP0_VIDSRC_DSI_RX(1 << 0)
>  #define DP0_VIDSRC_DPI_RX(2 << 0)
>  #define DP0_VIDSRC_COLOR_BAR (3 << 0)
> +#define SYSRSTENB0x050c
> +#define ENBI2C   (1 << 0)
> +#define ENBLCD0  (1 << 2)
> +#define ENBBM(1 << 3)
> +#define ENBDSIRX (1 << 4)
> +#define ENBREG   (1 << 5)
> +#define ENBHDCP  (1 << 8)
>  #define GPIOM0x0540
>  #define GPIOC0x0544
>  #define GPIOO0x0548
> @@ -1497,6 +1504,22 @@ static int tc_probe(struct i2c_client *client, const 
> struct i2c_device_id *id)
>  
>   tc->assr = (tc->rev == 0x6601); /* Enable ASSR for eDP panels */
>  
> + if (!tc->reset_gpio) {
> + /*
> +  * If the reset pin isn't present, do a software reset. It isn't
> +  * as thorough as the hardware reset, as we can't reset the I2C
> +  * communication block for obvious reasons, but it's getting the
> +  * chip into a defined state.
> +  */
> + regmap_update_bits(tc->regmap, SYSRSTENB,
> + ENBLCD0 | ENBBM | ENBDSIRX | ENBREG | ENBHDCP,
> + 0);
> + regmap_update_bits(tc->regmap, SYSRSTENB,
> + ENBLCD0 | ENBBM | ENBDSIRX | ENBREG | ENBHDCP,
> + ENBLCD0 | ENBBM | ENBDSIRX | ENBREG | ENBHDCP);
> + usleep_range(5000, 1);
> + }
> +
>   if (tc->hpd_pin >= 0) {
>   u32 lcnt_reg = tc->hpd_pin == 0 ? INT_GP0_LCNT : INT_GP1_LCNT;
>   u32 h_lc = INT_GPIO_H(tc->hpd_pin) | INT_GPIO_LC(tc->hpd_pin);


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

Re: [PATCH] drm/bridge: dw-hdmi: Use automatic CTS generation mode when using non-AHB audio

[Andrzej Hajda]

On 12.06.2019 10:51, Neil Armstrong wrote:
> When using an I2S source using a different clock source (usually the I2S
> audio HW uses dedicated PLLs, different from the HDMI PHY PLL), fixed
> CTS values will cause some frequent audio drop-out and glitches as
> reported on Amlogic, Allwinner and Rockchip SoCs setups.
>
> Setting the CTS in automatic mode will let the HDMI controller generate
> automatically the CTS value to match the input audio clock.
>
> The DesignWare DW-HDMI User Guide explains:
>   For Automatic CTS generation
>   Write "0" on the bit field "CTS_manual", Register 0x3205: AUD_CTS3
>
> The DesignWare DW-HDMI Databook explains :
>   If "CTS_manual" bit equals 0b this registers contains "audCTS[19:0]"
>   generated by the Cycle time counter according to specified timing.
>
> Cc: Jernej Skrabec 
> Cc: Maxime Ripard 
> Cc: Jonas Karlman 
> Cc: Heiko Stuebner 
> Cc: Jerome Brunet 
> Signed-off-by: Neil Armstrong 


Queued to drm-misc-next.


Regards

Andrzej


> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 44 +++
>  1 file changed, 29 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index c68b6ed1bb35..6458c3a31d23 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -437,8 +437,14 @@ static void hdmi_set_cts_n(struct dw_hdmi *hdmi, 
> unsigned int cts,
>   /* nshift factor = 0 */
>   hdmi_modb(hdmi, 0, HDMI_AUD_CTS3_N_SHIFT_MASK, HDMI_AUD_CTS3);
>  
> - hdmi_writeb(hdmi, ((cts >> 16) & HDMI_AUD_CTS3_AUDCTS19_16_MASK) |
> - HDMI_AUD_CTS3_CTS_MANUAL, HDMI_AUD_CTS3);
> + /* Use automatic CTS generation mode when CTS is not set */
> + if (cts)
> + hdmi_writeb(hdmi, ((cts >> 16) &
> +HDMI_AUD_CTS3_AUDCTS19_16_MASK) |
> +   HDMI_AUD_CTS3_CTS_MANUAL,
> + HDMI_AUD_CTS3);
> + else
> + hdmi_writeb(hdmi, 0, HDMI_AUD_CTS3);
>   hdmi_writeb(hdmi, (cts >> 8) & 0xff, HDMI_AUD_CTS2);
>   hdmi_writeb(hdmi, cts & 0xff, HDMI_AUD_CTS1);
>  
> @@ -508,24 +514,32 @@ static void hdmi_set_clk_regenerator(struct dw_hdmi 
> *hdmi,
>  {
>   unsigned long ftdms = pixel_clk;
>   unsigned int n, cts;
> + u8 config3;
>   u64 tmp;
>  
>   n = hdmi_compute_n(sample_rate, pixel_clk);
>  
> - /*
> -  * Compute the CTS value from the N value.  Note that CTS and N
> -  * can be up to 20 bits in total, so we need 64-bit math.  Also
> -  * note that our TDMS clock is not fully accurate; it is accurate
> -  * to kHz.  This can introduce an unnecessary remainder in the
> -  * calculation below, so we don't try to warn about that.
> -  */
> - tmp = (u64)ftdms * n;
> - do_div(tmp, 128 * sample_rate);
> - cts = tmp;
> + config3 = hdmi_readb(hdmi, HDMI_CONFIG3_ID);
>  
> - dev_dbg(hdmi->dev, "%s: fs=%uHz ftdms=%lu.%03luMHz N=%d cts=%d\n",
> - __func__, sample_rate, ftdms / 100, (ftdms / 1000) % 1000,
> - n, cts);
> + /* Only compute CTS when using internal AHB audio */
> + if (config3 & HDMI_CONFIG3_AHBAUDDMA) {
> + /*
> +  * Compute the CTS value from the N value.  Note that CTS and N
> +  * can be up to 20 bits in total, so we need 64-bit math.  Also
> +  * note that our TDMS clock is not fully accurate; it is
> +  * accurate to kHz.  This can introduce an unnecessary remainder
> +  * in the calculation below, so we don't try to warn about that.
> +  */
> + tmp = (u64)ftdms * n;
> + do_div(tmp, 128 * sample_rate);
> + cts = tmp;
> +
> + dev_dbg(hdmi->dev, "%s: fs=%uHz ftdms=%lu.%03luMHz N=%d 
> cts=%d\n",
> + __func__, sample_rate,
> + ftdms / 100, (ftdms / 1000) % 1000,
> + n, cts);
> + } else
> + cts = 0;
>  
>   spin_lock_irq(>audio_lock);
>   hdmi->audio_n = n;


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

Re: drm/msm/dpu: Correct dpu encoder spinlock initialization

[dhar]

On 2019-06-26 03:10, Jeykumar Sankaran wrote:

On 2019-06-24 22:44, d...@codeaurora.org wrote:

On 2019-06-25 03:56, Jeykumar Sankaran wrote:

On 2019-06-23 23:27, Shubhashree Dhar wrote:

dpu encoder spinlock should be initialized during dpu encoder
init instead of dpu encoder setup which is part of commit.
There are chances that vblank control uses the uninitialized
spinlock if not initialized during encoder init.

Not much can be done if someone is performing a vblank operation
before encoder_setup is done.
Can you point to the path where this lock is acquired before
the encoder_setup?

Thanks
Jeykumar S.




When running some dp usecase, we are hitting this callstack.

Process kworker/u16:8 (pid: 215, stack limit = 0xdf9dd930)
Call trace:
 spin_dump+0x84/0x8c
 spin_dump+0x0/0x8c
 do_raw_spin_lock+0x80/0xb0
 _raw_spin_lock_irqsave+0x34/0x44
 dpu_encoder_toggle_vblank_for_crtc+0x8c/0xe8
 dpu_crtc_vblank+0x168/0x1a0
 dpu_kms_enable_vblank+0[   11.648998]  vblank_ctrl_worker+0x3c/0x60
 process_one_work+0x16c/0x2d8
 worker_thread+0x1d8/0x2b0
 kthread+0x124/0x134

Looks like vblank is getting enabled earlier causing this issue and we
are using the spinlock without initializing it.

Thanks,
Shubhashree


DP calls into set_encoder_mode during hotplug before even notifying the
u/s. Can you trace out the original caller of this stack?

Even though the patch is harmless, I am not entirely convinced to move 
this

initialization. Any call which acquires the lock before encoder_setup
will be a no-op since there will not be any physical encoder to work 
with.


Thanks and Regards,
Jeykumar S.


Change-Id: I5a18b95fa47397c834a266b22abf33a517b03a4e
Signed-off-by: Shubhashree Dhar 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 5f085b5..22938c7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2195,8 +2195,6 @@ int dpu_encoder_setup(struct drm_device *dev, 
struct

drm_encoder *enc,
if (ret)
goto fail;

-   spin_lock_init(_enc->enc_spinlock);
-
atomic_set(_enc->frame_done_timeout, 0);
timer_setup(_enc->frame_done_timer,
dpu_encoder_frame_done_timeout, 0);
@@ -2250,6 +2248,7 @@ struct drm_encoder *dpu_encoder_init(struct
drm_device *dev,

drm_encoder_helper_add(_enc->base, _encoder_helper_funcs);

+   spin_lock_init(_enc->enc_spinlock);
dpu_enc->enabled = false;

return _enc->base;


In dpu_crtc_vblank(), we are looping through all the encoders in the 
present mode_config: 
https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c#L1082
and hence calling dpu_encoder_toggle_vblank_for_crtc() for all the 
encoders. But in dpu_encoder_toggle_vblank_for_crtc(), after acquiring 
the spinlock, we will do a early return for
the encoders which are not currently assigned to our crtc: 
https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c#L1318.
Since the encoder_setup for the secondary encoder(dp encoder in this 
case) is not called until dp hotplug, we are hitting kernel panic while 
acquiring the lock.

Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I

[Maxime Ripard]

Hi!

On Fri, Jun 28, 2019 at 12:39:32PM +0200, Andrzej Hajda wrote:
> On 12.06.2019 17:20, Maxime Ripard wrote:
> >> I am not sure if I understand whole discussion here, but I also do not
> >> understand whole edp-connector thing.
> > The context is this one:
> > https://patchwork.freedesktop.org/patch/257352/?series=51182=1
> > https://patchwork.freedesktop.org/patch/283012/?series=56163=1
> > https://patchwork.freedesktop.org/patch/286468/?series=56776=2
> >
> > TL;DR: This bridge is being used on ARM laptops that can come with
> > different eDP panels. Some of these panels require a regulator to be
> > enabled for the panel to work, and this is obviously something that
> > should be in the DT.
> >
> > However, we can't really describe the panel itself, since the vendor
> > uses several of them and just relies on the eDP bus to do its job at
> > retrieving the EDIDs. A generic panel isn't really working either
> > since that would mean having a generic behaviour for all the panels
> > connected to that bus, which isn't there either.
> >
> > The connector allows to expose this nicely.
>
> As VESA presentation says[1] eDP is based on DP but is much more
> flexible, it is up to integrator (!!!) how the connection, power
> up/down, initialization sequence should be performed. Trying to cover
> every such case in edp-connector seems to me similar to panel-simple
> attempt failure. Moreover there is no such thing as physical standard
> eDP connector. Till now I though DT connector should describe physical
> connector on the device, now I am lost, are there some DT bindings
> guidelines about definition of a connector?

This might be semantics but I guess we're in some kind of grey area?

Like, for eDP, if it's soldered I guess we could say that there's no
connector. But what happens if for some other board, that signal is
routed through a ribbon?

You could argue that there's no physical connector in both cases, or
that there's one in both, or one for the ribbon and no connector for
the one soldered in.

> Maybe instead of edp-connector one would introduce integrator's specific
> connector, for example with compatible "olimex,teres-edp-connector"
> which should follow edp abstract connector rules? This will be at least
> consistent with below presentation[1] - eDP requirements depends on
> integrator. Then if olimex has standard way of dealing with panels
> present in olimex/teres platforms the driver would then create
> drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
> Anyway it still looks fishy for me :), maybe because I am not
> familiarized with details of these platforms.

That makes sense yes

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

[GIT PULL] etnaviv-fixes for 5.2-rc8/final

[Lucas Stach]

Hi Daniel, hi Dave,

please pull in this fix, which fixes a kernel nullptr deref on module
unload when any etnaviv GPU failed to initialize properly.

Regards,
Lucas

The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:

  Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)

are available in the Git repository at:

  https://git.pengutronix.de/git/lst/linux etnaviv/fixes

for you to fetch changes up to be132e1375c1fffe48801296279079f8a59a9ed3:

  drm/etnaviv: add missing failure path to destroy suballoc (2019-06-28 
10:59:44 +0200)


Lucas Stach (1):
  drm/etnaviv: add missing failure path to destroy suballoc

 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107877] deepin-desktop: xdg-email: no method available for opening 'mailto:'

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107877

--- Comment #28 from rozersamith  ---
mywifiexxt.net a one stop solution shop for all your queries related to Netgear
WiFi Extender Setup and Netgear Login issues. Get in touch will the leading
technical experts, who are eager to provide you with the best assistance for
Netgear WiFi  Extender 24*7. Just dial to our toll-free number +1-888-961-4011
for Netgear extender solutions.

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

Re: [PATCH] drm: bridge: DRM_SIL_SII8620 should depend on, not select INPUT

[Andrzej Hajda]

On 01.07.2019 11:23, Andrzej Hajda wrote:
> On 01.07.2019 05:39, Randy Dunlap wrote:
>> From: Randy Dunlap 
>>
>> A single driver should not enable (select) an entire subsystem,
>> such as INPUT, so change the 'select' to "depends on".
>>
>> Fixes: d6abe6df706c ("drm/bridge: sil_sii8620: do not have a dependency of 
>> RC_CORE")
>>
>> Signed-off-by: Randy Dunlap 
>> Cc: Inki Dae 
>> Cc: Andrzej Hajda 
>> Cc: Laurent Pinchart 
>> Cc: dri-devel@lists.freedesktop.org
>> ---
>> Linus has written this a couple of times in the last 15 years or so,
>> but my search fu cannot find it.  And there are a few drivers in the
>> kernel tree that do this, but we shouldn't be adding more that do so.
>
> The proper solution has been already posted [1], but it has not been
> applied yet to input tree?
>
> Randy are there chances your patchset will appear in ML in near future,
> or should I merge your sii8620 patch alone?


Ups, I used wrong surname, I meant Ronald, added him input ML to cc.


Regards

Andrzej



>
>
> [1]:
> https://lore.kernel.org/lkml/20190419081926.13567-2-ron...@innovation.ch/
>
>
> Regards
>
> Andrzej
>
>
>
>>  drivers/gpu/drm/bridge/Kconfig |3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> --- lnx-52-rc7.orig/drivers/gpu/drm/bridge/Kconfig
>> +++ lnx-52-rc7/drivers/gpu/drm/bridge/Kconfig
>> @@ -83,10 +83,9 @@ config DRM_PARADE_PS8622
>>  
>>  config DRM_SIL_SII8620
>>  tristate "Silicon Image SII8620 HDMI/MHL bridge"
>> -depends on OF
>> +depends on OF && INPUT
>>  select DRM_KMS_HELPER
>>  imply EXTCON
>> -select INPUT
>>  select RC_CORE
>>  help
>>Silicon Image SII8620 HDMI/MHL bridge chip driver.
>>
>>
>>
>>

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

Re: [PATCH] drm: bridge: DRM_SIL_SII8620 should depend on, not select INPUT

[Andrzej Hajda]

On 01.07.2019 05:39, Randy Dunlap wrote:
> From: Randy Dunlap 
>
> A single driver should not enable (select) an entire subsystem,
> such as INPUT, so change the 'select' to "depends on".
>
> Fixes: d6abe6df706c ("drm/bridge: sil_sii8620: do not have a dependency of 
> RC_CORE")
>
> Signed-off-by: Randy Dunlap 
> Cc: Inki Dae 
> Cc: Andrzej Hajda 
> Cc: Laurent Pinchart 
> Cc: dri-devel@lists.freedesktop.org
> ---
> Linus has written this a couple of times in the last 15 years or so,
> but my search fu cannot find it.  And there are a few drivers in the
> kernel tree that do this, but we shouldn't be adding more that do so.


The proper solution has been already posted [1], but it has not been
applied yet to input tree?

Randy are there chances your patchset will appear in ML in near future,
or should I merge your sii8620 patch alone?


[1]:
https://lore.kernel.org/lkml/20190419081926.13567-2-ron...@innovation.ch/


Regards

Andrzej



>
>  drivers/gpu/drm/bridge/Kconfig |3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> --- lnx-52-rc7.orig/drivers/gpu/drm/bridge/Kconfig
> +++ lnx-52-rc7/drivers/gpu/drm/bridge/Kconfig
> @@ -83,10 +83,9 @@ config DRM_PARADE_PS8622
>  
>  config DRM_SIL_SII8620
>   tristate "Silicon Image SII8620 HDMI/MHL bridge"
> - depends on OF
> + depends on OF && INPUT
>   select DRM_KMS_HELPER
>   imply EXTCON
> - select INPUT
>   select RC_CORE
>   help
> Silicon Image SII8620 HDMI/MHL bridge chip driver.
>
>
>
>

Re: [PATCH v1] drm/arm: drop use of drmP.h

[Liviu Dudau]

On Sun, Jun 30, 2019 at 07:21:31AM +0200, Sam Ravnborg wrote:
> Drop use of the deprecated drmP.h header file.
> 
> While touching the list of include files divide them
> into blocks and sort within each block.
> Fix fallout.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Liviu Dudau 

Acked-by: Liviu Dudau 

> Cc: Brian Starkey 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: mal...@foss.arm.com
> ---
> The patch is build tested using several configs and
> several architectures (including arm, arm64, x86).
> 
> The patch is based on drm-misc.
> 
> If patch is OK, please apply to your tree
> as this driver is maintained outside drm-misc.

I've applied the patch to my tree. I'll see if I can squeeze it into drm-next
before the merge window opens, otherwise it will get sent with the next batch
of patches.

Best regards,
Liviu

> 
> I am happy to rebase on another tree, just let me know.
> 
> Sam
> 
>  drivers/gpu/drm/arm/hdlcd_crtc.c| 12 +++-
>  drivers/gpu/drm/arm/hdlcd_drv.c |  7 ++-
>  drivers/gpu/drm/arm/malidp_crtc.c   | 11 +++
>  drivers/gpu/drm/arm/malidp_drv.c|  8 +---
>  drivers/gpu/drm/arm/malidp_drv.h|  7 ---
>  drivers/gpu/drm/arm/malidp_hw.c |  7 ++-
>  drivers/gpu/drm/arm/malidp_mw.c |  5 +++--
>  drivers/gpu/drm/arm/malidp_planes.c |  4 +++-
>  8 files changed, 41 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c 
> b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index a3efa28436ea..af67fefed38d 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -9,7 +9,12 @@
>   *  Implementation of a CRTC class for the HDLCD driver.
>   */
>  
> -#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
>  #include 
>  #include 
>  #include 
> @@ -19,10 +24,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
> -#include 
> -#include 
> +#include 
>  
>  #include "hdlcd_drv.h"
>  #include "hdlcd_regs.h"
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index 27c46a2838c5..2e053815b54a 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -14,21 +14,26 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
> -#include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "hdlcd_drv.h"
>  #include "hdlcd_regs.h"
> diff --git a/drivers/gpu/drm/arm/malidp_crtc.c 
> b/drivers/gpu/drm/arm/malidp_crtc.c
> index db4451260fff..587d94798f5c 100644
> --- a/drivers/gpu/drm/arm/malidp_crtc.c
> +++ b/drivers/gpu/drm/arm/malidp_crtc.c
> @@ -6,14 +6,17 @@
>   * ARM Mali DP500/DP550/DP650 driver (crtc operations)
>   */
>  
> -#include 
> +#include 
> +#include 
> +
> +#include 
> +
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> -#include 
> -#include 
> -#include 
> +#include 
>  
>  #include "malidp_drv.h"
>  #include "malidp_hw.h"
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 3ecdf1311335..a3242971d0d6 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -15,17 +15,19 @@
>  #include 
>  #include 
>  
> -#include 
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
> +#include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include "malidp_drv.h"
>  #include "malidp_mw.h"
> diff --git a/drivers/gpu/drm/arm/malidp_drv.h 
> b/drivers/gpu/drm/arm/malidp_drv.h
> index 0a639af8337e..cdfddfabf2d1 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.h
> +++ b/drivers/gpu/drm/arm/malidp_drv.h
> @@ -9,12 +9,13 @@
>  #ifndef __MALIDP_DRV_H__
>  #define __MALIDP_DRV_H__
>  
> -#include 
> -#include 
>  #include 
>  #include 
>  #include 
> -#include 
> +
> +#include 
> +#include 
> +
>  #include "malidp_hw.h"
>  
>  #define MALIDP_CONFIG_VALID_INIT 0
> diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
> index 50af399d7f6f..0d4c309efbce 100644
> --- a/drivers/gpu/drm/arm/malidp_hw.c
> +++ b/drivers/gpu/drm/arm/malidp_hw.c
> @@ -9,12 +9,17 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
> -#include 
> +
>  #include 
>  #include 
>  
> +#include 
> +#include 
> +#include 
> +
>  #include "malidp_drv.h"
>  #include "malidp_hw.h"
>  #include "malidp_mw.h"
> diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
> index 2e812525025d..22c0847986df 100644
> --- a/drivers/gpu/drm/arm/malidp_mw.c
> +++ b/drivers/gpu/drm/arm/malidp_mw.c
> @@ -5,13 +5,14 @@
>   *
>   * ARM Mali DP Writeback connector implementation
>   */
> +
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
> +#include 
>  #include 
> -#include 
> +#include 
>  #include 
>  
>  #include 

Re: [PATCH v1 03/33] drm/stm: drop use of drmP.h

[Benjamin Gaignard]

Le dim. 30 juin 2019 à 08:19, Sam Ravnborg  a écrit :
>
> Drop use of the deprecated header file drmP.h
> from the sole user in the stm driver.
> Replace with necessary include files.

Applied on drm-misc-next.

Thanks,
Benjamin

>
> Signed-off-by: Sam Ravnborg 
> Cc: Yannick Fertre 
> Cc: Philippe Cornu 
> Cc: Benjamin Gaignard 
> Cc: Vincent Abriou 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Maxime Coquelin 
> Cc: Alexandre Torgue 
> Cc: linux-st...@st-md-mailman.stormreply.com
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-st...@st-md-mailman.stormreply.com
> Cc: linux-arm-ker...@lists.infradead.org
> ---
> The list of cc: was too large to add all recipients to the cover letter.
> Please find cover letter here:
> https://lists.freedesktop.org/archives/dri-devel/2019-June/thread.html
> Search for "drm: drop use of drmp.h in drm-misc"
>
> Sam
>
>  drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c 
> b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> index 0ab32fee6c1b..a03a642c147c 100644
> --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> @@ -8,13 +8,17 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
> -#include 
> -#include 
> -#include 
> +
>  #include 
>
> +#include 
> +#include 
> +#include 
> +
>  #define HWVER_130  0x31333000  /* IP version 1.30 */
>  #define HWVER_131  0x31333100  /* IP version 1.31 */
>
> --
> 2.20.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] drm/vram: Set GEM object functions for PRIME

[Gerd Hoffmann]

On Mon, Jul 01, 2019 at 09:28:59AM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 01.07.19 um 08:32 schrieb Gerd Hoffmann:
> > On Fri, Jun 28, 2019 at 02:26:56PM +0200, Thomas Zimmermann wrote:
> >> PRIME functionality is now provided via the callback functions in
> >> struct drm_gem_object_funcs. The driver-structure functions are obsolete.
> >> As a side effect of this patch, VRAM-based drivers get basic PRIME
> >> support automatically without having to set any flags or additional
> >> fields.
> > 
> >> +static void drm_gem_vram_object_free(struct drm_gem_object *gem)
> >> +static int drm_gem_vram_object_funcs_pin(struct drm_gem_object *gem)
> >> +static void drm_gem_vram_object_funcs_unpin(struct drm_gem_object *gem)
> >> +static void *drm_gem_vram_object_funcs_vmap(struct drm_gem_object *gem)
> >> +static void drm_gem_vram_object_funcs_vunmap(struct drm_gem_object *gem,
> >> +   void *vaddr)
> > 
> >> +static const struct drm_gem_object_funcs drm_gem_vram_object_funcs = {
> >> +  .free   = drm_gem_vram_object_free,
> >> +  .pin= drm_gem_vram_object_funcs_pin,
> >> +  .unpin  = drm_gem_vram_object_funcs_unpin,
> >> +  .vmap   = drm_gem_vram_object_funcs_vmap,
> >> +  .vunmap = drm_gem_vram_object_funcs_vunmap
> >> +};
> > 
> > Why new functions?  Can't you just hook up the existing prime functions?
> 
> The final patch will remove the existing functions, so drivers won't use
> them accidentally.

But the new and the old ones are identical, right?  So why add/remove?
Why not just rename them?

I'd also suggest to name them consistently (free has no _funcs, all
others have).  I'd drop _funcs from all function names.

cheers,
  Gerd

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

Re: use exact allocation for dma coherent memory

[Christoph Hellwig]

On Fri, Jun 14, 2019 at 03:47:10PM +0200, Christoph Hellwig wrote:
> Switching to a slightly cleaned up alloc_pages_exact is pretty easy,
> but it turns out that because we didn't filter valid gfp_t flags
> on the DMA allocator, a bunch of drivers were passing __GFP_COMP
> to it, which is rather bogus in too many ways to explain.  Arm has
> been filtering it for a while, but this series instead tries to fix
> the drivers and warn when __GFP_COMP is passed, which makes it much
> larger than just adding the functionality.

Dear driver maintainers,

can you look over the patches touching your drivers, please?  I'd
like to get as much as possible of the driver patches into this
merge window, so that it can you through your maintainer trees.

Re: [PATCH 3/3] video: fbdev: don't print error message on framebuffer_alloc() failure

[Benjamin Tissoires]

Hi Bartlomiej,

On Fri, Jun 14, 2019 at 4:52 PM Bartlomiej Zolnierkiewicz
 wrote:
>
> framebuffer_alloc() can fail only on kzalloc() memory allocation
> failure and since kzalloc() will print error message in such case
> we can omit printing extra error message in drivers (which BTW is
> what the majority of framebuffer_alloc() users is doing already).
>
> Cc: "Bruno Prémont" 
> Cc: Jiri Kosina 
> Cc: Benjamin Tissoires 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> ---
>  drivers/hid/hid-picolcd_fb.c   |4 +---
>  drivers/video/fbdev/amifb.c|4 +---
>  drivers/video/fbdev/arkfb.c|4 +---
>  drivers/video/fbdev/atmel_lcdfb.c  |4 +---
>  drivers/video/fbdev/aty/aty128fb.c |5 ++---
>  drivers/video/fbdev/aty/atyfb_base.c   |   10 --
>  drivers/video/fbdev/aty/radeon_base.c  |2 --
>  drivers/video/fbdev/chipsfb.c  |1 -
>  drivers/video/fbdev/cirrusfb.c |5 +
>  drivers/video/fbdev/da8xx-fb.c |1 -
>  drivers/video/fbdev/efifb.c|1 -
>  drivers/video/fbdev/grvga.c|4 +---
>  drivers/video/fbdev/gxt4500.c  |5 ++---
>  drivers/video/fbdev/hyperv_fb.c|4 +---
>  drivers/video/fbdev/i740fb.c   |4 +---
>  drivers/video/fbdev/imsttfb.c  |5 +
>  drivers/video/fbdev/intelfb/intelfbdrv.c   |5 ++---
>  drivers/video/fbdev/jz4740_fb.c|4 +---
>  drivers/video/fbdev/mb862xx/mb862xxfbdrv.c |5 +
>  drivers/video/fbdev/mbx/mbxfb.c|4 +---
>  drivers/video/fbdev/omap/omapfb_main.c |2 --
>  drivers/video/fbdev/omap2/omapfb/omapfb-main.c |6 +-
>  drivers/video/fbdev/platinumfb.c   |5 ++---
>  drivers/video/fbdev/pmag-aa-fb.c   |4 +---
>  drivers/video/fbdev/pmag-ba-fb.c   |4 +---
>  drivers/video/fbdev/pmagb-b-fb.c   |4 +---
>  drivers/video/fbdev/pvr2fb.c   |6 +-
>  drivers/video/fbdev/riva/fbdev.c   |1 -
>  drivers/video/fbdev/s3c-fb.c   |4 +---
>  drivers/video/fbdev/s3fb.c |4 +---
>  drivers/video/fbdev/sh_mobile_lcdcfb.c |8 ++--
>  drivers/video/fbdev/sm501fb.c  |4 +---
>  drivers/video/fbdev/sm712fb.c  |1 -
>  drivers/video/fbdev/smscufx.c  |4 +---
>  drivers/video/fbdev/ssd1307fb.c|4 +---
>  drivers/video/fbdev/sunxvr1000.c   |1 -
>  drivers/video/fbdev/sunxvr2500.c   |1 -
>  drivers/video/fbdev/sunxvr500.c|1 -
>  drivers/video/fbdev/tgafb.c|4 +---
>  drivers/video/fbdev/udlfb.c|4 +---
>  drivers/video/fbdev/via/viafbdev.c |6 +-
>  drivers/video/fbdev/vt8623fb.c |4 +---
>  42 files changed, 40 insertions(+), 123 deletions(-)
>
> Index: b/drivers/hid/hid-picolcd_fb.c
> ===
> --- a/drivers/hid/hid-picolcd_fb.c
> +++ b/drivers/hid/hid-picolcd_fb.c
> @@ -522,10 +522,8 @@ int picolcd_init_framebuffer(struct pico
> sizeof(struct fb_deferred_io) +
> sizeof(struct picolcd_fb_data) +
> PICOLCDFB_SIZE, dev);
> -   if (info == NULL) {
> -   dev_err(dev, "failed to allocate a framebuffer\n");
> +   if (!info)
> goto err_nomem;
> -   }

It would have been better to split this change as the HID and fbdev
are different trees.

However, I do not expect a conflict here (there hasn't been updates of
hid-picolcd_fb.c in a while), so feel free to take this patch through
the fbdev tree with my:
Acked-By: Benjamin Tissoires 

Cheers,
Benjamin

>
> info->fbdefio = info->par;
> *info->fbdefio = picolcd_fb_defio;
> Index: b/drivers/video/fbdev/amifb.c
> ===
> --- a/drivers/video/fbdev/amifb.c
> +++ b/drivers/video/fbdev/amifb.c
> @@ -3554,10 +3554,8 @@ static int __init amifb_probe(struct pla
> custom.dmacon = DMAF_ALL | DMAF_MASTER;
>
> info = framebuffer_alloc(sizeof(struct amifb_par), >dev);
> -   if (!info) {
> -   dev_err(>dev, "framebuffer_alloc failed\n");
> +   if (!info)
> return -ENOMEM;
> -   }
>
> strcpy(info->fix.id, "Amiga ");
> info->fix.visual = FB_VISUAL_PSEUDOCOLOR;
> Index: b/drivers/video/fbdev/arkfb.c
> ===
> --- a/drivers/video/fbdev/arkfb.c
> +++ b/drivers/video/fbdev/arkfb.c
> @@ -954,10 +954,8 @@ static int ark_pci_probe(struct pci_dev
>
> /* Allocate and fill 

[PATCH 1/2] drm: report dp downstream port type as a subconnector property

[Oleg Vasilev]

Currently, downstream port type is only reported in debugfs. This
information should be considered important since it reflects the actual
physical connector type. Some userspace (e.g. window compositors)
may want to show this info to a user.

The 'subconnector' property is already utilized for DVI-I and TV-out for
reporting connector subtype.

The initial motivation for this feature came from i2c test [1].
It is supposed to be skipped on VGA connectors, but it cannot
detect VGA over DP and fails instead.

[1]: https://bugs.freedesktop.org/show_bug.cgi?id=104097
Signed-off-by: Oleg Vasilev 
---
 drivers/gpu/drm/drm_connector.c | 38 +++--
 drivers/gpu/drm/drm_dp_helper.c | 36 +++
 include/drm/drm_connector.h |  2 ++
 include/drm/drm_dp_helper.h |  3 +++
 include/drm/drm_mode_config.h   |  6 ++
 include/uapi/drm/drm_mode.h | 22 ---
 6 files changed, 97 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 068d4b05f1be..95cd51254be6 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -793,7 +793,7 @@ static const struct drm_prop_enum_list 
drm_dvi_i_select_enum_list[] = {
 DRM_ENUM_NAME_FN(drm_get_dvi_i_select_name, drm_dvi_i_select_enum_list)
 
 static const struct drm_prop_enum_list drm_dvi_i_subconnector_enum_list[] = {
-   { DRM_MODE_SUBCONNECTOR_Unknown,   "Unknown"   }, /* DVI-I and TV-out */
+   { DRM_MODE_SUBCONNECTOR_Unknown,   "Unknown"   }, /* DVI-I, TV-out and 
DP */
{ DRM_MODE_SUBCONNECTOR_DVID,  "DVI-D" }, /* DVI-I  */
{ DRM_MODE_SUBCONNECTOR_DVIA,  "DVI-A" }, /* DVI-I  */
 };
@@ -810,7 +810,7 @@ static const struct drm_prop_enum_list 
drm_tv_select_enum_list[] = {
 DRM_ENUM_NAME_FN(drm_get_tv_select_name, drm_tv_select_enum_list)
 
 static const struct drm_prop_enum_list drm_tv_subconnector_enum_list[] = {
-   { DRM_MODE_SUBCONNECTOR_Unknown,   "Unknown"   }, /* DVI-I and TV-out */
+   { DRM_MODE_SUBCONNECTOR_Unknown,   "Unknown"   }, /* DVI-I, TV-out and 
DP */
{ DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
{ DRM_MODE_SUBCONNECTOR_SVIDEO,"SVIDEO"}, /* TV-out */
{ DRM_MODE_SUBCONNECTOR_Component, "Component" }, /* TV-out */
@@ -819,6 +819,19 @@ static const struct drm_prop_enum_list 
drm_tv_subconnector_enum_list[] = {
 DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
 drm_tv_subconnector_enum_list)
 
+static const struct drm_prop_enum_list drm_dp_subconnector_enum_list[] = {
+   { DRM_MODE_SUBCONNECTOR_Unknown,   "Unknown"   }, /* DVI-I, TV-out and 
DP */
+   { DRM_MODE_SUBCONNECTOR_VGA,   "VGA"   }, /* DP */
+   { DRM_MODE_SUBCONNECTOR_DVI,   "DVI"   }, /* DP */
+   { DRM_MODE_SUBCONNECTOR_HDMI,  "HDMI"  }, /* DP */
+   { DRM_MODE_SUBCONNECTOR_DP,"DP"}, /* DP */
+   { DRM_MODE_SUBCONNECTOR_Wireless,  "Wireless"  }, /* DP */
+   { DRM_MODE_SUBCONNECTOR_Native,"Native"}, /* DP */
+};
+
+DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
+drm_dp_subconnector_enum_list)
+
 static const struct drm_prop_enum_list hdmi_colorspaces[] = {
/* For Default case, driver will set the colorspace */
{ DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
@@ -1128,6 +1141,27 @@ int drm_mode_create_dvi_i_properties(struct drm_device 
*dev)
 }
 EXPORT_SYMBOL(drm_mode_create_dvi_i_properties);
 
+/**
+ * drm_mode_create_dp_properties - create DP specific connector properties
+ * @dev: DRM device
+ *
+ * Called by a driver the first time a DP connector is made.
+ */
+void drm_mode_create_dp_properties(struct drm_device *dev)
+{
+   struct drm_property *dp_subconnector;
+
+   if (dev->mode_config.dp_subconnector_property)
+   return;
+
+   dp_subconnector = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
+  "subconnector",
+  
drm_dp_subconnector_enum_list,
+  
ARRAY_SIZE(drm_dp_subconnector_enum_list));
+   dev->mode_config.dp_subconnector_property = dp_subconnector;
+}
+EXPORT_SYMBOL(drm_mode_create_dp_properties);
+
 /**
  * DOC: HDMI connector properties
  *
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 0b994d083a89..63d8f0b8492c 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -662,6 +662,42 @@ void drm_dp_downstream_debug(struct seq_file *m,
 }
 EXPORT_SYMBOL(drm_dp_downstream_debug);
 
+/**
+ * drm_dp_downstream_subconnector_type() - get DP branch device type
+ * @dpcd: DisplayPort configuration data
+ * @port_cap: port capabilities
+ *
+ */
+enum drm_mode_subconnector
+drm_dp_downstream_subconnector_type(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+   

Re: [PATCH] drm/selftests: reduce stack usage

[Maxime Ripard]

On Fri, Jun 28, 2019 at 02:16:45PM +0200, Arnd Bergmann wrote:
> Putting a large drm_connector object on the stack can lead to warnings
> in some configuration, such as:
>
> drivers/gpu/drm/selftests/test-drm_cmdline_parser.c:18:12: error: stack frame 
> size of 1040 bytes in function 'drm_cmdline_test_res' 
> [-Werror,-Wframe-larger-than=]
> static int drm_cmdline_test_res(void *ignored)
>
> Since the object is never modified, just declare it as 'static const'
> and allow this to be passed down.
>
> Fixes: b7ced38916a9 ("drm/selftests: Add command line parser selftests")
> Signed-off-by: Arnd Bergmann 

Applied, thanks!
Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: [PATCH 1/4] drm/vram: Set GEM object functions for PRIME

[Thomas Zimmermann]

Hi

Am 01.07.19 um 08:32 schrieb Gerd Hoffmann:
> On Fri, Jun 28, 2019 at 02:26:56PM +0200, Thomas Zimmermann wrote:
>> PRIME functionality is now provided via the callback functions in
>> struct drm_gem_object_funcs. The driver-structure functions are obsolete.
>> As a side effect of this patch, VRAM-based drivers get basic PRIME
>> support automatically without having to set any flags or additional
>> fields.
> 
>> +static void drm_gem_vram_object_free(struct drm_gem_object *gem)
>> +static int drm_gem_vram_object_funcs_pin(struct drm_gem_object *gem)
>> +static void drm_gem_vram_object_funcs_unpin(struct drm_gem_object *gem)
>> +static void *drm_gem_vram_object_funcs_vmap(struct drm_gem_object *gem)
>> +static void drm_gem_vram_object_funcs_vunmap(struct drm_gem_object *gem,
>> + void *vaddr)
> 
>> +static const struct drm_gem_object_funcs drm_gem_vram_object_funcs = {
>> +.free   = drm_gem_vram_object_free,
>> +.pin= drm_gem_vram_object_funcs_pin,
>> +.unpin  = drm_gem_vram_object_funcs_unpin,
>> +.vmap   = drm_gem_vram_object_funcs_vmap,
>> +.vunmap = drm_gem_vram_object_funcs_vunmap
>> +};
> 
> Why new functions?  Can't you just hook up the existing prime functions?

The final patch will remove the existing functions, so drivers won't use
them accidentally.

Best regards
Thomas

> 
> cheers,
>   Gerd
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)



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

Re: nouveau: DRM: GPU lockup - switching to software fbcon

[Sergey Senozhatsky]

On (06/19/19 02:07), Ilia Mirkin wrote:
> If all else fails, just remove nouveau_dri.so and/or boot with
> nouveau.noaccel=1 -- should be perfect.

nouveau.noaccel=1 did the trick. Is there any other, let's say
less CPU-intensive, way to fix nouveau?

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

[PATCH v2 0/2] fix vendor prefix for arcxcnn driver and bindings

[Brian Dodge]

These v2 patches incorporate the following changes

1/2 dt-bindings: backlight:

The documentation for "arc" has been re-added but marked (deprecated)
to match the actual driver support for that

2/2 backlight: arcxcnn:

Added new-lines and fixed spelling as per feedback

Original patch description:

This patch is to update the arcxcnn backlight driver to use the
proper "arctic" vendor-prefix and document that in the device-
tree bindings.

There is at least one existing device using the old "arc"
vendor-prefix (Samsung Chromebook Plus), so support for that
remains in the driver source.

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

[PATCH 1/4] gpu: Use dev_get_drvdata()

[Fuqian Huang]

Using dev_get_drvdata directly.

Signed-off-by: Fuqian Huang 
---
 drivers/gpu/drm/msm/adreno/adreno_device.c  |  6 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 13 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c|  6 ++
 drivers/gpu/drm/msm/dsi/dsi_host.c  |  6 ++
 drivers/gpu/drm/msm/msm_drv.c   |  3 +--
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 15 +--
 drivers/gpu/drm/panfrost/panfrost_device.c  |  6 ++
 7 files changed, 19 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index b3deb346a42b..fafd00d2574a 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -403,16 +403,14 @@ static const struct of_device_id dt_match[] = {
 #ifdef CONFIG_PM
 static int adreno_resume(struct device *dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct msm_gpu *gpu = platform_get_drvdata(pdev);
+   struct msm_gpu *gpu = dev_get_drvdata(dev);
 
return gpu->funcs->pm_resume(gpu);
 }
 
 static int adreno_suspend(struct device *dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct msm_gpu *gpu = platform_get_drvdata(pdev);
+   struct msm_gpu *gpu = dev_get_drvdata(dev);
 
return gpu->funcs->pm_suspend(gpu);
 }
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index ae885e5dd07d..6c6f8ca9380f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1025,16 +1025,15 @@ static int dpu_bind(struct device *dev, struct device 
*master, void *data)
 
 static void dpu_unbind(struct device *dev, struct device *master, void *data)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
+   struct dpu_kms *dpu_kms = dev_get_drvdata(dev);
struct dss_module_power *mp = _kms->mp;
 
msm_dss_put_clk(mp->clk_config, mp->num_clk);
-   devm_kfree(>dev, mp->clk_config);
+   devm_kfree(dev, mp->clk_config);
mp->num_clk = 0;
 
if (dpu_kms->rpm_enabled)
-   pm_runtime_disable(>dev);
+   pm_runtime_disable(dev);
 }
 
 static const struct component_ops dpu_ops = {
@@ -1056,8 +1055,7 @@ static int dpu_dev_remove(struct platform_device *pdev)
 static int __maybe_unused dpu_runtime_suspend(struct device *dev)
 {
int rc = -1;
-   struct platform_device *pdev = to_platform_device(dev);
-   struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
+   struct dpu_kms *dpu_kms = dev_get_drvdata(dev);
struct drm_device *ddev;
struct dss_module_power *mp = _kms->mp;
 
@@ -1077,8 +1075,7 @@ static int __maybe_unused dpu_runtime_suspend(struct 
device *dev)
 static int __maybe_unused dpu_runtime_resume(struct device *dev)
 {
int rc = -1;
-   struct platform_device *pdev = to_platform_device(dev);
-   struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
+   struct dpu_kms *dpu_kms = dev_get_drvdata(dev);
struct drm_encoder *encoder;
struct drm_device *ddev;
struct dss_module_power *mp = _kms->mp;
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 901009e1f219..25d1ebb32e73 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -1052,8 +1052,7 @@ static int mdp5_dev_remove(struct platform_device *pdev)
 
 static __maybe_unused int mdp5_runtime_suspend(struct device *dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct mdp5_kms *mdp5_kms = platform_get_drvdata(pdev);
+   struct mdp5_kms *mdp5_kms = dev_get_drvdata(dev);
 
DBG("");
 
@@ -1062,8 +1061,7 @@ static __maybe_unused int mdp5_runtime_suspend(struct 
device *dev)
 
 static __maybe_unused int mdp5_runtime_resume(struct device *dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct mdp5_kms *mdp5_kms = platform_get_drvdata(pdev);
+   struct mdp5_kms *mdp5_kms = dev_get_drvdata(dev);
 
DBG("");
 
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index dbf490176c2c..882f13725819 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -477,8 +477,7 @@ static void dsi_bus_clk_disable(struct msm_dsi_host 
*msm_host)
 
 int msm_dsi_runtime_suspend(struct device *dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct msm_dsi *msm_dsi = platform_get_drvdata(pdev);
+   struct msm_dsi *msm_dsi = dev_get_drvdata(dev);
struct mipi_dsi_host *host = msm_dsi->host;
struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
 
@@ -492,8 +491,7 @@ int msm_dsi_runtime_suspend(struct device *dev)
 
 

[PATCH] drm/nouveau: fix memory leak in nouveau_conn_reset()

[Yongxin Liu]

In nouveau_conn_reset(), if connector->state is true,
__drm_atomic_helper_connector_destroy_state() will be called,
but the memory pointed by asyc isn't freed. Memory leak happens
in the following function __drm_atomic_helper_connector_reset(),
where newly allocated asyc->state will be assigned to connector->state.

So using nouveau_conn_atomic_destroy_state() instead of
__drm_atomic_helper_connector_destroy_state to free the "old" asyc.

Here the is the log showing memory leak.

unreferenced object 0x8c5480483c80 (size 192):
  comm "kworker/0:2", pid 188, jiffies 4294695279 (age 53.179s)
  hex dump (first 32 bytes):
00 f0 ba 7b 54 8c ff ff 00 00 00 00 00 00 00 00  ...{T...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  backtrace:
[<5005c0d0>] kmem_cache_alloc_trace+0x195/0x2c0
[] nouveau_conn_reset+0x25/0xc0 [nouveau]
[<4fd189a2>] nouveau_connector_create+0x3a7/0x610 [nouveau]
[] nv50_display_create+0x343/0x980 [nouveau]
[<2e2b03c3>] nouveau_display_create+0x51f/0x660 [nouveau]
[] nouveau_drm_device_init+0x182/0x7f0 [nouveau]
[] nouveau_drm_probe+0x20c/0x2c0 [nouveau]
[<7e961c3e>] local_pci_probe+0x47/0xa0
[] work_for_cpu_fn+0x1a/0x30
[<28da4805>] process_one_work+0x27c/0x660
[<1d415b04>] worker_thread+0x22b/0x3f0
[<03b69f1f>] kthread+0x12f/0x150
[] ret_from_fork+0x3a/0x50

Signed-off-by: Yongxin Liu 
---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 4116ee62adaf..f69ff22beee0 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -252,7 +252,7 @@ nouveau_conn_reset(struct drm_connector *connector)
return;
 
if (connector->state)
-   __drm_atomic_helper_connector_destroy_state(connector->state);
+   nouveau_conn_atomic_destroy_state(connector, connector->state);
__drm_atomic_helper_connector_reset(connector, >state);
asyc->dither.mode = DITHERING_MODE_AUTO;
asyc->dither.depth = DITHERING_DEPTH_AUTO;
-- 
2.14.4

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

[PATCH 1/2] dt-bindings: backlight: fix vendor prefix for ArcticSand arcxcnn driver bindings

[Brian Dodge]

The vendor-prefixes.txt file properly refers to ArcticSand
as arctic but the driver bindings improperly abbreviated the
prefix to arc. This was a mistake in the original patch. This
patch adds "arctic" and retains "arc" (deprecated) bindings

Signed-off-by: Brian Dodge 
---
 .../bindings/leds/backlight/arcxcnn_bl.txt | 31 +++---
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt 
b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
index 230abde..4d98394 100644
--- a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
+++ b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
@@ -1,8 +1,13 @@
-Binding for ArcticSand arc2c0608 LED driver
+Binding for ArcticSand arc family LED drivers
 
 Required properties:
-- compatible:  should be "arc,arc2c0608"
-- reg: slave address
+- compatible: one of
+   "arctic,arc1c0608"
+   "arctic,arc2c0608"
+   "arctic,arc3c0845"
+   "arc,arc2c0608" (deprecated)
+
+- reg: slave address
 
 Optional properties:
 - default-brightness:  brightness value on boot, value from: 0-4095
@@ -11,19 +16,25 @@ Optional properties:
 - led-sources: List of enabled channels from 0 to 5.
See Documentation/devicetree/bindings/leds/common.txt
 
-- arc,led-config-0:setting for register ILED_CONFIG_0
-- arc,led-config-1:setting for register ILED_CONFIG_1
-- arc,dim-freq:PWM mode frequence setting (bits [3:0] used)
-- arc,comp-config: setting for register CONFIG_COMP
-- arc,filter-config:   setting for register FILTER_CONFIG
-- arc,trim-config: setting for register IMAXTUNE
+- arctic,led-config-0: setting for register ILED_CONFIG_0
+- arctic,led-config-1: setting for register ILED_CONFIG_1
+- arctic,dim-freq: PWM mode frequence setting (bits [3:0] used)
+- arctic,comp-config:  setting for register CONFIG_COMP
+- arctic,filter-config:setting for register FILTER_CONFIG
+- arctic,trim-config:  setting for register IMAXTUNE
+- arc,led-config-0:setting for register ILED_CONFIG_0 (deprecated)
+- arc,led-config-1:setting for register ILED_CONFIG_1 (deprecated)
+- arc,dim-freq:PWM mode frequence setting (bits [3:0] used) 
(deprecated)
+- arc,comp-config: setting for register CONFIG_COMP (deprecated)
+- arc,filter-config:   setting for register FILTER_CONFIG (deprecated)
+- arc,trim-config: setting for register IMAXTUNE (deprecated)
 
 Note: Optional properties not specified will default to values in IC EPROM
 
 Example:
 
 arc2c0608@30 {
-   compatible = "arc,arc2c0608";
+   compatible = "arctic,arc2c0608";
reg = <0x30>;
default-brightness = <500>;
label = "lcd-backlight";
-- 
2.7.4

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

[PATCH 2/2] backlight: arcxcnn: add "arctic" vendor prefix

[Brian Dodge]

The original patch adding this driver and DT bindings improperly
used "arc" as the vendor-prefix. This adds "arctic" which is the
proper prefix and retains "arc" to allow existing users of the
"arc" prefix to update to new kernels. There is at least one
(Samsung Chromebook Plus)

Signed-off-by: Brian Dodge 
Acked-by: Daniel Thompson 
---
 drivers/video/backlight/arcxcnn_bl.c | 41 +++-
 1 file changed, 31 insertions(+), 10 deletions(-)

diff --git a/drivers/video/backlight/arcxcnn_bl.c 
b/drivers/video/backlight/arcxcnn_bl.c
index 7b1c0a0..a419554 100644
--- a/drivers/video/backlight/arcxcnn_bl.c
+++ b/drivers/video/backlight/arcxcnn_bl.c
@@ -1,9 +1,9 @@
 // SPDX-License-Identifier: GPL-2.0-only
 /*
- * Backlight driver for ArcticSand ARC_X_C_0N_0N Devices
+ * Backlight driver for pSemi (formerly ArcticSand) ARC_X_C_0N_0N Devices
  *
- * Copyright 2016 ArcticSand, Inc.
- * Author : Brian Dodge 
+ * Copyright 2016-2019  pSemi, Inc.
+ * Author : Brian Dodge 
  */
 
 #include 
@@ -191,27 +191,46 @@ static void arcxcnn_parse_dt(struct arcxcnn *lp)
if (ret == 0)
lp->pdata->initial_brightness = prog_val;
 
-   ret = of_property_read_u32(node, "arc,led-config-0", _val);
+   ret = of_property_read_u32(node, "arctic,led-config-0", _val);
+   if (ret)
+   ret = of_property_read_u32(node, "arc,led-config-0", _val);
+
if (ret == 0)
lp->pdata->led_config_0 = (u8)prog_val;
 
-   ret = of_property_read_u32(node, "arc,led-config-1", _val);
+   ret = of_property_read_u32(node, "arctic,led-config-1", _val);
+   if (ret)
+   ret = of_property_read_u32(node, "arc,led-config-1", _val);
+
if (ret == 0)
lp->pdata->led_config_1 = (u8)prog_val;
 
-   ret = of_property_read_u32(node, "arc,dim-freq", _val);
+   ret = of_property_read_u32(node, "arctic,dim-freq", _val);
+   if (ret)
+   ret = of_property_read_u32(node, "arc,dim-freq", _val);
+
if (ret == 0)
lp->pdata->dim_freq = (u8)prog_val;
 
-   ret = of_property_read_u32(node, "arc,comp-config", _val);
+   ret = of_property_read_u32(node, "arctic,comp-config", _val);
+   if (ret)
+   ret = of_property_read_u32(node, "arc,comp-config", _val);
+
if (ret == 0)
lp->pdata->comp_config = (u8)prog_val;
 
-   ret = of_property_read_u32(node, "arc,filter-config", _val);
+   ret = of_property_read_u32(node, "arctic,filter-config", _val);
+   if (ret)
+   ret = of_property_read_u32(node,
+   "arc,filter-config", _val);
+
if (ret == 0)
lp->pdata->filter_config = (u8)prog_val;
 
-   ret = of_property_read_u32(node, "arc,trim-config", _val);
+   ret = of_property_read_u32(node, "arctic,trim-config", _val);
+   if (ret)
+   ret = of_property_read_u32(node, "arc,trim-config", _val);
+
if (ret == 0)
lp->pdata->trim_config = (u8)prog_val;
 
@@ -381,6 +400,8 @@ static int arcxcnn_remove(struct i2c_client *cl)
 }
 
 static const struct of_device_id arcxcnn_dt_ids[] = {
+   { .compatible = "arctic,arc2c0608" },
+   /* here to remain compatible with an older binding, do not use */
{ .compatible = "arc,arc2c0608" },
{ }
 };
@@ -404,5 +425,5 @@ static struct i2c_driver arcxcnn_driver = {
 module_i2c_driver(arcxcnn_driver);
 
 MODULE_LICENSE("GPL v2");
-MODULE_AUTHOR("Brian Dodge ");
+MODULE_AUTHOR("Brian Dodge ");
 MODULE_DESCRIPTION("ARCXCNN Backlight driver");
-- 
2.7.4

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

[PATCH] drm: bridge: DRM_SIL_SII8620 should depend on, not select INPUT

[Randy Dunlap]

From: Randy Dunlap 

A single driver should not enable (select) an entire subsystem,
such as INPUT, so change the 'select' to "depends on".

Fixes: d6abe6df706c ("drm/bridge: sil_sii8620: do not have a dependency of 
RC_CORE")

Signed-off-by: Randy Dunlap 
Cc: Inki Dae 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: dri-devel@lists.freedesktop.org
---
Linus has written this a couple of times in the last 15 years or so,
but my search fu cannot find it.  And there are a few drivers in the
kernel tree that do this, but we shouldn't be adding more that do so.

 drivers/gpu/drm/bridge/Kconfig |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- lnx-52-rc7.orig/drivers/gpu/drm/bridge/Kconfig
+++ lnx-52-rc7/drivers/gpu/drm/bridge/Kconfig
@@ -83,10 +83,9 @@ config DRM_PARADE_PS8622
 
 config DRM_SIL_SII8620
tristate "Silicon Image SII8620 HDMI/MHL bridge"
-   depends on OF
+   depends on OF && INPUT
select DRM_KMS_HELPER
imply EXTCON
-   select INPUT
select RC_CORE
help
  Silicon Image SII8620 HDMI/MHL bridge chip driver.


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

Re: [PATCH] drm/komeda: Adds system power management support

[Lowry Li (Arm Technology China)]

Hi,

This is a duplicated patchset and please ignore this.
The latest changes for power management  have been committed at:
https://patchwork.freedesktop.org/series/62181/
Sorry for the inconvenience.

Best regards,
Lowry

On Fri, Jun 21, 2019 at 03:57:29PM +0800, Lowry Li (Arm Technology China) wrote:
> From: "Lowry Li (Arm Technology China)" 
> 
> Adds system power management support in KMS kernel driver.
> 
> Depends on:
> - https://patchwork.freedesktop.org/series/61650/
> - https://patchwork.freedesktop.org/series/60083/
> - https://patchwork.freedesktop.org/series/61647/
> 
> Changes since v1:
> Since we have unified mclk/pclk/pipeline->aclk to one mclk, which will
> be turned on/off when crtc atomic enable/disable, removed runtime power
> management.
> Adds to disable the aclk when register access finished.
> 
> Changes since v2:
> Removes run time get/put related flow.
> 
> Signed-off-by: Lowry Li (Arm Technology China) 
> ---
>  drivers/gpu/drm/arm/display/komeda/komeda_crtc.c |  1 -
>  drivers/gpu/drm/arm/display/komeda/komeda_dev.c  | 63 
> +---
>  drivers/gpu/drm/arm/display/komeda/komeda_dev.h  |  2 +
>  drivers/gpu/drm/arm/display/komeda/komeda_drv.c  | 35 +++--
>  4 files changed, 91 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index cafb445..d14e7f3 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -5,7 +5,6 @@
>   *
>   */
>  #include 
> -#include 
>  #include 
>  
>  #include 
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c 
> b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> index e1aa58e..c9837dc 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> @@ -209,7 +209,7 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
> product->product_id,
> MALIDP_CORE_ID_PRODUCT_ID(mdev->chip.core_id));
>   err = -ENODEV;
> - goto err_cleanup;
> + goto disable_clk;
>   }
>  
>   DRM_INFO("Found ARM Mali-D%x version r%dp%d\n",
> @@ -222,19 +222,19 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
>   err = mdev->funcs->enum_resources(mdev);
>   if (err) {
>   DRM_ERROR("enumerate display resource failed.\n");
> - goto err_cleanup;
> + goto disable_clk;
>   }
>  
>   err = komeda_parse_dt(dev, mdev);
>   if (err) {
>   DRM_ERROR("parse device tree failed.\n");
> - goto err_cleanup;
> + goto disable_clk;
>   }
>  
>   err = komeda_assemble_pipelines(mdev);
>   if (err) {
>   DRM_ERROR("assemble display pipelines failed.\n");
> - goto err_cleanup;
> + goto disable_clk;
>   }
>  
>   dev->dma_parms = >dma_parms;
> @@ -247,11 +247,13 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
>   if (mdev->iommu && mdev->funcs->connect_iommu) {
>   err = mdev->funcs->connect_iommu(mdev);
>   if (err) {
> - mdev->iommu = NULL;
> - goto err_cleanup;
> + DRM_ERROR("connect iommu failed.\n");
> + goto disable_clk;
>   }
>   }
>  
> + clk_disable_unprepare(mdev->aclk);
> +
>   err = sysfs_create_group(>kobj, _sysfs_attr_group);
>   if (err) {
>   DRM_ERROR("create sysfs group failed.\n");
> @@ -264,6 +266,8 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
>  
>   return mdev;
>  
> +disable_clk:
> + clk_disable_unprepare(mdev->aclk);
>  err_cleanup:
>   komeda_dev_destroy(mdev);
>   return ERR_PTR(err);
> @@ -281,6 +285,9 @@ void komeda_dev_destroy(struct komeda_dev *mdev)
>   debugfs_remove_recursive(mdev->debugfs_root);
>  #endif
>  
> + if (mdev->aclk)
> + clk_prepare_enable(mdev->aclk);
> +
>   if (mdev->iommu && mdev->funcs->disconnect_iommu)
>   mdev->funcs->disconnect_iommu(mdev);
>   mdev->iommu = NULL;
> @@ -308,3 +315,47 @@ void komeda_dev_destroy(struct komeda_dev *mdev)
>  
>   devm_kfree(dev, mdev);
>  }
> +
> +int komeda_dev_resume(struct komeda_dev *mdev)
> +{
> + int ret = 0;
> +
> + clk_prepare_enable(mdev->aclk);
> +
> + if (mdev->iommu && mdev->funcs->connect_iommu) {
> + ret = mdev->funcs->connect_iommu(mdev);
> + if (ret < 0) {
> + DRM_ERROR("connect iommu failed.\n");
> + goto disable_clk;
> + }
> + }
> +
> + ret = mdev->funcs->enable_irq(mdev);
> +
> +disable_clk:
> + clk_disable_unprepare(mdev->aclk);
> +
> + return ret;
> +}
> +
> +int komeda_dev_suspend(struct komeda_dev *mdev)
> +{
> + int ret = 0;
> +
> + 

[PATCH] drm/komeda: Adds power management support

[Lowry Li (Arm Technology China)]

From: "Lowry Li (Arm Technology China)" 

Adds system power management support in KMS kernel driver.

Depends on:
- https://patchwork.freedesktop.org/series/61650/
- https://patchwork.freedesktop.org/series/60083/

Changes since v1:
Since we have unified mclk/pclk/pipeline->aclk to one mclk, which will
be turned on/off when crtc atomic enable/disable, removed runtime power
management.
Removes run time get/put related flow.
Adds to disable the aclk when register access finished.

Signed-off-by: Lowry Li (Arm Technology China) 
---
 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c |  1 -
 drivers/gpu/drm/arm/display/komeda/komeda_dev.c  | 65 +---
 drivers/gpu/drm/arm/display/komeda/komeda_dev.h  |  2 +
 drivers/gpu/drm/arm/display/komeda/komeda_drv.c  | 30 ++-
 4 files changed, 90 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index cafb445..d14e7f3 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -5,7 +5,6 @@
  *
  */
 #include 
-#include 
 #include 
 
 #include 
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index e1aa58e..a82f67b 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -209,7 +209,7 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
  product->product_id,
  MALIDP_CORE_ID_PRODUCT_ID(mdev->chip.core_id));
err = -ENODEV;
-   goto err_cleanup;
+   goto disable_clk;
}
 
DRM_INFO("Found ARM Mali-D%x version r%dp%d\n",
@@ -222,19 +222,19 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
err = mdev->funcs->enum_resources(mdev);
if (err) {
DRM_ERROR("enumerate display resource failed.\n");
-   goto err_cleanup;
+   goto disable_clk;
}
 
err = komeda_parse_dt(dev, mdev);
if (err) {
DRM_ERROR("parse device tree failed.\n");
-   goto err_cleanup;
+   goto disable_clk;
}
 
err = komeda_assemble_pipelines(mdev);
if (err) {
DRM_ERROR("assemble display pipelines failed.\n");
-   goto err_cleanup;
+   goto disable_clk;
}
 
dev->dma_parms = >dma_parms;
@@ -247,11 +247,14 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
if (mdev->iommu && mdev->funcs->connect_iommu) {
err = mdev->funcs->connect_iommu(mdev);
if (err) {
+   DRM_ERROR("connect iommu failed.\n");
mdev->iommu = NULL;
-   goto err_cleanup;
+   goto disable_clk;
}
}
 
+   clk_disable_unprepare(mdev->aclk);
+
err = sysfs_create_group(>kobj, _sysfs_attr_group);
if (err) {
DRM_ERROR("create sysfs group failed.\n");
@@ -264,6 +267,8 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
 
return mdev;
 
+disable_clk:
+   clk_disable_unprepare(mdev->aclk);
 err_cleanup:
komeda_dev_destroy(mdev);
return ERR_PTR(err);
@@ -281,8 +286,12 @@ void komeda_dev_destroy(struct komeda_dev *mdev)
debugfs_remove_recursive(mdev->debugfs_root);
 #endif
 
+   if (mdev->aclk)
+   clk_prepare_enable(mdev->aclk);
+
if (mdev->iommu && mdev->funcs->disconnect_iommu)
-   mdev->funcs->disconnect_iommu(mdev);
+   if (mdev->funcs->disconnect_iommu(mdev))
+   DRM_ERROR("disconnect iommu failed.\n");
mdev->iommu = NULL;
 
for (i = 0; i < mdev->n_pipelines; i++) {
@@ -308,3 +317,47 @@ void komeda_dev_destroy(struct komeda_dev *mdev)
 
devm_kfree(dev, mdev);
 }
+
+int komeda_dev_resume(struct komeda_dev *mdev)
+{
+   int ret = 0;
+
+   clk_prepare_enable(mdev->aclk);
+
+   if (mdev->iommu && mdev->funcs->connect_iommu) {
+   ret = mdev->funcs->connect_iommu(mdev);
+   if (ret < 0) {
+   DRM_ERROR("connect iommu failed.\n");
+   goto disable_clk;
+   }
+   }
+
+   ret = mdev->funcs->enable_irq(mdev);
+
+disable_clk:
+   clk_disable_unprepare(mdev->aclk);
+
+   return ret;
+}
+
+int komeda_dev_suspend(struct komeda_dev *mdev)
+{
+   int ret = 0;
+
+   clk_prepare_enable(mdev->aclk);
+
+   if (mdev->iommu && mdev->funcs->disconnect_iommu) {
+   ret = mdev->funcs->disconnect_iommu(mdev);
+   if (ret < 0) {
+   DRM_ERROR("disconnect iommu failed.\n");
+   goto disable_clk;
+   }
+   }
+
+   ret = mdev->funcs->disable_irq(mdev);
+

Re: [PATCH v1 31/33] drm/bochs: drop use of drmP.h

[Gerd Hoffmann]

On Sun, Jun 30, 2019 at 08:19:20AM +0200, Sam Ravnborg wrote:
> Drop use of the deprecated drmP.h header file.
> Made bochs.h self-contained and then fixed
> fallout in remaining files.
> Several unused includes was dropped in the process.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Gerd Hoffmann 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: virtualizat...@lists.linux-foundation.org

Acked-by: Gerd Hoffmann 

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

Re: [PATCH v1 09/33] drm/qxl: drop use of drmP.h

[Gerd Hoffmann]

On Sun, Jun 30, 2019 at 08:18:58AM +0200, Sam Ravnborg wrote:
> Drop use of the deprecated drmP.h header file.
> While touching the files divided includes in blocks,
> and when needed sort the blocks.
> Fix fallout.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Dave Airlie 
> Cc: Gerd Hoffmann 
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: spice-de...@lists.freedesktop.org

Acked-by: Gerd Hoffmann 

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

Re: [PATCH v1 27/33] drm/virtgpu: drop use of drmP.h

[Gerd Hoffmann]

On Sun, Jun 30, 2019 at 08:19:16AM +0200, Sam Ravnborg wrote:
> Drop use of the deprecated drmP.h header file.
> Fix fallout by adding missing include files.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: David Airlie 
> Cc: Gerd Hoffmann 
> Cc: Daniel Vetter 
> Cc: virtualizat...@lists.linux-foundation.org

Acked-by: Gerd Hoffmann 

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