Re: [PATCH] drm/pl111: select DRM_PANEL

[Daniel Vetter]

On Tue, May 30, 2017 at 01:35:51PM +0200, Linus Walleij wrote:
> On Tue, May 30, 2017 at 11:22 AM, Arnd Bergmann  wrote:
> 
> > When DRM_PANEL is disabled, we get a link error for pl111:
> >
> > drivers/gpu/built-in.o: In function `pl111_connector_destroy':
> > pl111_connector.c:(.text+0x3487e6): undefined reference to 
> > `drm_panel_detach'
> >
> > For some reason this only appears in the latest linux-next
> > although the driver appears to have used the symbol for a few
> > weeks already. The solution however is simple enough, we just
> > need to add a 'select' statement.
> >
> > Fixes: bed41005e617 ("drm/pl111: Initial drm/kms driver for pl111")
> > Signed-off-by: Arnd Bergmann 
> 
> Tested-by: Linus Walleij 
> 
> I had the same patch in my tree, just haven't had time to send
> it out.

Eric seems out, so I picked this up for him. Thanks for the patch&testing.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Freedreno] [PATCH 10/13] drm/msm: Support multiple ringbuffers

[Daniel Vetter]

On Tue, May 30, 2017 at 12:34:34PM -0400, Alex Deucher wrote:
> On Tue, May 30, 2017 at 12:20 PM, Jordan Crouse  
> wrote:
> > On Sun, May 28, 2017 at 09:43:35AM -0400, Rob Clark wrote:
> >> On Mon, May 8, 2017 at 4:35 PM, Jordan Crouse  
> >> wrote:
> >> > Add the infrastructure to support the idea of multiple ringbuffers.
> >> > Assign each ringbuffer an id and use that as an index for the various
> >> > ring specific operations.
> >> >
> >> > The biggest delta is to support legacy fences. Each fence gets its own
> >> > sequence number but the legacy functions expect to use a unique integer.
> >> > To handle this we return a unique identifer for each submission but
> >> > map it to a specific ring/sequence under the covers. Newer users use
> >> > a dma_fence pointer anyway so they don't care about the actual sequence
> >> > ID or ring.
> >>
> >> So, WAIT_FENCE is alive and well, and useful since it avoids the
> >> overhead of creating a 'struct file', but it is only used within a
> >> single pipe_context (or at least situations where we know which ctx
> >> the seqno fence applies to).  It seems like it would be simpler if we
> >> just introduced a ctx-id in all the ioctls (SUBMIT and WAIT_FENCE)
> >> that take a uint fence.  Then I think we don't need hashtable
> >> fancyness.
> >>
> >> Also, one thing I was thinking of is that some-day we might want to
> >> make SUBMIT non-blocking when there is a dependency on a fence from a
> >> different ring.  (Ie. queue it up but don't write cmds into rb yet.)
> >> Which means we'd need multiple fence timelines per priority-level rb.
> >> Which brings me back to wanting a CREATE_CTX type of ioctl.  (And I
> >> guess DESTROY_CTX.)  We could make these simple stubs for now, ie.
> >> CREATE_CTX just returns the priority level back, and not really have
> >> any separate "context" object on the kernel side for now.  This
> >> wouldn't change the implementation much from what you have, but I
> >> think that gives us some flexibility to later on actually let us have
> >> multiple contexts at a given priority level which don't block each
> >> other for submits that are still pending on some fence, without
> >> another UABI change.
> >
> > Sure. My motivation here was to mostly avoid making that decision because I 
> > know
> > from experience once we start going down that path we end up using the 
> > context
> > ID for everything and we end up re-spinning a bunch of APIs.
> >
> > But I agree that the context concept is our inevitable future - I've already
> > posted one set of patches for "draw queues" (which will soon be bravely 
> > renamed
> > as submit queues). I think thats the way we want to go because as you said,
> > there is a 100% chance we'll go for asynchronous submissions in the very 
> > near
> > future.
> >
> > That said, there is a bit of added complexity for per-queue fences - namely,
> > we need to move the per-ring fence value in the memptrs to a per-queue 
> > value.
> > This probably isn't a huge deal (an extra page of memory would give us up to
> > 1024 queues to work with globally) but I get itchy every time an arbitrary
> > limit is introduced no matter how reasonable it might be.
> >
> 
> FWIW, we have contexts in amdgpu and it makes a lot of things easier
> when dealing with dependencies.  Feel free to browse our
> implementation for ideas.

Same on i915, we use contexts (not batches) as the scheduling entity.
Think of them like threads on a cpu, at least in our case. And we can
dynamically allocate as many as we need (well until we run out of memory
of course), we can even swap them in/out :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 5/7] drm/ltdc: Use the panel-bridge helper.

[Archit Taneja]

Hi Boris,

On 05/31/2017 11:56 AM, Boris Brezillon wrote:

Hi Philippe,

Le Tue, 30 May 2017 16:55:42 +,
Philippe CORNU  a écrit :


Hi Eric,

I took your patch for the panel-bridge and it works perfectly in both
DPI mode (panel RGB //) and DSI mode (bridge dw mipi dsi), bravo :-)


I still don't understand how it can work without a call to
drm_bridge_attach() (which is used to link the RGB encoder to the DPI
connector). I'm probably missing something obvious. Maybe someone can
point it out :-).


I think the expectation is that there will be a follow-up patch that
would add bridge support. Philippe had posted a patch for adding bridges
to ltdc before:

https://patchwork.kernel.org/patch/9724835/

He can now redo his patch over Eric's panel-bridge patch-set.

Thanks,
Archit



Thanks,

Boris



~160 lines have been removed from ltdc.c thanks to your panel-bridge code!

Many thanks
Philippe

On 05/11/2017 08:31 PM, Eric Anholt wrote:

Another 100 lines of boilerplate gone.  Bridges aren't supported yet,
but will be trivial to add later.

Signed-off-by: Eric Anholt 
---

Also untested.

  drivers/gpu/drm/stm/ltdc.c | 128 +
  drivers/gpu/drm/stm/ltdc.h |   2 +-
  2 files changed, 13 insertions(+), 117 deletions(-)

diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index a40418cda74a..41a1c5d68f5b 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -269,11 +269,6 @@ static inline struct ltdc_device *encoder_to_ltdc(struct 
drm_encoder *enc)
return (struct ltdc_device *)enc->dev->dev_private;
  }

-static inline struct ltdc_device *connector_to_ltdc(struct drm_connector *con)
-{
-   return (struct ltdc_device *)con->dev->dev_private;
-}
-
  static inline enum ltdc_pix_fmt to_ltdc_pixelformat(u32 drm_fmt)
  {
enum ltdc_pix_fmt pf;
@@ -815,22 +810,12 @@ static int ltdc_crtc_init(struct drm_device *ddev, struct 
drm_crtc *crtc)

  static void ltdc_rgb_encoder_enable(struct drm_encoder *encoder)
  {
-   struct ltdc_device *ldev = encoder_to_ltdc(encoder);
-
DRM_DEBUG_DRIVER("\n");
-
-   drm_panel_prepare(ldev->panel);
-   drm_panel_enable(ldev->panel);
  }

  static void ltdc_rgb_encoder_disable(struct drm_encoder *encoder)
  {
-   struct ltdc_device *ldev = encoder_to_ltdc(encoder);
-
DRM_DEBUG_DRIVER("\n");
-
-   drm_panel_disable(ldev->panel);
-   drm_panel_unprepare(ldev->panel);
  }

  static const struct drm_encoder_helper_funcs ltdc_rgb_encoder_helper_funcs = {
@@ -863,82 +848,6 @@ static struct drm_encoder *ltdc_rgb_encoder_create(struct 
drm_device *ddev)
return encoder;
  }

-/*
- * DRM_CONNECTOR
- */
-
-static int ltdc_rgb_connector_get_modes(struct drm_connector *connector)
-{
-   struct drm_device *ddev = connector->dev;
-   struct ltdc_device *ldev = ddev->dev_private;
-   int ret = 0;
-
-   DRM_DEBUG_DRIVER("\n");
-
-   if (ldev->panel)
-   ret = drm_panel_get_modes(ldev->panel);
-
-   return ret < 0 ? 0 : ret;
-}
-
-static struct drm_connector_helper_funcs ltdc_rgb_connector_helper_funcs = {
-   .get_modes = ltdc_rgb_connector_get_modes,
-};
-
-static enum drm_connector_status
-ltdc_rgb_connector_detect(struct drm_connector *connector, bool force)
-{
-   struct ltdc_device *ldev = connector_to_ltdc(connector);
-
-   return ldev->panel ? connector_status_connected :
-  connector_status_disconnected;
-}
-
-static void ltdc_rgb_connector_destroy(struct drm_connector *connector)
-{
-   DRM_DEBUG_DRIVER("\n");
-
-   drm_connector_unregister(connector);
-   drm_connector_cleanup(connector);
-}
-
-static const struct drm_connector_funcs ltdc_rgb_connector_funcs = {
-   .dpms = drm_atomic_helper_connector_dpms,
-   .fill_modes = drm_helper_probe_single_connector_modes,
-   .detect = ltdc_rgb_connector_detect,
-   .destroy = ltdc_rgb_connector_destroy,
-   .reset = drm_atomic_helper_connector_reset,
-   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
-   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
-};
-
-struct drm_connector *ltdc_rgb_connector_create(struct drm_device *ddev)
-{
-   struct drm_connector *connector;
-   int err;
-
-   connector = devm_kzalloc(ddev->dev, sizeof(*connector), GFP_KERNEL);
-   if (!connector) {
-   DRM_ERROR("Failed to allocate connector\n");
-   return NULL;
-   }
-
-   connector->polled = DRM_CONNECTOR_POLL_HPD;
-
-   err = drm_connector_init(ddev, connector, base.id);
-
-   ret

Re: [PATCH 07/37] drm: Extract drm_vblank.[hc]

[Daniel Vetter]

On Mon, May 29, 2017 at 12:36:54PM -0700, Stefan Agner wrote:
> On 2017-05-24 07:51, Daniel Vetter wrote:
> > drm_irq.c contains both the irq helper library (optional) and the
> > vblank support (optional, but part of the modeset uapi, and doesn't
> > require the use of the irq helpers at all.
> > 
> > Split this up for more clarity of the scope of the individual bits.
> > 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  Documentation/gpu/drm-kms.rst |4 +-
> >  drivers/gpu/drm/drm_irq.c | 1623 
> > +---
> >  drivers/gpu/drm/drm_vblank.c  | 1645 
> > +
> >  include/drm/drmP.h|5 +-
> >  include/drm/drm_file.h|1 +
> >  include/drm/drm_irq.h |  158 +---
> >  include/drm/drm_prime.h   |2 +
> >  include/drm/drm_vblank.h  |  181 +
> >  8 files changed, 1857 insertions(+), 1762 deletions(-)
> >  create mode 100644 drivers/gpu/drm/drm_vblank.c
> >  create mode 100644 include/drm/drm_vblank.h
> > 
> > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> > index bfecd21a8cdf..2d77c9580164 100644
> > --- a/Documentation/gpu/drm-kms.rst
> > +++ b/Documentation/gpu/drm-kms.rst
> > @@ -612,8 +612,8 @@ operation handler.
> >  Vertical Blanking and Interrupt Handling Functions Reference
> >  
> >  
> > -.. kernel-doc:: include/drm/drm_irq.h
> > +.. kernel-doc:: include/drm/drm_vblank.h
> > :internal:
> >  
> > -.. kernel-doc:: drivers/gpu/drm/drm_irq.c
> > +.. kernel-doc:: drivers/gpu/drm/drm_vblank.c
> 
> Is that removing drm_irq from kernel-docs? Why? At least the C files
> seems to contain valid kernel docs...

Get's fixed in the next patch again, where I re-add them when rewriting
all the irq docs. Thats why I said these two patches depend upon each
another :-)

I can shuffle the include hunk of the rewrite into this patch if you think
it's better, but I figured renaming/splitting separate from rewriting the
docs is good.

> 
> > :export:
> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > index c7debaad67f8..28d736c3fcb4 100644
> > --- a/drivers/gpu/drm/drm_irq.c
> > +++ b/drivers/gpu/drm/drm_irq.c
> 
>   
> 
> >  /**
> >   * drm_irq_install - install IRQ handler
> > @@ -571,7 +176,7 @@ int drm_irq_uninstall(struct drm_device *dev)
> >  
> > WARN_ON(drm_core_check_feature(dev, DRIVER_MODESET));
> >  
> > -   vblank_disable_and_save(dev, i);
> > +   drm_vblank_disable_and_save(dev, i);
> 
> This leads to:
> 
> drivers/gpu/drm/drm_irq.c: In function 'drm_irq_uninstall':   
> drivers/gpu/drm/drm_irq.c:179:4: error: implicit declaration of function
> 'drm_vblank_disable_and_save' [-Werror=implicit-function-declaration]   
>  
> drm_vblank_disable_and_save(dev, i);  
> ^
> 
> Since you moved the function to drm_vblank.c, I guess you have to add a
> deceleration in drm_vblank.h?

Oops, misplaced hunk, a later patch adds it to drm_internal.h. I'll fix
that up.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915/gvt: remove redundant -Wall

[Zhenyu Wang]

On 2017.05.21 00:15:27 -0700, Nick Desaulniers wrote:
> This flag is already set in the top level Makefile of the kernel.
> 
> Also, by having set CONFIG_DRM_I915_GVT, thereby appending -Wall to
> ccflags, you undo all the -Wno-* cflags previously set in the Make
> variable KBUILD_CFLAGS.
> 
> For example:
> 
> cc foo.c -Wall -Wno-format -Wall
> 
> resets -Wformat.
> 
> Signed-off-by: Nick Desaulniers 
> ---
> I verified that -Wall was redundant by compiling with V=1:
> make V=1 -j4 drivers/gpu/drm/i915/i915_gem_request.o
> 
>  drivers/gpu/drm/i915/gvt/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
> b/drivers/gpu/drm/i915/gvt/Makefile
> index b123c20e2097..f5486cb94818 100644
> --- a/drivers/gpu/drm/i915/gvt/Makefile
> +++ b/drivers/gpu/drm/i915/gvt/Makefile
> @@ -3,6 +3,6 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o 
> trace_points.o firmware.o \
>   interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
>   execlist.o scheduler.o sched_policy.o render.o cmd_parser.o
>  
> -ccflags-y+= -I$(src) -I$(src)/$(GVT_DIR) -Wall
> +ccflags-y+= -I$(src) -I$(src)/$(GVT_DIR)
>  i915-y   += $(addprefix $(GVT_DIR)/, 
> $(GVT_SOURCE))
>  obj-$(CONFIG_DRM_I915_GVT_KVMGT) += $(GVT_DIR)/kvmgt.o
> -- 

Pushed, thanks!

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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

Re: [PATCH v2 5/7] drm/ltdc: Use the panel-bridge helper.

[Boris Brezillon]

Hi Archit,

Le Wed, 31 May 2017 13:31:16 +0530,
Archit Taneja  a écrit :

> Hi Boris,
> 
> On 05/31/2017 11:56 AM, Boris Brezillon wrote:
> > Hi Philippe,
> >
> > Le Tue, 30 May 2017 16:55:42 +,
> > Philippe CORNU  a écrit :
> >  
> >> Hi Eric,
> >>
> >> I took your patch for the panel-bridge and it works perfectly in both
> >> DPI mode (panel RGB //) and DSI mode (bridge dw mipi dsi), bravo :-)  
> >
> > I still don't understand how it can work without a call to
> > drm_bridge_attach() (which is used to link the RGB encoder to the DPI
> > connector). I'm probably missing something obvious. Maybe someone can
> > point it out :-).  
> 
> I think the expectation is that there will be a follow-up patch that
> would add bridge support. Philippe had posted a patch for adding bridges
> to ltdc before:
> 
> https://patchwork.kernel.org/patch/9724835/
> 
> He can now redo his patch over Eric's panel-bridge patch-set.

But by doing that you're breaking bisectability, or is it working when
applying only Eric's patchset?

If applying this patch breaks the driver, why not applying it after
bridge support has been added to this driver?

Regards,

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

Re: [ANN] HDMI CEC Status Update

[Andrzej Hajda]

On 30.05.2017 08:53, Hans Verkuil wrote:
> For those who are interested in HDMI CEC support I made a little status
> document that I intend to keep up to date:
>
> https://hverkuil.home.xs4all.nl/cec-status.txt
>
> My goal is to get CEC supported for any mainlined HDMI driver where the 
> hardware
> supports CEC.
>
> If anyone is working on a CEC driver that I don't know already about, just 
> drop
> me an email so I can update the status.

Sii8620 HDMI->MHL bridge is on my TODO list.
Regarding Exynos5 it is apparently the same IP as in Exynos4.

Regards
Andrzej

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

Re: [PATCH v5 08/10] drm/arm: malidp: Use crtc->mode_valid() callback

[Daniel Vetter]

On Tue, May 30, 2017 at 10:37:29AM +0100, Liviu Dudau wrote:
> On Tue, May 30, 2017 at 09:29:44AM +0200, Neil Armstrong wrote:
> > On 05/25/2017 04:19 PM, Jose Abreu wrote:
> > > Now that we have a callback to check if crtc supports a given mode
> > > we can use it in malidp so that we restrict the number of probbed
> > > modes to the ones we can actually display.
> > > 
> > > Also, remove the mode_fixup() callback as this is no longer needed
> > > because mode_valid() will be called before.
> > > 
> > > NOTE: Not even compiled tested
> 
> I did compile it, even done some testing, but by no means have I managed
> to cover all the cases. Looks OK to me.
> 
> > > 
> > > Signed-off-by: Jose Abreu 
> > > Cc: Carlos Palminha 
> > > Cc: Daniel Vetter 
> > > Cc: Liviu Dudau 
> 
> Acked-by: Liviu Dudau 

What does this mean? Do you expect me to merge this through drm-misc? Or
do you plan to merge it through your arm tree (all the required patches
are in drm-misc-next and will be in Dave's tree soonish)?

/me confused.

Thanks, Daniel

> 
> > > Cc: Brian Starkey 
> > > Cc: David Airlie 
> > > ---
> > >  drivers/gpu/drm/arm/malidp_crtc.c | 11 +--
> > >  1 file changed, 5 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/arm/malidp_crtc.c 
> > > b/drivers/gpu/drm/arm/malidp_crtc.c
> > > index 9446a67..4bb38a2 100644
> > > --- a/drivers/gpu/drm/arm/malidp_crtc.c
> > > +++ b/drivers/gpu/drm/arm/malidp_crtc.c
> > > @@ -22,9 +22,8 @@
> > >  #include "malidp_drv.h"
> > >  #include "malidp_hw.h"
> > >  
> > > -static bool malidp_crtc_mode_fixup(struct drm_crtc *crtc,
> > > -const struct drm_display_mode *mode,
> > > -struct drm_display_mode *adjusted_mode)
> > > +static enum drm_mode_status malidp_crtc_mode_valid(struct drm_crtc *crtc,
> > > +const struct 
> > > drm_display_mode *mode)
> > >  {
> > >   struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
> > >   struct malidp_hw_device *hwdev = malidp->dev;
> > > @@ -40,11 +39,11 @@ static bool malidp_crtc_mode_fixup(struct drm_crtc 
> > > *crtc,
> > >   if (rate != req_rate) {
> > >   DRM_DEBUG_DRIVER("pxlclk doesn't support %ld Hz\n",
> > >req_rate);
> > > - return false;
> > > + return MODE_NOCLOCK;
> > >   }
> > >   }
> > >  
> > > - return true;
> > > + return MODE_OK;
> > >  }
> > >  
> > >  static void malidp_crtc_enable(struct drm_crtc *crtc)
> > > @@ -408,7 +407,7 @@ static int malidp_crtc_atomic_check(struct drm_crtc 
> > > *crtc,
> > >  }
> > >  
> > >  static const struct drm_crtc_helper_funcs malidp_crtc_helper_funcs = {
> > > - .mode_fixup = malidp_crtc_mode_fixup,
> > > + .mode_valid = malidp_crtc_mode_valid,
> > >   .enable = malidp_crtc_enable,
> > >   .disable = malidp_crtc_disable,
> > >   .atomic_check = malidp_crtc_atomic_check,
> > > 
> > 
> > Reviewed-by: Neil Armstrong 
> 
> -- 
> 
> | I would like to |
> | fix the world,  |
> | but they're not |
> | giving me the   |
>  \ source code!  /
>   ---
> ¯\_(ツ)_/¯

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Use vsnprintf extension %ph

[Daniel Vetter]

On Tue, May 30, 2017 at 04:35:37PM -0700, Joe Perches wrote:
> Using the extension saves a bit of code.
> 
> Miscellanea:
> 
> o Neaten and simplify dump_dp_payload_table
> o Removed trailing blank space from output

Not a huge fan of smashing random trivia into the same patch, but merged
anyway. %ph is rather neat, TIL.

Thanks, Daniel

> 
> $ size drivers/gpu/drm/drm_dp_mst_topology.o.* drivers/gpu/drm/tinydrm/*.o*
>text  data bss dec hex filename
>   25848 0  16   258646508 
> drivers/gpu/drm/drm_dp_mst_topology.o.new
>   26091 0  16   2610765fb 
> drivers/gpu/drm/drm_dp_mst_topology.o.old
>3362 2   03364 d24 
> drivers/gpu/drm/tinydrm/mipi-dbi.o.new
>3376 2   03378 d32 
> drivers/gpu/drm/tinydrm/mipi-dbi.o.old
> 
> Signed-off-by: Joe Perches 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 51 
> +++
>  drivers/gpu/drm/tinydrm/mipi-dbi.c|  7 ++---
>  2 files changed, 18 insertions(+), 40 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 222eb1a8549b..bfd237c15e76 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2836,16 +2836,15 @@ static void drm_dp_mst_dump_mstb(struct seq_file *m,
>  static bool dump_dp_payload_table(struct drm_dp_mst_topology_mgr *mgr,
> char *buf)
>  {
> - int ret;
>   int i;
> - for (i = 0; i < 4; i++) {
> - ret = drm_dp_dpcd_read(mgr->aux, DP_PAYLOAD_TABLE_UPDATE_STATUS 
> + (i * 16), &buf[i * 16], 16);
> - if (ret != 16)
> - break;
> +
> + for (i = 0; i < 64; i += 16) {
> + if (drm_dp_dpcd_read(mgr->aux,
> +  DP_PAYLOAD_TABLE_UPDATE_STATUS + i,
> +  &buf[i], 16) != 16)
> + return false;
>   }
> - if (i == 4)
> - return true;
> - return false;
> + return true;
>  }
>  
>  static void fetch_monitor_name(struct drm_dp_mst_topology_mgr *mgr,
> @@ -2909,42 +2908,24 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
>   mutex_lock(&mgr->lock);
>   if (mgr->mst_primary) {
>   u8 buf[64];
> - bool bret;
>   int ret;
> +
>   ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, buf, 
> DP_RECEIVER_CAP_SIZE);
> - seq_printf(m, "dpcd: ");
> - for (i = 0; i < DP_RECEIVER_CAP_SIZE; i++)
> - seq_printf(m, "%02x ", buf[i]);
> - seq_printf(m, "\n");
> + seq_printf(m, "dpcd: %*ph\n", DP_RECEIVER_CAP_SIZE, buf);
>   ret = drm_dp_dpcd_read(mgr->aux, DP_FAUX_CAP, buf, 2);
> - seq_printf(m, "faux/mst: ");
> - for (i = 0; i < 2; i++)
> - seq_printf(m, "%02x ", buf[i]);
> - seq_printf(m, "\n");
> + seq_printf(m, "faux/mst: %*ph\n", 2, buf);
>   ret = drm_dp_dpcd_read(mgr->aux, DP_MSTM_CTRL, buf, 1);
> - seq_printf(m, "mst ctrl: ");
> - for (i = 0; i < 1; i++)
> - seq_printf(m, "%02x ", buf[i]);
> - seq_printf(m, "\n");
> + seq_printf(m, "mst ctrl: %*ph\n", 1, buf);
>  
>   /* dump the standard OUI branch header */
>   ret = drm_dp_dpcd_read(mgr->aux, DP_BRANCH_OUI, buf, 
> DP_BRANCH_OUI_HEADER_SIZE);
> - seq_printf(m, "branch oui: ");
> - for (i = 0; i < 0x3; i++)
> - seq_printf(m, "%02x", buf[i]);
> - seq_printf(m, " devid: ");
> + seq_printf(m, "branch oui: %*phN devid: ", 3, buf);
>   for (i = 0x3; i < 0x8 && buf[i]; i++)
>   seq_printf(m, "%c", buf[i]);
> -
> - seq_printf(m, " revision: hw: %x.%x sw: %x.%x", buf[0x9] >> 4, 
> buf[0x9] & 0xf, buf[0xa], buf[0xb]);
> - seq_printf(m, "\n");
> - bret = dump_dp_payload_table(mgr, buf);
> - if (bret == true) {
> - seq_printf(m, "payload table: ");
> - for (i = 0; i < 63; i++)
> - seq_printf(m, "%02x ", buf[i]);
> - seq_printf(m, "\n");
> - }
> + seq_printf(m, " revision: hw: %x.%x sw: %x.%x\n",
> +buf[0x9] >> 4, buf[0x9] & 0xf, buf[0xa], buf[0xb]);
> + if (dump_dp_payload_table(mgr, buf))
> + seq_printf(m, "payload table: %*ph\n", 63, buf);
>  
>   }
>  
> diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
> b/drivers/gpu/drm/tinydrm/mipi-dbi.c
> index f4eb412f3604..c83eeb7a34b0 100644
> --- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
> +++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
> @@ -914,7 +914,7 @@ static int mipi_dbi_debugfs_command_show(struct seq_file 
> *m, voi

Re: [PATCH v2 5/7] drm/ltdc: Use the panel-bridge helper.

[Archit Taneja]

On 05/31/2017 01:37 PM, Boris Brezillon wrote:

Hi Archit,

Le Wed, 31 May 2017 13:31:16 +0530,
Archit Taneja  a écrit :


Hi Boris,

On 05/31/2017 11:56 AM, Boris Brezillon wrote:

Hi Philippe,

Le Tue, 30 May 2017 16:55:42 +,
Philippe CORNU  a écrit :


Hi Eric,

I took your patch for the panel-bridge and it works perfectly in both
DPI mode (panel RGB //) and DSI mode (bridge dw mipi dsi), bravo :-)


I still don't understand how it can work without a call to
drm_bridge_attach() (which is used to link the RGB encoder to the DPI
connector). I'm probably missing something obvious. Maybe someone can
point it out :-).


I think the expectation is that there will be a follow-up patch that
would add bridge support. Philippe had posted a patch for adding bridges
to ltdc before:

https://patchwork.kernel.org/patch/9724835/

He can now redo his patch over Eric's panel-bridge patch-set.


But by doing that you're breaking bisectability, or is it working when
applying only Eric's patchset?

If applying this patch breaks the driver, why not applying it after
bridge support has been added to this driver?


Yeah, it would break the driver. Philippe can create a patch that adds
bridge support using the panel-bridge glue layer using Eric's patch as a
reference. In the end, there should only be a single patch.

Thanks,
Archit



Regards,

Boris



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Fix locking in drm_atomic_helper_resume

[Daniel Vetter]

In the conversion to drop drm_modeset_lock_all and the magic implicit
context I failed to realize that _resume starts out with a pile of
state copies, but not with the locks. And hence drm_atomic_commit
won't grab these for us.

v2: Add locking checks in helpers to make sure we catch this in the
future. Note we can only require the locks in the atomic_check phase,
not in the commit phase. But since any commit is guaranteed to first
run the checks (even for the resume stuff where we use stored
duplicated old state) this should give us full coverage. Requested by
Maarten.

Cc: Jyri Sarha 
Fixes: a5b8444e289c ("drm/atomic-helper: remove modeset_lock_all from 
helper_resume")
Cc: Maarten Lankhorst 
Reviewed-by: Maarten Lankhorst 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Sean Paul 
Signed-off-by: Daniel Vetter 
---
Needs to be applied to drm-misc-fixes for 4.12. Jyri, testing from you
would also be great, just to confirm.
-Daniel
---
 drivers/gpu/drm/drm_atomic_helper.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index af07368846e0..285fab6d1a90 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -508,6 +508,8 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
bool has_connectors =
!!new_crtc_state->connector_mask;
 
+   WARN_ON(!drm_modeset_is_locked(&crtc->mutex));
+
if (!drm_mode_equal(&old_crtc_state->mode, 
&new_crtc_state->mode)) {
DRM_DEBUG_ATOMIC("[CRTC:%d:%s] mode changed\n",
 crtc->base.id, crtc->name);
@@ -551,6 +553,8 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
for_each_oldnew_connector_in_state(state, connector, 
old_connector_state, new_connector_state, i) {
const struct drm_connector_helper_funcs *funcs = 
connector->helper_private;
 
+   
WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
+
/*
 * This only sets crtc->connectors_changed for routing changes,
 * drivers must set crtc->connectors_changed themselves when
@@ -650,6 +654,8 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
for_each_oldnew_plane_in_state(state, plane, old_plane_state, 
new_plane_state, i) {
const struct drm_plane_helper_funcs *funcs;
 
+   WARN_ON(!drm_modeset_is_locked(&plane->mutex));
+
funcs = plane->helper_private;
 
drm_atomic_helper_plane_changed(state, old_plane_state, 
new_plane_state, plane);
@@ -2669,7 +2675,12 @@ int drm_atomic_helper_resume(struct drm_device *dev,
 
drm_modeset_acquire_init(&ctx, 0);
while (1) {
+   err = drm_modeset_lock_all_ctx(dev, &ctx);
+   if (err)
+   goto out;
+
err = drm_atomic_helper_commit_duplicated_state(state, &ctx);
+out:
if (err != -EDEADLK)
break;
 
-- 
2.11.0

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

Re: [PATCH 18/37] drm/exynos: Drop drm_vblank_cleanup

[Daniel Vetter]

On Tue, May 30, 2017 at 09:03:34AM +0900, Inki Dae wrote:
> Hi Daniel,
> 
> 2017년 05월 24일 23:51에 Daniel Vetter 이(가) 쓴 글:
> > Only in the load failure path, where the hardware is quiet anyway.
> > 
> > Cc: Inki Dae 
> > Cc: Joonyoung Shim 
> > Cc: Seung-Woo Kim 
> > Cc: Kyungmin Park 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/exynos/exynos_drm_drv.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> > b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > index 50294a7bd29d..1c814b9342af 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > @@ -376,7 +376,7 @@ static int exynos_drm_bind(struct device *dev)
> > /* Probe non kms sub drivers and virtual display driver. */
> > ret = exynos_drm_device_subdrv_probe(drm);
> > if (ret)
> > -   goto err_cleanup_vblank;
> > +   goto err_unbind_all;
> 
> With this change shouldn't you post the patch to remove drm_vblank_init and 
> setup vblank stuff in drm_crtc_init together?
> I couldn't find the relevant patch on your patch series[1].

No, drm_vblank_cleanup is already called in the core. The only reason to
call it in the driver is to fall back from kms to ums when irq setup
somehow failed, then you need to disable vblank support again.

The only driver which ever needed this was radeon, and radeon long ago
lost ums support. drm_vblank_cleanup is already called for you, and most
drivers don't even do this cleanup call. But somehow a lot of people
copied from radeon without understanding what it does.

Looking at the last patch in this series might help a bit in understanding
the history here. Can you pls reevaluate the patch?

Thanks, Daniel

> As of now, I think resource leak would happen with this patch only.
> 
> Thanks,
> Inki Dae
> 
> [1] http://www.spinics.net/lists/dri-devel/msg142387.html
> 
> >  
> > drm_mode_config_reset(drm);
> >  
> > @@ -407,8 +407,6 @@ static int exynos_drm_bind(struct device *dev)
> > exynos_drm_fbdev_fini(drm);
> > drm_kms_helper_poll_fini(drm);
> > exynos_drm_device_subdrv_remove(drm);
> > -err_cleanup_vblank:
> > -   drm_vblank_cleanup(drm);
> >  err_unbind_all:
> > component_unbind_all(drm->dev, drm);
> >  err_mode_config_cleanup:
> > 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 23/37] drm/imx: Drop drm_vblank_cleanup

[Daniel Vetter]

On Mon, May 29, 2017 at 01:07:40PM +0200, Philipp Zabel wrote:
> Hi Daniel,
> 
> On Wed, 2017-05-24 at 16:51 +0200, Daniel Vetter wrote:
> > It's only done in the driver load error path, where vblanks don't need
> > to be quiescent anyway. And that's all drm_vblank_cleanup does, since
> > the core will release the vblank allocations on its own already. So
> > drop it.
> 
> Thank you for cleaning this up and improving the docs.
> From the function name and kerneldoc comment, it was really not clear
> that this function is already called in the drm_device release path.
> 
> I think the comment is slightly misleading though, as drm_vblank_cleanup
> does call kfree(dev->vblank).

Yeah I got a bit sloppy with the commit message. Since this is error code
resetting ->num_crtcs doesn't do anything useful, and the kfree happens
anyway (because the core calls drm_vblank_cleanup for you). That only
leaves the timer shutdown, and the timer can't run yet here at this point.

Hence this does nothing useful (except move the kfree around).
> 
> > Cc: Philipp Zabel 
> > Signed-off-by: Daniel Vetter 
> >
> > ---
> >  drivers/gpu/drm/imx/imx-drm-core.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
> > b/drivers/gpu/drm/imx/imx-drm-core.c
> > index 50add2f9e250..95e2181963d9 100644
> > --- a/drivers/gpu/drm/imx/imx-drm-core.c
> > +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> > @@ -278,7 +278,7 @@ static int imx_drm_bind(struct device *dev)
> > /* Now try and bind all our sub-components */
> > ret = component_bind_all(dev, drm);
> > if (ret)
> > -   goto err_vblank;
> > +   goto err_kms;
> >  
> > drm_mode_config_reset(drm);
> >  
> > @@ -316,8 +316,6 @@ static int imx_drm_bind(struct device *dev)
> >  err_unbind:
> >  #endif
> > component_unbind_all(drm->dev, drm);
> > -err_vblank:
> > -   drm_vblank_cleanup(drm);
> >  err_kms:
> > drm_mode_config_cleanup(drm);
> >  err_unref:
> 
> As I understand, the drm_dev_unref(drm) that follows this causes
> drm_dev_release -> drm_dev_fini -> drm_vblank_cleanup to be called, so
> 
> Acked-by: Philipp Zabel 

Thanks, applied, as I did all the other patches which gathered an ack or
r-b already.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 19/37] drm/fsl: Drop drm_vblank_cleanup

[Daniel Vetter]

On Tue, May 30, 2017 at 02:17:04PM -0700, Stefan Agner wrote:
> On 2017-05-26 00:00, Daniel Vetter wrote:
> > On Thu, May 25, 2017 at 10:18 AM, Stefan Agner  wrote:
> >> On 2017-05-24 07:51, Daniel Vetter wrote:
> >>> Again cleanup before irq disabling doesn't really stop the races,
> >>> so just drop it. Proper fix would be to put drm_atomic_helper_shutdown
> >>> before everything gets cleaned up.
> >>
> >> Hm, I already use the non-atomic drm_crtc_force_disable_all before, I
> >> think that fixed the races I saw.
> >>
> >> But I guess what you are saying instead of using
> >> drm_crtc_force_disable_all I should use drm_atomic_helper_shutdown...?
> > 
> > Yes. I thought I audited all existing users of the legacy
> > force_disable (it won't work correctly for atomic drivers), but
> > somehow I missed the one in fsl. See
> > 
> > commit 18dddadc78c91a91b546acc48506c24f5f840c4f
> > Author: Daniel Vetter 
> > Date:   Tue Mar 21 17:41:49 2017 +0100
> > 
> > drm/atomic: Introduce drm_atomic_helper_shutdown
> > 
> 
> Ok, I see.
> 
> Since this leads to a change just a few lines above this patch, it has
> potential for merge conflict. Can I take this change through my tree?

Yeah, it'll probably take until 4.14 anyway until I get them all in and
finally can remove drm_vblank_cleanup from the driver-exported set of
functions. Just make sure it does get into 4.13 pls.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/doc: Improve ioctl/fops docs a bit more

[Daniel Vetter]

I spotted a markup issue, plus adding the descriptions in drm_driver.
Plus a few more links while at it.

I'm still mildly unhappy with the split between fops and ioctls, but I
still think having the ioctls in the uapi chapter makes more sense. Oh
well ...

v2: Rebase.

v3: Move misplace hunk to the right patch.

Cc: Stefan Agner 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-internals.rst |  2 ++
 Documentation/gpu/drm-uapi.rst  |  2 ++
 drivers/gpu/drm/drm_file.c  |  7 ++-
 drivers/gpu/drm/drm_ioctl.c |  5 -
 include/drm/drm_drv.h   | 18 ++
 5 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/Documentation/gpu/drm-internals.rst 
b/Documentation/gpu/drm-internals.rst
index babfb6143bd9..d218dd29221a 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -243,6 +243,8 @@ drivers.
 Open/Close, File Operations and IOCTLs
 ==
 
+.. _drm_driver_fops:
+
 File Operations
 ---
 
diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 858457567d3d..679373b4a03f 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -160,6 +160,8 @@ other hand, a driver requires shared state between clients 
which is
 visible to user-space and accessible beyond open-file boundaries, they
 cannot support render nodes.
 
+.. _drm_driver_ioctl:
+
 IOCTL Support on Device Nodes
 =
 
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index caad93dab54b..6631f61b66ca 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -75,7 +75,7 @@ DEFINE_MUTEX(drm_global_mutex);
  * for drivers which use the CMA GEM helpers it's drm_gem_cma_mmap().
  *
  * No other file operations are supported by the DRM userspace API. Overall the
- * following is an example #file_operations structure::
+ * following is an example &file_operations structure::
  *
  * static const example_drm_fops = {
  * .owner = THIS_MODULE,
@@ -92,6 +92,11 @@ DEFINE_MUTEX(drm_global_mutex);
  * For plain GEM based drivers there is the DEFINE_DRM_GEM_FOPS() macro, and 
for
  * CMA based drivers there is the DEFINE_DRM_GEM_CMA_FOPS() macro to make this
  * simpler.
+ *
+ * The driver's &file_operations must be stored in &drm_driver.fops.
+ *
+ * For driver-private IOCTL handling see the more detailed discussion in
+ * :ref:`IOCTL support in the userland interfaces chapter`.
  */
 
 static int drm_open_helper(struct file *filp, struct drm_minor *minor);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index a423bf60e230..3690706f051d 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -683,7 +683,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
  * 
  * DRM driver private IOCTL must be in the range from DRM_COMMAND_BASE to
  * DRM_COMMAND_END. Finally you need an array of &struct drm_ioctl_desc to wire
- * up the handlers and set the access rights:
+ * up the handlers and set the access rights::
  *
  * static const struct drm_ioctl_desc my_driver_ioctls[] = {
  * DRM_IOCTL_DEF_DRV(MY_DRIVER_OPERATION, my_driver_operation,
@@ -692,6 +692,9 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
  *
  * And then assign this to the &drm_driver.ioctls field in your driver
  * structure.
+ *
+ * See the separate chapter on :ref:`file operations` for how
+ * the driver-specific IOCTLs are wired up.
  */
 
 /**
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 5d06c68bb00b..ebb41688581b 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -486,8 +486,26 @@ struct drm_driver {
char *date;
 
u32 driver_features;
+
+   /**
+* @ioctls:
+*
+* Array of driver-private IOCTL description entries. See the chapter on
+* :ref:`IOCTL support in the userland interfaces
+* chapter` for the full details.
+*/
+
const struct drm_ioctl_desc *ioctls;
+   /** @num_ioctls: Number of entries in @ioctls. */
int num_ioctls;
+
+   /**
+* @fops:
+*
+* File operations for the DRM device node. See the discussion in
+* :ref:`file operations` for in-depth coverage and
+* some examples.
+*/
const struct file_operations *fops;
 
/* Everything below here is for legacy driver, never use! */
-- 
2.11.0

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

Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

[Lukas Wunner]

On Wed, May 31, 2017 at 10:48:37AM +0200, Florian Echtler wrote:
> On 30.05.2017 12:54, Lukas Wunner wrote:
> > On Tue, May 30, 2017 at 11:34:17AM +0200, Florian Echtler wrote:
> >> On 26.05.2017 23:03, Lukas Wunner wrote:
> >>> On Fri, May 26, 2017 at 02:13:29PM +0200, Florian Echtler wrote:
>  I'm running Ubuntu 16.04.2 on a 27" unibody iMac 10,1 from 2009. 
>  However, even
>  with the most recent HWE stack (kernel 4.8), the display stays black 
>  after
>  suspend. I can ssh into the machine, so wakeup is OK, but the display is
>  entirely black (backlight stays off).
> > 
> > So, just to confirm, if you never plug in an external DP source and the iMac
> > comes out of sleep, the display stays black?
> 
> Correct, verified this just now.
> 
> > If you log in via ssh and look at dmesg, was radeon able to train the DP
> > link again?  No error messages, nothing?
> 
> Here are the relevant dmesg lines after wakeup:
> 
> [  157.622950] [drm] enabling PCIE gen 2 link speeds, disable with
> radeon.pcie_gen2=0
> [  157.626077] [drm] PCIE GART of 1024M enabled (table at 0x0014C000).
> [  157.626094] radeon :02:00.0: WB enabled
> [  157.626097] radeon :02:00.0: fence driver on ring 0 use gpu addr
> 0x1c00 and cpu addr 0xa1242dfd6c00
> [  157.626098] radeon :02:00.0: fence driver on ring 3 use gpu addr
> 0x1c0c and cpu addr 0xa1242dfd6c0c
> [  157.626315] radeon :02:00.0: fence driver on ring 5 use gpu addr
> 0x0005c598 and cpu addr 0xbc3081c1c598
> [  157.672183] [drm] ring test on 0 succeeded in 1 usecs
> [  157.672187] [drm] ring test on 3 succeeded in 2 usecs
> [  157.847098] [drm] ring test on 5 succeeded in 1 usecs
> [  157.847102] [drm] UVD initialized successfully.
> [  157.847121] [drm] ib test on ring 0 succeeded in 0 usecs
> [  157.847136] [drm] ib test on ring 3 succeeded in 0 usecs
> [  158.524061] [drm] ib test on ring 5 succeeded

Hm, try booting with drm.debug=0xf to see if link training for the
eDP connector succeeds.  If the link cannot be trained, it would
explain that the screen stays black.  Should this indeed be the
case, one possible explanation would be that the panel is muxed
to the external port on resume and an appropriate command needs to
be sent to the SMC to switch the mux to the radeon card.  This could
be done in the ->resume_early hook of your APP000C platform driver.
The apple-gmux driver contains something similar to power the discrete
GPU down if it was off before suspend (because the BIOS always powers
it up on resume).

Another possible explanation would be that panel power needs to be
enabled by writing to the registers which control the pins mentioned
below.


> And this is logged in Xorg.0.log after wakeup:
> 
> [   229.956] (II) RADEON(0): Allocate new frame buffer 320x200 stride 384
> [   229.956] (II) RADEON(0): VRAM usage limit set to 219596K
> 
> xrandr still shows the eDP output as connected and active with 2560x1440 
> resolution.
> 
> > Is the panel off or is it on but merely with 0% brightness?
> 
> The backlight is definitely off. I've tried to shine a torch onto the panel 
> and
> see if any content is visible, but it looks like the panel itself is off, too.
> 
> > There's a block of pins on the GPU for "system management" which contains
> > a bunch of GPIO, OEM and reserved pins.  Three of these are used to control
> > the panel when it's switched to the radeon card:
> > pin 23 PNL_PWR_EN
> > pin 25 PNL_BL_EN
> > pin 27 PNL_BL_PWM
> > 
> > Basically you'd need to know what these are set to before and after sleep.
> > I don't know how to access them, presumably via a BAR register.  A quick
> > look at the RV730-specific registers in drivers/gpu/drm/radeon/*.h did not
> > yield anything useful, but someone at AMD may be able to find this out.
> 
> Can I perhaps use radeontool for this? I.e. dump registers before and after
> sleep and see if there's a difference? Or is radeontool too old to know about
> the correct registers?

*shrug*  Unfortunately I'm not familiar at all with radeontool. :-(

Best regards,

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

[PATCH] drm/doc: Polish irq helper documentation

[Daniel Vetter]

Pull a (much shorter) overview into drm_irq.c, and instead put the
callback documentation into in-line comments in drm_drv.h.

v2: Move the include stanzas back to the split-up patch (Stefan).

Cc: Stefan Agner 
Reviewed-by: Stefan Agner 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-internals.rst | 54 -
 drivers/gpu/drm/drm_irq.c   | 30 +
 drivers/gpu/drm/drm_vblank.c|  3 +++
 include/drm/drmP.h  |  9 +--
 include/drm/drm_drv.h   | 33 +--
 5 files changed, 66 insertions(+), 63 deletions(-)

diff --git a/Documentation/gpu/drm-internals.rst 
b/Documentation/gpu/drm-internals.rst
index dd28e39cf966..bece92258647 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -149,60 +149,6 @@ Device Instance and Driver Handling
 Driver Load
 ---
 
-IRQ Registration
-
-
-The DRM core tries to facilitate IRQ handler registration and
-unregistration by providing :c:func:`drm_irq_install()` and
-:c:func:`drm_irq_uninstall()` functions. Those functions only
-support a single interrupt per device, devices that use more than one
-IRQs need to be handled manually.
-
-Managed IRQ Registration
-
-
-:c:func:`drm_irq_install()` starts by calling the irq_preinstall
-driver operation. The operation is optional and must make sure that the
-interrupt will not get fired by clearing all pending interrupt flags or
-disabling the interrupt.
-
-The passed-in IRQ will then be requested by a call to
-:c:func:`request_irq()`. If the DRIVER_IRQ_SHARED driver feature
-flag is set, a shared (IRQF_SHARED) IRQ handler will be requested.
-
-The IRQ handler function must be provided as the mandatory irq_handler
-driver operation. It will get passed directly to
-:c:func:`request_irq()` and thus has the same prototype as all IRQ
-handlers. It will get called with a pointer to the DRM device as the
-second argument.
-
-Finally the function calls the optional irq_postinstall driver
-operation. The operation usually enables interrupts (excluding the
-vblank interrupt, which is enabled separately), but drivers may choose
-to enable/disable interrupts at a different time.
-
-:c:func:`drm_irq_uninstall()` is similarly used to uninstall an
-IRQ handler. It starts by waking up all processes waiting on a vblank
-interrupt to make sure they don't hang, and then calls the optional
-irq_uninstall driver operation. The operation must disable all hardware
-interrupts. Finally the function frees the IRQ by calling
-:c:func:`free_irq()`.
-
-Manual IRQ Registration
-'''
-
-Drivers that require multiple interrupt handlers can't use the managed
-IRQ registration functions. In that case IRQs must be registered and
-unregistered manually (usually with the :c:func:`request_irq()` and
-:c:func:`free_irq()` functions, or their :c:func:`devm_request_irq()` and
-:c:func:`devm_free_irq()` equivalents).
-
-When manually registering IRQs, drivers must not set the
-DRIVER_HAVE_IRQ driver feature flag, and must not provide the
-irq_handler driver operation. They must set the :c:type:`struct
-drm_device ` irq_enabled field to 1 upon
-registration of the IRQs, and clear it to 0 after unregistering the
-IRQs.
 
 IRQ Helper Library
 ~~
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 28d736c3fcb4..3b04c25100ae 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -62,19 +62,39 @@
 #include "drm_internal.h"
 
 /**
+ * DOC: irq helpers
+ *
+ * The DRM core provides very simple support helpers to enable IRQ handling on 
a
+ * device through the drm_irq_install() and drm_irq_uninstall() functions. This
+ * only supports devices with a single interrupt on the main device stored in
+ * &drm_device.dev and set as the device paramter in drm_dev_alloc().
+ *
+ * These IRQ helpers are strictly optional. Drivers which roll their own only
+ * need to set &drm_device.irq_enabled to signal the DRM core that vblank
+ * interrupts are working. Since these helpers don't automatically clean up the
+ * requested interrupt like e.g. devm_request_irq() they're not really
+ * recommended.
+ */
+
+/**
  * drm_irq_install - install IRQ handler
  * @dev: DRM device
  * @irq: IRQ number to install the handler for
  *
  * Initializes the IRQ related data. Installs the handler, calling the driver
- * irq_preinstall() and irq_postinstall() functions before and after the
- * installation.
+ * &drm_driver.irq_preinstall and &drm_driver.irq_postinstall functions before
+ * and after the installation.
  *
  * This is the simplified helper interface provided for drivers with no special
  * needs. Drivers which need to install interrupt handlers for multiple
  * interrupts must instead set &drm_device.irq_enabled to signal the DRM core
  * that vblank interrupts are available.
  *
+ * @irq must match the interrupt number 

[RFC 2/9] drm: Add CEA extended tag blocks and HDR bitfield macros

[Uma Shankar]

Add bit field and macro for extended tag in CEA block. Also,
declare macros for HDR metadata block.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/drm_edid.c |   16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 2e55599..4dee139 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2572,6 +2572,22 @@ static int drm_cvt_modes(struct drm_connector *connector,
 #define EDID_CEA_YCRCB422  (1 << 4)
 #define EDID_CEA_VCDB_QS   (1 << 6)
 
+#define DATA_BLOCK_EXTENDED_TAG0x07
+#define VIDEO_CAPABILITY_DATA_BLOCK0x0
+#define VSVD_DATA_BLOCK0x1
+#define COLORIMETRY_DATA_BLOCK 0x5
+#define HDR_STATIC_METADATA_BLOCK  0x6
+
+/* HDR Metadata Block: Bit fields */
+#define SUPPORTED_EOTF_MASK0x3f
+#define TRADITIONAL_GAMMA_SDR  (0x1 << 0)
+#define TRADITIONAL_GAMMA_HDR  (0x1 << 1)
+#define SMPTE_ST2084   (0x1 << 2)
+#define FUTURE_EOTF(0x1 << 3)
+#define RESERVED_EOTF  (0x3 << 4)
+
+#define STATIC_METADATA_TYPE1  (0x1 << 0)
+
 /*
  * Search EDID for CEA extension block.
  */
-- 
1.7.9.5

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

[RFC 0/9] Add HDR Metadata Parsing and handling in DRM layer

[Uma Shankar]

This patch series enables HDR support in drm.
It basically defines HDR metadata structures, 
property to pass content (after blending) metadata from user space
compositors to driver. 

Dynamic Range and Mastering infoframe creation and sending. 

ToDo: 
1. We need to get the color framework in place for all planes
   which support HDR content in hardware.
2. UserSpace/Compositors: Blending policies and metadata blob
   creation and passing to driver.

Please review and share your feedbacks/suggestions. 

Note: The intention for these patches is to get a design feedback on the uapi 
changes,
generic property design and infoframe handling. This cannot get merged as of 
now without
the userspace support in place. This series is not yet tested.

Uma Shankar (9):
  drm: Add HDR source metadata property
  drm: Add CEA extended tag blocks and HDR bitfield macros
  drm: Parse HDR metadata info from EDID
  drm: Parse Colorimetry data block from EDID
  drm/i915: Attach HDR metadata property to connector
  drm: Add HDR capabilty field to plane structure
  drm: Implement HDR source metadata set and get property handling
  drm: Enable HDR infoframe support
  drm/i915: Write HDR infoframe and send to panel

 drivers/gpu/drm/drm_atomic.c|   15 
 drivers/gpu/drm/drm_atomic_helper.c |6 ++
 drivers/gpu/drm/drm_connector.c |7 ++
 drivers/gpu/drm/drm_edid.c  |  151 +++
 drivers/gpu/drm/i915/intel_hdmi.c   |   27 +++
 drivers/video/hdmi.c|  138 
 include/drm/drm_connector.h |   13 +++
 include/drm/drm_edid.h  |4 +
 include/drm/drm_mode_config.h   |6 ++
 include/drm/drm_plane.h |3 +
 include/linux/hdmi.h|   21 +
 include/uapi/drm/drm_mode.h |   22 +
 12 files changed, 413 insertions(+)

-- 
1.7.9.5

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

[RFC 7/9] drm: Implement HDR source metadata set and get property handling

[Uma Shankar]

HDR source metadata set and get property implemented in this
patch. The blob data is received from userspace and saved in
connector state, the same is returned as blob in get property
call to userspace.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/drm_atomic.c|   15 +++
 drivers/gpu/drm/drm_atomic_helper.c |6 ++
 2 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index e163701..c0007c1 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1140,6 +1140,8 @@ int drm_atomic_connector_set_property(struct 
drm_connector *connector,
 {
struct drm_device *dev = connector->dev;
struct drm_mode_config *config = &dev->mode_config;
+   bool replaced = false;
+   int ret;
 
if (property == config->prop_crtc_id) {
struct drm_crtc *crtc = drm_crtc_find(dev, val);
@@ -1188,6 +1190,14 @@ int drm_atomic_connector_set_property(struct 
drm_connector *connector,
 */
if (state->link_status != DRM_LINK_STATUS_GOOD)
state->link_status = val;
+   } else if (property == config->hdr_source_metadata_property) {
+   ret = drm_atomic_replace_property_blob_from_id(dev,
+   &state->hdr_source_metadata_blob_ptr,
+   val,
+   -1,
+   &replaced);
+   state->hdr_metadata_changed |= replaced;
+   return ret;
} else if (property == config->aspect_ratio_property) {
state->picture_aspect_ratio = val;
} else if (property == connector->scaling_mode_property) {
@@ -1210,6 +1220,8 @@ static void drm_atomic_connector_print_state(struct 
drm_printer *p,
 
drm_printf(p, "connector[%u]: %s\n", connector->base.id, 
connector->name);
drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name : 
"(null)");
+   drm_printf(p, "\thdr_metadata_changed=%d\n",
+   state->hdr_metadata_changed);
 
if (connector->funcs->atomic_print_state)
connector->funcs->atomic_print_state(p, state);
@@ -1272,6 +1284,9 @@ static void drm_atomic_connector_print_state(struct 
drm_printer *p,
*val = state->picture_aspect_ratio;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
+   } else if (property == config->hdr_source_metadata_property) {
+   *val = (state->hdr_source_metadata_blob_ptr) ?
+   state->hdr_source_metadata_blob_ptr->base.id : 0;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 93b0221..1406441 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3436,6 +3436,10 @@ void drm_atomic_helper_connector_reset(struct 
drm_connector *connector)
memcpy(state, connector->state, sizeof(*state));
if (state->crtc)
drm_connector_get(connector);
+   if (state->hdr_source_metadata_blob_ptr)
+   drm_property_blob_get(state->hdr_source_metadata_blob_ptr);
+
+   state->hdr_metadata_changed = false;
 }
 EXPORT_SYMBOL(__drm_atomic_helper_connector_duplicate_state);
 
@@ -3562,6 +3566,8 @@ struct drm_atomic_state *
 {
if (state->crtc)
drm_connector_put(state->connector);
+   if (state->hdr_source_metadata_blob_ptr)
+   drm_property_blob_put(state->hdr_source_metadata_blob_ptr);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_connector_destroy_state);
 
-- 
1.7.9.5

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

[RFC 9/9] drm/i915: Write HDR infoframe and send to panel

[Uma Shankar]

Enable writing of HDR metadata infoframe to panel.
The data will be provid by usersapace compositors, based
on blending policies and passsed to driver through a blob
property.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_hdmi.c |   25 +
 drivers/video/hdmi.c  |2 +-
 2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index d8b53d0..91e0399 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -453,6 +453,27 @@ static void intel_write_infoframe(struct drm_encoder 
*encoder,
intel_hdmi->write_infoframe(encoder, crtc_state, frame->any.type, 
buffer, len);
 }
 
+/* Set Dynamic Range and Mastering Infoframe */
+static void intel_hdmi_set_drm_infoframe(struct drm_encoder *encoder,
+const struct intel_crtc_state 
*crtc_state,
+const struct drm_connector_state 
*conn_state)
+{
+   union hdmi_infoframe frame;
+   struct hdr_static_metadata *hdr_metadata;
+   int ret;
+
+   hdr_metadata = (struct hdr_static_metadata *)
+   conn_state->hdr_source_metadata_blob_ptr->data;
+
+   ret = drm_hdmi_infoframe_set_hdr_metadata(&frame.drm, hdr_metadata);
+   if (ret < 0) {
+   DRM_ERROR("couldn't set HDR metadata in infoframe\n");
+   return;
+   }
+
+   intel_write_infoframe(encoder, crtc_state, &frame);
+}
+
 static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder,
 const struct intel_crtc_state 
*crtc_state)
 {
@@ -840,6 +861,10 @@ static void hsw_set_infoframes(struct drm_encoder *encoder,
intel_hdmi_set_avi_infoframe(encoder, crtc_state);
intel_hdmi_set_spd_infoframe(encoder, crtc_state);
intel_hdmi_set_hdmi_infoframe(encoder, crtc_state);
+
+   /* Set Dynamic Range and Mastering Infoframe if supported and changed */
+   if (conn_state->hdr_metadata_changed)
+   intel_hdmi_set_drm_infoframe(encoder, crtc_state, conn_state);
 }
 
 void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool enable)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 2740f40..8d06ea2 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -421,7 +421,7 @@ int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe 
*frame)
  * error code on failure.
  */
 ssize_t hdmi_drm_infoframe_pack(struct hdmi_drm_infoframe *frame, void *buffer,
-size_t size)
+   size_t size)
 {
u8 *ptr = buffer;
size_t length;
-- 
1.7.9.5

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

[RFC 4/9] drm: Parse Colorimetry data block from EDID

[Uma Shankar]

CEA 861.3 spec adds colorimetry data block for HDMI.
Parsing the block to get the colorimetry data from
panel.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/drm_edid.c  |   24 
 include/drm/drm_connector.h |2 ++
 2 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 14f2740..c9b9c3c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3375,6 +3375,28 @@ static void fixup_detailed_cea_mode_clock(struct 
drm_display_mode *mode)
mode->clock = clock;
 }
 
+static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db)
+{
+   if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG)
+   return false;
+
+   if (db[1] != COLORIMETRY_DATA_BLOCK)
+   return false;
+
+   return true;
+}
+
+static void
+drm_parse_colorimetry_data_block(struct drm_connector *connector, const u8 *db)
+{
+   struct drm_hdmi_info *info = &connector->display_info.hdmi;
+   uint16_t len;
+
+   len = cea_db_payload_len(db);
+   info->colorimetry = db[2];
+}
+
+
 static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
 {
if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG)
@@ -4055,6 +4077,8 @@ static void drm_parse_cea_ext(struct drm_connector 
*connector,
drm_parse_hdmi_forum_vsdb(connector, db);
if (cea_db_is_hdmi_hdr_metadata_block(db))
drm_parse_hdr_metadata_block(connector, db);
+   if (cea_db_is_hdmi_colorimetry_data_block(db))
+   drm_parse_colorimetry_data_block(connector, db);
}
 }
 
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index c99d737..c2b0798 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -137,6 +137,8 @@ struct drm_scdc {
 struct drm_hdmi_info {
/** @scdc: sink's scdc support and capabilities */
struct drm_scdc scdc;
+   /* Colorimerty info from EDID */
+   u32 colorimetry;
 };
 
 /**
-- 
1.7.9.5

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

[RFC 8/9] drm: Enable HDR infoframe support

[Uma Shankar]

Enable Dynamic Range and Mastering Infoframe for HDR
content, which is defined in CEA 861.3 spec.

 The metadata will be computed based on blending
policy in userspace compositors and passed as a connector
property blob to driver. The same will be sent as infoframe
to panel which support HDR.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/drm_edid.c |   53 +
 drivers/video/hdmi.c   |  138 
 include/drm/drm_edid.h |4 ++
 include/linux/hdmi.h   |   21 +++
 4 files changed, 216 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c9b9c3c..3b99284 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4428,6 +4428,59 @@ void drm_set_preferred_mode(struct drm_connector 
*connector,
 EXPORT_SYMBOL(drm_set_preferred_mode);
 
 /**
+ * drm_hdmi_infoframe_set_hdr_metadata() - fill an HDMI AVI infoframe with
+ *  HDR metadata from userspace
+ * @frame: HDMI AVI infoframe
+ * @hdr_source_metadata: hdr_source_metadata info from userspace
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int
+drm_hdmi_infoframe_set_hdr_metadata(struct hdmi_drm_infoframe *frame,
+  void *hdr_metadata)
+{
+   struct hdr_static_metadata *hdr_source_metadata;
+   int err, i;
+
+   if (!frame || !hdr_metadata)
+   return -EINVAL;
+
+   err = hdmi_drm_infoframe_init(frame);
+   if (err < 0)
+   return err;
+
+   hdr_source_metadata = (struct hdr_static_metadata *)hdr_metadata;
+
+   frame->length = sizeof(struct hdr_static_metadata);
+
+
+   frame->eotf = hdr_source_metadata->eotf;
+   frame->type = hdr_source_metadata->type;
+
+   for (i = 0; i < 3; i++) {
+   frame->display_primaries_x[i] =
+   hdr_source_metadata->display_primaries_x[i];
+   frame->display_primaries_y[i] =
+   hdr_source_metadata->display_primaries_y[i];
+   }
+
+   frame->white_point_x = hdr_source_metadata->white_point_x;
+   frame->white_point_y = hdr_source_metadata->white_point_y;
+
+   frame->max_mastering_display_luminance =
+   hdr_source_metadata->max_mastering_display_luminance;
+   frame->min_mastering_display_luminance =
+   hdr_source_metadata->min_mastering_display_luminance;
+
+   frame->max_cll = hdr_source_metadata->max_cll;
+   frame->max_fall = hdr_source_metadata->max_fall;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_hdmi_infoframe_set_hdr_metadata);
+
+
+/**
  * drm_hdmi_avi_infoframe_from_display_mode() - fill an HDMI AVI infoframe with
  *  data from a DRM display mode
  * @frame: HDMI AVI infoframe
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1cf907e..2740f40 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -388,6 +388,103 @@ ssize_t hdmi_vendor_infoframe_pack(struct 
hdmi_vendor_infoframe *frame,
 }
 EXPORT_SYMBOL(hdmi_vendor_infoframe_pack);
 
+/**
+ * hdmi_drm_infoframe_init() - initialize an HDMI Dynaminc Range and
+ * mastering infoframe
+ * @frame: HDMI DRM infoframe
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe *frame)
+{
+   memset(frame, 0, sizeof(*frame));
+
+   frame->type = HDMI_INFOFRAME_TYPE_DRM;
+   frame->version = 1;
+
+   return 0;
+}
+EXPORT_SYMBOL(hdmi_drm_infoframe_init);
+
+/**
+ * hdmi_drm_infoframe_pack() - write HDMI DRM infoframe to binary buffer
+ * @frame: HDMI DRM infoframe
+ * @buffer: destination buffer
+ * @size: size of buffer
+ *
+ * Packs the information contained in the @frame structure into a binary
+ * representation that can be written into the corresponding controller
+ * registers. Also computes the checksum as required by section 5.3.5 of
+ * the HDMI 1.4 specification.
+ *
+ * Returns the number of bytes packed into the binary buffer or a negative
+ * error code on failure.
+ */
+ssize_t hdmi_drm_infoframe_pack(struct hdmi_drm_infoframe *frame, void *buffer,
+size_t size)
+{
+   u8 *ptr = buffer;
+   size_t length;
+
+   length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
+
+   if (size < length)
+   return -ENOSPC;
+
+   memset(buffer, 0, size);
+
+   ptr[0] = frame->type;
+   ptr[1] = frame->version;
+   ptr[2] = frame->length;
+   ptr[3] = 0; /* checksum */
+
+   /* start infoframe payload */
+   ptr += HDMI_INFOFRAME_HEADER_SIZE;
+
+   ptr[0] = frame->eotf;
+   ptr[1] = frame->metadata_type;
+
+   ptr[2] = frame->display_primaries_x[0] & 0xff;
+   ptr[3] = frame->display_primaries_x[0] >> 8;
+
+   ptr[4] = frame->display_primaries_x[1] & 0xff;
+   ptr[5] = frame->display_primaries_x[1] >> 8;
+
+   ptr[6] = fr

[RFC 1/9] drm: Add HDR source metadata property

[Uma Shankar]

This patch adds a blob property to get HDR metadata
information from userspace. This will be send as part
of AVI Infoframe to panel.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/drm_connector.c |7 +++
 include/drm/drm_connector.h |   11 +++
 include/drm/drm_mode_config.h   |6 ++
 include/uapi/drm/drm_mode.h |   22 ++
 4 files changed, 46 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 5cd61af..1b36fa2 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -789,6 +789,13 @@ int drm_connector_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.link_status_property = prop;
 
+   prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
+  "HDR_SOURCE_METADATA", 0);
+
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.hdr_source_metadata_property = prop;
+
return 0;
 }
 
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index d8bb25f..c99d737 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -342,6 +342,13 @@ struct drm_connector_state {
 * upscaling, mostly used for built-in panels.
 */
unsigned int scaling_mode;
+
+   /**
+* @metadata_blob_ptr:
+* DRM blob property for HDR metadata
+*/
+   struct drm_property_blob *hdr_source_metadata_blob_ptr;
+   bool hdr_metadata_changed : 1;
 };
 
 /**
@@ -877,6 +884,10 @@ struct drm_connector {
uint8_t num_h_tile, num_v_tile;
uint8_t tile_h_loc, tile_v_loc;
uint16_t tile_h_size, tile_v_size;
+
+   /* HDR metdata */
+   struct hdr_static_metadata *hdr_panel_metadata;
+   struct hdr_static_metadata *hdr_source_metadata;
 };
 
 #define obj_to_connector(x) container_of(x, struct drm_connector, base)
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 4298171..9ca49ea 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -741,6 +741,12 @@ struct drm_mode_config {
 */
struct drm_property *suggested_y_property;
 
+   /**
+* hdr_metadata_property: Connector property containing hdr metatda
+* This will be provided by userspace compositors based on HDR content
+*/
+   struct drm_property *hdr_source_metadata_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
 
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 403339f..920ea2a 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -590,6 +590,28 @@ struct drm_color_lut {
__u16 reserved;
 };
 
+enum supported_eotf_type {
+   TRADITIONAL_GAMMA_SDR = 0,
+   TRADITIONA_GAMMA_HDR,
+   SMPTE_ST2084,
+   FUTURE_EOTF
+};
+
+/* HDR Metadata */
+struct hdr_static_metadata {
+   uint16_t eotf;
+   uint16_t type;
+   uint16_t display_primaries_x[3];
+   uint16_t display_primaries_y[3];
+   uint16_t white_point_x;
+   uint16_t white_point_y;
+   uint16_t max_mastering_display_luminance;
+   uint16_t min_mastering_display_luminance;
+   uint16_t max_fall;
+   uint16_t max_cll;
+   uint16_t min_cll;
+};
+
 #define DRM_MODE_PAGE_FLIP_EVENT 0x01
 #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
 #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
-- 
1.7.9.5

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

[RFC 5/9] drm/i915: Attach HDR metadata property to connector

[Uma Shankar]

Attach HDR metadata property to connector object.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_hdmi.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 41267ff..d8b53d0 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1734,6 +1734,8 @@ static void intel_hdmi_destroy(struct drm_connector 
*connector)
intel_attach_broadcast_rgb_property(connector);
intel_attach_aspect_ratio_property(connector);
connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+   drm_object_attach_property(&connector->base,
+   connector->dev->mode_config.hdr_source_metadata_property, 0);
 }
 
 /*
-- 
1.7.9.5

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

[RFC 3/9] drm: Parse HDR metadata info from EDID

[Uma Shankar]

HDR metadata block is introduced in CEA-861.3 spec.
Parsing the same to get the panel's HDR metadata.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/drm_edid.c |   58 
 1 file changed, 58 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 4dee139..14f2740 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3375,6 +3375,62 @@ static void fixup_detailed_cea_mode_clock(struct 
drm_display_mode *mode)
mode->clock = clock;
 }
 
+static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
+{
+   if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG)
+   return false;
+
+   if (db[1] != HDR_STATIC_METADATA_BLOCK)
+   return false;
+
+   return true;
+}
+
+static uint16_t eotf_supported(const u8 *edid_ext)
+{
+   uint16_t val = 0;
+
+   if (edid_ext[2] & TRADITIONAL_GAMMA_SDR)
+   val |= TRADITIONAL_GAMMA_SDR;
+   if (edid_ext[2] & TRADITIONAL_GAMMA_HDR)
+   val |= TRADITIONAL_GAMMA_HDR;
+   if (edid_ext[2] & SMPTE_ST2084)
+   val |= SMPTE_ST2084;
+
+   return val;
+}
+
+static uint16_t hdr_metadata_type(const u8 *edid_ext)
+{
+   uint16_t val = 0;
+
+   if (edid_ext[3] & STATIC_METADATA_TYPE1)
+   val |= STATIC_METADATA_TYPE1;
+
+   return val;
+}
+
+static void
+drm_parse_hdr_metadata_block(struct drm_connector *connector, const u8 *db)
+{
+   uint16_t len;
+
+   len = cea_db_payload_len(db);
+   connector->hdr_panel_metadata->eotf = eotf_supported(db);
+   connector->hdr_panel_metadata->type = hdr_metadata_type(db);
+
+   if (len == 6) {
+   connector->hdr_panel_metadata->max_cll = db[4];
+   connector->hdr_panel_metadata->max_fall = db[5];
+   connector->hdr_panel_metadata->min_cll = db[6];
+   } else if (len == 5) {
+   connector->hdr_panel_metadata->max_cll = db[4];
+   connector->hdr_panel_metadata->max_fall = db[5];
+   } else if (len == 4)
+   connector->hdr_panel_metadata->max_cll = db[4];
+
+}
+
 static void
 drm_parse_hdmi_vsdb_audio(struct drm_connector *connector, const u8 *db)
 {
@@ -3997,6 +4053,8 @@ static void drm_parse_cea_ext(struct drm_connector 
*connector,
drm_parse_hdmi_vsdb_video(connector, db);
if (cea_db_is_hdmi_forum_vsdb(db))
drm_parse_hdmi_forum_vsdb(connector, db);
+   if (cea_db_is_hdmi_hdr_metadata_block(db))
+   drm_parse_hdr_metadata_block(connector, db);
}
 }
 
-- 
1.7.9.5

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

[RFC 6/9] drm: Add HDR capabilty field to plane structure

[Uma Shankar]

Hardware may have HDR capability on certain plane
engines. Enabling the same in drm plane structure
so that this can be communicated to user space.

Each drm driver should set this flag to true for planes
which support HDR.

Signed-off-by: Uma Shankar 
---
 include/drm/drm_plane.h |3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 9ab3e70..96d8f55 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -498,6 +498,9 @@ struct drm_plane {
 
enum drm_plane_type type;
 
+   /* Value of true:1 means HDR is supported */
+   bool hdr_supported;
+
/**
 * @index: Position inside the mode_config.list, can be used as an array
 * index. It is invariant over the lifetime of the plane.
-- 
1.7.9.5

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

Re: [Intel-gfx] [RFC 0/9] Add HDR Metadata Parsing and handling in DRM layer

[Daniel Vetter]

On Wed, May 31, 2017 at 03:40:48PM +0530, Uma Shankar wrote:
> This patch series enables HDR support in drm.
> It basically defines HDR metadata structures, 
> property to pass content (after blending) metadata from user space
> compositors to driver. 
> 
> Dynamic Range and Mastering infoframe creation and sending. 
> 
> ToDo: 
> 1. We need to get the color framework in place for all planes
>which support HDR content in hardware.
> 2. UserSpace/Compositors: Blending policies and metadata blob
>creation and passing to driver.

This is the key, before we have the userspace there's not much point in
reviewing the details of the kernel interface, nor the implementation.
-Daniel

> 
> Please review and share your feedbacks/suggestions. 
> 
> Note: The intention for these patches is to get a design feedback on the uapi 
> changes,
> generic property design and infoframe handling. This cannot get merged as of 
> now without
> the userspace support in place. This series is not yet tested.
> 
> Uma Shankar (9):
>   drm: Add HDR source metadata property
>   drm: Add CEA extended tag blocks and HDR bitfield macros
>   drm: Parse HDR metadata info from EDID
>   drm: Parse Colorimetry data block from EDID
>   drm/i915: Attach HDR metadata property to connector
>   drm: Add HDR capabilty field to plane structure
>   drm: Implement HDR source metadata set and get property handling
>   drm: Enable HDR infoframe support
>   drm/i915: Write HDR infoframe and send to panel
> 
>  drivers/gpu/drm/drm_atomic.c|   15 
>  drivers/gpu/drm/drm_atomic_helper.c |6 ++
>  drivers/gpu/drm/drm_connector.c |7 ++
>  drivers/gpu/drm/drm_edid.c  |  151 
> +++
>  drivers/gpu/drm/i915/intel_hdmi.c   |   27 +++
>  drivers/video/hdmi.c|  138 
>  include/drm/drm_connector.h |   13 +++
>  include/drm/drm_edid.h  |4 +
>  include/drm/drm_mode_config.h   |6 ++
>  include/drm/drm_plane.h |3 +
>  include/linux/hdmi.h|   21 +
>  include/uapi/drm/drm_mode.h |   22 +
>  12 files changed, 413 insertions(+)
> 
> -- 
> 1.7.9.5
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] gma500: Fix a sleep-in-atomic bug in psbfb_2d_submit

[Patrik Jakobsson]

On Wed, May 31, 2017 at 10:48 AM, Jia-Ju Bai  wrote:
> The driver may sleep under a spin lock, and the function call path is:
> psbfb_2d_submit (acquire the lock by spin_lock_irqsave)
>   psb_2d_wait_available
> psb_spank
>   msleep --> may sleep
>
> To fix it, the "msleep" is replaced with "mdelay" in psb_spank.
>
> Signed-off-by: Jia-Ju Bai 

Thanks for the patch. checkpatch complains about DOS line endings so
you might want to take a look at your editor settings. Usually we tag
the subject with drm/gma500 but don't think there's a hard rule about
that. I'll fix it up and take it through drm-misc-next.

Signed-off-by: Patrik Jakobsson 

> ---
>  drivers/gpu/drm/gma500/accel_2d.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/accel_2d.c 
> b/drivers/gpu/drm/gma500/accel_2d.c
> index c51d925..7c24c8a 100644
> --- a/drivers/gpu/drm/gma500/accel_2d.c
> +++ b/drivers/gpu/drm/gma500/accel_2d.c
> @@ -55,7 +55,7 @@ void psb_spank(struct drm_psb_private *dev_priv)
> _PSB_CS_RESET_TWOD_RESET, PSB_CR_SOFT_RESET);
> PSB_RSGX32(PSB_CR_SOFT_RESET);
>
> -   msleep(1);
> +   mdelay(1);
>
> PSB_WSGX32(0, PSB_CR_SOFT_RESET);
> wmb();
> @@ -64,7 +64,7 @@ void psb_spank(struct drm_psb_private *dev_priv)
> wmb();
> (void) PSB_RSGX32(PSB_CR_BIF_CTRL);
>
> -   msleep(1);
> +   mdelay(1);
> PSB_WSGX32(PSB_RSGX32(PSB_CR_BIF_CTRL) & ~_PSB_CB_CTRL_CLEAR_FAULT,
>PSB_CR_BIF_CTRL);
> (void) PSB_RSGX32(PSB_CR_BIF_CTRL);
> --
> 1.7.9.5
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 08/10] drm/arm: malidp: Use crtc->mode_valid() callback

[Liviu Dudau]

On Wed, May 31, 2017 at 10:20:04AM +0200, Daniel Vetter wrote:
> On Tue, May 30, 2017 at 10:37:29AM +0100, Liviu Dudau wrote:
> > On Tue, May 30, 2017 at 09:29:44AM +0200, Neil Armstrong wrote:
> > > On 05/25/2017 04:19 PM, Jose Abreu wrote:
> > > > Now that we have a callback to check if crtc supports a given mode
> > > > we can use it in malidp so that we restrict the number of probbed
> > > > modes to the ones we can actually display.
> > > > 
> > > > Also, remove the mode_fixup() callback as this is no longer needed
> > > > because mode_valid() will be called before.
> > > > 
> > > > NOTE: Not even compiled tested
> > 
> > I did compile it, even done some testing, but by no means have I managed
> > to cover all the cases. Looks OK to me.
> > 
> > > > 
> > > > Signed-off-by: Jose Abreu 
> > > > Cc: Carlos Palminha 
> > > > Cc: Daniel Vetter 
> > > > Cc: Liviu Dudau 
> > 
> > Acked-by: Liviu Dudau 
> 
> What does this mean? Do you expect me to merge this through drm-misc? Or
> do you plan to merge it through your arm tree (all the required patches
> are in drm-misc-next and will be in Dave's tree soonish)?
> 
> /me confused.

/me too. :) I've only got Cc-ed on one patch, so I'm guessing the whole series 
is
going to be picked up through drm-misc. For patches that are part of a larger
series (to me) it makes sense to push them through a single channel. But I'm not
the author of the series so I don't know what Jose prefers. If Jose wants this
patch to go through mali-dp tree then I'm happy to pull it, otherwise I can 
sort out
the conflict(s) before sending a pull request to Dave.

On the larger topic, I'm guessing this is not the first time a series touches 
multiple
drivers that are not together in a single tree. How was this sorted in the 
past? Is
there a better way?

Best regards,
Liviu

> 
> Thanks, Daniel
> 
> > 
> > > > Cc: Brian Starkey 
> > > > Cc: David Airlie 
> > > > ---
> > > >  drivers/gpu/drm/arm/malidp_crtc.c | 11 +--
> > > >  1 file changed, 5 insertions(+), 6 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/arm/malidp_crtc.c 
> > > > b/drivers/gpu/drm/arm/malidp_crtc.c
> > > > index 9446a67..4bb38a2 100644
> > > > --- a/drivers/gpu/drm/arm/malidp_crtc.c
> > > > +++ b/drivers/gpu/drm/arm/malidp_crtc.c
> > > > @@ -22,9 +22,8 @@
> > > >  #include "malidp_drv.h"
> > > >  #include "malidp_hw.h"
> > > >  
> > > > -static bool malidp_crtc_mode_fixup(struct drm_crtc *crtc,
> > > > -  const struct drm_display_mode *mode,
> > > > -  struct drm_display_mode 
> > > > *adjusted_mode)
> > > > +static enum drm_mode_status malidp_crtc_mode_valid(struct drm_crtc 
> > > > *crtc,
> > > > +  const struct 
> > > > drm_display_mode *mode)
> > > >  {
> > > > struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
> > > > struct malidp_hw_device *hwdev = malidp->dev;
> > > > @@ -40,11 +39,11 @@ static bool malidp_crtc_mode_fixup(struct drm_crtc 
> > > > *crtc,
> > > > if (rate != req_rate) {
> > > > DRM_DEBUG_DRIVER("pxlclk doesn't support %ld 
> > > > Hz\n",
> > > >  req_rate);
> > > > -   return false;
> > > > +   return MODE_NOCLOCK;
> > > > }
> > > > }
> > > >  
> > > > -   return true;
> > > > +   return MODE_OK;
> > > >  }
> > > >  
> > > >  static void malidp_crtc_enable(struct drm_crtc *crtc)
> > > > @@ -408,7 +407,7 @@ static int malidp_crtc_atomic_check(struct drm_crtc 
> > > > *crtc,
> > > >  }
> > > >  
> > > >  static const struct drm_crtc_helper_funcs malidp_crtc_helper_funcs = {
> > > > -   .mode_fixup = malidp_crtc_mode_fixup,
> > > > +   .mode_valid = malidp_crtc_mode_valid,
> > > > .enable = malidp_crtc_enable,
> > > > .disable = malidp_crtc_disable,
> > > > .atomic_check = malidp_crtc_atomic_check,
> > > > 
> > > 
> > > Reviewed-by: Neil Armstrong 
> > 
> > -- 
> > 
> > | I would like to |
> > | fix the world,  |
> > | but they're not |
> > | giving me the   |
> >  \ source code!  /
> >   ---
> > ¯\_(ツ)_/¯
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 08/10] drm/arm: malidp: Use crtc->mode_valid() callback

[Daniel Vetter]

On Wed, May 31, 2017 at 12:48 PM, Liviu Dudau  wrote:
> On Wed, May 31, 2017 at 10:20:04AM +0200, Daniel Vetter wrote:
>> On Tue, May 30, 2017 at 10:37:29AM +0100, Liviu Dudau wrote:
>> > On Tue, May 30, 2017 at 09:29:44AM +0200, Neil Armstrong wrote:
>> > > On 05/25/2017 04:19 PM, Jose Abreu wrote:
>> > > > Now that we have a callback to check if crtc supports a given mode
>> > > > we can use it in malidp so that we restrict the number of probbed
>> > > > modes to the ones we can actually display.
>> > > >
>> > > > Also, remove the mode_fixup() callback as this is no longer needed
>> > > > because mode_valid() will be called before.
>> > > >
>> > > > NOTE: Not even compiled tested
>> >
>> > I did compile it, even done some testing, but by no means have I managed
>> > to cover all the cases. Looks OK to me.
>> >
>> > > >
>> > > > Signed-off-by: Jose Abreu 
>> > > > Cc: Carlos Palminha 
>> > > > Cc: Daniel Vetter 
>> > > > Cc: Liviu Dudau 
>> >
>> > Acked-by: Liviu Dudau 
>>
>> What does this mean? Do you expect me to merge this through drm-misc? Or
>> do you plan to merge it through your arm tree (all the required patches
>> are in drm-misc-next and will be in Dave's tree soonish)?
>>
>> /me confused.
>
> /me too. :) I've only got Cc-ed on one patch, so I'm guessing the whole 
> series is
> going to be picked up through drm-misc. For patches that are part of a larger
> series (to me) it makes sense to push them through a single channel. But I'm 
> not
> the author of the series so I don't know what Jose prefers. If Jose wants this
> patch to go through mali-dp tree then I'm happy to pull it, otherwise I can 
> sort out
> the conflict(s) before sending a pull request to Dave.
>
> On the larger topic, I'm guessing this is not the first time a series touches 
> multiple
> drivers that are not together in a single tree. How was this sorted in the 
> past? Is
> there a better way?

I change my preferred merge strategy depending upon how invasive the
patch is. Since this one here is more complex than a simple refactor,
I prefer it goes in through the right trees. And the required patches
are already in drm-misc-next now, so this should be doable.

For simpler stuff it's often easier to just get it landed through
drm-misc, especially if it's just a dumb patch to e.g. add a new
argument to a function and fill out the default one everywhere. For
those I think it's not even required to get an ack from driver
maintainers, just solid review of the idea&implementation in general.

A bit a grey thing in-between is refactorings that are simple, but
require and audit on each driver, and then a final patch at the end to
remove the old helper functions. My drm_vblank_cleanup removal is such
a case. There I prefer driver maintainers to pick things up
themselves, and 1 kernel release afterwards I'll put the leftover
driver patches + the final cleanup into drm-misc.

Anyway, long story short: Your choice here. I just need to know
whether you'll pick it up or want me to merge it through
drm-misc-next. I think in general it'd be good if maintainers don't
just ack patches, but also state what they expect to happen, e.g. when
I ack something I try to make it clear that I expect this to go in
through a different tree than one I maintain. Otherwise I just pick it
up and merge (and say so).

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [ANN] HDMI CEC Status Update

[Marek Szyprowski]

Hi Andrzej and Hans,

On 2017-05-31 10:12, Andrzej Hajda wrote:

On 30.05.2017 08:53, Hans Verkuil wrote:

For those who are interested in HDMI CEC support I made a little status
document that I intend to keep up to date:

https://hverkuil.home.xs4all.nl/cec-status.txt

My goal is to get CEC supported for any mainlined HDMI driver where the hardware
supports CEC.

If anyone is working on a CEC driver that I don't know already about, just drop
me an email so I can update the status.

Sii8620 HDMI->MHL bridge is on my TODO list.
Regarding Exynos5 it is apparently the same IP as in Exynos4.


I've just posted a patch enabling CEC module on Exynos5250 (Google Snow)
and Exynos5422 (Odroid XU3).

Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland

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

Re: [PATCH 16/37] drm/hdlcd|mali: Drop drm_vblank_cleanup

[Liviu Dudau]

Hi Daniel,

On Wed, May 24, 2017 at 04:51:51PM +0200, Daniel Vetter wrote:
> IRQs are properly shut down, so it almost works as race-free shutdown.
> Except the irq is stopped after the vblank stuff, so boom anyway.
> Proper way would be to call drm_atomic_helper_shutdown before any of
> the kms things gets stopped. So no harm in removing the
> drm_vblank_cleanup here really.

Slightly confused on the implied message in the commit text: is "Proper way
would be to call drm_atomic_helper_shutdown" a hint? A promise of a future
patch? A message to the future us on how to fix things if they blow up?

If calling drm_atomic_helper_shutdown() is the proper thing to do, why does the
patch (and the series) avoids doing that? Lack of understanding of the driver's
internal workings? Then I want to help, if I can understand the new direction.

Best regards,
Liviu

> 
> Same story for both hdlcd and mali.
> 
> v2: Move misplaced malidp hunk to this patch (Liviu).
> 
> Cc: Liviu Dudau 
> Cc: Brian Starkey 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/arm/hdlcd_drv.c  | 2 --
>  drivers/gpu/drm/arm/malidp_drv.c | 2 --
>  2 files changed, 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index 0f49c4b12772..345c8357b273 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -340,7 +340,6 @@ static int hdlcd_drm_bind(struct device *dev)
>   }
>  err_fbdev:
>   drm_kms_helper_poll_fini(drm);
> - drm_vblank_cleanup(drm);
>  err_vblank:
>   pm_runtime_disable(drm->dev);
>  err_pm_active:
> @@ -368,7 +367,6 @@ static void hdlcd_drm_unbind(struct device *dev)
>   }
>   drm_kms_helper_poll_fini(drm);
>   component_unbind_all(dev, drm);
> - drm_vblank_cleanup(drm);
>   pm_runtime_get_sync(drm->dev);
>   drm_irq_uninstall(drm);
>   pm_runtime_put_sync(drm->dev);
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 0d3eb537d08b..01b13d219917 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -652,7 +652,6 @@ static int malidp_bind(struct device *dev)
>   drm_kms_helper_poll_fini(drm);
>  fbdev_fail:
>   pm_runtime_get_sync(dev);
> - drm_vblank_cleanup(drm);
>  vblank_fail:
>   malidp_se_irq_fini(drm);
>   malidp_de_irq_fini(drm);
> @@ -692,7 +691,6 @@ static void malidp_unbind(struct device *dev)
>   }
>   drm_kms_helper_poll_fini(drm);
>   pm_runtime_get_sync(dev);
> - drm_vblank_cleanup(drm);
>   malidp_se_irq_fini(drm);
>   malidp_de_irq_fini(drm);
>   component_unbind_all(dev, drm);
> -- 
> 2.11.0
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 16/37] drm/hdlcd|mali: Drop drm_vblank_cleanup

[Daniel Vetter]

On Wed, May 31, 2017 at 12:57 PM, Liviu Dudau  wrote:
> On Wed, May 24, 2017 at 04:51:51PM +0200, Daniel Vetter wrote:
>> IRQs are properly shut down, so it almost works as race-free shutdown.
>> Except the irq is stopped after the vblank stuff, so boom anyway.
>> Proper way would be to call drm_atomic_helper_shutdown before any of
>> the kms things gets stopped. So no harm in removing the
>> drm_vblank_cleanup here really.
>
> Slightly confused on the implied message in the commit text: is "Proper way
> would be to call drm_atomic_helper_shutdown" a hint? A promise of a future
> patch? A message to the future us on how to fix things if they blow up?
>
> If calling drm_atomic_helper_shutdown() is the proper thing to do, why does 
> the
> patch (and the series) avoids doing that? Lack of understanding of the 
> driver's
> internal workings? Then I want to help, if I can understand the new direction.

Yes, I wanted to not make things worse. If you look at the overall
result (especially last patch) I'm also trying to better document
stuff in the vblank area, but summarized, if you want to make sure
that vblank processing has stopped, you need to call drm_vblank_off on
each active crtc. The simplest way to get that is by using
drm_atomic_helper_shutdown(). Calling drm_vblank_cleanup doesn't
really do anything useful (see the last patch for the only valid
usecase there ever was).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 08/10] drm/arm: malidp: Use crtc->mode_valid() callback

[Liviu Dudau]

On Wed, May 31, 2017 at 12:56:59PM +0200, Daniel Vetter wrote:
> On Wed, May 31, 2017 at 12:48 PM, Liviu Dudau  wrote:
> > On Wed, May 31, 2017 at 10:20:04AM +0200, Daniel Vetter wrote:
> >> On Tue, May 30, 2017 at 10:37:29AM +0100, Liviu Dudau wrote:
> >> > On Tue, May 30, 2017 at 09:29:44AM +0200, Neil Armstrong wrote:
> >> > > On 05/25/2017 04:19 PM, Jose Abreu wrote:
> >> > > > Now that we have a callback to check if crtc supports a given mode
> >> > > > we can use it in malidp so that we restrict the number of probbed
> >> > > > modes to the ones we can actually display.
> >> > > >
> >> > > > Also, remove the mode_fixup() callback as this is no longer needed
> >> > > > because mode_valid() will be called before.
> >> > > >
> >> > > > NOTE: Not even compiled tested
> >> >
> >> > I did compile it, even done some testing, but by no means have I managed
> >> > to cover all the cases. Looks OK to me.
> >> >
> >> > > >
> >> > > > Signed-off-by: Jose Abreu 
> >> > > > Cc: Carlos Palminha 
> >> > > > Cc: Daniel Vetter 
> >> > > > Cc: Liviu Dudau 
> >> >
> >> > Acked-by: Liviu Dudau 
> >>
> >> What does this mean? Do you expect me to merge this through drm-misc? Or
> >> do you plan to merge it through your arm tree (all the required patches
> >> are in drm-misc-next and will be in Dave's tree soonish)?
> >>
> >> /me confused.
> >
> > /me too. :) I've only got Cc-ed on one patch, so I'm guessing the whole 
> > series is
> > going to be picked up through drm-misc. For patches that are part of a 
> > larger
> > series (to me) it makes sense to push them through a single channel. But 
> > I'm not
> > the author of the series so I don't know what Jose prefers. If Jose wants 
> > this
> > patch to go through mali-dp tree then I'm happy to pull it, otherwise I can 
> > sort out
> > the conflict(s) before sending a pull request to Dave.
> >
> > On the larger topic, I'm guessing this is not the first time a series 
> > touches multiple
> > drivers that are not together in a single tree. How was this sorted in the 
> > past? Is
> > there a better way?
> 
> I change my preferred merge strategy depending upon how invasive the
> patch is. Since this one here is more complex than a simple refactor,
> I prefer it goes in through the right trees. And the required patches
> are already in drm-misc-next now, so this should be doable.
> 
> For simpler stuff it's often easier to just get it landed through
> drm-misc, especially if it's just a dumb patch to e.g. add a new
> argument to a function and fill out the default one everywhere. For
> those I think it's not even required to get an ack from driver
> maintainers, just solid review of the idea&implementation in general.
> 
> A bit a grey thing in-between is refactorings that are simple, but
> require and audit on each driver, and then a final patch at the end to
> remove the old helper functions. My drm_vblank_cleanup removal is such
> a case. There I prefer driver maintainers to pick things up
> themselves, and 1 kernel release afterwards I'll put the leftover
> driver patches + the final cleanup into drm-misc.
> 
> Anyway, long story short: Your choice here. I just need to know
> whether you'll pick it up or want me to merge it through
> drm-misc-next. I think in general it'd be good if maintainers don't
> just ack patches, but also state what they expect to happen, e.g. when
> I ack something I try to make it clear that I expect this to go in
> through a different tree than one I maintain. Otherwise I just pick it
> up and merge (and say so).

OK, if Jose doesn't like a different approach then I'll pick up this patch.
Then I guess I'll keep an eye on when airlied's git tree and see when 
drm-misc-next
gets merged before sending my pull request.

And sorry for not stating my follow up action with the Ack, like I've said, I
thought the whole series will be picked up by you based on this reply:

https://lists.freedesktop.org/archives/dri-devel/2017-May/142377.html

Best regards,
Liviu

> 
> Thanks, Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] drm/msm: msm-fixes for 4.12-rc4

[Rob Clark]

Hi Dave,

a few fixes for 4.12..

The following changes since commit bc1f0e04da20473d6feab0cd9ac638a348d5:

  Merge branch 'drm-fixes-4.12' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2017-05-26
11:51:55 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~robclark/linux msm-fixes-4.12-rc4

for you to fetch changes up to d72fea538fe6d783c1e63a2fc304019abf4be93a:

  drm/msm: Fix the check for the command size (2017-05-27 13:48:29 -0400)


Eric Anholt (2):
  drm/msm: Expose our reservation object when exporting a dmabuf.
  drm/msm: Reuse dma_fence_release.

Jordan Crouse (2):
  drm/msm: Take the mutex before calling msm_gem_new_impl
  drm/msm: Fix the check for the command size

Philipp Zabel (1):
  drm/msm: for array in-fences, check if all backing fences are
from our own context before waiting

Rob Clark (4):
  drm/msm: select PM_OPP
  drm/msm/mdp5: use __drm_atomic_helper_plane_duplicate_state()
  drm/msm/gpu: check legacy clk names in get_clocks()
  drm/msm/mdp5: release hwpipe(s) for unused planes

Tobias Klauser (1):
  drm/msm: constify irq_domain_ops

 drivers/gpu/drm/msm/Kconfig   |  1 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c  |  2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c |  9 +++--
 drivers/gpu/drm/msm/msm_drv.c |  1 +
 drivers/gpu/drm/msm/msm_drv.h |  1 +
 drivers/gpu/drm/msm/msm_fence.c   | 10 ++
 drivers/gpu/drm/msm/msm_gem.c |  6 ++
 drivers/gpu/drm/msm/msm_gem_prime.c   |  7 +++
 drivers/gpu/drm/msm/msm_gem_submit.c  | 14 +++---
 drivers/gpu/drm/msm/msm_gpu.c |  4 ++--
 10 files changed, 35 insertions(+), 20 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 16/37] drm/hdlcd|mali: Drop drm_vblank_cleanup

[Liviu Dudau]

On Wed, May 31, 2017 at 01:03:34PM +0200, Daniel Vetter wrote:
> On Wed, May 31, 2017 at 12:57 PM, Liviu Dudau  wrote:
> > On Wed, May 24, 2017 at 04:51:51PM +0200, Daniel Vetter wrote:
> >> IRQs are properly shut down, so it almost works as race-free shutdown.
> >> Except the irq is stopped after the vblank stuff, so boom anyway.
> >> Proper way would be to call drm_atomic_helper_shutdown before any of
> >> the kms things gets stopped. So no harm in removing the
> >> drm_vblank_cleanup here really.
> >
> > Slightly confused on the implied message in the commit text: is "Proper way
> > would be to call drm_atomic_helper_shutdown" a hint? A promise of a future
> > patch? A message to the future us on how to fix things if they blow up?
> >
> > If calling drm_atomic_helper_shutdown() is the proper thing to do, why does 
> > the
> > patch (and the series) avoids doing that? Lack of understanding of the 
> > driver's
> > internal workings? Then I want to help, if I can understand the new 
> > direction.
> 
> Yes, I wanted to not make things worse. If you look at the overall
> result (especially last patch) I'm also trying to better document
> stuff in the vblank area, but summarized, if you want to make sure
> that vblank processing has stopped, you need to call drm_vblank_off on
> each active crtc. The simplest way to get that is by using
> drm_atomic_helper_shutdown(). Calling drm_vblank_cleanup doesn't
> really do anything useful (see the last patch for the only valid
> usecase there ever was).

OK, so there should be a follow up patch adding drm_atomic_helper_shutdown(). I 
guess
I need to call dibs on it? :)

Best regards,
Liviu

> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 194761] amdgpu driver breaks on Oland (SI)

[bugzilla-daemon]

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

--- Comment #29 from Berg (b...@uralmail.com) ---
(In reply to Jean Delvare from comment #28)
> I don't know how reliable it is, but Wikipedia claims that the Radeon R5 240
> has a 128-bit bus to video RAM.
I confirm as the owner of the R7 240, - yes, the 128-bit bus, R5 240 is same

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

[Bug 98145] X modesetting problem on dell laptop

[bugzilla-daemon]

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

--- Comment #4 from Henri Kemppainen  ---
This looks very much like symptoms of bug 101249:
https://bugs.freedesktop.org/show_bug.cgi?id=101249

Klaus if you're still around, you could try a workaround to test the theory. 
See next attachment.

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

[Bug 98145] X modesetting problem on dell laptop

[bugzilla-daemon]

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

--- Comment #5 from Henri Kemppainen  ---
Created attachment 131597
  --> https://bugs.freedesktop.org/attachment.cgi?id=131597&action=edit
disable gtf modes

-- 
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 02/11] drm/edid: Complete CEA modedb(VIC 1-107)

[Ville Syrjälä]

On Tue, May 30, 2017 at 09:56:56PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 5/30/2017 9:48 PM, Ville Syrjälä wrote:
> > On Tue, May 30, 2017 at 05:43:41PM +0530, Shashank Sharma wrote:
> >> CEA-861-F specs defines new video modes to be used with
> >> HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
> >> 1-107.
> >>
> >> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> >> to be able to parse new CEA modes using the existing methods, we have
> >> to complete the modedb (VIC=65 onwards).
> >>
> >> This patch adds:
> >> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
> >> - Newly added 4k modes (from VIC=93 to VIC=107).
> > Still missing the "native bit" handling.
> I tried searching the native bit handling in the code, but I could not 
> get any thing. We are typically doing a (vic & 127) and that's all.

And that's not really correct. We shouldn't discard the msb until we've
checked that we're in the correct range of VICs that have the native
bit. drm_display_mode_from_vic_index() is the place where we should be
checking this I think.

> Can you please point out a bit here ?
> 
> - Shashank
> >> The patch was originaly discussed and reviewed here:
> >> https://patchwork.freedesktop.org/patch/135810/
> >>
> >> Cc: Ville Syrjala 
> >> Cc: Jose Abreu 
> >> Cc: Andrzej Hajda 
> >> Cc: Alex Deucher 
> >> Cc: Harry Wentland 
> >>
> >> V2: Rebase
> >>
> >> Reviewed-by: Jose Abreu 
> >> Reviewed-by: Alex Deucher 
> >> Acked-by: Harry Wentland 
> >> Signed-off-by: Shashank Sharma 
> >> ---
> >>   drivers/gpu/drm/drm_edid.c | 215 
> >> +
> >>   1 file changed, 215 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 8b23435..c3fa3a1 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -1006,6 +1006,221 @@ static const struct drm_display_mode 
> >> edid_cea_modes[] = {
> >>   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> >>   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> >> +  /* 65 - 1280x720@24Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
> >> + 3080, 3300, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 66 - 1280x720@25Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
> >> + 3740, 3960, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 67 - 1280x720@30Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
> >> + 3080, 3300, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 68 - 1280x720@50Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
> >> + 1760, 1980, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 69 - 1280x720@60Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
> >> + 1430, 1650, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 70 - 1280x720@100Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
> >> + 1760, 1980, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 71 - 1280x720@120Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
> >> + 1430, 1650, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 72 - 1920x1080@24Hz */
> >> +  { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
> >> + 2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 73 - 1920x1080@25Hz */
> >> +  { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
> >> + 2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 74 - 

Re: [PATCH v2 01/11] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Ville Syrjälä]

On Tue, May 30, 2017 at 10:00:12PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 5/30/2017 9:43 PM, Ville Syrjälä wrote:
> > On Tue, May 30, 2017 at 05:43:40PM +0530, Shashank Sharma wrote:
> >> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> >> For any other mode, the VIC filed in AVI infoframes should be 0.
> >> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> >> extended to (VIC 1-107).
> >>
> >> This patch adds a bool input variable, which indicates if the connected
> >> sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
> >> HDMI 2.0 VIC to a HDMI 1.4 sink.
> >>
> >> This patch touches all drm drivers, who are callers of this function
> >> drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
> >> no change in current behavior, is_hdmi2 is kept as false.
> >>
> >> In case of I915 driver, this patch checks the connector->display_info
> >> to check if the connected display is HDMI 2.0.
> >>
> >> Cc: Ville Syrjala 
> >> Cc: Jose Abreu 
> >> Cc: Andrzej Hajda 
> >> Cc: Alex Deucher 
> >> Cc: Daniel Vetter 
> >>
> >> PS: This patch touches a few lines in few files, which were
> >> already above 80 char, so checkpatch gives 80 char warning again.
> >> - gpu/drm/omapdrm/omap_encoder.c
> >> - gpu/drm/i915/intel_sdvo.c
> >>
> >> V2: Rebase, Added r-b from Andrzej
> >>
> >> Reviewed-by: Andrzej Hajda 
> >> Signed-off-by: Shashank Sharma 
> >> ---
> >>   drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
> >>   drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
> >>   drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
> >>   drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
> >>   drivers/gpu/drm/bridge/sii902x.c  |  2 +-
> >>   drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
> >>   drivers/gpu/drm/drm_edid.c| 12 +++-
> >>   drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
> >>   drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
> >>   drivers/gpu/drm/i915/intel_hdmi.c |  5 -
> >>   drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
> >>   drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
> >>   drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
> >>   drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
> >>   drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
> >>   drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
> >>   drivers/gpu/drm/tegra/hdmi.c  |  2 +-
> >>   drivers/gpu/drm/tegra/sor.c   |  2 +-
> >>   drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
> >>   drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
> >>   include/drm/drm_edid.h|  3 ++-
> >>   21 files changed, 38 insertions(+), 21 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
> >> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> >> index 3c62c45..4923ddc 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> >> @@ -1864,7 +1864,7 @@ static void dce_v10_0_afmt_setmode(struct 
> >> drm_encoder *encoder,
> >>dce_v10_0_audio_write_sad_regs(encoder);
> >>dce_v10_0_audio_write_latency_fields(encoder, mode);
> >>   
> >> -  err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> >> +  err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> >>if (err < 0) {
> >>DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> >>return;
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
> >> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> >> index c8ed0fa..4101684 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> >> @@ -1848,7 +1848,7 @@ static void dce_v11_0_afmt_setmode(struct 
> >> drm_encoder *encoder,
> >>dce_v11_0_audio_write_sad_regs(encoder);
> >>dce_v11_0_audio_write_latency_fields(encoder, mode);
> >>   
> >> -  err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> >> +  err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> >>if (err < 0) {
> >>DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> >>return;
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
> >> b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> >> index 3e90c19..a7f6b32 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> >> @@ -1747,7 +1747,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder 
> >> *encoder,
> >>dce_v8_0_audio_write_sad_regs(encoder);
> >>dce_v8_0_audio_write_latency_fields(encoder, mode);
> >>   
> >> -  err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> >> +  err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> >>if (err < 0) {
> >>DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> >>return;
> >> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
> >> b/drivers/gpu/drm/bridge/a

Re: [PATCH v2 05/11] drm: create hdmi output property

[Ville Syrjälä]

On Tue, May 30, 2017 at 10:18:19PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 5/30/2017 10:06 PM, Ville Syrjälä wrote:
> > On Tue, May 30, 2017 at 05:43:44PM +0530, Shashank Sharma wrote:
> >> HDMI displays can support various output types, based on
> >> the color space and subsampling type. The possible
> >> outputs from a HDMI 2.0 monitor could be:
> >>   - RGB
> >>   - YCBCR 444
> >>   - YCBCR 422
> >>   - YCBCR 420
> >>
> >> This patch adds a drm property, using which, a userspace
> > I think we should add the 4:2:0 only mode support first since that
> > doesn't require new uapi. The uapi stuff probably needs more careful
> > thought as we might want to consider exposing more of the
> > colorimetry stuff supported by the HDMI infoframes, and DP MSA MISC
> > and VSC SDP.
> I was coming from the opposite school of thought. I was thinking 
> 420_only modes should
> be handled carefully, whereas 420_also doesnt need any uapi (This patch 
> series contains
> 420_also and doesnt modify the UAPI) due to following reasons:
> 
> assume there is a mode 3840x2160@60 appears to be in 2 different EDIDs, 
> in first EDID as a 420_only mode
> and in other as 420_also mode.
> - If we add a 420_also mode in the mode_list, userspace might pick it 
> for the modeset as favorite, as most of the
>   420 modes are 4k modes.
> - Now, if userspace doesn't set the hdmi_output property to YCBCR420, 
> and sends a modeset on this mode:
>   - the modeset will be successful in case of a 420_also mode, as it 
> can be supported in RGB/YUV444 also.
>   - the modeset will fail in case of 420_only mode, as this mode 
> cant be supported in any other hdmi output format.
> 
> In this case, addition of 420_only mode, in the connectors->modes list 
> should be done, only when the driver is ready to
> handle the YCBCR420 output, or we have to inform userspace about these 
> modes which need the hdmi_ouput property to
> be set with the modeset, which might in turn need an uabi.
> 
> Does it make a case ?

What I think we want is to automagically enable 4:2:0 output if
userspace picks a 4:2:0 only mode, regardless of the property value.
And in fact this way we don't even need the property to enable the
use of 4:2:0 only modes. Which is great because it means current
userspace can start to use those modes without any code changes.

> - Shashank
> >> can specify its preference, for the HDMI output type.
> >> The output type enums are similar to the mentioned outputs
> >> above. To handle various subsampling of YCBCR output types,
> >> this property allows two special cases:
> >>   - DRM_HDMI_OUTPUT_YCBCR_HQ
> >> This indicates preferred output should be YCBCR output, with highest
> >> subsampling rate by the source/sink, which can be typically:
> >>   - ycbcr444
> >>   - ycbcr422
> >>   - ycbcr420
> >>   - DRM_HDMI_OUTPUT_YCBCR_LQ
> >> This indicates preferred output should be YCBCR output, with lowest
> >> subsampling rate supported by source/sink, which can be:
> >>   - ycbcr420
> >>   - ycbcr422
> >>   - ycbcr444
> >>
> >> Default value of the property is set to 0 = RGB, so no changes if you
> >> dont set the property.
> >>
> >> V2: Added description for the new variable to address build warning
> >>
> >> Cc: Ville Syrjala 
> >> Cc: Jose Abreu 
> >> Cc: Daniel Vetter 
> >> Signed-off-by: Shashank Sharma 
> >> ---
> >>   drivers/gpu/drm/drm_atomic.c|  2 ++
> >>   drivers/gpu/drm/drm_atomic_helper.c |  4 
> >>   drivers/gpu/drm/drm_connector.c | 32 
> >>   include/drm/drm_connector.h | 18 ++
> >>   include/drm/drm_mode_config.h   |  5 +
> >>   5 files changed, 61 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >> index e163701..8c4e040 100644
> >> --- a/drivers/gpu/drm/drm_atomic.c
> >> +++ b/drivers/gpu/drm/drm_atomic.c
> >> @@ -1192,6 +1192,8 @@ int drm_atomic_connector_set_property(struct 
> >> drm_connector *connector,
> >>state->picture_aspect_ratio = val;
> >>} else if (property == connector->scaling_mode_property) {
> >>state->scaling_mode = val;
> >> +  } else if (property == config->hdmi_output_property) {
> >> +  state->hdmi_output = val;
> >>} else if (connector->funcs->atomic_set_property) {
> >>return connector->funcs->atomic_set_property(connector,
> >>state, property, val);
> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> >> b/drivers/gpu/drm/drm_atomic_helper.c
> >> index 636e561..86b1780 100644
> >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> @@ -567,6 +567,10 @@ drm_atomic_helper_check_modeset(struct drm_device 
> >> *dev,
> >>if (old_connector_state->link_status !=
> >>new_connector_state->link_status)
> >>new_crtc_state->connectors_changed = true;
> >> +
> >

[GIT PULL] omapdrm changes for v4.13

[Tomi Valkeinen]

Hi Dave,

Please pull omapdrm changes for v4.13.

 Tomi


The following changes since commit e98c58e55f68f8785aebfab1f8c9a03d8de0afe1:

  Merge tag 'drm-misc-next-2017-05-16' of 
git://anongit.freedesktop.org/git/drm-misc into drm-next (2017-05-18 12:57:06 
+1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git 
tags/omapdrm-4.13

for you to fetch changes up to aff8bd9b716e43cbc6997ea47e5613ab655e4cb3:

  drm/omap: fix tiled buffer stride calculations (2017-05-26 09:42:55 +0300)


omapdrm changes for v4.13

* dmabuf fence support
* TILER rotation fixes
* big pile of various cleanups and refactorings


Laurent Pinchart (24):
  drm: omapdrm: Handle events when enabling/disabling CRTCs
  drm: omapdrm: Use DRM core's atomic commit helper
  drm: omapdrm: Remove legacy buffer synchronization support
  drm: omapdrm: Store the Z order in the plane state zpos field
  drm: omapdrm: Remove custom plane state
  drm: omapdrm: Add zpos property
  drm: omapdrm: Remove remap argument to omap_gem_get_paddr()
  drm: omapdrm: Rename occurrences of paddr to dma_addr
  drm: omapdrm: Rename omap_gem_(get|put)_paddr() to omap_gem_(un)pin()
  drm: omapdrm: Lower indentation level in omap_gem_dma_sync_buffer()
  drm: omapdrm: Rename the omap_gem_object addrs field to dma_addrs
  drm: omapdrm: Rename GEM DMA sync functions
  drm: omapdrm: Fix incorrect usage of the term 'cache coherency'
  drm: omapdrm: DMA-unmap pages for all buffer types when freeing buffers
  drm: omapdrm: Map pages for DMA in DMA_TO_DEVICE direction
  drm: omapdrm: Take GEM object reference when exporting dmabuf
  drm: omapdrm: Remove duplicate error messages when mapping memory
  drm: omapdrm: Drop support for non-DT devices
  drm: omapdrm: Remove unused dss_get_core_pdev() function
  drm: omapdrm: Remove unused default display name support
  drm: omapdrm: Infer the OMAP version from the SoC family
  drm: omapdrm: dpi: Remove platform driver
  drm: omapdrm: sdi: Remove platform driver
  drm/omap: Remove unused omap_dss_find_output() function

Tomi Valkeinen (40):
  drm/omap: add new connector types
  drm/omap: remove unused ovl_enabled()
  drm/omap: remove ovl_set_channel_out
  drm/omap: remove read_irqenable()
  drm/omap: 64bit compile fixes
  drm/omap: define compat_ioctl
  drm/omap: panel-dpi: remove non-DT support
  drm/omap: acx565akm: remove non-DT support
  drm/omap: connector-analog-tv: remove non-DT support
  drm/omap: connector-dvi/hdmi: remove extra include
  drm/omap: sdi: remove legacy set_datapairs
  drm/omap: venc: remove set_type & invert_vid_out_polarity
  drm/omap: remove recommended_bpp
  drm/omap: dpi: remove legacy data_lines
  drm/omap: remove rfbi
  drm/omap: remove unused get_dimensions()
  drm/omap: remove legacy get_resolution
  drm/omap: remove unused fields
  drm/omap: remove omap_overlay & omap_overlay_manager
  drm/omap: fix setting & clearing DOUBLESTRIDE
  drm/omap: remove CLUT
  drm/omap: ratelimit OCP error
  drm/omap: remove dma & vrfb rotation
  drm/omap: cleanup offset calculation
  drm/omap: add format_is_yuv() helper
  drm/omap: remove unneeded prototypes
  drm/omap: change supported_modes to an array
  drm/omap: use u32 instead of enum omap_color_mode
  drm/omap: use DRM_FORMAT_* instead of OMAP_DSS_COLOR_*
  drm/omap: remove omap_framebuffer_get_formats()
  drm/omap: cleanup formats array
  drm/omap: rename color_mode to fourcc
  drm/omap: add drm_rotation_to_tiler helper()
  drm/omap: remove omap_drm_win
  drm/omap: use DRM_ROTATE_* instead of OMAP_DSS_ROT_*
  drm/omap: DRM_REFLECT_* instead of mirror boolean
  drm/omap: pass rotation to dispc
  drm/omap: fix YUV422 rotation with TILER
  drm/omap: fix YUV422 90/270 rotation with mirroring
  drm/omap: fix tiled buffer stride calculations

 .../gpu/drm/omapdrm/displays/connector-analog-tv.c |   51 +-
 drivers/gpu/drm/omapdrm/displays/connector-dvi.c   |3 -
 drivers/gpu/drm/omapdrm/displays/connector-hdmi.c  |3 -
 drivers/gpu/drm/omapdrm/displays/encoder-opa362.c  |   10 -
 drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c  |4 -
 drivers/gpu/drm/omapdrm/displays/panel-dpi.c   |   83 +-
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c|   10 -
 .../omapdrm/displays/panel-lgphilips-lb035q02.c|7 -
 .../drm/omapdrm/displays/panel-nec-nl8048hl11.c|6 -
 .../drm/omapdrm/displays/panel-sharp-ls037v7dw01.c |7 -
 .../drm/omapdrm/displays/panel-sony-acx565akm.c|   49 +-
 .../drm/omapdrm/displays/panel-tpo-td028ttec1.c|5 -
 .../drm/omapdrm/displays/panel-tpo-td043mtea1.c|6 -
 drivers/gpu/drm/

Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

[Alex Deucher]

On Wed, May 31, 2017 at 5:21 AM, Lukas Wunner  wrote:
> On Wed, May 31, 2017 at 10:48:37AM +0200, Florian Echtler wrote:
>> On 30.05.2017 12:54, Lukas Wunner wrote:
>> > On Tue, May 30, 2017 at 11:34:17AM +0200, Florian Echtler wrote:
>> >> On 26.05.2017 23:03, Lukas Wunner wrote:
>> >>> On Fri, May 26, 2017 at 02:13:29PM +0200, Florian Echtler wrote:
>>  I'm running Ubuntu 16.04.2 on a 27" unibody iMac 10,1 from 2009. 
>>  However, even
>>  with the most recent HWE stack (kernel 4.8), the display stays black 
>>  after
>>  suspend. I can ssh into the machine, so wakeup is OK, but the display is
>>  entirely black (backlight stays off).
>> >
>> > So, just to confirm, if you never plug in an external DP source and the 
>> > iMac
>> > comes out of sleep, the display stays black?
>>
>> Correct, verified this just now.
>>
>> > If you log in via ssh and look at dmesg, was radeon able to train the DP
>> > link again?  No error messages, nothing?
>>
>> Here are the relevant dmesg lines after wakeup:
>>
>> [  157.622950] [drm] enabling PCIE gen 2 link speeds, disable with
>> radeon.pcie_gen2=0
>> [  157.626077] [drm] PCIE GART of 1024M enabled (table at 
>> 0x0014C000).
>> [  157.626094] radeon :02:00.0: WB enabled
>> [  157.626097] radeon :02:00.0: fence driver on ring 0 use gpu addr
>> 0x1c00 and cpu addr 0xa1242dfd6c00
>> [  157.626098] radeon :02:00.0: fence driver on ring 3 use gpu addr
>> 0x1c0c and cpu addr 0xa1242dfd6c0c
>> [  157.626315] radeon :02:00.0: fence driver on ring 5 use gpu addr
>> 0x0005c598 and cpu addr 0xbc3081c1c598
>> [  157.672183] [drm] ring test on 0 succeeded in 1 usecs
>> [  157.672187] [drm] ring test on 3 succeeded in 2 usecs
>> [  157.847098] [drm] ring test on 5 succeeded in 1 usecs
>> [  157.847102] [drm] UVD initialized successfully.
>> [  157.847121] [drm] ib test on ring 0 succeeded in 0 usecs
>> [  157.847136] [drm] ib test on ring 3 succeeded in 0 usecs
>> [  158.524061] [drm] ib test on ring 5 succeeded
>
> Hm, try booting with drm.debug=0xf to see if link training for the
> eDP connector succeeds.  If the link cannot be trained, it would
> explain that the screen stays black.  Should this indeed be the
> case, one possible explanation would be that the panel is muxed
> to the external port on resume and an appropriate command needs to
> be sent to the SMC to switch the mux to the radeon card.  This could
> be done in the ->resume_early hook of your APP000C platform driver.
> The apple-gmux driver contains something similar to power the discrete
> GPU down if it was off before suspend (because the BIOS always powers
> it up on resume).
>
> Another possible explanation would be that panel power needs to be
> enabled by writing to the registers which control the pins mentioned
> below.
>
>
>> And this is logged in Xorg.0.log after wakeup:
>>
>> [   229.956] (II) RADEON(0): Allocate new frame buffer 320x200 stride 384
>> [   229.956] (II) RADEON(0): VRAM usage limit set to 219596K
>>
>> xrandr still shows the eDP output as connected and active with 2560x1440 
>> resolution.
>>
>> > Is the panel off or is it on but merely with 0% brightness?
>>
>> The backlight is definitely off. I've tried to shine a torch onto the panel 
>> and
>> see if any content is visible, but it looks like the panel itself is off, 
>> too.
>>
>> > There's a block of pins on the GPU for "system management" which contains
>> > a bunch of GPIO, OEM and reserved pins.  Three of these are used to control
>> > the panel when it's switched to the radeon card:
>> > pin 23 PNL_PWR_EN
>> > pin 25 PNL_BL_EN
>> > pin 27 PNL_BL_PWM
>> >
>> > Basically you'd need to know what these are set to before and after sleep.
>> > I don't know how to access them, presumably via a BAR register.  A quick
>> > look at the RV730-specific registers in drivers/gpu/drm/radeon/*.h did not
>> > yield anything useful, but someone at AMD may be able to find this out.
>>
>> Can I perhaps use radeontool for this? I.e. dump registers before and after
>> sleep and see if there's a difference? Or is radeontool too old to know about
>> the correct registers?
>
> *shrug*  Unfortunately I'm not familiar at all with radeontool. :-(

You can use the radeonreg tool to dump the display registers:
https://cgit.freedesktop.org/~agd5f/radeontool/
radeonreg regs dce3
replace dce3 with whatever dce version your card has.

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

Re: [PATCH v2 05/11] drm: create hdmi output property

[Sharma, Shashank]

Regards

Shashank


On 5/31/2017 6:16 PM, Ville Syrjälä wrote:

On Tue, May 30, 2017 at 10:18:19PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 5/30/2017 10:06 PM, Ville Syrjälä wrote:

On Tue, May 30, 2017 at 05:43:44PM +0530, Shashank Sharma wrote:

HDMI displays can support various output types, based on
the color space and subsampling type. The possible
outputs from a HDMI 2.0 monitor could be:
   - RGB
   - YCBCR 444
   - YCBCR 422
   - YCBCR 420

This patch adds a drm property, using which, a userspace

I think we should add the 4:2:0 only mode support first since that
doesn't require new uapi. The uapi stuff probably needs more careful
thought as we might want to consider exposing more of the
colorimetry stuff supported by the HDMI infoframes, and DP MSA MISC
and VSC SDP.

I was coming from the opposite school of thought. I was thinking
420_only modes should
be handled carefully, whereas 420_also doesnt need any uapi (This patch
series contains
420_also and doesnt modify the UAPI) due to following reasons:

assume there is a mode 3840x2160@60 appears to be in 2 different EDIDs,
in first EDID as a 420_only mode
and in other as 420_also mode.
- If we add a 420_also mode in the mode_list, userspace might pick it
for the modeset as favorite, as most of the
   420 modes are 4k modes.
- Now, if userspace doesn't set the hdmi_output property to YCBCR420,
and sends a modeset on this mode:
   - the modeset will be successful in case of a 420_also mode, as it
can be supported in RGB/YUV444 also.
   - the modeset will fail in case of 420_only mode, as this mode
cant be supported in any other hdmi output format.

In this case, addition of 420_only mode, in the connectors->modes list
should be done, only when the driver is ready to
handle the YCBCR420 output, or we have to inform userspace about these
modes which need the hdmi_ouput property to
be set with the modeset, which might in turn need an uabi.

Does it make a case ?

What I think we want is to automagically enable 4:2:0 output if
userspace picks a 4:2:0 only mode, regardless of the property value.
And in fact this way we don't even need the property to enable the
use of 4:2:0 only modes. Which is great because it means current
userspace can start to use those modes without any code changes.

I was worried about this sitution:
- There is one 420_only mode (38x21@60) in EDID
- We added a 420_only mode in the list, which userspace can see (but 
cant differentiate between non-420 or 420 mode)
- Userspace triggers a modeset on this, but the driver doesn't support 
YCBCR420 output yet, as source doesn't support it yet.


In this case, we will cause modeset failure for each driver which doesnt 
support HDMI 2.0.
So if we have to make a 420_only mode visible to userspace, we have to 
indicate somehow that its 420_only mode.

Do you think so ?

- Shashank

- Shashank

can specify its preference, for the HDMI output type.
The output type enums are similar to the mentioned outputs
above. To handle various subsampling of YCBCR output types,
this property allows two special cases:
   - DRM_HDMI_OUTPUT_YCBCR_HQ
This indicates preferred output should be YCBCR output, with highest
subsampling rate by the source/sink, which can be typically:
   - ycbcr444
   - ycbcr422
   - ycbcr420
   - DRM_HDMI_OUTPUT_YCBCR_LQ
This indicates preferred output should be YCBCR output, with lowest
subsampling rate supported by source/sink, which can be:
   - ycbcr420
   - ycbcr422
   - ycbcr444

Default value of the property is set to 0 = RGB, so no changes if you
dont set the property.

V2: Added description for the new variable to address build warning

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Signed-off-by: Shashank Sharma 
---
   drivers/gpu/drm/drm_atomic.c|  2 ++
   drivers/gpu/drm/drm_atomic_helper.c |  4 
   drivers/gpu/drm/drm_connector.c | 32 
   include/drm/drm_connector.h | 18 ++
   include/drm/drm_mode_config.h   |  5 +
   5 files changed, 61 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index e163701..8c4e040 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1192,6 +1192,8 @@ int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->picture_aspect_ratio = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
+   } else if (property == config->hdmi_output_property) {
+   state->hdmi_output = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 636e561..86b1780 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -

[PULL] topic/dp-quirks for v4.12

[Jani Nikula]

Hi Dave, this series, based on v4.12-rc3, starts a DP sink/branch device
specific quirk database, and uses it to handle conflicting requirements
on the DP Mvid/Nvid main stream attributes by different sinks.

v4.12 has a Mvid/Nvid fix for a common USB Type-C DP adapter (the
DA200), which unfortunately regresses an eDP display. Handle the DA200
as a quirk. Reverting the DA200 fix in v4.12 would presumably have a
wider impact than not reverting, but can't have the regression either.

This was tested by Clint on (at least) the DA200, and Rafael on the
regressing eDP display.

BR,
Jani.

The following changes since commit 5ed02dbb497422bf225783f46e6eadd237d23d6b:

  Linux 4.12-rc3 (2017-05-28 17:20:53 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-intel tags/topic/dp-quirks-2017-05-31

for you to fetch changes up to b31e85eda38c58cae986162ae2c462b53b0a2065:

  drm/i915: Detect USB-C specific dongles before reducing M and N (2017-05-29 
13:43:47 +0300)


DP sink specific quirks


Jani Nikula (4):
  drm/dp: add helper for reading DP sink/branch device desc from DPCD
  drm/i915: use drm DP helper to read DPCD desc
  drm/dp: start a DPCD based DP sink/branch device quirk database
  drm/i915: Detect USB-C specific dongles before reducing M and N

 drivers/gpu/drm/drm_dp_helper.c  | 83 
 drivers/gpu/drm/i915/i915_drv.h  |  3 +-
 drivers/gpu/drm/i915/intel_display.c | 22 ++
 drivers/gpu/drm/i915/intel_dp.c  | 45 +--
 drivers/gpu/drm/i915/intel_dp_mst.c  |  5 ++-
 drivers/gpu/drm/i915/intel_drv.h | 13 +-
 drivers/gpu/drm/i915/intel_lspcon.c  |  2 +-
 include/drm/drm_dp_helper.h  | 51 ++
 8 files changed, 166 insertions(+), 58 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PULL] topic/e1000e-fix

[David Miller]

From: Daniel Vetter 
Date: Wed, 31 May 2017 08:10:45 +0200

> On Wed, May 31, 2017 at 7:54 AM, Daniel Vetter  wrote:
>> On Wed, May 31, 2017 at 1:06 AM, Dave Airlie  wrote:
>>> On 31 May 2017 at 08:10, David Miller  wrote:
 From: Daniel Vetter 
 Date: Tue, 30 May 2017 22:15:42 +0200

> If the e1000e maintainer wants to coalesce or not return statements
> this simple way, that's imo on him to change the color as needed.

 That's not how things work.

 If the maintainer wants you to style things a certain way, either you
 do it that way or your patch isn't accepted.
>>
>> Consider this pull a regression report, pls handle it.
> 
> And I guess I pile of more cc, to make this regression report
> complete. I mean you got the backtrace, bisect and a proposed fix, and
> the almost-whitespace change demanded is something gcc does in its
> sleep. I'd understand a request to retest if it would be a real
> functional change, but in this situation I have no idea why this
> regression just can't be fixed already.

And we can't understand why respinning with the requested change is
less work than making several postings such as this one.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm 2/2] headers: sync drm_sarea.h with airlied/drm-next

[Eric Engestrom]

Adds the C++ extern guards from
ebbb0e5cfd2ceb1150b1 drm: add extern C guard for the UAPI headers

Generated using `make headers_install` from airlied/drm-next
at commit 2a1720376adda5ecf8e636fbfb05339c7dad1c55

Signed-off-by: Eric Engestrom 
---
 include/drm/drm_sarea.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h
index 502934ed..93025be8 100644
--- a/include/drm/drm_sarea.h
+++ b/include/drm/drm_sarea.h
@@ -34,6 +34,10 @@
 
 #include "drm.h"
 
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
 /* SAREA area needs to be at least a page */
 #if defined(__alpha__)
 #define SAREA_MAX   0x2000U
@@ -81,4 +85,8 @@ typedef struct drm_sarea_drawable drm_sarea_drawable_t;
 typedef struct drm_sarea_frame drm_sarea_frame_t;
 typedef struct drm_sarea drm_sarea_t;
 
+#if defined(__cplusplus)
+}
+#endif
+
 #endif /* _DRM_SAREA_H_ */
-- 
Cheers,
  Eric

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

[PATCH libdrm 1/2] headers: sync drm_fourcc.h with airlied/drm-next

[Eric Engestrom]

This adds a bunch of modifiers stuff, as well as a few new formats.
Includes the following changes:
ebbb0e5cfd2ceb1150b1 drm: add extern C guard for the UAPI headers
b9fb2a21ac8058965a6b drm_fourcc: Document linear modifier
af913418261d6d3e7a29 drm_fourcc: Fix DRM_FORMAT_MOD_LINEAR #define
fd056f05b9fcba35b77e drm: add fourcc codes for 16bit R and RG
73f1a5858bf82f3bf232 drm/fourcc: add vivante tiled layout format modifiers
ba2b5277dc52cc96944d drm: add RGB formats with separate alpha plane
5e91144dd702d068b22a drm/tegra: Add tiling FB modifiers

Generated using `make headers_install` from airlied/drm-next
at commit 2a1720376adda5ecf8e636fbfb05339c7dad1c55

Signed-off-by: Eric Engestrom 
---
 include/drm/drm_fourcc.h | 126 +++
 1 file changed, 126 insertions(+)

diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 4d8da699..55e30104 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -26,6 +26,10 @@
 
 #include "drm.h"
 
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
 #define fourcc_code(a, b, c, d) ((__u32)(a) | ((__u32)(b) << 8) | \
 ((__u32)(c) << 16) | ((__u32)(d) << 24))
 
@@ -37,10 +41,17 @@
 /* 8 bpp Red */
 #define DRM_FORMAT_R8  fourcc_code('R', '8', ' ', ' ') /* [7:0] R */
 
+/* 16 bpp Red */
+#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15:0] R 
little endian */
+
 /* 16 bpp RG */
 #define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /* 
[15:0] R:G 8:8 little endian */
 #define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /* 
[15:0] G:R 8:8 little endian */
 
+/* 32 bpp RG */
+#define DRM_FORMAT_RG1616  fourcc_code('R', 'G', '3', '2') /* [31:0] R:G 
16:16 little endian */
+#define DRM_FORMAT_GR1616  fourcc_code('G', 'R', '3', '2') /* [31:0] G:R 
16:16 little endian */
+
 /* 8 bpp RGB */
 #define DRM_FORMAT_RGB332  fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B 
3:3:2 */
 #define DRM_FORMAT_BGR233  fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R 
2:3:3 */
@@ -103,6 +114,20 @@
 #define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /* 
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
 
 /*
+ * 2 plane RGB + A
+ * index 0 = RGB plane, same format as the corresponding non _A8 format has
+ * index 1 = A plane, [7:0] A
+ */
+#define DRM_FORMAT_XRGB_A8 fourcc_code('X', 'R', 'A', '8')
+#define DRM_FORMAT_XBGR_A8 fourcc_code('X', 'B', 'A', '8')
+#define DRM_FORMAT_RGBX_A8 fourcc_code('R', 'X', 'A', '8')
+#define DRM_FORMAT_BGRX_A8 fourcc_code('B', 'X', 'A', '8')
+#define DRM_FORMAT_RGB888_A8   fourcc_code('R', '8', 'A', '8')
+#define DRM_FORMAT_BGR888_A8   fourcc_code('B', '8', 'A', '8')
+#define DRM_FORMAT_RGB565_A8   fourcc_code('R', '5', 'A', '8')
+#define DRM_FORMAT_BGR565_A8   fourcc_code('B', '5', 'A', '8')
+
+/*
  * 2 plane YCbCr
  * index 0 = Y plane, [7:0] Y
  * index 1 = Cr:Cb plane, [15:0] Cr:Cb little endian
@@ -150,11 +175,13 @@
 
 /* Vendor Ids: */
 #define DRM_FORMAT_MOD_NONE   0
+#define DRM_FORMAT_MOD_VENDOR_NONE0
 #define DRM_FORMAT_MOD_VENDOR_INTEL   0x01
 #define DRM_FORMAT_MOD_VENDOR_AMD 0x02
 #define DRM_FORMAT_MOD_VENDOR_NV  0x03
 #define DRM_FORMAT_MOD_VENDOR_SAMSUNG 0x04
 #define DRM_FORMAT_MOD_VENDOR_QCOM0x05
+#define DRM_FORMAT_MOD_VENDOR_VIVANTE 0x06
 /* add more to the end as needed */
 
 #define fourcc_mod_code(vendor, val) \
@@ -168,6 +195,16 @@
  * authoritative source for all of these.
  */
 
+/*
+ * Linear Layout
+ *
+ * Just plain linear layout. Note that this is different from no specifying any
+ * modifier (e.g. not setting DRM_MODE_FB_MODIFIERS in the DRM_ADDFB2 ioctl),
+ * which tells the driver to also take driver-internal information into account
+ * and so might actually result in a tiled framebuffer.
+ */
+#define DRM_FORMAT_MOD_LINEAR  fourcc_mod_code(NONE, 0)
+
 /* Intel framebuffer modifiers */
 
 /*
@@ -229,4 +266,93 @@
  */
 #define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE  fourcc_mod_code(SAMSUNG, 1)
 
+/* Vivante framebuffer modifiers */
+
+/*
+ * Vivante 4x4 tiling layout
+ *
+ * This is a simple tiled layout using tiles of 4x4 pixels in a row-major
+ * layout.
+ */
+#define DRM_FORMAT_MOD_VIVANTE_TILED   fourcc_mod_code(VIVANTE, 1)
+
+/*
+ * Vivante 64x64 super-tiling layout
+ *
+ * This is a tiled layout using 64x64 pixel super-tiles, where each super-tile
+ * contains 8x4 groups of 2x4 tiles of 4x4 pixels (like above) each, all in 
row-
+ * major layout.
+ *
+ * For more information: see
+ * 
https://github.com/etnaviv/etna_viv/blob/master/doc/hardware.md#texture-tiling
+ */
+#define DRM_FORMAT_MOD_VIVANTE_SUPER_TILED fourcc_mod_code(VIVANTE, 2)
+
+/*
+ * Vivante 4x4 tiling layout for dual-pipe
+ *
+ * Same as the 4x4 tiling layout, except every second 4x4 pixel tile starts at 
a
+ * different base address. Offsets from the base addresses are therefore halved
+ * compared to the non-split tiled layou

[Bug 98145] X modesetting problem on dell laptop

[bugzilla-daemon]

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

--- Comment #6 from Klaus Kusche  ---
(In reply to Henri Kemppainen from comment #4)
> Klaus if you're still around, you could try a workaround to test the theory.
> See next attachment.

I'll try to test it, but it will take some days.

-- 
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 02/11] drm/edid: Complete CEA modedb(VIC 1-107)

[Sharma, Shashank]

Regards

Shashank


On 5/31/2017 6:09 PM, Ville Syrjälä wrote:

On Tue, May 30, 2017 at 09:56:56PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 5/30/2017 9:48 PM, Ville Syrjälä wrote:

On Tue, May 30, 2017 at 05:43:41PM +0530, Shashank Sharma wrote:

CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.

Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse new CEA modes using the existing methods, we have
to complete the modedb (VIC=65 onwards).

This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).

Still missing the "native bit" handling.

I tried searching the native bit handling in the code, but I could not
get any thing. We are typically doing a (vic & 127) and that's all.

And that's not really correct. We shouldn't discard the msb until we've
checked that we're in the correct range of VICs that have the native
bit. drm_display_mode_from_vic_index() is the place where we should be
checking this I think.
Yep, Even I looked into these function only for the native mode 
processing, But looks like

all its doing is:
vic = (video_db[video_index] & 127);

- Shashank

Can you please point out a bit here ?

- Shashank

The patch was originaly discussed and reviewed here:
https://patchwork.freedesktop.org/patch/135810/

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Andrzej Hajda 
Cc: Alex Deucher 
Cc: Harry Wentland 

V2: Rebase

Reviewed-by: Jose Abreu 
Reviewed-by: Alex Deucher 
Acked-by: Harry Wentland 
Signed-off-by: Shashank Sharma 
---
   drivers/gpu/drm/drm_edid.c | 215 
+
   1 file changed, 215 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 8b23435..c3fa3a1 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1006,6 +1006,221 @@ static const struct drm_display_mode edid_cea_modes[] = 
{
   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 65 - 1280x720@24Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 66 - 1280x720@25Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+  3740, 3960, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 67 - 1280x720@30Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 68 - 1280x720@50Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 69 - 1280x720@60Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 70 - 1280x720@100Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 71 - 1280x720@120Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 72 - 1920x1080@24Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
+  2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 73 - 1920x1080@25Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_

Re: [PATCH v2 01/11] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Sharma, Shashank]

Regards

Shashank


On 5/31/2017 6:11 PM, Ville Syrjälä wrote:

On Tue, May 30, 2017 at 10:00:12PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 5/30/2017 9:43 PM, Ville Syrjälä wrote:

On Tue, May 30, 2017 at 05:43:40PM +0530, Shashank Sharma wrote:

HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).

This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.

This patch touches all drm drivers, who are callers of this function
drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
no change in current behavior, is_hdmi2 is kept as false.

In case of I915 driver, this patch checks the connector->display_info
to check if the connected display is HDMI 2.0.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Andrzej Hajda 
Cc: Alex Deucher 
Cc: Daniel Vetter 

PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c

V2: Rebase, Added r-b from Andrzej

Reviewed-by: Andrzej Hajda 
Signed-off-by: Shashank Sharma 
---
   drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
   drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
   drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
   drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
   drivers/gpu/drm/bridge/sii902x.c  |  2 +-
   drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
   drivers/gpu/drm/drm_edid.c| 12 +++-
   drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
   drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
   drivers/gpu/drm/i915/intel_hdmi.c |  5 -
   drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
   drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
   drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
   drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
   drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
   drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
   drivers/gpu/drm/tegra/hdmi.c  |  2 +-
   drivers/gpu/drm/tegra/sor.c   |  2 +-
   drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
   drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
   include/drm/drm_edid.h|  3 ++-
   21 files changed, 38 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 3c62c45..4923ddc 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -1864,7 +1864,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v10_0_audio_write_sad_regs(encoder);
dce_v10_0_audio_write_latency_fields(encoder, mode);
   
-	err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);

+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index c8ed0fa..4101684 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -1848,7 +1848,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v11_0_audio_write_sad_regs(encoder);
dce_v11_0_audio_write_latency_fields(encoder, mode);
   
-	err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);

+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index 3e90c19..a7f6b32 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -1747,7 +1747,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v8_0_audio_write_sad_regs(encoder);
dce_v8_0_audio_write_latency_fields(encoder, mode);
   
-	err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);

+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index a2a8236..f9b77b8 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -1097,7 +1097,8 @@ static void anx78xx_bridge_mode_set(struct drm_bridge 
*bridge,
   
   	mutex_lock(&anx78xx->lock);
   
-	err = drm_hdmi_avi_infoframe_from_display_mode(&frame, adjusted

Re: [PULL] topic/e1000e-fix

[Jani Nikula]

On Wed, 31 May 2017, David Miller  wrote:
> And we can't understand why respinning with the requested change is
> less work than making several postings such as this one.

When our CI hits tons of non-drm issues every merge window, I imagine
our developers can start to get a little frustrated trying to get them
fixed. Especially so when valid fixes like this get blocked by silly
bikesheds from developers who don't even seem to have very many
contributions upstream, and the maintainers don't respond. We have
enough on our plates trying to get our own stuff fixed.

While I understand why our developers aren't willing to jump through all
the hoops, updated patch follows. Please let's move on.

BR,
Jani.


Chris Wilson (1):
  e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

 drivers/net/ethernet/intel/e1000e/netdev.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

-- 
2.11.0

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

[PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

[Jani Nikula]

From: Chris Wilson 

An error during suspend (e100e_pm_suspend),

[  429.994338] ACPI : EC: event blocked
[  429.994633] e1000e: EEE TX LPI TIMER: 0011
[  430.955451] pci_pm_suspend(): e1000e_pm_suspend+0x0/0x30 [e1000e] returns -2
[  430.955454] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -2
[  430.955458] PM: Device :00:19.0 failed to suspend async: error -2
[  430.955581] PM: Some devices failed to suspend, or early wake event detected
[  430.957709] ACPI : EC: event unblocked

lead to complete failure:

[  432.585002] [ cut here ]
[  432.585013] WARNING: CPU: 3 PID: 8372 at kernel/irq/manage.c:1478 
__free_irq+0x9f/0x280
[  432.585015] Trying to free already-free IRQ 20
[  432.585016] Modules linked in: cdc_ncm usbnet x86_pkg_temp_thermal 
intel_powerclamp coretemp mii crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel 
snd_hda_codec snd_hwdep lpc_ich snd_hda_core snd_pcm mei_me mei sdhci_pci sdhci 
i915 mmc_core e1000e ptp pps_core prime_numbers
[  432.585042] CPU: 3 PID: 8372 Comm: kworker/u16:40 Tainted: G U  
4.10.0-rc8-CI-Patchwork_3870+ #1
[  432.585044] Hardware name: LENOVO 2356GCG/2356GCG, BIOS G7ET31WW (1.13 ) 
07/02/2012
[  432.585050] Workqueue: events_unbound async_run_entry_fn
[  432.585051] Call Trace:
[  432.585058]  dump_stack+0x67/0x92
[  432.585062]  __warn+0xc6/0xe0
[  432.585065]  warn_slowpath_fmt+0x4a/0x50
[  432.585070]  ? _raw_spin_lock_irqsave+0x49/0x60
[  432.585072]  __free_irq+0x9f/0x280
[  432.585075]  free_irq+0x34/0x80
[  432.585089]  e1000_free_irq+0x65/0x70 [e1000e]
[  432.585098]  e1000e_pm_freeze+0x7a/0xb0 [e1000e]
[  432.585106]  e1000e_pm_suspend+0x21/0x30 [e1000e]
[  432.585113]  pci_pm_suspend+0x71/0x140
[  432.585118]  dpm_run_callback+0x6f/0x330
[  432.585122]  ? pci_pm_freeze+0xe0/0xe0
[  432.585125]  __device_suspend+0xea/0x330
[  432.585128]  async_suspend+0x1a/0x90
[  432.585132]  async_run_entry_fn+0x34/0x160
[  432.585137]  process_one_work+0x1f4/0x6d0
[  432.585140]  ? process_one_work+0x16e/0x6d0
[  432.585143]  worker_thread+0x49/0x4a0
[  432.585145]  kthread+0x107/0x140
[  432.585148]  ? process_one_work+0x6d0/0x6d0
[  432.585150]  ? kthread_create_on_node+0x40/0x40
[  432.585154]  ret_from_fork+0x2e/0x40
[  432.585156] ---[ end trace 6712df7f8c4b9124 ]---

The unwind failures stems from commit 2800209994f8 ("e1000e: Refactor PM
flows"), but it may be a later patch that introduced the non-recoverable
behaviour.

Fixes: 2800209994f8 ("e1000e: Refactor PM flows")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99847
Cc: Tvrtko Ursulin 
Cc: Jeff Kirsher 
Cc: Dave Ertman 
Cc: Bruce Allan 
Cc: intel-wired-...@lists.osuosl.org
Cc: net...@vger.kernel.org
Signed-off-by: Chris Wilson 
[Jani: bikeshed repainted]
Signed-off-by: Jani Nikula 
---
 drivers/net/ethernet/intel/e1000e/netdev.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
b/drivers/net/ethernet/intel/e1000e/netdev.c
index b3679728caac..5cad688be609 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -6630,12 +6630,17 @@ static int e1000e_pm_thaw(struct device *dev)
 static int e1000e_pm_suspend(struct device *dev)
 {
struct pci_dev *pdev = to_pci_dev(dev);
+   int rc;
 
e1000e_flush_lpic(pdev);
 
e1000e_pm_freeze(dev);
 
-   return __e1000_shutdown(pdev, false);
+   rc = __e1000_shutdown(pdev, false);
+   if (rc)
+   e1000e_pm_thaw(dev);
+
+   return rc;
 }
 
 static int e1000e_pm_resume(struct device *dev)
-- 
2.11.0

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

Re: [PULL] topic/e1000e-fix

[Daniel Vetter]

On Wed, May 31, 2017 at 5:08 PM, David Miller  wrote:
> From: Daniel Vetter 
> Date: Wed, 31 May 2017 08:10:45 +0200
>
>> On Wed, May 31, 2017 at 7:54 AM, Daniel Vetter  
>> wrote:
>>> On Wed, May 31, 2017 at 1:06 AM, Dave Airlie  wrote:
 On 31 May 2017 at 08:10, David Miller  wrote:
> From: Daniel Vetter 
> Date: Tue, 30 May 2017 22:15:42 +0200
>
>> If the e1000e maintainer wants to coalesce or not return statements
>> this simple way, that's imo on him to change the color as needed.
>
> That's not how things work.
>
> If the maintainer wants you to style things a certain way, either you
> do it that way or your patch isn't accepted.
>>>
>>> Consider this pull a regression report, pls handle it.
>>
>> And I guess I pile of more cc, to make this regression report
>> complete. I mean you got the backtrace, bisect and a proposed fix, and
>> the almost-whitespace change demanded is something gcc does in its
>> sleep. I'd understand a request to retest if it would be a real
>> functional change, but in this situation I have no idea why this
>> regression just can't be fixed already.
>
> And we can't understand why respinning with the requested change is
> less work than making several postings such as this one.

I guess next time around we should do even less, i.e. report the
regression + bisect and then escalate this until the netdev folks fix
it on their own?

Like Jani said every -rc1 a pile of our CI machines keel over, and
unfortunately this patch here isn't the only one which seems to not
really move anywhere.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 16/37] drm/hdlcd|mali: Drop drm_vblank_cleanup

[Liviu Dudau]

On Wed, May 24, 2017 at 04:51:51PM +0200, Daniel Vetter wrote:
> IRQs are properly shut down, so it almost works as race-free shutdown.
> Except the irq is stopped after the vblank stuff, so boom anyway.
> Proper way would be to call drm_atomic_helper_shutdown before any of
> the kms things gets stopped. So no harm in removing the
> drm_vblank_cleanup here really.
> 
> Same story for both hdlcd and mali.
> 
> v2: Move misplaced malidp hunk to this patch (Liviu).
> 
> Cc: Liviu Dudau 
> Cc: Brian Starkey 
> Signed-off-by: Daniel Vetter 

On the assumption that a subsequent patch will fix the issue highlighted in
the commit message (doesn't have to be part of this series):

Acked-by: Liviu Dudau 

I'm assuming that you are going to carry this patch through one of your trees,
so I will not pull it into mali-dp tree.

Thanks,
Liviu

> ---
>  drivers/gpu/drm/arm/hdlcd_drv.c  | 2 --
>  drivers/gpu/drm/arm/malidp_drv.c | 2 --
>  2 files changed, 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index 0f49c4b12772..345c8357b273 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -340,7 +340,6 @@ static int hdlcd_drm_bind(struct device *dev)
>   }
>  err_fbdev:
>   drm_kms_helper_poll_fini(drm);
> - drm_vblank_cleanup(drm);
>  err_vblank:
>   pm_runtime_disable(drm->dev);
>  err_pm_active:
> @@ -368,7 +367,6 @@ static void hdlcd_drm_unbind(struct device *dev)
>   }
>   drm_kms_helper_poll_fini(drm);
>   component_unbind_all(dev, drm);
> - drm_vblank_cleanup(drm);
>   pm_runtime_get_sync(drm->dev);
>   drm_irq_uninstall(drm);
>   pm_runtime_put_sync(drm->dev);
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 0d3eb537d08b..01b13d219917 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -652,7 +652,6 @@ static int malidp_bind(struct device *dev)
>   drm_kms_helper_poll_fini(drm);
>  fbdev_fail:
>   pm_runtime_get_sync(dev);
> - drm_vblank_cleanup(drm);
>  vblank_fail:
>   malidp_se_irq_fini(drm);
>   malidp_de_irq_fini(drm);
> @@ -692,7 +691,6 @@ static void malidp_unbind(struct device *dev)
>   }
>   drm_kms_helper_poll_fini(drm);
>   pm_runtime_get_sync(dev);
> - drm_vblank_cleanup(drm);
>   malidp_se_irq_fini(drm);
>   malidp_de_irq_fini(drm);
>   component_unbind_all(dev, drm);
> -- 
> 2.11.0
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 16/37] drm/hdlcd|mali: Drop drm_vblank_cleanup

[Daniel Vetter]

On Wed, May 31, 2017 at 1:22 PM, Liviu Dudau  wrote:
> On Wed, May 31, 2017 at 01:03:34PM +0200, Daniel Vetter wrote:
>> On Wed, May 31, 2017 at 12:57 PM, Liviu Dudau  wrote:
>> > On Wed, May 24, 2017 at 04:51:51PM +0200, Daniel Vetter wrote:
>> >> IRQs are properly shut down, so it almost works as race-free shutdown.
>> >> Except the irq is stopped after the vblank stuff, so boom anyway.
>> >> Proper way would be to call drm_atomic_helper_shutdown before any of
>> >> the kms things gets stopped. So no harm in removing the
>> >> drm_vblank_cleanup here really.
>> >
>> > Slightly confused on the implied message in the commit text: is "Proper way
>> > would be to call drm_atomic_helper_shutdown" a hint? A promise of a future
>> > patch? A message to the future us on how to fix things if they blow up?
>> >
>> > If calling drm_atomic_helper_shutdown() is the proper thing to do, why 
>> > does the
>> > patch (and the series) avoids doing that? Lack of understanding of the 
>> > driver's
>> > internal workings? Then I want to help, if I can understand the new 
>> > direction.
>>
>> Yes, I wanted to not make things worse. If you look at the overall
>> result (especially last patch) I'm also trying to better document
>> stuff in the vblank area, but summarized, if you want to make sure
>> that vblank processing has stopped, you need to call drm_vblank_off on
>> each active crtc. The simplest way to get that is by using
>> drm_atomic_helper_shutdown(). Calling drm_vblank_cleanup doesn't
>> really do anything useful (see the last patch for the only valid
>> usecase there ever was).
>
> OK, so there should be a follow up patch adding drm_atomic_helper_shutdown(). 
> I guess
> I need to call dibs on it? :)

I googled what "to call dibs on smth" means and still can't figure out
what you mean here. Can you pls explain?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 16/37] drm/hdlcd|mali: Drop drm_vblank_cleanup

[Liviu Dudau]

On Wed, May 31, 2017 at 06:41:05PM +0200, Daniel Vetter wrote:
> On Wed, May 31, 2017 at 1:22 PM, Liviu Dudau  wrote:
> > On Wed, May 31, 2017 at 01:03:34PM +0200, Daniel Vetter wrote:
> >> On Wed, May 31, 2017 at 12:57 PM, Liviu Dudau  wrote:
> >> > On Wed, May 24, 2017 at 04:51:51PM +0200, Daniel Vetter wrote:
> >> >> IRQs are properly shut down, so it almost works as race-free shutdown.
> >> >> Except the irq is stopped after the vblank stuff, so boom anyway.
> >> >> Proper way would be to call drm_atomic_helper_shutdown before any of
> >> >> the kms things gets stopped. So no harm in removing the
> >> >> drm_vblank_cleanup here really.
> >> >
> >> > Slightly confused on the implied message in the commit text: is "Proper 
> >> > way
> >> > would be to call drm_atomic_helper_shutdown" a hint? A promise of a 
> >> > future
> >> > patch? A message to the future us on how to fix things if they blow up?
> >> >
> >> > If calling drm_atomic_helper_shutdown() is the proper thing to do, why 
> >> > does the
> >> > patch (and the series) avoids doing that? Lack of understanding of the 
> >> > driver's
> >> > internal workings? Then I want to help, if I can understand the new 
> >> > direction.
> >>
> >> Yes, I wanted to not make things worse. If you look at the overall
> >> result (especially last patch) I'm also trying to better document
> >> stuff in the vblank area, but summarized, if you want to make sure
> >> that vblank processing has stopped, you need to call drm_vblank_off on
> >> each active crtc. The simplest way to get that is by using
> >> drm_atomic_helper_shutdown(). Calling drm_vblank_cleanup doesn't
> >> really do anything useful (see the last patch for the only valid
> >> usecase there ever was).
> >
> > OK, so there should be a follow up patch adding 
> > drm_atomic_helper_shutdown(). I guess
> > I need to call dibs on it? :)
> 
> I googled what "to call dibs on smth" means and still can't figure out
> what you mean here. Can you pls explain?

Means I put my name on it. Urban dictionary on "call dibs" gives it a very 
gender
specific usage, my intent was to convey the message that I will take it on my 
TODO list.

Best regards,
Liviu

> 
> Thanks, Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] gma500: Fix a sleep-in-atomic bug in psbfb_2d_submit

[Jia-Ju Bai]

The driver may sleep under a spin lock, and the function call path is:
psbfb_2d_submit (acquire the lock by spin_lock_irqsave)
  psb_2d_wait_available
psb_spank
  msleep --> may sleep

To fix it, the "msleep" is replaced with "mdelay" in psb_spank.

Signed-off-by: Jia-Ju Bai 
---
 drivers/gpu/drm/gma500/accel_2d.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/gma500/accel_2d.c 
b/drivers/gpu/drm/gma500/accel_2d.c
index c51d925..7c24c8a 100644
--- a/drivers/gpu/drm/gma500/accel_2d.c
+++ b/drivers/gpu/drm/gma500/accel_2d.c
@@ -55,7 +55,7 @@ void psb_spank(struct drm_psb_private *dev_priv)
_PSB_CS_RESET_TWOD_RESET, PSB_CR_SOFT_RESET);
PSB_RSGX32(PSB_CR_SOFT_RESET);
 
-   msleep(1);
+   mdelay(1);
 
PSB_WSGX32(0, PSB_CR_SOFT_RESET);
wmb();
@@ -64,7 +64,7 @@ void psb_spank(struct drm_psb_private *dev_priv)
wmb();
(void) PSB_RSGX32(PSB_CR_BIF_CTRL);
 
-   msleep(1);
+   mdelay(1);
PSB_WSGX32(PSB_RSGX32(PSB_CR_BIF_CTRL) & ~_PSB_CB_CTRL_CLEAR_FAULT,
   PSB_CR_BIF_CTRL);
(void) PSB_RSGX32(PSB_CR_BIF_CTRL);
-- 
1.7.9.5


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

Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

[Florian Echtler]

On 30.05.2017 12:54, Lukas Wunner wrote:
> On Tue, May 30, 2017 at 11:34:17AM +0200, Florian Echtler wrote:
>> On 26.05.2017 23:03, Lukas Wunner wrote:
>>> On Fri, May 26, 2017 at 02:13:29PM +0200, Florian Echtler wrote:
 I'm running Ubuntu 16.04.2 on a 27" unibody iMac 10,1 from 2009. However, 
 even
 with the most recent HWE stack (kernel 4.8), the display stays black after
 suspend. I can ssh into the machine, so wakeup is OK, but the display is
 entirely black (backlight stays off).
> 
> So, just to confirm, if you never plug in an external DP source and the iMac
> comes out of sleep, the display stays black?

Correct, verified this just now.

> If you log in via ssh and look at dmesg, was radeon able to train the DP
> link again?  No error messages, nothing?

Here are the relevant dmesg lines after wakeup:

[  157.622950] [drm] enabling PCIE gen 2 link speeds, disable with
radeon.pcie_gen2=0
[  157.626077] [drm] PCIE GART of 1024M enabled (table at 0x0014C000).
[  157.626094] radeon :02:00.0: WB enabled
[  157.626097] radeon :02:00.0: fence driver on ring 0 use gpu addr
0x1c00 and cpu addr 0xa1242dfd6c00
[  157.626098] radeon :02:00.0: fence driver on ring 3 use gpu addr
0x1c0c and cpu addr 0xa1242dfd6c0c
[  157.626315] radeon :02:00.0: fence driver on ring 5 use gpu addr
0x0005c598 and cpu addr 0xbc3081c1c598
[  157.672183] [drm] ring test on 0 succeeded in 1 usecs
[  157.672187] [drm] ring test on 3 succeeded in 2 usecs
[  157.847098] [drm] ring test on 5 succeeded in 1 usecs
[  157.847102] [drm] UVD initialized successfully.
[  157.847121] [drm] ib test on ring 0 succeeded in 0 usecs
[  157.847136] [drm] ib test on ring 3 succeeded in 0 usecs
[  158.524061] [drm] ib test on ring 5 succeeded

And this is logged in Xorg.0.log after wakeup:

[   229.956] (II) RADEON(0): Allocate new frame buffer 320x200 stride 384
[   229.956] (II) RADEON(0): VRAM usage limit set to 219596K

xrandr still shows the eDP output as connected and active with 2560x1440 
resolution.

> Is the panel off or is it on but merely with 0% brightness?

The backlight is definitely off. I've tried to shine a torch onto the panel and
see if any content is visible, but it looks like the panel itself is off, too.

> There's a block of pins on the GPU for "system management" which contains
> a bunch of GPIO, OEM and reserved pins.  Three of these are used to control
> the panel when it's switched to the radeon card:
> pin 23   PNL_PWR_EN
> pin 25   PNL_BL_EN
> pin 27   PNL_BL_PWM
> 
> Basically you'd need to know what these are set to before and after sleep.
> I don't know how to access them, presumably via a BAR register.  A quick
> look at the RV730-specific registers in drivers/gpu/drm/radeon/*.h did not
> yield anything useful, but someone at AMD may be able to find this out.

Can I perhaps use radeontool for this? I.e. dump registers before and after
sleep and see if there's a difference? Or is radeontool too old to know about
the correct registers?

Best, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL




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

Re: [Intel-gfx] [PATCH v10 3/3] drm/i915: Set PWM divider to match desired frequency in vbt

[Pandiyan, Dhinakaran]

The patch looks good overall, it would have been easier to merge if
you'd sent this as the first patch in this version. Some comments
inline.



On Fri, 2017-05-26 at 18:42 -0700, Puthikorn Voravootivat wrote:
> Read desired PWM frequency from panel vbt and calculate the
> value for divider in DPCD address 0x724 and 0x728 to have
> as many bits as possible for PWM duty cyle for granularity of
> brightness adjustment while the frequency divisor is still
> within 25% of the desired value.
> 
> Signed-off-by: Puthikorn Voravootivat 
> ---
>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 79 
> +++
>  1 file changed, 79 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index f55af41ce3bd..a8d485a29f29 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -116,6 +116,81 @@ intel_dp_aux_set_dynamic_backlight_percent(struct 
> intel_dp *intel_dp,
>   }
>  }
>  
> +/*
> + * Set PWM Frequency divider to match desired frequency in vbt.
> + * The PWM Frequency is calculated as 27Mhz / (F x P).
> + * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
> + * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
> + * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
> + * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
> + */
> +static int intel_dp_aux_set_pwm_freq(struct intel_connector *connector)
> +{
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base);
> + int freq, fxp, fxp_min, fxp_max, fxp_actual, f = 1;

nit: unnecessary initialization for f?

> + u8 pn, pn_min, pn_max;
> +
> + /* Find desired value of (F x P)
> +  * Note that, if F x P is out of supported range, the maximum value or
> +  * minimum value will applied automatically. So no need to check that.
> +  */
> + freq = dev_priv->vbt.backlight.pwm_freq_hz;
> + DRM_DEBUG_KMS("VBT defined backlight frequency %u Hz\n", freq);
> + if (!freq) {
> + DRM_DEBUG_KMS("Use panel default backlight frequency\n");
> + return -1;
> + }
> +
> + fxp = DIV_ROUND_CLOSEST(KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ), freq);
> +
> + /* Use highest possible value of Pn for more granularity of brightness
> +  * adjustment while satifying the conditions below.
> +  * - Pn is in the range of Pn_min and Pn_max
> +  * - F is in the range of 1 and 255
> +  * - FxP is within 25% of desired value.
> +  *   Note: 25% is arbitrary value and may need some tweak.
> +  */
> + if (drm_dp_dpcd_readb(&intel_dp->aux,
> +DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN, &pn_min) != 1) {
> + DRM_DEBUG_KMS("Failed to read pwmgen bit count cap min\n");
> + return -EIO;

The error numbers are not propagated outside, so I don't see a real need
for them. bool should suffice.


> + }
> + if (drm_dp_dpcd_readb(&intel_dp->aux,
> +DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX, &pn_max) != 1) {
> + DRM_DEBUG_KMS("Failed to read pwmgen bit count cap max\n");
> + return -EIO;
> + }
> + pn_min &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
> + pn_max &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
> +
> + fxp_min = DIV_ROUND_CLOSEST(fxp * 3, 4);
> + fxp_max = DIV_ROUND_CLOSEST(fxp * 5, 4);
> + if (fxp_min < (1 << pn_min) || (255 << pn_max) < fxp_max) {
> + DRM_DEBUG_KMS("VBT defined backlight frequency out of range\n");
> + return -ERANGE;
> + }
> +
> + for (pn = pn_max; pn >= pn_min; pn--) {
> + f = clamp(DIV_ROUND_CLOSEST(fxp, 1 << pn), 1, 255);
> + fxp_actual = f << pn;
> + if (fxp_min <= fxp_actual && fxp_actual <= fxp_max)
> + break;
> + }
> +
> + if (drm_dp_dpcd_writeb(&intel_dp->aux,
> +DP_EDP_PWMGEN_BIT_COUNT, pn) < 0) {
> + DRM_DEBUG_KMS("Failed to write aux pwmgen bit count\n");
> + return -EIO;
> + }
> + if (drm_dp_dpcd_writeb(&intel_dp->aux,
> +DP_EDP_BACKLIGHT_FREQ_SET, (u8) f) < 0) {
> + DRM_DEBUG_KMS("Failed to write aux backlight freq\n");
> + return -EIO;
> + }
> + return 0;
> +}
> +
>  static void intel_dp_aux_enable_backlight(struct intel_connector *connector)
>  {
>   struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base);
> @@ -152,6 +227,10 @@ static void intel_dp_aux_enable_backlight(struct 
> intel_connector *connector)
>   DRM_DEBUG_KMS("Enable dynamic brightness.\n");
>   }
>  
> + if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP)
> + if (!intel_dp_aux_set_pwm_freq(connector))

nit: This doesn't read 

Re: [Intel-gfx] [PATCH v10 2/3] drm/i915: Add option to support dynamic backlight via DPCD

[Pandiyan, Dhinakaran]

On Fri, 2017-05-26 at 18:42 -0700, Puthikorn Voravootivat wrote:
> This patch adds option to enable dynamic backlight for eDP
> panel that supports this feature via DPCD register and
> set minimum / maximum brightness to 0% and 100% of the
> normal brightness.
> 
> Signed-off-by: Puthikorn Voravootivat 
> ---
>  drivers/gpu/drm/i915/i915_params.c|  5 
>  drivers/gpu/drm/i915/i915_params.h|  3 +-
>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 42 
> ++-
>  3 files changed, 41 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index 3758ae1f11b4..ce033d58134e 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -65,6 +65,7 @@ struct i915_params i915 __read_mostly = {
>   .inject_load_failure = 0,
>   .enable_dpcd_backlight = -1,
>   .enable_gvt = false,
> + .enable_dbc = false,

Based on Daniel's earlier comments on module parameters, shouldn't this
be enabled by default too?

Or even more importantly, is this the right approach to enable/disable
dynamic back light control? The reason I recommended having some sort of
control to disable/enable is that the eDP spec. says the feature can
have user visible impact.

Table 10-3  Display Control Capabilities

"While the DBC control bit’s function is defined in this
Standard, DBC implementation specifics are not defined, including
interaction with other DPCD register settings. The DBC implementation,
visual performance, and power savings characteristics can differ between
specific panels."
 
-DK

>  };
>  
>  module_param_named(modeset, i915.modeset, int, 0400);
> @@ -254,3 +255,7 @@ MODULE_PARM_DESC(enable_dpcd_backlight,
>  module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
>  MODULE_PARM_DESC(enable_gvt,
>   "Enable support for Intel GVT-g graphics virtualization host 
> support(default:false)");
> +
> +module_param_named_unsafe(enable_dbc, i915.enable_dbc, bool, 0600);
> +MODULE_PARM_DESC(enable_dbc,
> + "Enable support for dynamic backlight control (default:false)");
> diff --git a/drivers/gpu/drm/i915/i915_params.h 
> b/drivers/gpu/drm/i915/i915_params.h
> index ac02efce6e22..2de3e2850b54 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -67,7 +67,8 @@
>   func(bool, nuclear_pageflip); \
>   func(bool, enable_dp_mst); \
>   func(int, enable_dpcd_backlight); \
> - func(bool, enable_gvt)
> + func(bool, enable_gvt); \
> + func(bool, enable_dbc)
>  
>  #define MEMBER(T, member) T member
>  struct i915_params {
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index c89aae804659..f55af41ce3bd 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -100,11 +100,26 @@ intel_dp_aux_set_backlight(struct intel_connector 
> *connector, u32 level)
>   }
>  }
>  
> +/*
> + * Set minimum / maximum dynamic brightness percentage. This value is 
> expressed
> + * as the percentage of normal brightness in 5% increments.
> + */
> +static void
> +intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp *intel_dp,
> +u32 min, u32 max)
> +{
> + u8 dbc[] = { DIV_ROUND_CLOSEST(min, 5), DIV_ROUND_CLOSEST(max, 5) };
> +
> + if (drm_dp_dpcd_write(&intel_dp->aux, DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET,
> +   dbc, sizeof(dbc)) < 0) {
> + DRM_DEBUG_KMS("Failed to write aux DBC brightness level\n");
> + }
> +}
> +
>  static void intel_dp_aux_enable_backlight(struct intel_connector *connector)
>  {
>   struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base);
> - uint8_t dpcd_buf = 0;
> - uint8_t edp_backlight_mode = 0;
> + uint8_t dpcd_buf, new_dpcd_buf, edp_backlight_mode;
>  
>   if (drm_dp_dpcd_readb(&intel_dp->aux,
>   DP_EDP_BACKLIGHT_MODE_SET_REGISTER, &dpcd_buf) != 1) {
> @@ -113,18 +128,15 @@ static void intel_dp_aux_enable_backlight(struct 
> intel_connector *connector)
>   return;
>   }
>  
> + new_dpcd_buf = dpcd_buf;
>   edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
>  
>   switch (edp_backlight_mode) {
>   case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
>   case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
>   case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
> - dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> - dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
> - if (drm_dp_dpcd_writeb(&intel_dp->aux,
> - DP_EDP_BACKLIGHT_MODE_SET_REGISTER, dpcd_buf) < 0) {
> - DRM_DEBUG_KMS("Failed to write aux backlight mode\n");
> - }
> + new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> + new_dp

Re: [PATCH 21/22] drm/tegra: Don't use IOMMU on Tegra20

[Dmitry Osipenko]

On 30.05.2017 12:21, Joerg Roedel wrote:
> On Tue, May 23, 2017 at 03:16:32AM +0300, Dmitry Osipenko wrote:
>> There is no IOMMU on Tegra20, instead a GART would be picked as an IOMMU
>> provider.
>>
>> Signed-off-by: Dmitry Osipenko 
>> ---
>>  drivers/gpu/drm/tegra/drm.c | 5 -
>>  drivers/gpu/host1x/dev.c| 5 -
>>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> Not sure what the context here is or if the patches need to merged with
> the rest of the patch-set, so:
> 
>   Acked-by: Joerg Roedel 
> 

Probably I would have to add you on the CC to the cover latter, sorry. These two
patches do not depend on the rest of the patchset, I just aggregated all the
patches into a series for ease of managing them for me and maintainers. Thank
you for the ack!

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

[PATCH 3/4] drm/bridge: dw-hdmi: add better clock disable control

[Russell King]

The video setup path aways sets the clock disable register to a specific
value, which has the effect of disabling the CEC engine.  When we add the
CEC driver, this becomes a problem.

Fix this by only setting/clearing the bits that the video path needs to.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 25 +++--
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 966422576c44..58781d4c1034 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -166,6 +166,7 @@ struct dw_hdmi {
bool bridge_is_on;  /* indicates the bridge is on */
bool rxsense;   /* rxsense state */
u8 phy_mask;/* desired phy int mask settings */
+   u8 mc_clkdis;   /* clock disable register */
 
spinlock_t audio_lock;
struct mutex audio_mutex;
@@ -1543,8 +1544,6 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
 /* HDMI Initialization Step B.4 */
 static void dw_hdmi_enable_video_path(struct dw_hdmi *hdmi)
 {
-   u8 clkdis;
-
/* control period minimum duration */
hdmi_writeb(hdmi, 12, HDMI_FC_CTRLDUR);
hdmi_writeb(hdmi, 32, HDMI_FC_EXCTRLDUR);
@@ -1556,17 +1555,21 @@ static void dw_hdmi_enable_video_path(struct dw_hdmi 
*hdmi)
hdmi_writeb(hdmi, 0x21, HDMI_FC_CH2PREAM);
 
/* Enable pixel clock and tmds data path */
-   clkdis = 0x7F;
-   clkdis &= ~HDMI_MC_CLKDIS_PIXELCLK_DISABLE;
-   hdmi_writeb(hdmi, clkdis, HDMI_MC_CLKDIS);
+   hdmi->mc_clkdis |= HDMI_MC_CLKDIS_HDCPCLK_DISABLE |
+  HDMI_MC_CLKDIS_CSCCLK_DISABLE |
+  HDMI_MC_CLKDIS_AUDCLK_DISABLE |
+  HDMI_MC_CLKDIS_PREPCLK_DISABLE |
+  HDMI_MC_CLKDIS_TMDSCLK_DISABLE;
+   hdmi->mc_clkdis &= ~HDMI_MC_CLKDIS_PIXELCLK_DISABLE;
+   hdmi_writeb(hdmi, hdmi->mc_clkdis, HDMI_MC_CLKDIS);
 
-   clkdis &= ~HDMI_MC_CLKDIS_TMDSCLK_DISABLE;
-   hdmi_writeb(hdmi, clkdis, HDMI_MC_CLKDIS);
+   hdmi->mc_clkdis &= ~HDMI_MC_CLKDIS_TMDSCLK_DISABLE;
+   hdmi_writeb(hdmi, hdmi->mc_clkdis, HDMI_MC_CLKDIS);
 
/* Enable csc path */
if (is_color_space_conversion(hdmi)) {
-   clkdis &= ~HDMI_MC_CLKDIS_CSCCLK_DISABLE;
-   hdmi_writeb(hdmi, clkdis, HDMI_MC_CLKDIS);
+   hdmi->mc_clkdis &= ~HDMI_MC_CLKDIS_CSCCLK_DISABLE;
+   hdmi_writeb(hdmi, hdmi->mc_clkdis, HDMI_MC_CLKDIS);
}
 
/* Enable color space conversion if needed */
@@ -1580,7 +1583,8 @@ static void dw_hdmi_enable_video_path(struct dw_hdmi 
*hdmi)
 
 static void hdmi_enable_audio_clk(struct dw_hdmi *hdmi)
 {
-   hdmi_modb(hdmi, 0, HDMI_MC_CLKDIS_AUDCLK_DISABLE, HDMI_MC_CLKDIS);
+   hdmi->mc_clkdis &= ~HDMI_MC_CLKDIS_AUDCLK_DISABLE;
+   hdmi_writeb(hdmi, hdmi->mc_clkdis, HDMI_MC_CLKDIS);
 }
 
 /* Workaround to clear the overflow condition */
@@ -2261,6 +2265,7 @@ __dw_hdmi_probe(struct platform_device *pdev,
hdmi->disabled = true;
hdmi->rxsense = true;
hdmi->phy_mask = (u8)~(HDMI_PHY_HPD | HDMI_PHY_RX_SENSE);
+   hdmi->mc_clkdis = 0x7f;
 
mutex_init(&hdmi->mutex);
mutex_init(&hdmi->audio_mutex);
-- 
2.7.4

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

[PATCH 1/4] drm/bridge: dw-hdmi: remove CEC engine register definitions

[Russell King]

We don't need the CEC engine register definitions, so let's remove them.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 45 ---
 1 file changed, 45 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
index c59f87e1483e..091831e4f9d5 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
@@ -478,51 +478,6 @@
 #define HDMI_A_PRESETUP 0x501A
 #define HDMI_A_SRM_BASE 0x5020
 
-/* CEC Engine Registers */
-#define HDMI_CEC_CTRL   0x7D00
-#define HDMI_CEC_STAT   0x7D01
-#define HDMI_CEC_MASK   0x7D02
-#define HDMI_CEC_POLARITY   0x7D03
-#define HDMI_CEC_INT0x7D04
-#define HDMI_CEC_ADDR_L 0x7D05
-#define HDMI_CEC_ADDR_H 0x7D06
-#define HDMI_CEC_TX_CNT 0x7D07
-#define HDMI_CEC_RX_CNT 0x7D08
-#define HDMI_CEC_TX_DATA0   0x7D10
-#define HDMI_CEC_TX_DATA1   0x7D11
-#define HDMI_CEC_TX_DATA2   0x7D12
-#define HDMI_CEC_TX_DATA3   0x7D13
-#define HDMI_CEC_TX_DATA4   0x7D14
-#define HDMI_CEC_TX_DATA5   0x7D15
-#define HDMI_CEC_TX_DATA6   0x7D16
-#define HDMI_CEC_TX_DATA7   0x7D17
-#define HDMI_CEC_TX_DATA8   0x7D18
-#define HDMI_CEC_TX_DATA9   0x7D19
-#define HDMI_CEC_TX_DATA10  0x7D1a
-#define HDMI_CEC_TX_DATA11  0x7D1b
-#define HDMI_CEC_TX_DATA12  0x7D1c
-#define HDMI_CEC_TX_DATA13  0x7D1d
-#define HDMI_CEC_TX_DATA14  0x7D1e
-#define HDMI_CEC_TX_DATA15  0x7D1f
-#define HDMI_CEC_RX_DATA0   0x7D20
-#define HDMI_CEC_RX_DATA1   0x7D21
-#define HDMI_CEC_RX_DATA2   0x7D22
-#define HDMI_CEC_RX_DATA3   0x7D23
-#define HDMI_CEC_RX_DATA4   0x7D24
-#define HDMI_CEC_RX_DATA5   0x7D25
-#define HDMI_CEC_RX_DATA6   0x7D26
-#define HDMI_CEC_RX_DATA7   0x7D27
-#define HDMI_CEC_RX_DATA8   0x7D28
-#define HDMI_CEC_RX_DATA9   0x7D29
-#define HDMI_CEC_RX_DATA10  0x7D2a
-#define HDMI_CEC_RX_DATA11  0x7D2b
-#define HDMI_CEC_RX_DATA12  0x7D2c
-#define HDMI_CEC_RX_DATA13  0x7D2d
-#define HDMI_CEC_RX_DATA14  0x7D2e
-#define HDMI_CEC_RX_DATA15  0x7D2f
-#define HDMI_CEC_LOCK   0x7D30
-#define HDMI_CEC_WKUPCTRL   0x7D31
-
 /* I2C Master Registers (E-DDC) */
 #define HDMI_I2CM_SLAVE 0x7E00
 #define HDMI_I2CM_ADDRESS   0x7E01
-- 
2.7.4

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

Linux Kernel 4.4.0-66 Possible DRM connector_status Bug For LG Displays

[Tom Reddish]

LG Displays are being reported as "disconnected" when they are powered off 
(currently connected through DVI to mini-displayport adapter)

Only seeing this with LG displays (have tested NEC and Samsung *limited model 
types for each manufacturer*). With the LG display connected to the graphics 
card and powered off the system is reporting the DisplayPort as disconnected. 
In any kernel <= 4.4.0-31 the system would report the DisplayPort as connected 
even if the LG display was off. 

Kernel tested on
Linux version 4.4.0-66-generic (buildd@lgw01-28) (gcc version 5.4.0 20160609 
(Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #87-Ubuntu

Most recent kernel without the bug: 
Linux version 4.4.0-31-generic (buildd@lgw01-16) (gcc version 5.3.1 20160413 
(Ubuntu 5.3.1-14ubuntu2.1) ) #50-Ubuntu

"cat /sys/class/drm/card1-DP-1/status" will show the status as disconnected if 
the LG display is powered off

Environment
Ubuntu 16.04
Graphics Card: Cape Verde PRO [Radeon HD 7750/8740 / R7 250E]
Radeon Graphics Drivers
Kernel: 4.4.0-66


Processor
processor   : 0-3
vendor_id   : AuthenticAMD
cpu family  : 21
model   : 48
model name  : AMD A8-7600 Radeon R7, 10 Compute Cores 4C+6G
stepping: 1
microcode   : 0x6003106
cpu MHz : 1400.000
cache size  : 2048 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 2
apicid  : 16
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf 
eagerfpu pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave 
avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 
3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext 
perfctr_core perfctr_nb bpext cpb hw_pstate vmmcall fsgsbase bmi1 xsaveopt arat 
npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists 
pausefilter pfthreshold
bugs: fxsave_leak sysret_ss_attrs
bogomips: 6188.48
TLB size: 1536 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro [13]


Loaded driver and hardware information
cat /proc/ioports:
-03af : PCI Bus :00
  -001f : dma1
  0020-0021 : pic1
  0040-0043 : timer0
  0050-0053 : timer1
  0060-0060 : keyboard
  0061-0061 : PNP0800:00
  0064-0064 : keyboard
  0070-0071 : rtc0
  0080-008f : dma page reg
  00a0-00a1 : pic2
  00c0-00df : dma2
  00f0-00ff : PNP0C04:00
00f0-00ff : fpu
03b0-03df : PCI Bus :00
  03c0-03df : vesafb
03e0-0cf7 : PCI Bus :00
  03f8-03ff : serial
  040b-040b : pnp 00:08
  04d0-04d1 : pnp 00:07
04d0-04d1 : pnp 00:08
  04d6-04d6 : pnp 00:08
  0800-0803 : ACPI PM1a_EVT_BLK
  0804-0805 : ACPI PM1a_CNT_BLK
  0808-080b : ACPI PM_TMR
  0810-0815 : ACPI CPU throttle
  0820-0827 : ACPI GPE0_BLK
  0900-090f : pnp 00:08
  0910-091f : pnp 00:08
  0a00-0a0f : pnp 00:03
0a00-0a07 : f71882fg
  0a10-0a1f : pnp 00:03
  0b00-0b07 : piix4_smbus
  0b20-0b3f : pnp 00:08
0b20-0b27 : piix4_smbus
  0c00-0c01 : pnp 00:08
  0c14-0c14 : pnp 00:08
  0c50-0c51 : pnp 00:08
  0c52-0c52 : pnp 00:08
  0c6c-0c6c : pnp 00:08
  0c6f-0c6f : pnp 00:08
  0cd0-0cd1 : pnp 00:08
  0cd2-0cd3 : pnp 00:08
  0cd4-0cd5 : pnp 00:08
  0cd6-0cd7 : pnp 00:08
  0cd8-0cdf : pnp 00:08
0cf8-0cff : PCI conf1
0d00- : PCI Bus :00
  d000-dfff : PCI Bus :02
d000-d0ff : :02:00.0
  d000-d0ff : r8169
  e000-efff : PCI Bus :01
e000-e0ff : :01:00.0
  f000-f0ff : :00:01.0
  f100-f10f : :00:11.0
f100-f10f : ahci
  f110-f113 : :00:11.0
f110-f113 : ahci
  f120-f127 : :00:11.0
f120-f127 : ahci
  f130-f133 : :00:11.0
f130-f133 : ahci
  f140-f147 : :00:11.0
f140-f147 : ahci
  fe00-fefe : pnp 00:08

PCI Information
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cape 
Verde PRO [Radeon HD 7750/8740 / R7 250E] (prog-if 00 [VGA controller])
Subsystem: Hightech Information System Ltd. Cape Verde PRO [Radeon HD 
7750/8740 / R7 250E]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1 
unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLRe

[PATCH 2/4] drm/bridge: dw-hdmi: add cec notifier support

[Russell King]

Add CEC notifier support to the HDMI bridge driver, so that the CEC
part of the IP can receive its physical address.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 4e1f54a675d8..966422576c44 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -36,7 +36,10 @@
 #include "dw-hdmi.h"
 #include "dw-hdmi-audio.h"
 
+#include 
+
 #define DDC_SEGMENT_ADDR   0x30
+
 #define HDMI_EDID_LEN  512
 
 enum hdmi_datamap {
@@ -173,6 +176,8 @@ struct dw_hdmi {
 
unsigned int reg_shift;
struct regmap *regm;
+
+   struct cec_notifier *cec_notifier;
 };
 
 #define HDMI_IH_PHY_STAT0_RX_SENSE \
@@ -1870,6 +1875,7 @@ static int dw_hdmi_connector_get_modes(struct 
drm_connector *connector)
hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
drm_mode_connector_update_edid_property(connector, edid);
+   cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier, edid);
ret = drm_add_edid_modes(connector, edid);
/* Store the ELD */
drm_edid_to_eld(connector, edid);
@@ -2108,11 +2114,16 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
 * ask the source to re-read the EDID.
 */
if (intr_stat &
-   (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD))
+   (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) {
__dw_hdmi_setup_rx_sense(hdmi,
 phy_stat & HDMI_PHY_HPD,
 phy_stat & HDMI_PHY_RX_SENSE);
 
+   if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0)
+   cec_notifier_set_phys_addr(hdmi->cec_notifier,
+  CEC_PHYS_ADDR_INVALID);
+   }
+
if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
dev_dbg(hdmi->dev, "EVENT=%s\n",
phy_int_pol & HDMI_PHY_HPD ? "plugin" : "plugout");
@@ -2365,6 +2376,12 @@ __dw_hdmi_probe(struct platform_device *pdev,
if (ret)
goto err_iahb;
 
+   hdmi->cec_notifier = cec_notifier_get(dev);
+   if (!hdmi->cec_notifier) {
+   ret = -ENOMEM;
+   goto err_iahb;
+   }
+
/*
 * To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator
 * N and cts values before enabling phy
@@ -2437,6 +2454,9 @@ __dw_hdmi_probe(struct platform_device *pdev,
hdmi->ddc = NULL;
}
 
+   if (hdmi->cec_notifier)
+   cec_notifier_put(hdmi->cec_notifier);
+
clk_disable_unprepare(hdmi->iahb_clk);
 err_isfr:
clk_disable_unprepare(hdmi->isfr_clk);
-- 
2.7.4

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

[PATCH 0/4] dw-hdmi CEC support

[Russell King - ARM Linux]

Hi,

This series adds dw-hdmi CEC support.  This is done in four stages:

1. Remove definitions that are not required from dw-hdmi.h
2. Add cec-notifier support
3. Fix up the clkdis register support, as this register contains a
   clock disable bit for the CEC module.
4. Add the driver.

The CEC driver has been updated to use the register accessors in the
main driver - it would be nice if it was possible to use the regmap
support directly, but there's some knowledge private to the main
driver that's required to correctly access the registers.  (I don't
understand why the register stride isn't part of regmap.)

 drivers/gpu/drm/bridge/synopsys/Kconfig   |   8 +
 drivers/gpu/drm/bridge/synopsys/Makefile  |   1 +
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 320 ++
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h |  19 ++
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  87 ++-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.h |  45 
 6 files changed, 423 insertions(+), 57 deletions(-)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

[Florian Echtler]

On 26.05.2017 23:03, Lukas Wunner wrote:
> On Fri, May 26, 2017 at 02:13:29PM +0200, Florian Echtler wrote:
>> I'm running Ubuntu 16.04.2 on a 27" unibody iMac 10,1 from 2009. However, 
>> even
>> with the most recent HWE stack (kernel 4.8), the display stays black after
>> suspend. I can ssh into the machine, so wakeup is OK, but the display is
>> entirely black (backlight stays off).
>>
> The ATI card has MXM_PNL_PWR_EN and MXM_PNL_BL_EN pins.  Those must be
> enabled for the panel to light up.  Perhaps radeon needs to be extended
> to do that.  One theory is that this is done via ACPI, but perhaps
> only if a certain operating system is running.  Dump the ACPI tables
> and search DSDT and SSDT* tables for methods relating to the ATI card
> and/or backlight.  If you find checks for OSDW there (e.g. in _PS0,
> i.e. on resume), it means the AML code is only executed on Darwin.
I've already had a look at the ACPI tables; there seem to be no references to
the "official" backlight/display control functions (no _BL? or _DO? methods).

> Conversely !OSDW means the code is only executed on Windows (Boot Camp).
> Linux masquerades as Darwin, but this can be disabled with
> acpi_osi=!Darwin on the command line.  It's worth trying if that changes
> the behaviour.  If it does, then macOS likely sets those pins on resume
> and we need to do the same in radeon.
There are OSDW checks present, however, booting with acpi_osi=!Darwin doesn't
make a difference to the backlight behaviour.

I'd be grateful for other suggestions...

Best regards, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL




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 v2 5/7] drm/ltdc: Use the panel-bridge helper.

[Philippe CORNU]

Hi Eric,

I took your patch for the panel-bridge and it works perfectly in both 
DPI mode (panel RGB //) and DSI mode (bridge dw mipi dsi), bravo :-)

~160 lines have been removed from ltdc.c thanks to your panel-bridge code!

Many thanks
Philippe

On 05/11/2017 08:31 PM, Eric Anholt wrote:
> Another 100 lines of boilerplate gone.  Bridges aren't supported yet,
> but will be trivial to add later.
> 
> Signed-off-by: Eric Anholt 
> ---
> 
> Also untested.
> 
>   drivers/gpu/drm/stm/ltdc.c | 128 
> +
>   drivers/gpu/drm/stm/ltdc.h |   2 +-
>   2 files changed, 13 insertions(+), 117 deletions(-)
> 
> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> index a40418cda74a..41a1c5d68f5b 100644
> --- a/drivers/gpu/drm/stm/ltdc.c
> +++ b/drivers/gpu/drm/stm/ltdc.c
> @@ -269,11 +269,6 @@ static inline struct ltdc_device *encoder_to_ltdc(struct 
> drm_encoder *enc)
>   return (struct ltdc_device *)enc->dev->dev_private;
>   }
>   
> -static inline struct ltdc_device *connector_to_ltdc(struct drm_connector 
> *con)
> -{
> - return (struct ltdc_device *)con->dev->dev_private;
> -}
> -
>   static inline enum ltdc_pix_fmt to_ltdc_pixelformat(u32 drm_fmt)
>   {
>   enum ltdc_pix_fmt pf;
> @@ -815,22 +810,12 @@ static int ltdc_crtc_init(struct drm_device *ddev, 
> struct drm_crtc *crtc)
>   
>   static void ltdc_rgb_encoder_enable(struct drm_encoder *encoder)
>   {
> - struct ltdc_device *ldev = encoder_to_ltdc(encoder);
> -
>   DRM_DEBUG_DRIVER("\n");
> -
> - drm_panel_prepare(ldev->panel);
> - drm_panel_enable(ldev->panel);
>   }
>   
>   static void ltdc_rgb_encoder_disable(struct drm_encoder *encoder)
>   {
> - struct ltdc_device *ldev = encoder_to_ltdc(encoder);
> -
>   DRM_DEBUG_DRIVER("\n");
> -
> - drm_panel_disable(ldev->panel);
> - drm_panel_unprepare(ldev->panel);
>   }
>   
>   static const struct drm_encoder_helper_funcs ltdc_rgb_encoder_helper_funcs 
> = {
> @@ -863,82 +848,6 @@ static struct drm_encoder 
> *ltdc_rgb_encoder_create(struct drm_device *ddev)
>   return encoder;
>   }
>   
> -/*
> - * DRM_CONNECTOR
> - */
> -
> -static int ltdc_rgb_connector_get_modes(struct drm_connector *connector)
> -{
> - struct drm_device *ddev = connector->dev;
> - struct ltdc_device *ldev = ddev->dev_private;
> - int ret = 0;
> -
> - DRM_DEBUG_DRIVER("\n");
> -
> - if (ldev->panel)
> - ret = drm_panel_get_modes(ldev->panel);
> -
> - return ret < 0 ? 0 : ret;
> -}
> -
> -static struct drm_connector_helper_funcs ltdc_rgb_connector_helper_funcs = {
> - .get_modes = ltdc_rgb_connector_get_modes,
> -};
> -
> -static enum drm_connector_status
> -ltdc_rgb_connector_detect(struct drm_connector *connector, bool force)
> -{
> - struct ltdc_device *ldev = connector_to_ltdc(connector);
> -
> - return ldev->panel ? connector_status_connected :
> -connector_status_disconnected;
> -}
> -
> -static void ltdc_rgb_connector_destroy(struct drm_connector *connector)
> -{
> - DRM_DEBUG_DRIVER("\n");
> -
> - drm_connector_unregister(connector);
> - drm_connector_cleanup(connector);
> -}
> -
> -static const struct drm_connector_funcs ltdc_rgb_connector_funcs = {
> - .dpms = drm_atomic_helper_connector_dpms,
> - .fill_modes = drm_helper_probe_single_connector_modes,
> - .detect = ltdc_rgb_connector_detect,
> - .destroy = ltdc_rgb_connector_destroy,
> - .reset = drm_atomic_helper_connector_reset,
> - .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> - .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> -};
> -
> -struct drm_connector *ltdc_rgb_connector_create(struct drm_device *ddev)
> -{
> - struct drm_connector *connector;
> - int err;
> -
> - connector = devm_kzalloc(ddev->dev, sizeof(*connector), GFP_KERNEL);
> - if (!connector) {
> - DRM_ERROR("Failed to allocate connector\n");
> - return NULL;
> - }
> -
> - connector->polled = DRM_CONNECTOR_POLL_HPD;
> -
> - err = drm_connector_init(ddev, connector,  -  DRM_MODE_CONNECTOR_DPI);
> - if (err) {
> - DRM_ERROR("Failed to initialize connector\n");
> - return NULL;
> - }
> -
> - drm_connector_helper_add(connector,  -
> - DRM_DEBUG_DRIVER("RGB connector:%d created\n", connector->base.id);
> -
> - return connector;
> -}
> -
>   static int ltdc_get_caps(struct drm_device *ddev)
>   {
>   struct ltdc_device *ldev = ddev->dev_private;
> @@ -972,7 +881,7 @@ static int ltdc_get_caps(struct drm_device *ddev)
>   return 0;
>   }
>   
> -static struct drm_panel *ltdc_get_panel(struct drm_device *ddev)
> +static struct drm_bridge *ltdc_get_bridge(struct drm_device *ddev)
>   {
>   struct device *dev = ddev->dev;
>   struct device_node *np = dev->of_node;
> @@ -10

[PATCH 4/4] drm/bridge: dw-hdmi: add cec driver

[Russell King]

Add a CEC driver for the dw-hdmi hardware.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/bridge/synopsys/Kconfig   |   8 +
 drivers/gpu/drm/bridge/synopsys/Makefile  |   1 +
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 320 ++
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h |  19 ++
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  40 +++-
 5 files changed, 387 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
 create mode 100644 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h

diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig 
b/drivers/gpu/drm/bridge/synopsys/Kconfig
index 40d2827a6d19..bd30a0a07272 100644
--- a/drivers/gpu/drm/bridge/synopsys/Kconfig
+++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
@@ -21,3 +21,11 @@ config DRM_DW_HDMI_I2S_AUDIO
help
  Support the I2S Audio interface which is part of the Synopsys
  Designware HDMI block.
+
+config DRM_DW_HDMI_CEC
+   tristate "Synopsis Designware CEC interface"
+   depends on DRM_DW_HDMI && MEDIA_CEC_SUPPORT
+   select MEDIA_CEC_NOTIFIER
+   help
+ Support the CE interface which is part of the Synopsis
+ Designware HDMI block.
diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile 
b/drivers/gpu/drm/bridge/synopsys/Makefile
index 17aa7a65b57e..6fe415903668 100644
--- a/drivers/gpu/drm/bridge/synopsys/Makefile
+++ b/drivers/gpu/drm/bridge/synopsys/Makefile
@@ -3,3 +3,4 @@
 obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
+obj-$(CONFIG_DRM_DW_HDMI_CEC) += dw-hdmi-cec.o
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
new file mode 100644
index ..761ef5ae687d
--- /dev/null
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
@@ -0,0 +1,320 @@
+/*
+ * Designware HDMI CEC driver
+ *
+ * Copyright (C) 2015-2017 Russell King.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+
+#include "dw-hdmi-cec.h"
+
+enum {
+   HDMI_IH_CEC_STAT0   = 0x0106,
+   HDMI_IH_MUTE_CEC_STAT0  = 0x0186,
+
+   HDMI_CEC_CTRL   = 0x7d00,
+   CEC_CTRL_START  = BIT(0),
+   CEC_CTRL_NORMAL = 1 << 1,
+
+   HDMI_CEC_STAT   = 0x7d01,
+   CEC_STAT_DONE   = BIT(0),
+   CEC_STAT_EOM= BIT(1),
+   CEC_STAT_NACK   = BIT(2),
+   CEC_STAT_ARBLOST= BIT(3),
+   CEC_STAT_ERROR_INIT = BIT(4),
+   CEC_STAT_ERROR_FOLL = BIT(5),
+   CEC_STAT_WAKEUP = BIT(6),
+
+   HDMI_CEC_MASK   = 0x7d02,
+   HDMI_CEC_POLARITY   = 0x7d03,
+   HDMI_CEC_INT= 0x7d04,
+   HDMI_CEC_ADDR_L = 0x7d05,
+   HDMI_CEC_ADDR_H = 0x7d06,
+   HDMI_CEC_TX_CNT = 0x7d07,
+   HDMI_CEC_RX_CNT = 0x7d08,
+   HDMI_CEC_TX_DATA0   = 0x7d10,
+   HDMI_CEC_RX_DATA0   = 0x7d20,
+   HDMI_CEC_LOCK   = 0x7d30,
+   HDMI_CEC_WKUPCTRL   = 0x7d31,
+};
+
+struct dw_hdmi_cec {
+   struct dw_hdmi *hdmi;
+   const struct dw_hdmi_cec_ops *ops;
+   u32 addresses;
+   struct cec_adapter *adap;
+   struct cec_msg rx_msg;
+   unsigned int tx_status;
+   bool tx_done;
+   bool rx_done;
+   struct cec_notifier *notify;
+   int retries;
+   int irq;
+};
+
+static void dw_hdmi_write(struct dw_hdmi_cec *cec, u8 val, int offset)
+{
+   cec->ops->write(cec->hdmi, val, offset);
+}
+
+static u8 dw_hdmi_read(struct dw_hdmi_cec *cec, int offset)
+{
+   return cec->ops->read(cec->hdmi, offset);
+}
+
+static int dw_hdmi_cec_log_addr(struct cec_adapter *adap, u8 logical_addr)
+{
+   struct dw_hdmi_cec *cec = adap->priv;
+   u32 addresses;
+
+   if (logical_addr == CEC_LOG_ADDR_INVALID)
+   addresses = cec->addresses = 0;
+   else
+   addresses = cec->addresses |= BIT(logical_addr) | BIT(15);
+
+   dw_hdmi_write(cec, addresses & 255, HDMI_CEC_ADDR_L);
+   dw_hdmi_write(cec, addresses >> 8, HDMI_CEC_ADDR_H);
+
+   return 0;
+}
+
+static int dw_hdmi_cec_transmit(struct cec_adapter *adap, u8 attempts,
+   u32 signal_free_time, struct cec_msg *msg)
+{
+   struct dw_hdmi_cec *cec = adap->priv;
+   unsigned i;
+
+   cec->retries = attempts;
+
+   for (i = 0; i < msg->len; i++)
+   dw_hdmi_write(cec, msg->msg[i], HDMI_CEC_TX_DATA0 + i);
+
+   dw_hdmi_write(cec, msg->len, HDMI_CEC_TX_CNT);
+   dw_hdmi_write(cec, CEC_CTRL_NORMAL | CEC_CTRL_START, HDMI_CEC_CTRL);
+
+   return 0;
+}
+
+static irqreturn_t dw_h

[pull] amdgpu drm-fixes-4.12

[Alex Deucher]

Hi Dave,

Just one fix for VCE3.

The following changes since commit 5ed02dbb497422bf225783f46e6eadd237d23d6b:

  Linux 4.12-rc3 (2017-05-28 17:20:53 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-4.12

for you to fetch changes up to 45cc6586b7a73e84a8806881122b6ec306cdc9e7:

  drm/amdgpu: Program ring for vce instance 1 at its register space (2017-05-31 
13:09:15 -0400)


Leo Liu (1):
  drm/amdgpu: Program ring for vce instance 1 at its register space

 drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 95 +--
 1 file changed, 68 insertions(+), 27 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm: Extract drm_vblank.[hc]

[kbuild test robot]

Hi Daniel,

[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20170531]
[cannot apply to v4.12-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-Extract-drm_vblank-hc/20170531-223258
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick 
(https://www.imagemagick.org)
   arch/x86/include/asm/uaccess_32.h:1: warning: no structured comments found
   include/linux/init.h:1: warning: no structured comments found
   include/linux/mod_devicetable.h:686: warning: Excess 
struct/union/enum/typedef member 'ver_major' description in 'fsl_mc_device_id'
   include/linux/mod_devicetable.h:686: warning: Excess 
struct/union/enum/typedef member 'ver_minor' description in 'fsl_mc_device_id'
   kernel/sched/core.c:2088: warning: No description found for parameter 'rf'
   kernel/sched/core.c:2088: warning: Excess function parameter 'cookie' 
description in 'try_to_wake_up_local'
   include/linux/kthread.h:26: warning: Excess function parameter '...' 
description in 'kthread_create'
   kernel/sys.c:1: warning: no structured comments found
   include/linux/device.h:969: warning: No description found for parameter 
'dma_ops'
   drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
   include/linux/iio/iio.h:597: warning: No description found for parameter 
'trig_readonly'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'indio_dev'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'trig'
   include/linux/device.h:970: warning: No description found for parameter 
'dma_ops'
   include/linux/usb/gadget.h:230: warning: No description found for parameter 
'claimed'
   include/linux/usb/gadget.h:230: warning: No description found for parameter 
'enabled'
   include/linux/usb/gadget.h:408: warning: No description found for parameter 
'quirk_altset_not_supp'
   include/linux/usb/gadget.h:408: warning: No description found for parameter 
'quirk_stall_not_supp'
   include/linux/usb/gadget.h:408: warning: No description found for parameter 
'quirk_zlp_not_supp'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'set_busid'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'irq_handler'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'irq_preinstall'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'irq_postinstall'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'irq_uninstall'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'debugfs_init'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_open_object'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_close_object'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'prime_handle_to_fd'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'prime_fd_to_handle'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_prime_export'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_prime_import'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_prime_pin'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_prime_unpin'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_prime_res_obj'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_prime_get_sg_table'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_prime_import_sg_table'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_prime_vmap'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_prime_vunmap'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_prime_mmap'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_vm_ops'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'major'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'minor'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'patchlevel'

Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC

[Maxime Ripard]

On Wed, May 24, 2017 at 04:25:46PM +0800, Icenowy Zheng wrote:
> 
> 
> 于 2017年5月24日 GMT+08:00 下午3:30:19, Maxime Ripard 
>  写到:
> >On Tue, May 23, 2017 at 09:00:59PM +0800, icen...@aosc.io wrote:
> >> 在 2017-05-23 20:53，Maxime Ripard 写道：
> >> > On Mon, May 22, 2017 at 07:55:56PM +0200, Jernej Škrabec wrote:
> >> > > Hi,
> >> > > 
> >> > > Dne sobota, 20. maj 2017 ob 03:37:53 CEST je Chen-Yu Tsai
> >napisal(a):
> >> > > > On Sat, May 20, 2017 at 2:23 AM, Jernej Škrabec
> >
> >> > > wrote:
> >> > > > > Hi,
> >> > > > >
> >> > > > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng
> >napisal(a):
> >> > > > >> 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard
> > >> > > > >
> >> > > > > electrons.com> 写到:
> >> > > > >> >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng
> >wrote:
> >> > > > >> >> Allwinner H3 features a TV encoder similar to the one in
> >earlier
> >> > > > >> >
> >> > > > >> >SoCs,
> >> > > > >> >
> >> > > > >> >> but with some different points about clocks:
> >> > > > >> >> - It has a mod clock and a bus clock.
> >> > > > >> >> - The mod clock must be at a fixed rate to generate
> >signal.
> >> > > > >> >
> >> > > > >> >Why?
> >> > > > >>
> >> > > > >> It's experiment result by Jernej.
> >> > > > >>
> >> > > > >> The clock rates in BSP kernel is also specially designed
> >> > > > >> (PLL_DE at 432MHz) in order to be able to feed the TVE.
> >> > > > >
> >> > > > > My experiments and search through BSP code showed that TVE
> >seems to have
> >> > > > > additional fixed predivider 8. So if you want to generate 27
> >MHz clock,
> >> > > > > unit has to be feed with 216 MHz.
> >> > > > >
> >> > > > > TVE has only one PLL source PLL_DE. And since 216 MHz is a
> >bit low for
> >> > > > > DE2,
> >> > > > > BSP defaults to 432 MHz for PLL_DE and use divider 2 to
> >generate 216 MHz.
> >> > > > > This clock is then divided by 8 internaly to get final 27
> >MHz.
> >> > > > >
> >> > > > > Please note that I don't have any hard evidence to support
> >that, only
> >> > > > > experimental data. However, only that explanation make sense
> >to me.
> >> > > > >
> >> > > > > BTW, BSP H3/H5 TV driver supports only PAL and NTSC which
> >both use 27 MHz
> >> > > > > base clock. Further experiments are needed to check if there
> >is any
> >> > > > > possibility to have other resolutions by manipulating clocks
> >and give
> >> > > > > other proper settings. I plan to do that, but not in very
> >near future.
> >> > > >
> >> > > > You only have composite video output, and those are the only 2
> >standard
> >> > > > resolutions that make any sense.
> >> > > 
> >> > > Right, other resolutions are for VGA.
> >> > > 
> >> > > Anyway, I did some more digging in A10 and R40 datasheets. I
> >think
> >> > > that H3 TVE
> >> > > unit is something in between. R40 TVE has a setting to select "up
> >> > > sample".
> >> > 
> >> > That might be just another translation of oversampling :)
> >> > 
> >> > I didn't know it could be applied to composite signals though, but
> >I
> >> > guess this is just another analog signal after all.
> >> > 
> >> > > Possible settings are 27 MHz, 54 MHz, 108 MHz and 216 MHz. BSP
> >> > > driver on R40
> >> > > has this setting enabled only for PAL and NTSC and it is always
> >216
> >> > > MHz. I
> >> > > think that H3 may have this hardwired to 216 MHz and this would
> >be
> >> > > the reason
> >> > > why 216 MHz is needed.
> >> > > 
> >> > > Has anyone else any better explanation?
> >> > 
> >> > That's already a pretty good one.
> >> > 
> >> > Either way, wether this is upsampling, oversampling or just a
> >> > pre-divider, this can and should be dealt with in the mode_set
> >> > callback, and not in the probe.
> >> 
> >> I got a better idea -- let TVE driver have the CLK_TVE as an
> >> input and create a subclock output with divider 16, and feed this
> >> subclock to TCON lcd-ch1.
> >> 
> >> This is a model of the real hardware -- the clock divider is in
> >> TVE, not TCON.
> >
> >That's definitely not a good representation of the hardware. There's
> >one clock, it goes to the TCON, period.
> 
> No, I still think it goes to the TVE as:
> 
> 1. it's named TVE in datasheet.

Feel free to come up with a better, more sensible explanation?

> 2. Generating signal with such a low resolution but such
> a high dotclock is not a good situation.

What? What do you mean? The pixel clock is 27MHz, I'm pretty sure we
agree on that.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.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 v2] drm: Do not call drm_dev_unregister twice on drm_unplug_dev

[Hans de Goede]

Hi,

On 30-05-17 14:02, Hans de Goede wrote:

Hi,

On 29-05-17 21:02, Daniel Vetter wrote:

On Sun, May 28, 2017 at 07:16:55PM +0200, Hans de Goede wrote:

Since commit a39be606f99d ("drm: Do a full device unregister when
unplugging") drm_unplug_dev has been calling drm_dev_unregister followed
by a drm_put_dev when open_count reaches 0. This drm_put_dev calls
drm_dev_unregister again. Since drm_dev_unregister is not protected
against being called multiple times this leads to havoc.

This commit fixes this by calling drm_dev_unref instead of drm_put_dev.

Fixes: a39be606f99d ("drm: Do a full device unregister when unplugging")
Cc: Chris Wilson 
Cc: Marco Diego Aurélio Mesquita 
Reported-by: Marco Diego Aurélio Mesquita 
Signed-off-by: Hans de Goede 
---
Note I don't have any USB display devices at hand for testing atm so
this patch has only been compile tested.
---
Changes in v2:
-Remove unnecessary mutex changes


Offending patch is in 4.8 ... do we need cc: stable?


Yes I think a Cc: stable would be good.


Does this need a bugreport link?


There is no bug-report that I know of (Marco reported the issues
to me by email). This likely fixes some crashes when unplugging
USB display link devices.

Note I plan to actually test this patch with an USB display device
tomorrow, so you may want to hold on merging this till I've got
around to testing this.


So as promised I've been testing (and then debugging) this today,
this patch is no good.

Chris was right when he said maybe we should not call drm_dev_unregister()
at all, that indeed is bad and causes oopses and an unusable system on
unplug. Reverting Chris' original commit replaces those oopses with
different oopses and still results in an unusable system. I believe
that I know how to fix this now, but it is almost 10pm over here
and I think it is better if I continue this tomorrow.

In the mean time in case it was not clear: self-NACK for this patch.

Regards,

Hans





Regards,

Hans



---
  drivers/gpu/drm/drm_drv.c  | 6 +++---
  drivers/gpu/drm/drm_file.c | 2 +-
  2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index b5c6bb46a425..30b5382bf877 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -364,9 +364,9 @@ void drm_unplug_dev(struct drm_device *dev)
  drm_device_set_unplugged(dev);
-if (dev->open_count == 0) {
-drm_put_dev(dev);
-}
+if (dev->open_count == 0)
+drm_dev_unref(dev);
+
  mutex_unlock(&drm_global_mutex);
  }
  EXPORT_SYMBOL(drm_unplug_dev);
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 3783b659cd38..edba71c8ccc3 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -424,7 +424,7 @@ int drm_release(struct inode *inode, struct file *filp)
  if (!--dev->open_count) {
  drm_lastclose(dev);
  if (drm_device_is_unplugged(dev))
-drm_put_dev(dev);
+drm_dev_unref(dev);
  }
  mutex_unlock(&drm_global_mutex);
--
2.13.0

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



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

[Bug 101229] Global screen tearing (scrolling, Hz miss-match?)

[bugzilla-daemon]

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

--- Comment #7 from Paul  ---
(In reply to Michel Dänzer from comment #6)
> Which rendering backend and tearing prevention method are selected in the
> kwin settings?

XRender and auto, I have tried the full-repaint but it didn't seem to have an
effect.

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

[PATCH 1/1] Adding VK_KHR_display to mesa based on KMS

["Keith Packard"]

As part of my adventures to implement 'DRM leases', it turns out to be
easiest to just implement 'real' VK_KHR_display in mesa now, rather than
a pile of ugly kludges. Because DRM leases just provide a DRM master
fd with limited resource access, mesa doesn't have to care whether you
provide a 'real' master or a lease.

That means all of the mesa code is separate from DRM leases, and can
also be used to run applications directly on bare hardware.

The implementation of the KHR_display extension lives pretty much
entirely within the common vulkan code in
src/vulkan/wsi/wsi_common_display.c

The driver functions in radv simply call those functions, which means
this should be 'trivial' to enable in the anv driver, but I haven't done
that work.

To get the master FD into the driver, I've created a new extension,
VK_KEITHP_kms_display which provides a DRM master file descriptor that
the driver uses in place of creating it's own render node file
descriptor. There's a bit of a dance involved in making sure we use the
right driver; that could probably be improved.

There are a few bits of unimplemented functionality within the
KHR_display implementation:

 1) I don't dig the monitor name out of EDID. I'm thinking this
should be done by the kernel and exposed as a property. It already
has the code for this...

 2) plane and surface capabilities are 'faked'. These expose the range
of source surface sizes and positions which can be used; obviously
the hardware can do a lot more than display an image at full size.

 3) Planes in general. I'm exposing only a single plane per connector at
this point. Obviously we'd want more.

 4) bpp/depth. For now, I'm assuming depth 24, 32bpp. I think I just
need a driver hook to get this out of the image; I sure don't want
to try and parse the format.

I haven't rebased this in a while; it's a few revs back on master. I'm
looking for general feedback and comments about the plan at this point;
this is the second implementation of the code, I'm entirely willing to
do at least one more to make it 'right'.

git://people.freedesktop.org/~keithp/mesa.git   khr_display

There are also some simple changes in the vulkan looader (replicated in
the relevant files in mesa) needed to gain access to the
VK_KEITHP_kms_display extension (thanks, Vulkan, for not exposing vendor
instance extensions by default)

git://people.freedesktop.org/~keithp/Vulkan-LoaderAndValidationLayers.git 
drm-leases

From 06088071af2a396ce58b0490ceb228e3aa079a09 Mon Sep 17 00:00:00 2001
From: Keith Packard 
Date: Wed, 17 May 2017 23:02:33 -0700
Subject: [PATCH] Add VK_KHR_display and VK_KEITHP_kms_display to radv vulkan
 driver [v2]

Implements VK_KHR_display using DRM/KMS.

Expose ability to get to that using VK_KEITHP_kms_display, which
allows the application to provide a master fd to the library which it
uses instead of opening its own.

Signed-off-by: Keith Packard 
---
 configure.ac  |1 +
 include/vulkan/vulkan.h   |3 +-
 include/vulkan/vulkan_keithp.h|   40 +
 src/Makefile.am   |7 +
 src/amd/vulkan/Makefile.am|9 +
 src/amd/vulkan/Makefile.sources   |3 +
 src/amd/vulkan/radv_device.c  |   71 +-
 src/amd/vulkan/radv_entrypoints_gen.py|2 +
 src/amd/vulkan/radv_private.h |7 +
 src/amd/vulkan/radv_radeon_winsys.h   |4 +
 src/amd/vulkan/radv_wsi.c |   37 +-
 src/amd/vulkan/radv_wsi_display.c |  144 
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c |   18 +
 src/intel/vulkan/anv_wsi.c|2 +-
 src/vulkan/Makefile.am|9 +
 src/vulkan/Makefile.sources   |4 +
 src/vulkan/registry/vk.xml|   18 +
 src/vulkan/wsi/wsi_common.h   |   12 +-
 src/vulkan/wsi/wsi_common_display.c   | 1063 +
 src/vulkan/wsi/wsi_common_display.h   |   80 ++
 src/vulkan/wsi/wsi_common_wayland.c   |2 +-
 src/vulkan/wsi/wsi_common_x11.c   |4 +-
 22 files changed, 1526 insertions(+), 14 deletions(-)
 create mode 100644 include/vulkan/vulkan_keithp.h
 create mode 100644 src/amd/vulkan/radv_wsi_display.c
 create mode 100644 src/vulkan/wsi/wsi_common_display.c
 create mode 100644 src/vulkan/wsi/wsi_common_display.h

diff --git a/configure.ac b/configure.ac
index df3eb6b29a..4712efcd5e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2238,6 +2238,7 @@ fi
 
 AM_CONDITIONAL(HAVE_PLATFORM_X11, echo "$egl_platforms" | grep -q 'x11')
 AM_CONDITIONAL(HAVE_PLATFORM_WAYLAND, echo "$egl_platforms" | grep -q 'wayland')
+AM_CONDITIONAL(HAVE_PLATFORM_DISPLAY, echo "$egl_platforms" | grep -q 'drm')
 AM_CONDITIONAL(HAVE_EGL_PLATFORM_DRM, echo "$egl_platforms" | grep -q 'drm')
 AM_CONDITIONAL(HAVE_EGL_PLATFORM_SURFACELESS, echo "$egl_platfor

[Bug 101262] Mesa reports no Video Memory

[bugzilla-daemon]

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

Bug ID: 101262
   Summary: Mesa reports no Video Memory
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: noonetin...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

When trying to run Dying Light. It seg faults.
I compiled Mesa-git well past the patches written
by Brooks. Plus, I am using the overrides.
In common/Dying Light/DW/out/logs/ there are some
logs to examine.

I see this:

{21:54:20.616} INFO: [INFO] > [OpenGL] Video memory detected: 0 [MB]!
{21:54:20.620} INFO: [INFO] > Caught signal 11 (Segmentation fault).
{21:54:20.622} INFO: [INFO] > /lib64/libc.so.6(+0x336e0) [0x7f2472ceb6e0]
{21:54:20.622} INFO: [INFO] | /lib64/libpthread.so.0(pthread_join+0x1e)
[0x7f247a2d06de]
{21:54:20.622} INFO: [INFO] | /usr/lib64/dri/radeonsi_dri.so(+0x303b90)
[0x7f24674fbb90]
{21:54:20.622} INFO: [INFO] | /usr/lib64/dri/radeonsi_dri.so(+0x303be8)
[0x7f24674fbbe8]

I have 4 gig's on my card. All other native linux games run fine.

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

Slower 3D with kernel 4.11.x

[Daniel Mota Leite]

Hi

I upgraded a few weeks ago to kernel 4.11.x from 4.10.x and
notice a drop in performance in my AMD RX480, using mesa 17.2-dev
and a A10-7890k APU

the worst example is Mad Max, with vulkan i get about 80fps
in 4.10, but about 25fps in 4.11. using openGL, i get about 50fps
on 4.10 and about 21 fps on 4.11.

I also notice this on war thunder, 35fps vs 25fps. On war thunder
i also notice that the GPU load is about 75% on 4.10 and 60% 4.11.

My upgrade from 4.10 to 4.11 was make oldconfig and choose
the recomended new settings.

So did anyone else notice any problem? can i check anything
first before trying a long bisect to the kernel?

Thanks in advance for the help

higuita
-- 
Naturally the common people don't want war... but after all it is the
leaders of a country who determine the policy, and it is always a 
simple matter to drag the people along, whether it is a democracy, or
a fascist dictatorship, or a parliament, or a communist dictatorship.
Voice or no voice, the people can always be brought to the bidding of
the leaders. That is easy. All you have to do is tell them they are 
being attacked, and denounce the pacifists for lack of patriotism and
exposing the country to danger.  It works the same in every country.
   -- Hermann Goering, Nazi and war criminal, 1883-1946


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

Re: [PATCH RESEND 6/6] drm/vc4: update cursors asynchronously through atomic

[Eric Anholt]

Gustavo Padovan  writes:

> From: Gustavo Padovan 
>
> Add support to async updates of cursors by using the new atomic

"Add support for"

> interface for that. Basically what this commit does is do what
> vc4_update_plane() did but through atomic.
>
> v3: move size checks back to drivers (Ville Syrjälä)
>
> v2: move fb setting to core and use new state (Eric Anholt)

Given that vc4 isn't using drm_atomic_helper_commit(), isn't this
effectively disabling async cursor updates on vc4?


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

Re: [PATCH RESEND 1/6] drm/atomic: initial support for asynchronous plane update

[Eric Anholt]

Gustavo Padovan  writes:

> From: Gustavo Padovan 
>
> In some cases, like cursor updates, it is interesting to update the
> plane in an asynchronous fashion to avoid big delays. The current queued
> update could be still waiting for a fence to signal and thus block any
> subsequent update until its scan out. In cases like this if we update the
> cursor synchronously through the atomic API it will cause significant
> delays that would even be noticed by the final user.
>
> This patch creates a fast path to jump ahead the current queued state and
> do single planes updates without going through all atomic steps in
> drm_atomic_helper_commit(). We take this path for legacy cursor updates.
>
> For now only single plane updates are supported, but we plan to support
> multiple planes updates and async PageFlips through this interface as well
> in the near future.

Sorry for taking so long to do some review for this.

> ---
>  drivers/gpu/drm/drm_atomic.c | 65 
> 
>  drivers/gpu/drm/drm_atomic_helper.c  | 35 +
>  include/drm/drm_atomic.h |  2 +
>  include/drm/drm_atomic_helper.h  |  2 +
>  include/drm/drm_modeset_helper_vtables.h | 48 +++
>  5 files changed, 152 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index be62774..2a0c297 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -631,6 +631,68 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
>   return 0;
>  }
>  
> +static bool drm_atomic_async_check(struct drm_atomic_state *state)
> +{
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *crtc_state;
> + struct drm_crtc_commit *commit;
> + struct drm_plane *__plane, *plane = NULL;
> + struct drm_plane_state *__plane_state, *plane_state = NULL;
> + const struct drm_plane_helper_funcs *funcs;
> + int i, j, n_planes = 0;
> +
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> + if (drm_atomic_crtc_needs_modeset(crtc_state))
> + return false;
> + }
> +
> + for_each_new_plane_in_state(state, __plane, __plane_state, i) {
> + n_planes++;
> + plane = __plane;
> + plane_state = __plane_state;
> + }
> +
> + /* FIXME: we support only single plane updates for now */
> + if (!plane || n_planes != 1)
> + return false;
> +
> + if (!plane_state->crtc)
> + return false;
> +
> + funcs = plane->helper_private;
> + if (!funcs->atomic_async_update)
> + return false;
> +
> + if (plane_state->fence)
> + return false;
> +

Could you add a comment here like:

/* Don't do an async update if there is an outstanding commit modifying
 * the plane.  This prevents our async update's changes from getting
 * overridden by a previous synchronous update's state.
 */

(assuming I understand its intent correctly)

I don't understand KMS locking enough to say if this loop is actually
safely guaranteeing that.  If you're convinced of that, then with my
little cleanups this patch will be:

Acked-by: Eric Anholt 

> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> + if (plane->crtc != crtc)
> + continue;
> +
> + spin_lock(&crtc->commit_lock);
> + commit = list_first_entry_or_null(&crtc->commit_list,
> +   struct drm_crtc_commit,
> +   commit_entry);
> + if (!commit) {
> + spin_unlock(&crtc->commit_lock);
> + continue;
> + }
> + spin_unlock(&crtc->commit_lock);
> +
> + if (!crtc->state->state)
> + continue;
> +
> + for_each_plane_in_state(crtc->state->state, __plane,
> + __plane_state, j) {
> + if (__plane == plane)
> + return false;
> + }
> + }
> +
> + return !funcs->atomic_async_check(plane, plane_state);
> +}
> +
>  static void drm_atomic_crtc_print_state(struct drm_printer *p,
>   const struct drm_crtc_state *state)
>  {
> @@ -1591,6 +1653,9 @@ int drm_atomic_check_only(struct drm_atomic_state 
> *state)
>   }
>   }
>  
> + if (state->legacy_cursor_update)
> + state->async_update = drm_atomic_async_check(state);
> +
>   return ret;
>  }
>  EXPORT_SYMBOL(drm_atomic_check_only);
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 5a3c9c0..a8efdfe 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1235,6 +1235,30 @@ static void commit_work(struct work_struct *work)
>  }
>  
>  /**
> + * drm_atomic_helper_async_commit - commit state asynch

[PATCH 2/5] drm/syncobj: add sync obj wait interface. (v4)

[Dave Airlie]

From: Dave Airlie 

This interface will allow sync object to be used to back
Vulkan fences. This API is pretty much the vulkan fence waiting
API, and I've ported the code from amdgpu.

v2: accept relative timeout, pass remaining time back
to userspace.
v3: return to absolute timeouts.
v4: absolute zero = poll,
rewrite any/all code to have same operation for arrays
return -EINVAL for 0 fences.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_internal.h |   2 +
 drivers/gpu/drm/drm_ioctl.c|   2 +
 drivers/gpu/drm/drm_syncobj.c  | 129 +
 include/uapi/drm/drm.h |  14 +
 4 files changed, 147 insertions(+)

diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 3fdef2c..53e3f6b 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -156,3 +156,5 @@ int drm_syncobj_handle_to_fd_ioctl(struct drm_device *dev, 
void *data,
   struct drm_file *file_private);
 int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_private);
+int drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file_private);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index f1e5681..385ce74 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -657,6 +657,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, 
drm_syncobj_fd_to_handle_ioctl,
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_WAIT, drm_syncobj_wait_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
 };
 
 #define DRM_CORE_IOCTL_COUNT   ARRAY_SIZE( drm_ioctls )
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 23bb197..ec462bd 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1,5 +1,7 @@
 /*
  * Copyright 2017 Red Hat
+ * Parts ported from amdgpu (fence wait code).
+ * Copyright 2016 Advanced Micro Devices, Inc.
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the "Software"),
@@ -31,6 +33,9 @@
  * that contain an optional fence. The fence can be updated with a new
  * fence, or be NULL.
  *
+ * syncobj's can be waited upon, where it will wait for the underlying
+ * fence.
+ *
  * syncobj's can be export to fd's and back, these fd's are opaque and
  * have no other use case, except passing the syncobj between processes.
  *
@@ -380,3 +385,127 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, 
void *data,
return drm_syncobj_fd_to_handle(file_private, args->fd,
&args->handle);
 }
+
+
+/**
+ * drm_timeout_abs_to_jiffies - calculate jiffies timeout from absolute value
+ *
+ * @timeout_ns: timeout in ns, 0 for poll
+ *
+ * Calculate the timeout in jiffies from an absolute timeout in ns.
+ */
+static unsigned long drm_timeout_abs_to_jiffies(uint64_t timeout_ns)
+{
+   unsigned long timeout_jiffies;
+   ktime_t timeout;
+
+   /* make 0 timeout means poll - absolute 0 doesn't seem valid */
+   if (timeout_ns == 0)
+   return 0;
+
+   /* clamp timeout if it's to large */
+   if (((int64_t)timeout_ns) < 0)
+   return MAX_SCHEDULE_TIMEOUT;
+
+   timeout = ktime_sub(ns_to_ktime(timeout_ns), ktime_get());
+   if (ktime_to_ns(timeout) < 0)
+   return 0;
+
+   timeout_jiffies = nsecs_to_jiffies(ktime_to_ns(timeout));
+   /*  clamp timeout to avoid infinite timeout */
+   if (timeout_jiffies >= MAX_SCHEDULE_TIMEOUT)
+   return MAX_SCHEDULE_TIMEOUT - 1;
+
+   return timeout_jiffies + 1;
+}
+
+static int drm_syncobj_wait_fences(struct drm_device *dev,
+  struct drm_file *file_private,
+  struct drm_syncobj_wait *wait,
+  struct dma_fence **fences)
+{
+   unsigned long timeout = drm_timeout_abs_to_jiffies(wait->timeout_ns);
+   int ret = 0;
+   uint32_t first = ~0;
+
+   if (wait->flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL) {
+   int i;
+   for (i = 0; i < wait->count_handles; i++) {
+   ret = dma_fence_wait_timeout(fences[i], true, timeout);
+
+   if (ret < 0)
+   return ret;
+   if (ret == 0)
+   break;
+   timeout = ret;
+   }
+   first = 0;
+   } else
+   ret = dma_fence_wait_any_timeout(fences,
+wait->count_handles,
+ 

[PATCH 1/5] drm: introduce sync objects (v4)

[Dave Airlie]

From: Dave Airlie 

Sync objects are new toplevel drm object, that contain a
pointer to a fence. This fence can be updated via command
submission ioctls via drivers.

There is also a generic wait obj API modelled on the vulkan
wait API (with code modelled on some amdgpu code).

These objects can be converted to an opaque fd that can be
passes between processes.

v2: rename reference/unreference to put/get (Chris)
fix leaked reference (David Zhou)
drop mutex in favour of cmpxchg (Chris)
v3: cleanups from danvet, rebase on drm_fops rename
check fd_flags is 0 in ioctls.
v4: export find/free, change replace fence to take a
syncobj. In order to support lookup first, replace
later semantics which seem in the end to be cleaner.

Reviewed-by: Sean Paul 
Signed-off-by: Dave Airlie 
---
 Documentation/gpu/drm-internals.rst |   3 +
 Documentation/gpu/drm-mm.rst|  12 ++
 drivers/gpu/drm/Makefile|   2 +-
 drivers/gpu/drm/drm_file.c  |   8 +
 drivers/gpu/drm/drm_internal.h  |  13 ++
 drivers/gpu/drm/drm_ioctl.c |  12 ++
 drivers/gpu/drm/drm_syncobj.c   | 382 
 include/drm/drmP.h  |   1 -
 include/drm/drm_drv.h   |   1 +
 include/drm/drm_file.h  |   5 +
 include/drm/drm_syncobj.h   |  90 +
 include/uapi/drm/drm.h  |  24 +++
 12 files changed, 551 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_syncobj.c
 create mode 100644 include/drm/drm_syncobj.h

diff --git a/Documentation/gpu/drm-internals.rst 
b/Documentation/gpu/drm-internals.rst
index babfb61..2b23d78 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -98,6 +98,9 @@ DRIVER_ATOMIC
 implement appropriate obj->atomic_get_property() vfuncs for any
 modeset objects with driver specific properties.
 
+DRIVER_SYNCOBJ
+Driver support drm sync objects.
+
 Major, Minor and Patchlevel
 ~~~
 
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index 96b9c34..9412798 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -484,3 +484,15 @@ DRM Cache Handling
 
 .. kernel-doc:: drivers/gpu/drm/drm_cache.c
:export:
+
+DRM Sync Objects
+===
+
+.. kernel-doc:: drivers/gpu/drm/drm_syncobj.c
+   :doc: Overview
+
+.. kernel-doc:: include/drm/drm_syncobj.h
+   :export:
+
+.. kernel-doc:: drivers/gpu/drm/drm_syncobj.c
+   :export:
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 59f0f9b..6f42188 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -16,7 +16,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_framebuffer.o drm_connector.o drm_blend.o \
drm_encoder.o drm_mode_object.o drm_property.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
-   drm_dumb_buffers.o drm_mode_config.o
+   drm_dumb_buffers.o drm_mode_config.o drm_syncobj.o
 
 drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
 drm-$(CONFIG_DRM_VM) += drm_vm.o
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 3783b65..a20d6a9 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -229,6 +229,9 @@ static int drm_open_helper(struct file *filp, struct 
drm_minor *minor)
if (drm_core_check_feature(dev, DRIVER_GEM))
drm_gem_open(dev, priv);
 
+   if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+   drm_syncobj_open(priv);
+
if (drm_core_check_feature(dev, DRIVER_PRIME))
drm_prime_init_file_private(&priv->prime);
 
@@ -276,6 +279,8 @@ static int drm_open_helper(struct file *filp, struct 
drm_minor *minor)
 out_prime_destroy:
if (drm_core_check_feature(dev, DRIVER_PRIME))
drm_prime_destroy_file_private(&priv->prime);
+   if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+   drm_syncobj_release(priv);
if (drm_core_check_feature(dev, DRIVER_GEM))
drm_gem_release(dev, priv);
put_pid(priv->pid);
@@ -398,6 +403,9 @@ int drm_release(struct inode *inode, struct file *filp)
drm_property_destroy_user_blobs(dev, file_priv);
}
 
+   if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+   drm_syncobj_release(file_priv);
+
if (drm_core_check_feature(dev, DRIVER_GEM))
drm_gem_release(dev, file_priv);
 
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 3d8e8f8..3fdef2c 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -142,4 +142,17 @@ static inline int drm_debugfs_crtc_crc_add(struct drm_crtc 
*crtc)
 {
return 0;
 }
+
 #endif
+
+/* drm_syncobj.c */
+void drm_syncobj_open(struct drm_file *file_private);
+void drm_syncobj_release(struct drm_file *file_private);
+int drm_syncobj_create_ioctl(struc

[PATCH 4/5] amdgpu/cs: split out fence dependency checking

[Dave Airlie]

From: Dave Airlie 

This just splits out the fence depenency checking into it's
own function to make it easier to add semaphore dependencies.

Reviewed-by: Christian König 
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 85 +++---
 1 file changed, 47 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 4e6b950..30225d7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -995,56 +995,65 @@ static int amdgpu_cs_ib_fill(struct amdgpu_device *adev,
return 0;
 }
 
-static int amdgpu_cs_dependencies(struct amdgpu_device *adev,
- struct amdgpu_cs_parser *p)
+static int amdgpu_cs_process_fence_dep(struct amdgpu_cs_parser *p,
+  struct amdgpu_cs_chunk *chunk)
 {
struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
-   int i, j, r;
-
-   for (i = 0; i < p->nchunks; ++i) {
-   struct drm_amdgpu_cs_chunk_dep *deps;
-   struct amdgpu_cs_chunk *chunk;
-   unsigned num_deps;
+   unsigned num_deps;
+   int i, r;
+   struct drm_amdgpu_cs_chunk_dep *deps;
 
-   chunk = &p->chunks[i];
+   deps = (struct drm_amdgpu_cs_chunk_dep *)chunk->kdata;
+   num_deps = chunk->length_dw * 4 /
+   sizeof(struct drm_amdgpu_cs_chunk_dep);
 
-   if (chunk->chunk_id != AMDGPU_CHUNK_ID_DEPENDENCIES)
-   continue;
+   for (i = 0; i < num_deps; ++i) {
+   struct amdgpu_ring *ring;
+   struct amdgpu_ctx *ctx;
+   struct dma_fence *fence;
 
-   deps = (struct drm_amdgpu_cs_chunk_dep *)chunk->kdata;
-   num_deps = chunk->length_dw * 4 /
-   sizeof(struct drm_amdgpu_cs_chunk_dep);
+   r = amdgpu_cs_get_ring(p->adev, deps[i].ip_type,
+  deps[i].ip_instance,
+  deps[i].ring, &ring);
+   if (r)
+   return r;
 
-   for (j = 0; j < num_deps; ++j) {
-   struct amdgpu_ring *ring;
-   struct amdgpu_ctx *ctx;
-   struct dma_fence *fence;
+   ctx = amdgpu_ctx_get(fpriv, deps[i].ctx_id);
+   if (ctx == NULL)
+   return -EINVAL;
 
-   r = amdgpu_cs_get_ring(adev, deps[j].ip_type,
-  deps[j].ip_instance,
-  deps[j].ring, &ring);
+   fence = amdgpu_ctx_get_fence(ctx, ring,
+deps[i].handle);
+   if (IS_ERR(fence)) {
+   r = PTR_ERR(fence);
+   amdgpu_ctx_put(ctx);
+   return r;
+   } else if (fence) {
+   r = amdgpu_sync_fence(p->adev, &p->job->sync,
+ fence);
+   dma_fence_put(fence);
+   amdgpu_ctx_put(ctx);
if (r)
return r;
+   }
+   }
+   return 0;
+}
 
-   ctx = amdgpu_ctx_get(fpriv, deps[j].ctx_id);
-   if (ctx == NULL)
-   return -EINVAL;
+static int amdgpu_cs_dependencies(struct amdgpu_device *adev,
+ struct amdgpu_cs_parser *p)
+{
+   int i, r;
 
-   fence = amdgpu_ctx_get_fence(ctx, ring,
-deps[j].handle);
-   if (IS_ERR(fence)) {
-   r = PTR_ERR(fence);
-   amdgpu_ctx_put(ctx);
-   return r;
+   for (i = 0; i < p->nchunks; ++i) {
+   struct amdgpu_cs_chunk *chunk;
 
-   } else if (fence) {
-   r = amdgpu_sync_fence(adev, &p->job->sync,
- fence);
-   dma_fence_put(fence);
-   amdgpu_ctx_put(ctx);
-   if (r)
-   return r;
-   }
+   chunk = &p->chunks[i];
+
+   if (chunk->chunk_id == AMDGPU_CHUNK_ID_DEPENDENCIES) {
+   r = amdgpu_cs_process_fence_dep(p, chunk);
+   if (r)
+   return r;
}
}
 
-- 
2.9.4

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

drm syncobjs - running out of tag lines

[Dave Airlie]

Okay so Christian said he wanted lookup and replace split in the
amdgpu cs, this does this, and looks a bit cleaner, it required
changing some of the interfaces around on what is exported.

Dave.

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

[PATCH 5/5] amdgpu: use drm sync objects for shared semaphores (v5)

[Dave Airlie]

From: Dave Airlie 

This creates a new command submission chunk for amdgpu
to add in and out sync objects around the submission.

Sync objects are managed via the drm syncobj ioctls.

The command submission interface is enhanced with two new
chunks, one for syncobj pre submission dependencies,
and one for post submission sync obj signalling,
and just takes a list of handles for each.

This is based on work originally done by David Zhou at AMD,
with input from Christian Konig on what things should look like.

In theory VkFences could be backed with sync objects and
just get passed into the cs as syncobj handles as well.

NOTE: this interface addition needs a version bump to expose
it to userspace.

TODO: update to dep_sync when rebasing onto amdgpu master.
(with this - r-b from Christian)

v1.1: keep file reference on import.
v2: move to using syncobjs
v2.1: change some APIs to just use p pointer.
v3: make more robust against CS failures, we now add the
wait sems but only remove them once the CS job has been
submitted.
v4: rewrite names of API and base on new syncobj code.
v5: move post deps earlier, rename some apis
v6: lookup post deps earlier, and just replace fences
in post deps stage (Christian)

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h |  3 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  | 88 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  2 +-
 include/uapi/drm/amdgpu_drm.h   |  6 +++
 4 files changed, 97 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 833c3c1..f520ba0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1109,6 +1109,9 @@ struct amdgpu_cs_parser {
 
/* user fence */
struct amdgpu_bo_list_entry uf_entry;
+
+   unsigned num_post_dep_syncobjs;
+   struct drm_syncobj **post_dep_syncobjs;
 };
 
 #define AMDGPU_PREAMBLE_IB_PRESENT  (1 << 0) /* bit set means command 
submit involves a preamble IB */
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 30225d7..30f6f1e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "amdgpu.h"
 #include "amdgpu_trace.h"
 
@@ -226,6 +227,8 @@ int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, void 
*data)
break;
 
case AMDGPU_CHUNK_ID_DEPENDENCIES:
+   case AMDGPU_CHUNK_ID_SYNCOBJ_IN:
+   case AMDGPU_CHUNK_ID_SYNCOBJ_OUT:
break;
 
default:
@@ -753,6 +756,11 @@ static void amdgpu_cs_parser_fini(struct amdgpu_cs_parser 
*parser, int error, bo
ttm_eu_backoff_reservation(&parser->ticket,
   &parser->validated);
}
+
+   for (i = 0; i < parser->num_post_dep_syncobjs; i++)
+   drm_syncobj_put(parser->post_dep_syncobjs[i]);
+   kfree(parser->post_dep_syncobjs);
+
dma_fence_put(parser->fence);
 
if (parser->ctx)
@@ -1040,6 +1048,64 @@ static int amdgpu_cs_process_fence_dep(struct 
amdgpu_cs_parser *p,
return 0;
 }
 
+static int amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p,
+uint32_t handle)
+{
+   int r;
+   struct dma_fence *fence;
+   r = drm_syncobj_fence_get(p->filp, handle, &fence);
+   if (r)
+   return r;
+
+   r = amdgpu_sync_fence(p->adev, &p->job->sync, fence);
+   dma_fence_put(fence);
+
+   return r;
+}
+
+static int amdgpu_cs_process_syncobj_in_dep(struct amdgpu_cs_parser *p,
+   struct amdgpu_cs_chunk *chunk)
+{
+   unsigned num_deps;
+   int i, r;
+   struct drm_amdgpu_cs_chunk_sem *deps;
+
+   deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata;
+   num_deps = chunk->length_dw * 4 /
+   sizeof(struct drm_amdgpu_cs_chunk_sem);
+
+   for (i = 0; i < num_deps; ++i) {
+   r = amdgpu_syncobj_lookup_and_add_to_sync(p, deps[i].handle);
+   if (r)
+   return r;
+   }
+   return 0;
+}
+
+static int amdgpu_cs_process_syncobj_out_dep(struct amdgpu_cs_parser *p,
+struct amdgpu_cs_chunk *chunk)
+{
+   unsigned num_deps;
+   int i;
+   struct drm_amdgpu_cs_chunk_sem *deps;
+   deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata;
+   num_deps = chunk->length_dw * 4 /
+   sizeof(struct drm_amdgpu_cs_chunk_sem);
+
+   p->post_dep_syncobjs = kmalloc_array(num_deps,
+sizeof(struct drm_syncobj *),
+GFP_KERNEL);
+   p->num_post_dep_syncobjs = 0;
+
+   for (i = 0; i < num_d

[PATCH 3/5] drm/syncobj: add sync_file interaction. (v1.2)

[Dave Airlie]

From: Dave Airlie 

This interface allows importing the fence from a sync_file into
an existing drm sync object, or exporting the fence attached to
an existing drm sync object into a new sync file object.

This should only be used to interact with sync files where necessary.

v1.1: fence put fixes (Chris), drop fence from ioctl names (Chris)
fixup for new fence replace API.

Reviewed-by: Sean Paul 
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_syncobj.c | 75 +--
 include/uapi/drm/drm.h|  2 ++
 2 files changed, 75 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index ec462bd..5814495 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -50,6 +50,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "drm_internal.h"
 #include 
@@ -281,6 +282,59 @@ static int drm_syncobj_fd_to_handle(struct drm_file 
*file_private,
return 0;
 }
 
+int drm_syncobj_import_sync_file_fence(struct drm_file *file_private,
+  int fd, int handle)
+{
+   struct dma_fence *fence = sync_file_get_fence(fd);
+   struct drm_syncobj *syncobj;
+
+   if (!fence)
+   return -EINVAL;
+
+   syncobj = drm_syncobj_find(file_private, handle);
+   if (!syncobj) {
+   dma_fence_put(fence);
+   return -ENOENT;
+   }
+
+   drm_syncobj_replace_fence(file_private, syncobj, fence);
+   dma_fence_put(fence);
+   drm_syncobj_put(syncobj);
+   return 0;
+}
+
+int drm_syncobj_export_sync_file(struct drm_file *file_private,
+int handle, int *p_fd)
+{
+   int ret;
+   struct dma_fence *fence;
+   struct sync_file *sync_file;
+   int fd = get_unused_fd_flags(O_CLOEXEC);
+
+   if (fd < 0)
+   return fd;
+
+   ret = drm_syncobj_fence_get(file_private, handle, &fence);
+   if (ret)
+   goto err_put_fd;
+
+   sync_file = sync_file_create(fence);
+
+   dma_fence_put(fence);
+
+   if (!sync_file) {
+   ret = -EINVAL;
+   goto err_put_fd;
+   }
+
+   fd_install(fd, sync_file->file);
+
+   *p_fd = fd;
+   return 0;
+err_put_fd:
+   put_unused_fd(fd);
+   return ret;
+}
 /**
  * drm_syncobj_open - initalizes syncobj file-private structures at devnode 
open time
  * @dev: drm_device which is being opened by userspace
@@ -363,9 +417,17 @@ drm_syncobj_handle_to_fd_ioctl(struct drm_device *dev, 
void *data,
if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
return -ENODEV;
 
-   if (args->pad || args->flags)
+   if (args->pad)
return -EINVAL;
 
+   if (args->flags != 0 &&
+   args->flags != DRM_SYNCOBJ_HANDLE_TO_FD_FLAGS_EXPORT_SYNC_FILE)
+   return -EINVAL;
+
+   if (args->flags & DRM_SYNCOBJ_HANDLE_TO_FD_FLAGS_EXPORT_SYNC_FILE)
+   return drm_syncobj_export_sync_file(file_private, args->handle,
+   &args->fd);
+
return drm_syncobj_handle_to_fd(file_private, args->handle,
&args->fd);
 }
@@ -379,9 +441,18 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, 
void *data,
if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
return -ENODEV;
 
-   if (args->pad || args->flags)
+   if (args->pad)
+   return -EINVAL;
+
+   if (args->flags != 0 &&
+   args->flags != DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPORT_SYNC_FILE)
return -EINVAL;
 
+   if (args->flags & DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPORT_SYNC_FILE)
+   return drm_syncobj_import_sync_file_fence(file_private,
+ args->fd,
+ args->handle);
+
return drm_syncobj_fd_to_handle(file_private, args->fd,
&args->handle);
 }
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index d6e2f62..49c4e69 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -708,6 +708,8 @@ struct drm_syncobj_destroy {
__u32 pad;
 };
 
+#define DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPORT_SYNC_FILE (1 << 0)
+#define DRM_SYNCOBJ_HANDLE_TO_FD_FLAGS_EXPORT_SYNC_FILE (1 << 0)
 struct drm_syncobj_handle {
__u32 handle;
__u32 flags;
-- 
2.9.4

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

Re: [PATCH RESEND 6/6] drm/vc4: update cursors asynchronously through atomic

[Gustavo Padovan]

2017-05-31 Eric Anholt :

> Gustavo Padovan  writes:
> 
> > From: Gustavo Padovan 
> >
> > Add support to async updates of cursors by using the new atomic
> 
> "Add support for"
> 
> > interface for that. Basically what this commit does is do what
> > vc4_update_plane() did but through atomic.
> >
> > v3: move size checks back to drivers (Ville Syrjälä)
> >
> > v2: move fb setting to core and use new state (Eric Anholt)
> 
> Given that vc4 isn't using drm_atomic_helper_commit(), isn't this
> effectively disabling async cursor updates on vc4?

Right, yes. I didn't have a chance to run this in at the hw as I don't
have it right now. I'll update the patch and resend.

Gustavo


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

Re: [PATCH RESEND 1/6] drm/atomic: initial support for asynchronous plane update

[Gustavo Padovan]

2017-05-31 Eric Anholt :

> Gustavo Padovan  writes:
> 
> > From: Gustavo Padovan 
> >
> > In some cases, like cursor updates, it is interesting to update the
> > plane in an asynchronous fashion to avoid big delays. The current queued
> > update could be still waiting for a fence to signal and thus block any
> > subsequent update until its scan out. In cases like this if we update the
> > cursor synchronously through the atomic API it will cause significant
> > delays that would even be noticed by the final user.
> >
> > This patch creates a fast path to jump ahead the current queued state and
> > do single planes updates without going through all atomic steps in
> > drm_atomic_helper_commit(). We take this path for legacy cursor updates.
> >
> > For now only single plane updates are supported, but we plan to support
> > multiple planes updates and async PageFlips through this interface as well
> > in the near future.
> 
> Sorry for taking so long to do some review for this.
> 
> > ---
> >  drivers/gpu/drm/drm_atomic.c | 65 
> > 
> >  drivers/gpu/drm/drm_atomic_helper.c  | 35 +
> >  include/drm/drm_atomic.h |  2 +
> >  include/drm/drm_atomic_helper.h  |  2 +
> >  include/drm/drm_modeset_helper_vtables.h | 48 +++
> >  5 files changed, 152 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index be62774..2a0c297 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -631,6 +631,68 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
> > return 0;
> >  }
> >  
> > +static bool drm_atomic_async_check(struct drm_atomic_state *state)
> > +{
> > +   struct drm_crtc *crtc;
> > +   struct drm_crtc_state *crtc_state;
> > +   struct drm_crtc_commit *commit;
> > +   struct drm_plane *__plane, *plane = NULL;
> > +   struct drm_plane_state *__plane_state, *plane_state = NULL;
> > +   const struct drm_plane_helper_funcs *funcs;
> > +   int i, j, n_planes = 0;
> > +
> > +   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> > +   if (drm_atomic_crtc_needs_modeset(crtc_state))
> > +   return false;
> > +   }
> > +
> > +   for_each_new_plane_in_state(state, __plane, __plane_state, i) {
> > +   n_planes++;
> > +   plane = __plane;
> > +   plane_state = __plane_state;
> > +   }
> > +
> > +   /* FIXME: we support only single plane updates for now */
> > +   if (!plane || n_planes != 1)
> > +   return false;
> > +
> > +   if (!plane_state->crtc)
> > +   return false;
> > +
> > +   funcs = plane->helper_private;
> > +   if (!funcs->atomic_async_update)
> > +   return false;
> > +
> > +   if (plane_state->fence)
> > +   return false;
> > +
> 
> Could you add a comment here like:
> 
> /* Don't do an async update if there is an outstanding commit modifying
>  * the plane.  This prevents our async update's changes from getting
>  * overridden by a previous synchronous update's state.
>  */
> 
> (assuming I understand its intent correctly)
> 
> I don't understand KMS locking enough to say if this loop is actually
> safely guaranteeing that.  If you're convinced of that, then with my
> little cleanups this patch will be:

I'm going to check the locking again just to make sure.

> 
> Acked-by: Eric Anholt 
> 
> > +   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> > +   if (plane->crtc != crtc)
> > +   continue;
> > +
> > +   spin_lock(&crtc->commit_lock);
> > +   commit = list_first_entry_or_null(&crtc->commit_list,
> > + struct drm_crtc_commit,
> > + commit_entry);
> > +   if (!commit) {
> > +   spin_unlock(&crtc->commit_lock);
> > +   continue;
> > +   }
> > +   spin_unlock(&crtc->commit_lock);
> > +
> > +   if (!crtc->state->state)
> > +   continue;
> > +
> > +   for_each_plane_in_state(crtc->state->state, __plane,
> > +   __plane_state, j) {
> > +   if (__plane == plane)
> > +   return false;
> > +   }
> > +   }
> > +
> > +   return !funcs->atomic_async_check(plane, plane_state);
> > +}
> > +
> >  static void drm_atomic_crtc_print_state(struct drm_printer *p,
> > const struct drm_crtc_state *state)
> >  {
> > @@ -1591,6 +1653,9 @@ int drm_atomic_check_only(struct drm_atomic_state 
> > *state)
> > }
> > }
> >  
> > +   if (state->legacy_cursor_update)
> > +   state->async_update = drm_atomic_async_check(state);
> > +
> > return ret;
> >  }
> >  EXPORT_SYMBOL(drm_atomic_check_only);
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 5a3c9c0..a8efdfe 10

[no subject]

[Dave Airlie]

Hi Linus,

This is the main set of fixes for rc4, one amdgpu fix, some exynos
regression fixes, some msm fixes and some i915 and GVT fixes.

I've got a second regression fix for some DP chips that might be a bit
large, but I think we'd like to land it now, I'll send it along
tomorrow, once you are happy with this set.

Dave.

The following changes since commit 5ed02dbb497422bf225783f46e6eadd237d23d6b:

  Linux 4.12-rc3 (2017-05-28 17:20:53 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.12-rc4

for you to fetch changes up to 400129f0a3ae989c30b37104bbc23b35c9d7a9a4:

  Merge tag 'exynos-drm-fixes-for-v4.12' of
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into
drm-fixes (2017-06-01 12:07:48 +1000)


msm/exynos/i915/amdgpu fixes


Changbin Du (1):
  drm/i915/gvt: clean up unsubmited workloads before destroying kmem cache

Chris Wilson (1):
  drm/i915/selftests: Silence compiler warning in igt_ctx_exec

Chuanxiao Dong (2):
  drm/i915: set initialised only when init_context callback is NULL
  drm/i915/gvt: Disable compression workaround for Gen9

Daniel Vetter (2):
  Revert "drm/i915: Restore lost "Initialized i915" welcome message"
  drm/exynos: Merge pre/postclose hooks

Dave Airlie (4):
  Merge tag 'drm-intel-fixes-2017-05-29' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes
  Merge branch 'msm-fixes-4.12-rc4' of
git://people.freedesktop.org/~robclark/linux into drm-fixes
  Merge branch 'drm-fixes-4.12' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'exynos-drm-fixes-for-v4.12' of
git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes

Eric Anholt (2):
  drm/msm: Expose our reservation object when exporting a dmabuf.
  drm/msm: Reuse dma_fence_release.

Hans de Goede (1):
  drm/i915: Fix new -Wint-in-bool-context gcc compiler warning

Hoegeun Kwon (2):
  drm/exynos: dsi: Fix the parse_dt function
  drm/exynos: dsi: Remove bridge node reference in removal

Inki Dae (1):
  drm/exynos: clean up description of exynos_drm_crtc

Jani Nikula (1):
  Merge tag 'gvt-fixes-2017-05-25' of
https://github.com/01org/gvt-linux into drm-intel-fixes

Joonas Lahtinen (1):
  drm/i915: Do not sync RCU during shrinking

Jordan Crouse (2):
  drm/msm: Take the mutex before calling msm_gem_new_impl
  drm/msm: Fix the check for the command size

Leo Liu (1):
  drm/amdgpu: Program ring for vce instance 1 at its register space

Matthew Auld (1):
  drm/i915: use vma->size for appgtt allocate_va_range

Philipp Zabel (1):
  drm/msm: for array in-fences, check if all backing fences are
from our own context before waiting

Rob Clark (4):
  drm/msm: select PM_OPP
  drm/msm/mdp5: use __drm_atomic_helper_plane_duplicate_state()
  drm/msm/gpu: check legacy clk names in get_clocks()
  drm/msm/mdp5: release hwpipe(s) for unused planes

Tobias Klauser (1):
  drm/msm: constify irq_domain_ops

Ville Syrjälä (1):
  drm/i915: Stop pretending to mask/unmask LPE audio interrupts

 drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 95 ---
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |  8 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  5 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c   | 26 +++
 drivers/gpu/drm/i915/gvt/execlist.c   | 30 ---
 drivers/gpu/drm/i915/gvt/handlers.c   | 30 ---
 drivers/gpu/drm/i915/i915_drv.c   |  4 -
 drivers/gpu/drm/i915/i915_gem_gtt.c   |  2 +-
 drivers/gpu/drm/i915/i915_gem_shrinker.c  |  5 --
 drivers/gpu/drm/i915/i915_irq.c   | 15 ++--
 drivers/gpu/drm/i915/i915_reg.h   |  2 +-
 drivers/gpu/drm/i915/intel_lpe_audio.c| 36 -
 drivers/gpu/drm/i915/intel_lrc.c  |  2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_context.c |  8 +-
 drivers/gpu/drm/msm/Kconfig   |  1 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c  |  2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c |  9 ++-
 drivers/gpu/drm/msm/msm_drv.c |  1 +
 drivers/gpu/drm/msm/msm_drv.h |  1 +
 drivers/gpu/drm/msm/msm_fence.c   | 10 +--
 drivers/gpu/drm/msm/msm_gem.c |  6 ++
 drivers/gpu/drm/msm/msm_gem_prime.c   |  7 ++
 drivers/gpu/drm/msm/msm_gem_submit.c  | 14 ++--
 drivers/gpu/drm/msm/msm_gpu.c |  4 +-
 24 files changed, 169 insertions(+), 154 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] drm fixes for v4.12-rc4

[Dave Airlie]

oops forgot subject.

On 1 June 2017 at 12:26, Dave Airlie  wrote:
> Hi Linus,
>
> This is the main set of fixes for rc4, one amdgpu fix, some exynos
> regression fixes, some msm fixes and some i915 and GVT fixes.
>
> I've got a second regression fix for some DP chips that might be a bit
> large, but I think we'd like to land it now, I'll send it along
> tomorrow, once you are happy with this set.
>
> Dave.
>
> The following changes since commit 5ed02dbb497422bf225783f46e6eadd237d23d6b:
>
>   Linux 4.12-rc3 (2017-05-28 17:20:53 -0700)
>
> are available in the git repository at:
>
>   git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.12-rc4
>
> for you to fetch changes up to 400129f0a3ae989c30b37104bbc23b35c9d7a9a4:
>
>   Merge tag 'exynos-drm-fixes-for-v4.12' of
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into
> drm-fixes (2017-06-01 12:07:48 +1000)
>
> 
> msm/exynos/i915/amdgpu fixes
>
> 
> Changbin Du (1):
>   drm/i915/gvt: clean up unsubmited workloads before destroying kmem cache
>
> Chris Wilson (1):
>   drm/i915/selftests: Silence compiler warning in igt_ctx_exec
>
> Chuanxiao Dong (2):
>   drm/i915: set initialised only when init_context callback is NULL
>   drm/i915/gvt: Disable compression workaround for Gen9
>
> Daniel Vetter (2):
>   Revert "drm/i915: Restore lost "Initialized i915" welcome message"
>   drm/exynos: Merge pre/postclose hooks
>
> Dave Airlie (4):
>   Merge tag 'drm-intel-fixes-2017-05-29' of
> git://anongit.freedesktop.org/git/drm-intel into drm-fixes
>   Merge branch 'msm-fixes-4.12-rc4' of
> git://people.freedesktop.org/~robclark/linux into drm-fixes
>   Merge branch 'drm-fixes-4.12' of
> git://people.freedesktop.org/~agd5f/linux into drm-fixes
>   Merge tag 'exynos-drm-fixes-for-v4.12' of
> git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes
>
> Eric Anholt (2):
>   drm/msm: Expose our reservation object when exporting a dmabuf.
>   drm/msm: Reuse dma_fence_release.
>
> Hans de Goede (1):
>   drm/i915: Fix new -Wint-in-bool-context gcc compiler warning
>
> Hoegeun Kwon (2):
>   drm/exynos: dsi: Fix the parse_dt function
>   drm/exynos: dsi: Remove bridge node reference in removal
>
> Inki Dae (1):
>   drm/exynos: clean up description of exynos_drm_crtc
>
> Jani Nikula (1):
>   Merge tag 'gvt-fixes-2017-05-25' of
> https://github.com/01org/gvt-linux into drm-intel-fixes
>
> Joonas Lahtinen (1):
>   drm/i915: Do not sync RCU during shrinking
>
> Jordan Crouse (2):
>   drm/msm: Take the mutex before calling msm_gem_new_impl
>   drm/msm: Fix the check for the command size
>
> Leo Liu (1):
>   drm/amdgpu: Program ring for vce instance 1 at its register space
>
> Matthew Auld (1):
>   drm/i915: use vma->size for appgtt allocate_va_range
>
> Philipp Zabel (1):
>   drm/msm: for array in-fences, check if all backing fences are
> from our own context before waiting
>
> Rob Clark (4):
>   drm/msm: select PM_OPP
>   drm/msm/mdp5: use __drm_atomic_helper_plane_duplicate_state()
>   drm/msm/gpu: check legacy clk names in get_clocks()
>   drm/msm/mdp5: release hwpipe(s) for unused planes
>
> Tobias Klauser (1):
>   drm/msm: constify irq_domain_ops
>
> Ville Syrjälä (1):
>   drm/i915: Stop pretending to mask/unmask LPE audio interrupts
>
>  drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 95 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c   |  8 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  5 +-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c   | 26 +++
>  drivers/gpu/drm/i915/gvt/execlist.c   | 30 ---
>  drivers/gpu/drm/i915/gvt/handlers.c   | 30 ---
>  drivers/gpu/drm/i915/i915_drv.c   |  4 -
>  drivers/gpu/drm/i915/i915_gem_gtt.c   |  2 +-
>  drivers/gpu/drm/i915/i915_gem_shrinker.c  |  5 --
>  drivers/gpu/drm/i915/i915_irq.c   | 15 ++--
>  drivers/gpu/drm/i915/i915_reg.h   |  2 +-
>  drivers/gpu/drm/i915/intel_lpe_audio.c| 36 -
>  drivers/gpu/drm/i915/intel_lrc.c  |  2 +-
>  drivers/gpu/drm/i915/selftests/i915_gem_context.c |  8 +-
>  drivers/gpu/drm/msm/Kconfig   |  1 +
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c  |  2 +-
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c |  9 ++-
>  drivers/gpu/drm/msm/msm_drv.c |  1 +
>  drivers/gpu/drm/msm/msm_drv.h |  1 +
>  drivers/gpu/drm/msm/msm_fence.c   | 10 +--
>  drivers/gpu/drm/msm/msm_gem.c |  6 ++
>  drivers/gpu/drm/msm/msm_gem_prime.c   |  7 ++
>  drivers/gpu/drm/msm/msm_gem_submit.c  | 14 ++--
>  drivers/gpu/drm/msm/msm_gpu.c 

[Bug 101229] Global screen tearing (scrolling, Hz miss-match?)

[bugzilla-daemon]

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

--- Comment #8 from Michel Dänzer  ---
To prevent tearing, you need to either choose OpenGL instead of XRender and an
appropriate tearing prevention setting, or enable TearFree with

xrandr --output eDP --set TearFree on

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

[Bug 101254] VDPAU videos take forever to start in different applications

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 QA Contact|xorg-t...@lists.x.org   |dri-devel@lists.freedesktop
   ||.org
   Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
   ||.org
Product|xorg|Mesa
  Component|Driver/Radeon   |Drivers/Gallium/radeonsi
Version|git |unspecified

--- Comment #1 from Michel Dänzer  ---
Mesa or the kernel is more likely.

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

[Bug 101266] segfault in libvdpau_radeonsi.so.1.0.0 when opening certain videos

[bugzilla-daemon]

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

Bug ID: 101266
   Summary: segfault in libvdpau_radeonsi.so.1.0.0 when opening
certain videos
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: nsane...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 131631
  --> https://bugs.freedesktop.org/attachment.cgi?id=131631&action=edit
gdb output of `run` and `thread apply all backtrace full`

When opening certain videos in vlc, I end up with a segfault in
libvdpau_radeonsi.so.1.0.0.  This has been going on for some time so I
eventually decided to rebuild all relevant packages with debugging flags for a
good backtrace.


Output of `uname --all`:

> Linux Home-PC 4.11.2-gentoo-r1 #2 SMP Tue May 23 00:27:39 EDT 2017 x86_64 
> Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz GenuineIntel GNU/Linux

Output of `glxinfo -B`:


> name of display: :0
> display: :0  screen: 0
> direct rendering: Yes
> Extended renderer info (GLX_MESA_query_renderer):
> Vendor: X.Org (0x1002)
> Device: AMD BONAIRE (DRM 2.49.0 / 4.11.2-gentoo-r1, LLVM 4.0.0) (0x6658)
> Version: 17.2.0
> Accelerated: yes
> Video memory: 2048MB
> Unified memory: no
> Preferred profile: core (0x1)
> Max core profile version: 4.5
> Max compat profile version: 3.0
> Max GLES1 profile version: 1.1
> Max GLES[23] profile version: 3.1
> OpenGL vendor string: X.Org
> OpenGL renderer string: Gallium 0.4 on AMD BONAIRE (DRM 2.49.0 / 
> 4.11.2-gentoo-r1, LLVM 4.0.0)
> OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.2.0-devel 
> (git-f42fb0012a)
> OpenGL core profile shading language version string: 4.50
> OpenGL core profile context flags: (none)
> OpenGL core profile profile mask: core profile
> 
> OpenGL version string: 3.0 Mesa 17.2.0-devel (git-f42fb0012a)
> OpenGL shading language version string: 1.30
> OpenGL context flags: (none)
> 
> OpenGL ES profile version string: OpenGL ES 3.1 Mesa 17.2.0-devel 
> (git-f42fb0012a)
> OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10

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

[Bug 101266] segfault in libvdpau_radeonsi.so.1.0.0 when opening certain videos

[bugzilla-daemon]

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

P. Levine  changed:

   What|Removed |Added

   Keywords||have-backtrace

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

[drm:drm-syncobj-sem 1/6] htmldocs: drivers/gpu/drm/drm_syncobj.c:88: warning: No description found for parameter 'syncobj'

[kbuild test robot]

tree:   git://people.freedesktop.org/~airlied/linux.git drm-syncobj-sem
head:   78159d5e37ad792306dcb6e1046b67fe0a3bde6e
commit: 6c72d92e70f50824c96d6c6f662ca237a50b81a5 [1/6] drm: introduce sync 
objects (v3)
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick 
(https://www.imagemagick.org)
   arch/x86/include/asm/uaccess_32.h:1: warning: no structured comments found
   include/linux/init.h:1: warning: no structured comments found
   include/linux/mod_devicetable.h:686: warning: Excess 
struct/union/enum/typedef member 'ver_major' description in 'fsl_mc_device_id'
   include/linux/mod_devicetable.h:686: warning: Excess 
struct/union/enum/typedef member 'ver_minor' description in 'fsl_mc_device_id'
   kernel/sched/core.c:2088: warning: No description found for parameter 'rf'
   kernel/sched/core.c:2088: warning: Excess function parameter 'cookie' 
description in 'try_to_wake_up_local'
   include/linux/kthread.h:26: warning: Excess function parameter '...' 
description in 'kthread_create'
   kernel/sys.c:1: warning: no structured comments found
   include/linux/device.h:969: warning: No description found for parameter 
'dma_ops'
   drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
   include/linux/iio/iio.h:597: warning: No description found for parameter 
'trig_readonly'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'indio_dev'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'trig'
   include/linux/device.h:970: warning: No description found for parameter 
'dma_ops'
   include/linux/usb/gadget.h:230: warning: No description found for parameter 
'claimed'
   include/linux/usb/gadget.h:230: warning: No description found for parameter 
'enabled'
   include/linux/usb/gadget.h:408: warning: No description found for parameter 
'quirk_altset_not_supp'
   include/linux/usb/gadget.h:408: warning: No description found for parameter 
'quirk_stall_not_supp'
   include/linux/usb/gadget.h:408: warning: No description found for parameter 
'quirk_zlp_not_supp'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'set_busid'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'irq_handler'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'irq_preinstall'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'irq_postinstall'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'irq_uninstall'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'debugfs_init'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'gem_open_object'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'gem_close_object'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'prime_handle_to_fd'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'prime_fd_to_handle'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'gem_prime_export'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'gem_prime_import'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'gem_prime_pin'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'gem_prime_unpin'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'gem_prime_res_obj'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'gem_prime_get_sg_table'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'gem_prime_import_sg_table'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'gem_prime_vmap'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'gem_prime_vunmap'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'gem_prime_mmap'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'gem_vm_ops'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'major'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'minor'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'patchlevel'
   include/drm/drm_drv.h:525: warning: No description found for parameter 'name'
   include/drm/drm_drv.h:525: warning: No description found for parameter 'desc'
   include/drm/drm_drv.h:525: warning: No description found for parameter 'date'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'driver_features'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'ioctls'
   include/drm/drm_drv.h:525: warning: No description found for parameter 
'num_ioctls'
   include/drm/drm_drv.h:525: warning: No description found for parameter 'fops'
   include/drm/drm_color_mgmt.h:1: w

Re: [Intel-gfx] [PATCH 16/37] drm/hdlcd|mali: Drop drm_vblank_cleanup

[Daniel Vetter]

On Wed, May 31, 2017 at 05:57:07PM +0100, Liviu Dudau wrote:
> On Wed, May 31, 2017 at 06:41:05PM +0200, Daniel Vetter wrote:
> > On Wed, May 31, 2017 at 1:22 PM, Liviu Dudau  wrote:
> > > On Wed, May 31, 2017 at 01:03:34PM +0200, Daniel Vetter wrote:
> > >> On Wed, May 31, 2017 at 12:57 PM, Liviu Dudau  
> > >> wrote:
> > >> > On Wed, May 24, 2017 at 04:51:51PM +0200, Daniel Vetter wrote:
> > >> >> IRQs are properly shut down, so it almost works as race-free shutdown.
> > >> >> Except the irq is stopped after the vblank stuff, so boom anyway.
> > >> >> Proper way would be to call drm_atomic_helper_shutdown before any of
> > >> >> the kms things gets stopped. So no harm in removing the
> > >> >> drm_vblank_cleanup here really.
> > >> >
> > >> > Slightly confused on the implied message in the commit text: is 
> > >> > "Proper way
> > >> > would be to call drm_atomic_helper_shutdown" a hint? A promise of a 
> > >> > future
> > >> > patch? A message to the future us on how to fix things if they blow up?
> > >> >
> > >> > If calling drm_atomic_helper_shutdown() is the proper thing to do, why 
> > >> > does the
> > >> > patch (and the series) avoids doing that? Lack of understanding of the 
> > >> > driver's
> > >> > internal workings? Then I want to help, if I can understand the new 
> > >> > direction.
> > >>
> > >> Yes, I wanted to not make things worse. If you look at the overall
> > >> result (especially last patch) I'm also trying to better document
> > >> stuff in the vblank area, but summarized, if you want to make sure
> > >> that vblank processing has stopped, you need to call drm_vblank_off on
> > >> each active crtc. The simplest way to get that is by using
> > >> drm_atomic_helper_shutdown(). Calling drm_vblank_cleanup doesn't
> > >> really do anything useful (see the last patch for the only valid
> > >> usecase there ever was).
> > >
> > > OK, so there should be a follow up patch adding 
> > > drm_atomic_helper_shutdown(). I guess
> > > I need to call dibs on it? :)
> > 
> > I googled what "to call dibs on smth" means and still can't figure out
> > what you mean here. Can you pls explain?
> 
> Means I put my name on it. Urban dictionary on "call dibs" gives it a very 
> gender
> specific usage, my intent was to convey the message that I will take it on my 
> TODO list.

Ah ok, thanks for explaining. I was indeed thrown off be the ub entry ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 16/37] drm/hdlcd|mali: Drop drm_vblank_cleanup

[Daniel Vetter]

On Wed, May 31, 2017 at 05:37:34PM +0100, Liviu Dudau wrote:
> On Wed, May 24, 2017 at 04:51:51PM +0200, Daniel Vetter wrote:
> > IRQs are properly shut down, so it almost works as race-free shutdown.
> > Except the irq is stopped after the vblank stuff, so boom anyway.
> > Proper way would be to call drm_atomic_helper_shutdown before any of
> > the kms things gets stopped. So no harm in removing the
> > drm_vblank_cleanup here really.
> > 
> > Same story for both hdlcd and mali.
> > 
> > v2: Move misplaced malidp hunk to this patch (Liviu).
> > 
> > Cc: Liviu Dudau 
> > Cc: Brian Starkey 
> > Signed-off-by: Daniel Vetter 
> 
> On the assumption that a subsequent patch will fix the issue highlighted in
> the commit message (doesn't have to be part of this series):
> 
> Acked-by: Liviu Dudau 
> 
> I'm assuming that you are going to carry this patch through one of your trees,
> so I will not pull it into mali-dp tree.

Ok, applied to drm-misc-next, thanks for checking things.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] Implementing Miracast

[Daniel Kasak]

Any news? Seems every TV I bump into these days has Miracast support ...

On Wed, Mar 8, 2017 at 12:24 AM, Martin Peres
 wrote:
> On 07/03/17 05:00, Daniel Kasak wrote:
>>
>> Any news on this? I'm also interested :)
>>
>> Dan
>
>
> Hmm, good question! I will ping internally and see if we are ready to
> release something as an RFC.
>
> Martin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel