Re: [Intel-gfx] [PATCH] drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

[Sean Paul]

On Wed, Jan 17, 2018 at 12:51:08PM +0100, Maarten Lankhorst wrote:
> From: "Leo (Sunpeng) Li" 
> 
> During a non-blocking commit, it is possible to return before the
> commit_tail work is queued (-ERESTARTSYS, for example).
> 
> Since a reference on the crtc commit object is obtained for the pending
> vblank event when preparing the commit, the above situation will leave
> us with an extra reference.
> 
> Therefore, if the commit_tail worker has not consumed the event at the
> end of a commit, release it's reference.
> 
> Changes since v1:
> - Also check for state->event->base.completion being set, to
>   handle the case where stall_checks() fails in setup_crtc_commit().
> Changes since v2:
> - Add a flag to drm_crtc_commit, to prevent dereferencing a freed event.
>   i915 may unreference the state in a worker.
> 
> Fixes: 24835e442f28 ("drm: reference count event->completion")
> Cc:  # v4.11+
> Signed-off-by: Leo (Sunpeng) Li 
> Acked-by: Harry Wentland  #v1
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 15 +++
>  include/drm/drm_atomic.h|  9 +
>  2 files changed, 24 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index ab4032167094..ae3cbfe9e01c 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1878,6 +1878,8 @@ int drm_atomic_helper_setup_commit(struct 
> drm_atomic_state *state,
>   new_crtc_state->event->base.completion = >flip_done;
>   new_crtc_state->event->base.completion_release = 
> release_crtc_commit;
>   drm_crtc_commit_get(commit);
> +
> + commit->abort_completion = true;
>   }
>  
>   for_each_oldnew_connector_in_state(state, conn, old_conn_state, 
> new_conn_state, i) {
> @@ -3421,8 +3423,21 @@ EXPORT_SYMBOL(drm_atomic_helper_crtc_duplicate_state);
>  void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc_state *state)
>  {
>   if (state->commit) {
> + /*
> +  * In the event that a non-blocking commit returns
> +  * -ERESTARTSYS before the commit_tail work is queued, we will
> +  * have an extra reference to the commit object. Release it, if
> +  * the event has not been consumed by the worker.
> +  *
> +  * state->event may be freed, so we can't directly look at
> +  * state->event->base.completion.
> +  */
> + if (state->event && state->commit->abort_completion)
> + drm_crtc_commit_put(state->commit);
> +
>   kfree(state->commit->event);
>   state->commit->event = NULL;
> +
>   drm_crtc_commit_put(state->commit);
>   }
>  
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index 1c27526c499e..cf13842a6dbd 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -134,6 +134,15 @@ struct drm_crtc_commit {
>* _pending_vblank_event pointer to clean up private events.
>*/
>   struct drm_pending_vblank_event *event;
> +
> + /**
> +  * @abort_completion:
> +  *
> +  * A flag that's set after drm_atomic_helper_setup_commit takes a second
> +  * reference for the completion of $drm_crtc_state.event. It's used by
> +  * the free code to remove the second reference if commit fails.
> +  */

Perhaps it's just me, or I'm oversimplifying the problem. I think this would
be easier to understand if we just dropped the additional reference at the point
of failure (ie: in swap_state). That way we don't have to add Yet Another Piece
Of State.

Sean

> + bool abort_completion;
>  };
>  
>  struct __drm_planes_state {
> -- 
> 2.15.1
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] [v2] drm/exynos: g2d: use monotonic timestamps

[Tobias Jakobi]

Hey Arnd,

looks good to me!

Reviewed-by: Tobias Jakobi 

- Tobias


Arnd Bergmann wrote:
> The exynos DRM driver uses real-time 'struct timeval' values
> for exporting its timestamps to user space. This has multiple
> problems:
> 
> 1. signed seconds overflow in y2038
> 2. the 'struct timeval' definition is deprecated in the kernel
> 3. time may jump or go backwards after a 'settimeofday()' syscall
> 4. other DRM timestamps are in CLOCK_MONOTONIC domain, so they
>can't be compared
> 5. exporting microseconds requires a division by 1000, which may
>be slow on some architectures.
> 
> The code existed in two places before, but the IPP portion was
> removed in 8ded59413ccc ("drm/exynos: ipp: Remove Exynos DRM
> IPP subsystem"), so we no longer need to worry about it.
> 
> Ideally timestamps should just use 64-bit nanoseconds instead, but
> of course we can't change that now. Instead, this tries to address
> the first four points above by using monotonic 'timespec' values.
> 
> According to Tobias Jakobi, user space doesn't care about the
> timestamp at the moment, so we can change the format. Even if
> there is something looking at them, it will work just fine with
> monotonic times as long as the application only looks at the
> relative values between two events.
> 
> Link: https://patchwork.kernel.org/patch/10038593/
> Cc: Tobias Jakobi 
> Signed-off-by: Arnd Bergmann 
> ---
> v2: rebased to what will be in 4.15, now that ipp is gone,
> updated changelog text based on input from Tobias.
> ---
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index 2b8bf2dd6387..9effe40f5fa5 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -926,7 +926,7 @@ static void g2d_finish_event(struct g2d_data *g2d, u32 
> cmdlist_no)
>   struct drm_device *drm_dev = g2d->subdrv.drm_dev;
>   struct g2d_runqueue_node *runqueue_node = g2d->runqueue_node;
>   struct drm_exynos_pending_g2d_event *e;
> - struct timeval now;
> + struct timespec64 now;
>  
>   if (list_empty(_node->event_list))
>   return;
> @@ -934,9 +934,9 @@ static void g2d_finish_event(struct g2d_data *g2d, u32 
> cmdlist_no)
>   e = list_first_entry(_node->event_list,
>struct drm_exynos_pending_g2d_event, base.link);
>  
> - do_gettimeofday();
> + ktime_get_ts64();
>   e->event.tv_sec = now.tv_sec;
> - e->event.tv_usec = now.tv_usec;
> + e->event.tv_usec = now.tv_nsec / NSEC_PER_USEC;
>   e->event.cmdlist_no = cmdlist_no;
>  
>   drm_send_event(drm_dev, >base);
> 

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

[Bug 102800] DRI_PRIME regression- radeon: Failed to allocate virtual address for buffer

[bugzilla-daemon]

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

--- Comment #19 from higu...@gmx.net ---
Created attachment 136810
  --> https://bugs.freedesktop.org/attachment.cgi?id=136810=edit
Dmesg with patch

Here is the dmesg with the patch applied

-- 
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 01/19] drm/fourcc: Add a function to tell if the format embeds alpha

[Ayan Halder]

On Tue, Jan 16, 2018 at 09:17:24PM +0100, Maxime Ripard wrote:
> Hi Ayan,
> 
> On Mon, Jan 15, 2018 at 03:47:44PM +, Ayan Halder wrote:
> > On Tue, Jan 09, 2018 at 02:28:33PM +0100, Maxime Ripard wrote:
> > > On Tue, Jan 09, 2018 at 02:29:58PM +0200, Laurent Pinchart wrote:
> > > > On Tuesday, 9 January 2018 12:56:20 EET Maxime Ripard wrote:
> > > > > There's a bunch of drivers that duplicate the same function to know 
> > > > > if a
> > > > > particular format embeds an alpha component or not.
> > > > >
> > > > > Let's create a helper to avoid duplicating that logic.
> > > > >
> > > > > Cc: Boris Brezillon 
> > > > > Cc: Eric Anholt 
> > > > > Cc: Inki Dae 
> > > > > Cc: Joonyoung Shim 
> > > > > Cc: Kyungmin Park 
> > > > > Cc: Laurent Pinchart 
> > > > > Cc: Mark Yao 
> > > > > Cc: Seung-Woo Kim 
> > > > > Signed-off-by: Maxime Ripard 
> > > > > ---
> > > > >  drivers/gpu/drm/drm_fourcc.c | 43 
> > > > > +-
> > > > >  include/drm/drm_fourcc.h |  1 +-
> > > > >  2 files changed, 44 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_fourcc.c 
> > > > > b/drivers/gpu/drm/drm_fourcc.c
> > > > > index 9c0152df45ad..6e6227d6a46b 100644
> > > > > --- a/drivers/gpu/drm/drm_fourcc.c
> > > > > +++ b/drivers/gpu/drm/drm_fourcc.c
> > > > > @@ -348,3 +348,46 @@ int drm_format_plane_height(int height, uint32_t
> > > > > format, int plane) return height / info->vsub;
> > > > >  }
> > > > >  EXPORT_SYMBOL(drm_format_plane_height);
> > > > > +
> > > > > +/**
> > > > > + * drm_format_has_alpha - get whether the format embeds an alpha 
> > > > > component
> > > > > + * @format: pixel format (DRM_FORMAT_*)
> > > > > + *
> > > > > + * Returns:
> > > > > + * true if the format embeds an alpha component, false otherwise.
> > > > > + */
> > > > > +bool drm_format_has_alpha(uint32_t format)
> > > > > +{
> > > > > + switch (format) {
> > > > > + case DRM_FORMAT_ARGB:
> > > > > + case DRM_FORMAT_ABGR:
> > > > > + case DRM_FORMAT_RGBA:
> > > > > + case DRM_FORMAT_BGRA:
> > > > > + case DRM_FORMAT_ARGB1555:
> > > > > + case DRM_FORMAT_ABGR1555:
> > > > > + case DRM_FORMAT_RGBA5551:
> > > > > + case DRM_FORMAT_BGRA5551:
> > > > > + case DRM_FORMAT_ARGB:
> > > > > + case DRM_FORMAT_ABGR:
> > > > > + case DRM_FORMAT_RGBA:
> > > > > + case DRM_FORMAT_BGRA:
> > > > > + case DRM_FORMAT_ARGB2101010:
> > > > > + case DRM_FORMAT_ABGR2101010:
> > > > > + case DRM_FORMAT_RGBA1010102:
> > > > > + case DRM_FORMAT_BGRA1010102:
> > > > > + case DRM_FORMAT_AYUV:
> > > > > + case DRM_FORMAT_XRGB_A8:
> > > > > + case DRM_FORMAT_XBGR_A8:
> > > > > + case DRM_FORMAT_RGBX_A8:
> > > > > + case DRM_FORMAT_BGRX_A8:
> > > > > + case DRM_FORMAT_RGB888_A8:
> > > > > + case DRM_FORMAT_BGR888_A8:
> > > > > + case DRM_FORMAT_RGB565_A8:
> > > > > + case DRM_FORMAT_BGR565_A8:
> > > > > + return true;
> > > > > +
> > > > > + default:
> > > > > + return false;
> > > > > + }
> > > > > +}
> > > > > +EXPORT_SYMBOL(drm_format_has_alpha);
> > > >
> > > > How about adding the information to struct drm_format_info instead ?
> > > > drm_format_has_alpha() could then be implemented as
> > > >
> > > > bool drm_format_has_alpha(uint32_t format)
> > > > {
> > > > const struct drm_format_info *info;
> > > >
> > > > info = drm_format_info(format);
> > > > return info ? info->has_alpha : false;
> > > > }
> > >
> > > I considered it, and wasn't too sure about if adding more fields to
> > > drm_format_info was ok. I can definitely do it that way.
> >
> > Are you going to send an updated patch with the change mentioned here.
> > Or should I update my patch (https://patchwork.kernel.org/patch/10161023/)
> > and change the type of '.alpha' to boolean to denote if the color
> > format has an alpha channel or not.
> 
> Yes, I already had those patches ready. I'm just waiting for the
> discussion on the alpha property to settle before sending a v2.
>
Thanks for your response. I will hold on my changes
(https://patchwork.kernel.org/patch/10161339/) as it depends on your patch. 
> Maxime
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com


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

[Bug 104001] GPU driver hung when start steam client while playback video on Youtube (it occurs on latest staging kernel)

[bugzilla-daemon]

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

--- Comment #16 from mikhail.v.gavri...@gmail.com ---
Created attachment 136809
  --> https://bugs.freedesktop.org/attachment.cgi?id=136809=edit
dmesg with 4.15.0-rc4 amd-staging-drm-next with SysRq : Show State

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

Re: [PATCH] drm: Remove bridge support from legacy helpers

[Sean Paul]

On Wed, Jan 17, 2018 at 07:27:03PM +0200, Laurent Pinchart wrote:
> DRM bridges are only used by atomic drivers, and none of them use the
> legacy helpers. Drop bridge support from those helpers to prepare for
> making the bridge operations atomic-aware.
> 
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/drm_crtc_helper.c | 32 
>  1 file changed, 32 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
> b/drivers/gpu/drm/drm_crtc_helper.c
> index 5a84c3bc915d..d365526be8b5 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -152,14 +152,10 @@ drm_encoder_disable(struct drm_encoder *encoder)
>   if (!encoder_funcs)
>   return;
>  
> - drm_bridge_disable(encoder->bridge);
> -
>   if (encoder_funcs->disable)
>   (*encoder_funcs->disable)(encoder);
>   else if (encoder_funcs->dpms)
>   (*encoder_funcs->dpms)(encoder, DRM_MODE_DPMS_OFF);
> -
> - drm_bridge_post_disable(encoder->bridge);
>  }
>  
>  static void __drm_helper_disable_unused_functions(struct drm_device *dev)
> @@ -318,13 +314,6 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
>   if (!encoder_funcs)
>   continue;
>  
> - ret = drm_bridge_mode_fixup(encoder->bridge,
> - mode, adjusted_mode);
> - if (!ret) {
> - DRM_DEBUG_KMS("Bridge fixup failed\n");
> - goto done;
> - }
> -
>   encoder_funcs = encoder->helper_private;
>   if (encoder_funcs->mode_fixup) {
>   if (!(ret = encoder_funcs->mode_fixup(encoder, mode,
> @@ -356,13 +345,9 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
>   if (!encoder_funcs)
>   continue;
>  
> - drm_bridge_disable(encoder->bridge);
> -
>   /* Disable the encoders as the first thing we do. */
>   if (encoder_funcs->prepare)
>   encoder_funcs->prepare(encoder);
> -
> - drm_bridge_post_disable(encoder->bridge);
>   }
>  
>   drm_crtc_prepare_encoders(dev);
> @@ -390,8 +375,6 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
>   mode->base.id, mode->name);
>   if (encoder_funcs->mode_set)
>   encoder_funcs->mode_set(encoder, mode, adjusted_mode);
> -
> - drm_bridge_mode_set(encoder->bridge, mode, adjusted_mode);
>   }
>  
>   /* Now enable the clocks, plane, pipe, and connectors that we set up. */
> @@ -406,12 +389,8 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
>   if (!encoder_funcs)
>   continue;
>  
> - drm_bridge_pre_enable(encoder->bridge);
> -
>   if (encoder_funcs->commit)
>   encoder_funcs->commit(encoder);
> -
> - drm_bridge_enable(encoder->bridge);
>   }
>  
>   /* Calculate and store various constants which
> @@ -809,25 +788,14 @@ static int drm_helper_choose_encoder_dpms(struct 
> drm_encoder *encoder)
>  /* Helper which handles bridge ordering around encoder dpms */
>  static void drm_helper_encoder_dpms(struct drm_encoder *encoder, int mode)
>  {
> - struct drm_bridge *bridge = encoder->bridge;
>   const struct drm_encoder_helper_funcs *encoder_funcs;
>  
>   encoder_funcs = encoder->helper_private;
>   if (!encoder_funcs)
>   return;
>  
> - if (mode == DRM_MODE_DPMS_ON)
> - drm_bridge_pre_enable(bridge);
> - else
> - drm_bridge_disable(bridge);
> -
>   if (encoder_funcs->dpms)
>   encoder_funcs->dpms(encoder, mode);
> -
> - if (mode == DRM_MODE_DPMS_ON)
> - drm_bridge_enable(bridge);
> - else
> - drm_bridge_post_disable(bridge);
>  }
>  
>  static int drm_helper_choose_crtc_dpms(struct drm_crtc *crtc)
> -- 
> Regards,
> 
> Laurent Pinchart
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/panel: panasonic-vvx10f034n00: Fix wuxga_nt_panel_disable() return value

[Sean Paul]

On Wed, Jan 17, 2018 at 05:01:07PM +, Philippe CORNU wrote:
> Hi Sean,
> 
> On 01/16/2018 11:22 PM, Sean Paul wrote:
> > Return value for mipi_dsi_shutdown_peripheral() is unchecked.
> > Check it and return any errors if they come up. Even if
> > mipi_dsi_shutdown_peripheral() fails, continue attempting to
> > disable.
> > 
> > Cc: Philippe Cornu 
> > Signed-off-by: Sean Paul 
> > ---
> >   drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c | 5 +++--
> >   1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c 
> > b/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
> > index 7f915f706fa6..91dc5a6b14f9 100644
> > --- a/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
> > +++ b/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
> > @@ -72,11 +72,12 @@ static int wuxga_nt_panel_on(struct wuxga_nt_panel 
> > *wuxga_nt)
> >   static int wuxga_nt_panel_disable(struct drm_panel *panel)
> >   {
> > struct wuxga_nt_panel *wuxga_nt = to_wuxga_nt_panel(panel);
> > +   int ret;
> >   
> > if (!wuxga_nt->enabled)
> > return 0;
> >   
> > -   mipi_dsi_shutdown_peripheral(wuxga_nt->dsi);
> > +   ret = mipi_dsi_shutdown_peripheral(wuxga_nt->dsi);
> >   
> > if (wuxga_nt->backlight) {
> > wuxga_nt->backlight->props.power = FB_BLANK_POWERDOWN;
> > @@ -86,7 +87,7 @@ static int wuxga_nt_panel_disable(struct drm_panel *panel)
> >   
> > wuxga_nt->enabled = false;
> >   
> > -   return 0;
> > +   return ret;
> >   }
> >   
> >   static int wuxga_nt_panel_unprepare(struct drm_panel *panel)
> > 
> 
> Many thanks for the patch.
> 
> I agree it is better to continue attempting to disable if 
> mipi_dsi_shutdown_peripheral() fails.
> 
> Looking more in details in this driver:
> * backlight_update_status() may also use a ret value...
> * wuxga_nt_panel_on() should simply do "return 
> mipi_dsi_turn_on_peripheral(dsi);"
> ... but it is not really part of your patch (and mine initially), maybe 
> TODOs for later : )
> 

Thanks for your review, Philippe, I've applied this to -misc-next. I'm stuck in
meetings all day today, so there's a good chance I'll get to the rest of the
TODOs while I sit here :-)

Sean

> 
> Reviewed-by: Philippe Cornu 
> 
> Philippe :-)

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Remove bridge support from legacy helpers

[Laurent Pinchart]

DRM bridges are only used by atomic drivers, and none of them use the
legacy helpers. Drop bridge support from those helpers to prepare for
making the bridge operations atomic-aware.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/drm_crtc_helper.c | 32 
 1 file changed, 32 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 5a84c3bc915d..d365526be8b5 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -152,14 +152,10 @@ drm_encoder_disable(struct drm_encoder *encoder)
if (!encoder_funcs)
return;
 
-   drm_bridge_disable(encoder->bridge);
-
if (encoder_funcs->disable)
(*encoder_funcs->disable)(encoder);
else if (encoder_funcs->dpms)
(*encoder_funcs->dpms)(encoder, DRM_MODE_DPMS_OFF);
-
-   drm_bridge_post_disable(encoder->bridge);
 }
 
 static void __drm_helper_disable_unused_functions(struct drm_device *dev)
@@ -318,13 +314,6 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
if (!encoder_funcs)
continue;
 
-   ret = drm_bridge_mode_fixup(encoder->bridge,
-   mode, adjusted_mode);
-   if (!ret) {
-   DRM_DEBUG_KMS("Bridge fixup failed\n");
-   goto done;
-   }
-
encoder_funcs = encoder->helper_private;
if (encoder_funcs->mode_fixup) {
if (!(ret = encoder_funcs->mode_fixup(encoder, mode,
@@ -356,13 +345,9 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
if (!encoder_funcs)
continue;
 
-   drm_bridge_disable(encoder->bridge);
-
/* Disable the encoders as the first thing we do. */
if (encoder_funcs->prepare)
encoder_funcs->prepare(encoder);
-
-   drm_bridge_post_disable(encoder->bridge);
}
 
drm_crtc_prepare_encoders(dev);
@@ -390,8 +375,6 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
mode->base.id, mode->name);
if (encoder_funcs->mode_set)
encoder_funcs->mode_set(encoder, mode, adjusted_mode);
-
-   drm_bridge_mode_set(encoder->bridge, mode, adjusted_mode);
}
 
/* Now enable the clocks, plane, pipe, and connectors that we set up. */
@@ -406,12 +389,8 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
if (!encoder_funcs)
continue;
 
-   drm_bridge_pre_enable(encoder->bridge);
-
if (encoder_funcs->commit)
encoder_funcs->commit(encoder);
-
-   drm_bridge_enable(encoder->bridge);
}
 
/* Calculate and store various constants which
@@ -809,25 +788,14 @@ static int drm_helper_choose_encoder_dpms(struct 
drm_encoder *encoder)
 /* Helper which handles bridge ordering around encoder dpms */
 static void drm_helper_encoder_dpms(struct drm_encoder *encoder, int mode)
 {
-   struct drm_bridge *bridge = encoder->bridge;
const struct drm_encoder_helper_funcs *encoder_funcs;
 
encoder_funcs = encoder->helper_private;
if (!encoder_funcs)
return;
 
-   if (mode == DRM_MODE_DPMS_ON)
-   drm_bridge_pre_enable(bridge);
-   else
-   drm_bridge_disable(bridge);
-
if (encoder_funcs->dpms)
encoder_funcs->dpms(encoder, mode);
-
-   if (mode == DRM_MODE_DPMS_ON)
-   drm_bridge_enable(bridge);
-   else
-   drm_bridge_post_disable(bridge);
 }
 
 static int drm_helper_choose_crtc_dpms(struct drm_crtc *crtc)
-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 2/6] backlight/generic-bl: remove DRIVER1 state

[Daniel Vetter]

On Wed, Jan 17, 2018 at 04:44:00PM +, Daniel Thompson wrote:
> On 17/01/18 14:01, Daniel Vetter wrote:
> > Nothing in the entire tree ever sets this, which means this is dead
> > code. Remove it.
> > 
> > Cc: Lee Jones 
> > Cc: Daniel Thompson 
> > Cc: Jingoo Han 
> > Signed-off-by: Daniel Vetter 
> 
> Not sure whether to ack this one or not.
> 
> There is nothing wrong with the change but having taken a closer look the
> driver seems like it exists mostly to allow mach-XXX code to plug in
> function pointers and we don't do that sort of thing any more.
> 
> I think the entire driver is dead code!

Well I can also supply a patch to outright nuke the code, but figuring out
whether that's the right thing to do is definitely way above may pay grade
:-)

I only really stitched these together after a long discussion with Meghana
about why backlight seems to have 3+ different ways to enable/disable a
backlight. Just trying to help a bit with getting the
backlight_enable/disable stuff going, so that long-term, at least for
newer drivers, we have one blessed way to do that.

btw that kind of display pm simplification matches what we've done when
implementing atomic modesetting about 3 years ago: We've smashed all the
various power states drm (and fbdev/fbcon) knew about into a simple "is it
on?" boolean. Todays digital hw doesn't really know anything in-between.
Ofc there's tons of components to switch on/off to get the entire display
pipe up, and they might want different autosuspend delays to optimize the
overall system, but that's orthogonal (well, driver internal
implementation detail) really.

Cheers, Daniel

> 
> 
> Daniel.
> 
> 
> > --- drivers/video/backlight/generic_bl.c | 5 - 1 file changed, 5
> > deletions(-)
> > 
> > diff --git a/drivers/video/backlight/generic_bl.c
> > b/drivers/video/backlight/generic_bl.c index
> > 67dfb939a514..4dea91acea13 100644 ---
> > a/drivers/video/backlight/generic_bl.c +++
> > b/drivers/video/backlight/generic_bl.c @@ -21,9 +21,6 @@ static int
> > genericbl_intensity; static struct backlight_device
> > *generic_backlight_device; static struct generic_bl_info *bl_machinfo;
> > -/* Flag to signal when the battery is low */ -#define
> > GENERICBL_BATTLOW   BL_CORE_DRIVER1 - static int
> > genericbl_send_intensity(struct backlight_device *bd) { int intensity
> > = bd->props.brightness; @@ -34,8 +31,6 @@ static int
> > genericbl_send_intensity(struct backlight_device *bd) intensity = 0;
> > if (bd->props.state & BL_CORE_SUSPENDED) intensity = 0; -   if
> > (bd->props.state & GENERICBL_BATTLOW) - intensity &=
> > bl_machinfo->limit_mask; bl_machinfo->set_bl_intensity(intensity);
> > 

-- 
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 v16 05/10] video: backlight: Add devres versions of of_find_backlight

[Daniel Thompson]

On 16/01/18 10:34, Meghana Madhyastha wrote:

Add devm_of_find_backlight and the corresponding release
function because some drivers use devres versions of functions
for acquiring device resources.

Signed-off-by: Meghana Madhyastha 
---
  drivers/video/backlight/backlight.c | 29 +
  include/linux/backlight.h   |  7 +++
  2 files changed, 36 insertions(+)

diff --git a/drivers/video/backlight/backlight.c 
b/drivers/video/backlight/backlight.c
index 7e4a5d77d..b3f76945f 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -620,6 +620,35 @@ struct backlight_device *of_find_backlight(struct device 
*dev)
  }
  EXPORT_SYMBOL(of_find_backlight);
  
+static void devm_backlight_put(void *data)

+{
+   backlight_put(data);


Shouldn't this be using devres_release()?



+}
+
+/**
+  * devm_of_find_backlight - Resource-managed of_find_backlight()
+  * @dev: Device
+  *
+  * Device managed version of of_find_backlight(). The reference on the 
backlight
+  * device is automatically dropped on driver detach.
+  */
+struct backlight_device *devm_of_find_backlight(struct device *dev)
+{
+   struct backlight_device *bd;
+   int ret;
+
+   bd = of_find_backlight(dev);
+   if (IS_ERR_OR_NULL(bd))
+   return bd;
+   ret = devm_add_action(dev, devm_backlight_put, bd);
+   if (ret) {
+   backlight_put(bd);
+   return ERR_PTR(ret);
+   }
+   return bd;
+}
+EXPORT_SYMBOL(devm_of_find_backlight);
+
  static void __exit backlight_class_exit(void)
  {
class_destroy(backlight_class);
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 32ea510da..1d373f5a6 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -215,11 +215,18 @@ of_find_backlight_by_node(struct device_node *node)
  
  #if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)

  struct backlight_device *of_find_backlight(struct device *dev);
+struct backlight_device *devm_of_find_backlight(struct device *dev);
  #else
  static inline struct backlight_device *of_find_backlight(struct device *dev)
  {
return NULL;
  }
+
+static inline struct backlight_device *
+devm_of_find_backlight(struct device *dev)
+{
+   return NULL;
+}
  #endif
  
  #endif



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

Re: [PATCH 6/6] MAINTAINERS: add dri-devel for backlight subsystem patches

[Jingoo Han]

On Wednesday, January 17, 2018 11:53 AM, Daniel Thompson wrote:
> On 17/01/18 14:01, Daniel Vetter wrote:
> > For the same reasons we've added dri-devel for all fbdev patches: Most
> > of the actively developed drivers using this infrastructure are in
> > drivers/gpu/. It just makes sense to cross-post patches and keep
> > aligned. And total activity in the backlight subsystem is miniscule
> > compared to drm overall.
> >
> > Cc: Lee Jones 
> > Cc: Daniel Thompson 
> > Cc: Jingoo Han 
> > Signed-off-by: Daniel Vetter 
> 
> Acked-by: Daniel Thompson 

Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> 
> 
> > ---
> >   MAINTAINERS | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 7691e1025708..6534517f53b6 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -2546,6 +2546,7 @@ BACKLIGHT CLASS/SUBSYSTEM
> >   M:Lee Jones 
> >   M:Daniel Thompson 
> >   M:Jingoo Han 
> > +L: dri-devel@lists.freedesktop.org
> >   T:git 
> > git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git
> >   S:Maintained
> >   F:drivers/video/backlight/
> >

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

[PATCH] [v2] drm/exynos: g2d: use monotonic timestamps

[Arnd Bergmann]

The exynos DRM driver uses real-time 'struct timeval' values
for exporting its timestamps to user space. This has multiple
problems:

1. signed seconds overflow in y2038
2. the 'struct timeval' definition is deprecated in the kernel
3. time may jump or go backwards after a 'settimeofday()' syscall
4. other DRM timestamps are in CLOCK_MONOTONIC domain, so they
   can't be compared
5. exporting microseconds requires a division by 1000, which may
   be slow on some architectures.

The code existed in two places before, but the IPP portion was
removed in 8ded59413ccc ("drm/exynos: ipp: Remove Exynos DRM
IPP subsystem"), so we no longer need to worry about it.

Ideally timestamps should just use 64-bit nanoseconds instead, but
of course we can't change that now. Instead, this tries to address
the first four points above by using monotonic 'timespec' values.

According to Tobias Jakobi, user space doesn't care about the
timestamp at the moment, so we can change the format. Even if
there is something looking at them, it will work just fine with
monotonic times as long as the application only looks at the
relative values between two events.

Link: https://patchwork.kernel.org/patch/10038593/
Cc: Tobias Jakobi 
Signed-off-by: Arnd Bergmann 
---
v2: rebased to what will be in 4.15, now that ipp is gone,
updated changelog text based on input from Tobias.
---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 2b8bf2dd6387..9effe40f5fa5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -926,7 +926,7 @@ static void g2d_finish_event(struct g2d_data *g2d, u32 
cmdlist_no)
struct drm_device *drm_dev = g2d->subdrv.drm_dev;
struct g2d_runqueue_node *runqueue_node = g2d->runqueue_node;
struct drm_exynos_pending_g2d_event *e;
-   struct timeval now;
+   struct timespec64 now;
 
if (list_empty(_node->event_list))
return;
@@ -934,9 +934,9 @@ static void g2d_finish_event(struct g2d_data *g2d, u32 
cmdlist_no)
e = list_first_entry(_node->event_list,
 struct drm_exynos_pending_g2d_event, base.link);
 
-   do_gettimeofday();
+   ktime_get_ts64();
e->event.tv_sec = now.tv_sec;
-   e->event.tv_usec = now.tv_usec;
+   e->event.tv_usec = now.tv_nsec / NSEC_PER_USEC;
e->event.cmdlist_no = cmdlist_no;
 
drm_send_event(drm_dev, >base);
-- 
2.9.0

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

Re: [PATCH v16 03/10] video: backlight: Add of_find_backlight helper in backlight.c

[Daniel Thompson]

On 16/01/18 10:33, Meghana Madhyastha wrote:

Add of_find_backlight, a helper function which is a generic version
of tinydrm_of_find_backlight that can be used by other drivers to avoid
repetition of code and simplify things.

Signed-off-by: Meghana Madhyastha 


Acked-by: Daniel Thompson 



---
Changes in v16:
-Add comment about brightness in of_find_backlight

  drivers/video/backlight/backlight.c | 40 +
  include/linux/backlight.h   | 19 ++
  2 files changed, 59 insertions(+)

diff --git a/drivers/video/backlight/backlight.c 
b/drivers/video/backlight/backlight.c
index 8049e7656..7e4a5d77d 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -580,6 +580,46 @@ struct backlight_device *of_find_backlight_by_node(struct 
device_node *node)
  EXPORT_SYMBOL(of_find_backlight_by_node);
  #endif
  
+/**

+  * of_find_backlight - Get backlight device
+  * @dev: Device
+  *
+  * This function looks for a property named 'backlight' on the DT node
+  * connected to @dev and looks up the backlight device.
+  *
+  * Call backlight_put() to drop the reference on the backlight device.
+  * gpio_backlight uses brightness as power state during probe.
+  *
+  * Returns:
+  * A pointer to the backlight device if found.
+  * Error pointer -EPROBE_DEFER if the DT property is set, but no backlight
+  * device is found.
+  * NULL if there's no backlight property.
+  */
+struct backlight_device *of_find_backlight(struct device *dev)
+{
+   struct backlight_device *bd = NULL;
+   struct device_node *np;
+
+   if (!dev)
+   return NULL;
+
+   if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
+   np = of_parse_phandle(dev->of_node, "backlight", 0);
+   if (np) {
+   bd = of_find_backlight_by_node(np);
+   of_node_put(np);
+   if (!bd)
+   return ERR_PTR(-EPROBE_DEFER);
+   if (!bd->props.brightness)
+   bd->props.brightness = bd->props.max_brightness;
+   }
+   }
+
+   return bd;
+}
+EXPORT_SYMBOL(of_find_backlight);
+
  static void __exit backlight_class_exit(void)
  {
class_destroy(backlight_class);
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 7b6a9a2a3..32ea510da 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -160,6 +160,16 @@ static inline int backlight_disable(struct 
backlight_device *bd)
return backlight_update_status(bd);
  }
  
+/**

+  * backlight_put - Drop backlight reference
+  * @bd: the backlight device to put
+  */
+static inline void backlight_put(struct backlight_device *bd)
+{
+   if (bd)
+   put_device(>dev);
+}
+
  extern struct backlight_device *backlight_device_register(const char *name,
struct device *dev, void *devdata, const struct backlight_ops *ops,
const struct backlight_properties *props);
@@ -203,4 +213,13 @@ of_find_backlight_by_node(struct device_node *node)
  }
  #endif
  
+#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)

+struct backlight_device *of_find_backlight(struct device *dev);
+#else
+static inline struct backlight_device *of_find_backlight(struct device *dev)
+{
+   return NULL;
+}
+#endif
+
  #endif


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

Re: [PATCH] drm/panel: panasonic-vvx10f034n00: Fix wuxga_nt_panel_disable() return value

[Philippe CORNU]

Hi Sean,

On 01/16/2018 11:22 PM, Sean Paul wrote:
> Return value for mipi_dsi_shutdown_peripheral() is unchecked.
> Check it and return any errors if they come up. Even if
> mipi_dsi_shutdown_peripheral() fails, continue attempting to
> disable.
> 
> Cc: Philippe Cornu 
> Signed-off-by: Sean Paul 
> ---
>   drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c 
> b/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
> index 7f915f706fa6..91dc5a6b14f9 100644
> --- a/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
> +++ b/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
> @@ -72,11 +72,12 @@ static int wuxga_nt_panel_on(struct wuxga_nt_panel 
> *wuxga_nt)
>   static int wuxga_nt_panel_disable(struct drm_panel *panel)
>   {
>   struct wuxga_nt_panel *wuxga_nt = to_wuxga_nt_panel(panel);
> + int ret;
>   
>   if (!wuxga_nt->enabled)
>   return 0;
>   
> - mipi_dsi_shutdown_peripheral(wuxga_nt->dsi);
> + ret = mipi_dsi_shutdown_peripheral(wuxga_nt->dsi);
>   
>   if (wuxga_nt->backlight) {
>   wuxga_nt->backlight->props.power = FB_BLANK_POWERDOWN;
> @@ -86,7 +87,7 @@ static int wuxga_nt_panel_disable(struct drm_panel *panel)
>   
>   wuxga_nt->enabled = false;
>   
> - return 0;
> + return ret;
>   }
>   
>   static int wuxga_nt_panel_unprepare(struct drm_panel *panel)
> 

Many thanks for the patch.

I agree it is better to continue attempting to disable if 
mipi_dsi_shutdown_peripheral() fails.

Looking more in details in this driver:
* backlight_update_status() may also use a ret value...
* wuxga_nt_panel_on() should simply do "return 
mipi_dsi_turn_on_peripheral(dsi);"
... but it is not really part of your patch (and mine initially), maybe 
TODOs for later : )


Reviewed-by: Philippe Cornu 

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

Re: [PATCH v16 01/10] video: backlight: Add helpers to enable and disable backlight

[Daniel Thompson]

On 16/01/18 10:31, Meghana Madhyastha wrote:

Add helper functions backlight_enable and backlight_disable to
enable/disable a backlight device. These helper functions can
then be used by different drm and tinydrm drivers to avoid
repetition of code and also to enforce a uniform and consistent
way to enable/disable a backlight device.

Signed-off-by: Meghana Madhyastha 


To be clear I don't disagree with anthing Daniel V. said about the 
horribly confused (and confusing) power states for backlight.


Nevertheless I don't recall seeing any response (positive or negative) 
to this post from v13:

https://www.spinics.net/lists/dri-devel/msg154459.html


Daniel.



---
  include/linux/backlight.h | 30 ++
  1 file changed, 30 insertions(+)

diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index af7003548..7b6a9a2a3 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -130,6 +130,36 @@ static inline int backlight_update_status(struct 
backlight_device *bd)
return ret;
  }
  
+/**

+  * backlight_enable - Enable backlight
+  * @bd: the backlight device to enable
+  */
+static inline int backlight_enable(struct backlight_device *bd)
+{
+   if (!bd)
+   return 0;
+
+   bd->props.power = FB_BLANK_UNBLANK;
+   bd->props.state &= ~BL_CORE_FBBLANK;
+
+   return backlight_update_status(bd);
+}
+
+/**
+  * backlight_disable - Disable backlight
+  * @bd: the backlight device to disable
+  */
+static inline int backlight_disable(struct backlight_device *bd)
+{
+   if (!bd)
+   return 0;
+   
+   bd->props.power = FB_BLANK_POWERDOWN;
+   bd->props.state |= BL_CORE_FBBLANK;
+
+   return backlight_update_status(bd);
+}
+
  extern struct backlight_device *backlight_device_register(const char *name,
struct device *dev, void *devdata, const struct backlight_ops *ops,
const struct backlight_properties *props);


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

Re: [PATCH] exynos: drm: use monotonic timestamps

[Arnd Bergmann]

On Fri, Nov 3, 2017 at 3:04 PM, Tobias Jakobi
 wrote:
> Hello Arnd,
>
> I guess you could coordinate the IPP changes with Marek, who is rewriting the
> IPP subsystem anyway (added Marek to Cc).
>
> Here is the most recent IPPv2 series:
> https://www.spinics.net/lists/linux-samsung-soc/msg61066.html
>
> Concerning the G2D changes, I don't think anything in userspace uses the
> timestamps (e.g. for synchronisation).

I'm cleaning out older patches that didn't make it in yet now, and got to this
one. I looked at the current state and found that the ipp specific half of my
patch is obsolete now, and we won't need to patch anything there with
Marek's new version.

For the G2D half, I'll just resubmit the patch I had here, let's discuss
further from there, if you think we should just drop the timestamp.

Thanks!

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

Re: [PATCH 6/6] MAINTAINERS: add dri-devel for backlight subsystem patches

[Daniel Thompson]

On 17/01/18 14:01, Daniel Vetter wrote:

For the same reasons we've added dri-devel for all fbdev patches: Most
of the actively developed drivers using this infrastructure are in
drivers/gpu/. It just makes sense to cross-post patches and keep
aligned. And total activity in the backlight subsystem is miniscule
compared to drm overall.

Cc: Lee Jones 
Cc: Daniel Thompson 
Cc: Jingoo Han 
Signed-off-by: Daniel Vetter 


Acked-by: Daniel Thompson 



---
  MAINTAINERS | 1 +
  1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7691e1025708..6534517f53b6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2546,6 +2546,7 @@ BACKLIGHT CLASS/SUBSYSTEM
  M:Lee Jones 
  M:Daniel Thompson 
  M:Jingoo Han 
+L: dri-devel@lists.freedesktop.org
  T:git git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git
  S:Maintained
  F:drivers/video/backlight/


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

Re: [PATCH 5/6] backlight: Also nuke BL_CORE_DRIVER1

[Daniel Thompson]

On 17/01/18 14:01, Daniel Vetter wrote:

Now that the 3 drivers using this are cleaned up we can also remove
this final bit of confusion of leaking driver internals into the
backlight power interface.

The backlight power interface itself is still a massive mess.

Cc: Lee Jones 
Cc: Daniel Thompson 
Cc: Jingoo Han 
Signed-off-by: Daniel Vetter 

Acked-by: Daniel Thompson 



---
  include/linux/backlight.h | 1 -
  1 file changed, 1 deletion(-)

diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 9776edb0ff06..b6f7c99d1c8e 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -84,7 +84,6 @@ struct backlight_properties {
  
  #define BL_CORE_SUSPENDED	(1 << 0)	/* backlight is suspended */

  #define BL_CORE_FBBLANK   (1 << 1)  /* backlight is under an fb 
blank event */
-#define BL_CORE_DRIVER1(1 << 31) /* reserved for driver 
specific use */
  
  };
  


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

Re: [PATCH 4/6] staging/fbtft: Stop using BL_CORE_DRIVER1

[Daniel Thompson]

On 17/01/18 14:01, Daniel Vetter wrote:

Leaking driver internal tracking into the already massively confusing
backlight power tracking is really confusing.

Luckily we have already a drvdata structure, so fixing this is really
easy.

Cc: Lee Jones 
Cc: Daniel Thompson 
Cc: Jingoo Han 
Cc: Thomas Petazzoni 
Signed-off-by: Daniel Vetter 


Acked-by: Daniel Thompson 



---
  drivers/staging/fbtft/fbtft-core.c | 4 ++--
  drivers/staging/fbtft/fbtft.h  | 1 +
  2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/fbtft/fbtft-core.c 
b/drivers/staging/fbtft/fbtft-core.c
index 6d0363deba61..448929cc7ba1 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -255,7 +255,7 @@ static int fbtft_request_gpios_dt(struct fbtft_par *par)
  static int fbtft_backlight_update_status(struct backlight_device *bd)
  {
struct fbtft_par *par = bl_get_data(bd);
-   bool polarity = !!(bd->props.state & BL_CORE_DRIVER1);
+   bool polarity = par->polarity;
  
  	fbtft_par_dbg(DEBUG_BACKLIGHT, par,

"%s: polarity=%d, power=%d, fb_blank=%d\n",
@@ -305,7 +305,7 @@ void fbtft_register_backlight(struct fbtft_par *par)
/* Assume backlight is off, get polarity from current state of pin */
bl_props.power = FB_BLANK_POWERDOWN;
if (!gpio_get_value(par->gpio.led[0]))
-   bl_props.state |= BL_CORE_DRIVER1;
+   par->polarity = true;
  
  	bd = backlight_device_register(dev_driver_string(par->info->device),

   par->info->device, par,
diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h
index 488ab788138e..54de7cdfdff7 100644
--- a/drivers/staging/fbtft/fbtft.h
+++ b/drivers/staging/fbtft/fbtft.h
@@ -240,6 +240,7 @@ struct fbtft_par {
ktime_t update_time;
bool bgr;
void *extra;
+   bool polarity;
  };
  
  #define NUMARGS(...)  (sizeof((int[]){__VA_ARGS__})/sizeof(int))



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

Re: [PATCH -next] drm/etnaviv: make local symbols static

[Lucas Stach]

Am Donnerstag, den 11.01.2018, 11:34 + schrieb Wei Yongjun:
> Fixes the following sparse warnings:
> 
> drivers/gpu/drm/etnaviv/etnaviv_iommu.c:161:39: warning:
>  symbol 'etnaviv_iommuv1_ops' was not declared. Should it be static?
> drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c:239:39: warning:
>  symbol 'etnaviv_iommuv2_ops' was not declared. Should it be static?
> 
> Signed-off-by: Wei Yongjun 

Thanks, applied to etnaviv/next.

> ---
>  drivers/gpu/drm/etnaviv/etnaviv_iommu.c | 2 +-
>  drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c | 2 +-
>  2 file changed, 2 insertion(+), 2 deletion(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> index 7a8c947..4b9b11c 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> @@ -158,7 +158,7 @@ void etnaviv_iommuv1_restore(struct etnaviv_gpu
> *gpu)
>   gpu_write(gpu, VIVS_MC_MMU_RA_PAGE_TABLE, pgtable);
>  }
>  
> -const struct etnaviv_iommu_domain_ops etnaviv_iommuv1_ops = {
> +static const struct etnaviv_iommu_domain_ops etnaviv_iommuv1_ops = {
>   .free = etnaviv_iommuv1_domain_free,
>   .map = etnaviv_iommuv1_map,
>   .unmap = etnaviv_iommuv1_unmap,
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
> b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
> index 1e956e2..6e7c892 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
> @@ -236,7 +236,7 @@ void etnaviv_iommuv2_restore(struct etnaviv_gpu
> *gpu)
>   gpu_write(gpu, VIVS_MMUv2_CONTROL,
> VIVS_MMUv2_CONTROL_ENABLE);
>  }
>  
> -const struct etnaviv_iommu_domain_ops etnaviv_iommuv2_ops = {
> +static const struct etnaviv_iommu_domain_ops etnaviv_iommuv2_ops = {
>   .free = etnaviv_iommuv2_domain_free,
>   .map = etnaviv_iommuv2_map,
>   .unmap = etnaviv_iommuv2_unmap,
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/1] drm: add kernel doc for exported gem dmabuf_ops

[Samuel Li]

Signed-off-by: Samuel Li 
---
 drivers/gpu/drm/drm_prime.c | 81 +
 1 file changed, 81 insertions(+)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index ca09ce7..3ead5a6 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -73,6 +73,9 @@
  * Drivers should detect this situation and return back the gem object
  * from the dma-buf private.  Prime will do this automatically for drivers that
  * use the drm_gem_prime_{import,export} helpers.
+ *
+ * GEM dmabuf_ops symbols are now exported. They can be resued by drivers
+ * which implement GEM interface.
  */
 
 struct drm_prime_member {
@@ -180,6 +183,17 @@ static int drm_prime_lookup_buf_handle(struct 
drm_prime_file_private *prime_fpri
return -ENOENT;
 }
 
+/**
+ * drm_gem_map_attach - dma_buf attach implementation for GEM
+ * @dmabuf: buffer to attach device to.
+ * @target_dev: not used
+ * @attach: buffer attachment data
+ *
+ * Allocates drm_prime_attachment and calls driver's gem_prime_pin for device
+ * specific attachment.
+ *
+ * Returns 0 on success, negative error code on failure.
+ */
 int drm_gem_map_attach(struct dma_buf *dma_buf, struct device *target_dev,
   struct dma_buf_attachment *attach)
 {
@@ -201,6 +215,13 @@ int drm_gem_map_attach(struct dma_buf *dma_buf, struct 
device *target_dev,
 }
 EXPORT_SYMBOL(drm_gem_map_attach);
 
+/**
+ * drm_gem_map_detach - dma_buf detach implementation for GEM
+ * @dmabuf: buffer to detach from.
+ * @attach: attachment to be detached.
+ *
+ * Cleans up dma_buf_attachment.
+ */
 void drm_gem_map_detach(struct dma_buf *dma_buf,
struct dma_buf_attachment *attach)
 {
@@ -255,6 +276,17 @@ void drm_prime_remove_buf_handle_locked(struct 
drm_prime_file_private *prime_fpr
}
 }
 
+/**
+ * drm_gem_map_dma_buf - map_dma_buf implementation for GEM
+ * @attach: attachment whose scatterlist is to be returned
+ * @dir: direction of DMA transfer
+ *
+ * This calls driver's gem_prime_get_sg_table() and then maps the scatterlist.
+ *
+ * Returns sg_table containing the scatterlist to be returned; returns ERR_PTR
+ * on error. May return -EINTR if it is interrupted by a signal.
+ */
+
 struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment *attach,
 enum dma_data_direction dir)
 {
@@ -294,6 +326,11 @@ struct sg_table *drm_gem_map_dma_buf(struct 
dma_buf_attachment *attach,
 }
 EXPORT_SYMBOL(drm_gem_map_dma_buf);
 
+/**
+ * drm_gem_unmap_dma_buf - unmap_dma_buf implementation for GEM
+ *
+ * Not implemented. The unmap is done at drm_gem_map_detach().
+ */
 void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
   struct sg_table *sgt,
   enum dma_data_direction dir)
@@ -351,6 +388,14 @@ void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
 }
 EXPORT_SYMBOL(drm_gem_dmabuf_release);
 
+/**
+ * drm_gem_dmabuf_vmap - dma_buf vmap implementation for GEM
+ * @dma_buf: buffer to be mapped
+ *
+ * Sets up a kernel virtual mapping.
+ *
+ * Returns the kernel virtual address.
+ */
 void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf)
 {
struct drm_gem_object *obj = dma_buf->priv;
@@ -360,6 +405,13 @@ void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf)
 }
 EXPORT_SYMBOL(drm_gem_dmabuf_vmap);
 
+/**
+ * drm_gem_dmabuf_vunmap - dma_buf vunmap implementation for GEM
+ * @dma_buf: buffer to be unmapped
+ * @vaddr: the virtual address of the buffer
+ *
+ * Releases a kernel virtual mapping.
+ */
 void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
 {
struct drm_gem_object *obj = dma_buf->priv;
@@ -369,6 +421,11 @@ void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void 
*vaddr)
 }
 EXPORT_SYMBOL(drm_gem_dmabuf_vunmap);
 
+/**
+ * drm_gem_dmabuf_kmap_atomic - map_atomic implementation for GEM
+ *
+ * Not implemented.
+ */
 void *drm_gem_dmabuf_kmap_atomic(struct dma_buf *dma_buf,
 unsigned long page_num)
 {
@@ -376,6 +433,11 @@ void *drm_gem_dmabuf_kmap_atomic(struct dma_buf *dma_buf,
 }
 EXPORT_SYMBOL(drm_gem_dmabuf_kmap_atomic);
 
+/**
+ * drm_gem_dmabuf_kunmap_atomic - unmap_atomic implementation for GEM
+ *
+ * Not implemented.
+ */
 void drm_gem_dmabuf_kunmap_atomic(struct dma_buf *dma_buf,
  unsigned long page_num, void *addr)
 {
@@ -383,12 +445,22 @@ void drm_gem_dmabuf_kunmap_atomic(struct dma_buf *dma_buf,
 }
 EXPORT_SYMBOL(drm_gem_dmabuf_kunmap_atomic);
 
+/**
+ * drm_gem_dmabuf_kmap - map implementation for GEM
+ *
+ * Not implemented.
+ */
 void *drm_gem_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)
 {
return NULL;
 }
 EXPORT_SYMBOL(drm_gem_dmabuf_kmap);
 
+/**
+ * drm_gem_dmabuf_kunmap - unmap implementation for GEM
+ *
+ * Not implemented.
+ */
 void drm_gem_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long page_num,
   

Re: [PATCH 3/6] backlight/pandora: Stop using BL_CORE_DRIVER1

[Daniel Thompson]

On 17/01/18 14:01, Daniel Vetter wrote:

Leaking driver internal tracking into the already massively confusing
backlight power tracking is really confusing.

Stop that by allocating a tiny driver private data structure instead.

Cc: Lee Jones 
Cc: Daniel Thompson 
Cc: Jingoo Han 
Signed-off-by: Daniel Vetter 
---
  drivers/video/backlight/pandora_bl.c | 26 +++---
  1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/video/backlight/pandora_bl.c 
b/drivers/video/backlight/pandora_bl.c
index a186bc677c7d..6bd159946a47 100644
--- a/drivers/video/backlight/pandora_bl.c
+++ b/drivers/video/backlight/pandora_bl.c
@@ -35,11 +35,15 @@
  #define MAX_VALUE 63
  #define MAX_USER_VALUE (MAX_VALUE - MIN_VALUE)
  
-#define PANDORABL_WAS_OFF BL_CORE_DRIVER1

+struct pandora_private {
+   unsigned old_state;
+#define PANDORABL_WAS_OFF 1


Nit, but we using old_state like a bitfield so, BIT(0)?



+};
  
  static int pandora_backlight_update_status(struct backlight_device *bl)

  {
int brightness = bl->props.brightness;
+   struct pandora_private *priv = bl_get_data(bl);
u8 r;
  
  	if (bl->props.power != FB_BLANK_UNBLANK)

@@ -53,7 +57,7 @@ static int pandora_backlight_update_status(struct 
backlight_device *bl)
brightness = MAX_USER_VALUE;
  
  	if (brightness == 0) {

-   if (bl->props.state & PANDORABL_WAS_OFF)
+   if (priv->old_state & PANDORABL_WAS_OFF)
goto done;
  
  		/* first disable PWM0 output, then clock */

@@ -66,7 +70,7 @@ static int pandora_backlight_update_status(struct 
backlight_device *bl)
goto done;
}
  
-	if (bl->props.state & PANDORABL_WAS_OFF) {

+   if (priv->old_state & PANDORABL_WAS_OFF) {
/*
 * set PWM duty cycle to max. TPS61161 seems to use this
 * to calibrate it's PWM sensitivity when it starts.
@@ -93,9 +97,9 @@ static int pandora_backlight_update_status(struct 
backlight_device *bl)
  
  done:

if (brightness != 0)
-   bl->props.state &= ~PANDORABL_WAS_OFF;
+   priv->old_state 0;
else
-   bl->props.state |= PANDORABL_WAS_OFF;
+   priv->old_state = PANDORABL_WAS_OFF;


Well, we were using it like a bitfield until this bit...


  
  	return 0;

  }
@@ -109,15 +113,23 @@ static int pandora_backlight_probe(struct platform_device 
*pdev)
  {
struct backlight_properties props;
struct backlight_device *bl;
+   struct pandora_private *priv;
u8 r;
  
+	priv = devm_kmalloc(>dev, sizeof(*priv), GFP_KERNEL);

+   if (!priv) {
+   dev_err(>dev, "failed to allocate driver private data\n");
+   return -ENOMEM;
+   }
+
memset(, 0, sizeof(props));
props.max_brightness = MAX_USER_VALUE;
props.type = BACKLIGHT_RAW;
bl = devm_backlight_device_register(>dev, pdev->name, >dev,
-   NULL, _backlight_ops, );
+   priv, _backlight_ops, );
if (IS_ERR(bl)) {
dev_err(>dev, "failed to register backlight\n");
+   kfree(priv);


Why can't we rely on devres for cleanup?



return PTR_ERR(bl);
}
  
@@ -126,7 +138,7 @@ static int pandora_backlight_probe(struct platform_device *pdev)

/* 64 cycle period, ON position 0 */
twl_i2c_write_u8(TWL_MODULE_PWM, 0x80, TWL_PWM0_ON);
  
-	bl->props.state |= PANDORABL_WAS_OFF;

+   priv->old_state = PANDORABL_WAS_OFF;
bl->props.brightness = MAX_USER_VALUE;
backlight_update_status(bl);
  


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

Re: [PATCH 2/6] backlight/generic-bl: remove DRIVER1 state

[Daniel Thompson]

On 17/01/18 14:01, Daniel Vetter wrote:

Nothing in the entire tree ever sets this, which means this is dead
code. Remove it.

Cc: Lee Jones 
Cc: Daniel Thompson 
Cc: Jingoo Han 
Signed-off-by: Daniel Vetter 


Not sure whether to ack this one or not.

There is nothing wrong with the change but having taken a closer look 
the driver seems like it exists mostly to allow mach-XXX code to plug in 
function pointers and we don't do that sort of thing any more.


I think the entire driver is dead code!


Daniel.



---
  drivers/video/backlight/generic_bl.c | 5 -
  1 file changed, 5 deletions(-)

diff --git a/drivers/video/backlight/generic_bl.c 
b/drivers/video/backlight/generic_bl.c
index 67dfb939a514..4dea91acea13 100644
--- a/drivers/video/backlight/generic_bl.c
+++ b/drivers/video/backlight/generic_bl.c
@@ -21,9 +21,6 @@ static int genericbl_intensity;
  static struct backlight_device *generic_backlight_device;
  static struct generic_bl_info *bl_machinfo;
  
-/* Flag to signal when the battery is low */

-#define GENERICBL_BATTLOW   BL_CORE_DRIVER1
-
  static int genericbl_send_intensity(struct backlight_device *bd)
  {
int intensity = bd->props.brightness;
@@ -34,8 +31,6 @@ static int genericbl_send_intensity(struct backlight_device 
*bd)
intensity = 0;
if (bd->props.state & BL_CORE_SUSPENDED)
intensity = 0;
-   if (bd->props.state & GENERICBL_BATTLOW)
-   intensity &= bl_machinfo->limit_mask;
  
  	bl_machinfo->set_bl_intensity(intensity);
  


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

Re: [PATCH 2/6] backlight/generic-bl: remove DRIVER1 state

[Daniel Thompson]

On 17/01/18 14:36, Emil Velikov wrote:

On 17 January 2018 at 14:01, Daniel Vetter  wrote:

Nothing in the entire tree ever sets this, which means this is dead
code. Remove it.

Cc: Lee Jones 
Cc: Daniel Thompson 
Cc: Jingoo Han 
Signed-off-by: Daniel Vetter 
---
  drivers/video/backlight/generic_bl.c | 5 -


Fly-by comment, while waiting for coffee to kick-in.
I think this patch should be after pandora/others have stopped abusing
BL_CORE_DRIVER1.


You sure?

I can't see why the use or disuse of BL_CORE_DRIVER1 in this driver 
should influence another independent driver.



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

[git pull] vmwgfx-fixes-4.15 for -rc9 / final

[Thomas Hellstrom]

Dave,
Last minute fixes for vmwgfx.
One fix for a drm helper warning introduced in 4.15
One important fix for a longer standing memory corruption issue on older
hardware versions.

The following changes since commit 0d9cac0ca0429830c40fe1a4e50e60f6221fd7b6:

  drm/vmwgfx: Potential off by one in vmw_view_add() (2018-01-10 15:21:39 +0100)

are available in the git repository at:

  git://people.freedesktop.org/~thomash/linux vmwgfx-fixes-4.15

for you to fetch changes up to 8a510a5c75261ba0ec39155326982aa786541e29:

  drm/vmwgfx: fix memory corruption with legacy/sou connectors (2018-01-17 
16:27:45 +0100)


Rob Clark (1):
  drm/vmwgfx: fix memory corruption with legacy/sou connectors

Woody Suwalski (1):
  drm/vmwgfx: Fix a boot time warning

 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  | 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  | 4 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: arc: Don't set connector DPMS handler

[Daniel Vetter]

On Wed, Jan 17, 2018 at 04:32:18PM +0200, Laurent Pinchart wrote:
> The connector .dpms operation is only used by the legacy helpers. The
> arc driver being fully atomic, the operation isn't needed anymore.
> Remove it.
> 
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Daniel Vetter 

Note that before

commit 144a7999d6334be5237d5926ab19c56bc24d0204
Author: Daniel Vetter 
Date:   Tue Jul 25 14:02:04 2017 +0200

drm: Handle properties in the core for atomic drivers

this was necessary. I guess I missed this one here because it was using
the wrong callback.
-Daniel

> ---
>  drivers/gpu/drm/arc/arcpgu_sim.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c 
> b/drivers/gpu/drm/arc/arcpgu_sim.c
> index bca3a678c955..1d4d5dd7e763 100644
> --- a/drivers/gpu/drm/arc/arcpgu_sim.c
> +++ b/drivers/gpu/drm/arc/arcpgu_sim.c
> @@ -53,7 +53,6 @@ arcpgu_drm_connector_helper_funcs = {
>  };
>  
>  static const struct drm_connector_funcs arcpgu_drm_connector_funcs = {
> - .dpms = drm_helper_connector_dpms,
>   .reset = drm_atomic_helper_connector_reset,
>   .fill_modes = drm_helper_probe_single_connector_modes,
>   .destroy = arcpgu_drm_connector_destroy,
> -- 
> Regards,
> 
> Laurent Pinchart
> 

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

[PATCH] [RESEND] drm: i915: remove timeval users

[Arnd Bergmann]

struct timeval is deprecated because it cannot represent times
past 2038. In this driver, the only use of this structure is
to capture debug information. This is easily changed to ktime_t,
which we then format as needed when printing it later.

Reviewed-by: Chris Wilson 
Signed-off-by: Arnd Bergmann 
---
Sent in November 2017, got the review from Chis, but the patch
so far hasn't been merged. Resending it unchanged, please apply
for 4.16 or 4.17.
---
 drivers/gpu/drm/i915/i915_drv.h   |  6 +++---
 drivers/gpu/drm/i915/i915_gpu_error.c | 25 ++---
 2 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index caebd5825279..8d860fcd8c43 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -453,9 +453,9 @@ struct intel_display_error_state;
 
 struct i915_gpu_state {
struct kref ref;
-   struct timeval time;
-   struct timeval boottime;
-   struct timeval uptime;
+   ktime_t time;
+   ktime_t boottime;
+   ktime_t uptime;
 
struct drm_i915_private *i915;
 
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 944059322daa..06577574296b 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -610,6 +610,7 @@ int i915_error_state_to_str(struct drm_i915_error_state_buf 
*m,
 {
struct drm_i915_private *dev_priv = m->i915;
struct drm_i915_error_object *obj;
+   struct timespec64 ts;
int i, j;
 
if (!error) {
@@ -620,12 +621,15 @@ int i915_error_state_to_str(struct 
drm_i915_error_state_buf *m,
if (*error->error_msg)
err_printf(m, "%s\n", error->error_msg);
err_printf(m, "Kernel: " UTS_RELEASE "\n");
-   err_printf(m, "Time: %ld s %ld us\n",
-  error->time.tv_sec, error->time.tv_usec);
-   err_printf(m, "Boottime: %ld s %ld us\n",
-  error->boottime.tv_sec, error->boottime.tv_usec);
-   err_printf(m, "Uptime: %ld s %ld us\n",
-  error->uptime.tv_sec, error->uptime.tv_usec);
+   ts = ktime_to_timespec64(error->time);
+   err_printf(m, "Time: %lld s %ld us\n",
+  (s64)ts.tv_sec, ts.tv_nsec / NSEC_PER_USEC);
+   ts = ktime_to_timespec64(error->boottime);
+   err_printf(m, "Boottime: %lld s %ld us\n",
+  (s64)ts.tv_sec, ts.tv_nsec / NSEC_PER_USEC);
+   ts = ktime_to_timespec64(error->uptime);
+   err_printf(m, "Uptime: %lld s %ld us\n",
+  (s64)ts.tv_sec, ts.tv_nsec / NSEC_PER_USEC);
 
for (i = 0; i < ARRAY_SIZE(error->engine); i++) {
if (error->engine[i].hangcheck_stalled &&
@@ -1737,11 +1741,10 @@ static int capture(void *data)
 {
struct i915_gpu_state *error = data;
 
-   do_gettimeofday(>time);
-   error->boottime = ktime_to_timeval(ktime_get_boottime());
-   error->uptime =
-   ktime_to_timeval(ktime_sub(ktime_get(),
-  error->i915->gt.last_init_time));
+   error->time = ktime_get_real();
+   error->boottime = ktime_get_boottime();
+   error->uptime = ktime_sub(ktime_get(),
+ error->i915->gt.last_init_time);
 
capture_params(error);
capture_uc_state(error);
-- 
2.9.0

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

[Bug 104611] [fiji, polaris10] BUG: unable to handle kernel NULL pointer dereference when waking up displays with amdgpu.dc=1

[bugzilla-daemon]

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

Vedran Miletić  changed:

   What|Removed |Added

Summary|[fiji] BUG: unable to   |[fiji, polaris10] BUG:
   |handle kernel NULL pointer  |unable to handle kernel
   |dereference when waking up  |NULL pointer dereference
   |displays with amdgpu.dc=1   |when waking up displays
   ||with amdgpu.dc=1

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

[Bug 104611] [fiji] BUG: unable to handle kernel NULL pointer dereference when waking up displays with amdgpu.dc=1

[bugzilla-daemon]

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

--- Comment #4 from Vedran Miletić  ---
Created attachment 136808
  --> https://bugs.freedesktop.org/attachment.cgi?id=136808=edit
dmesg with rx580 amdgpu.dc_log=1

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

Re: [git pull] vmwgfx-fixes-4.15 for -rc9 / final

[Thomas Hellstrom]

Dave,

On 01/17/2018 09:40 AM, Thomas Hellstrom wrote:

Dave,

A last minute minimal fix to kill a warning introduced in a helper in 4.15.

The following changes since commit 0d9cac0ca0429830c40fe1a4e50e60f6221fd7b6:

   drm/vmwgfx: Potential off by one in vmw_view_add() (2018-01-10 15:21:39 
+0100)

are available in the git repository at:

   git://people.freedesktop.org/~thomash/linux vmwgfx-fixes-4.15

for you to fetch changes up to 2b0bc6870f1a61b90b49012e917eea4cb251:

   drm/vmwgfx: Fix a boot time warning (2018-01-17 09:09:27 +0100)


Please ignore this pull request. I'll incorporate Rob Clark's vmwgfx 
memory corruption fix and resend ASAP.


Thanks,
Thomas

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

Re: [PATCH] drm/vmwgfx: fix memory corruption with legacy/sou connectors

[Thomas Hellstrom]

On 01/17/2018 04:16 PM, Rob Clark wrote:

From: Rob Clark 

It looks like in all cases 'struct vmw_connector_state' is used.  But
only in stdu connectors, was atomic_{duplicate,destroy}_state() properly
subclassed.  Leading to writes beyond the end of the allocated connector
state block and all sorts of fun memory corruption related crashes.

Fixes: d7721ca71126 "drm/vmwgfx: Connector atomic state"
Cc: 
Signed-off-by: Rob Clark 

Reviewed-by: Thomas Hellstrom 

Thanks, Rob!

/Thomas



---
  drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  | 4 ++--
  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4 ++--
  2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index b8a09807c5de..3824595fece1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -266,8 +266,8 @@ static const struct drm_connector_funcs 
vmw_legacy_connector_funcs = {
.set_property = vmw_du_connector_set_property,
.destroy = vmw_ldu_connector_destroy,
.reset = vmw_du_connector_reset,
-   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
-   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+   .atomic_duplicate_state = vmw_du_connector_duplicate_state,
+   .atomic_destroy_state = vmw_du_connector_destroy_state,
.atomic_set_property = vmw_du_connector_atomic_set_property,
.atomic_get_property = vmw_du_connector_atomic_get_property,
  };
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index bc5f6026573d..63a4cd794b73 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -420,8 +420,8 @@ static const struct drm_connector_funcs 
vmw_sou_connector_funcs = {
.set_property = vmw_du_connector_set_property,
.destroy = vmw_sou_connector_destroy,
.reset = vmw_du_connector_reset,
-   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
-   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+   .atomic_duplicate_state = vmw_du_connector_duplicate_state,
+   .atomic_destroy_state = vmw_du_connector_destroy_state,
.atomic_set_property = vmw_du_connector_atomic_set_property,
.atomic_get_property = vmw_du_connector_atomic_get_property,
  };



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

Re: [PATCH v3 3/8] drm/edid: Fix cea mode aspect ratio handling

[Ville Syrjälä]

On Wed, Jan 17, 2018 at 02:35:40PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 1/12/2018 11:51 AM, Nautiyal, Ankit K wrote:
> > From: Ville Syrjälä 
> >
> > commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
> > cause us to not send out any VICs in the AVI infoframes. That commit
> > was since reverted, but if and when we add aspect ratio handing back
> > we need to be more careful.
> >
> > Let's handle this by considering the aspect ratio as a requirement
> > for cea mode matching only if the passed in mode actually has a
> > non-zero aspect ratio field. This will keep userspace that doesn't
> > provide an aspect ratio working as before by matching it to the
> > first otherwise equal cea mode. And once userspace starts to
> > provide the aspect ratio it will be considerd a hard requirement
> > for the match.
> >
> > Also change the hdmi mode matching to use drm_mode_match() for
> > consistency, but we don't match on aspect ratio there since the
> > spec doesn't list a specific aspect ratio for those modes.
> >
> > Cc: Shashank Sharma 
> > Cc: "Lin, Jia" 
> > Cc: Akashdeep Sharma 
> > Cc: Jim Bride 
> > Cc: Jose Abreu 
> > Cc: Daniel Vetter 
> > Cc: Emil Velikov 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/drm_edid.c | 18 ++
> >   1 file changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 1818a71..3d57c41 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -2908,11 +2908,15 @@ cea_mode_alternate_timings(u8 vic, struct 
> > drm_display_mode *mode)
> >   static u8 drm_match_cea_mode_clock_tolerance(const struct 
> > drm_display_mode *to_match,
> >  unsigned int clock_tolerance)
> >   {
> > +   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
> > DRM_MODE_MATCH_FLAGS;
> > u8 vic;
> >   
> > if (!to_match->clock)
> > return 0;
> >   
> > +   if (to_match->picture_aspect_ratio)
> > +   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> > +
> > for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
> > struct drm_display_mode cea_mode = edid_cea_modes[vic];
> > unsigned int clock1, clock2;
> > @@ -2926,7 +2930,7 @@ static u8 drm_match_cea_mode_clock_tolerance(const 
> > struct drm_display_mode *to_m
> > continue;
> >   
> > do {
> > -   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
> > _mode))
> > +   if (drm_mode_match(to_match, _mode, match_flags))
> > return vic;
> > } while (cea_mode_alternate_timings(vic, _mode));
> > }
> > @@ -2943,11 +2947,15 @@ static u8 drm_match_cea_mode_clock_tolerance(const 
> > struct drm_display_mode *to_m
> >*/
> >   u8 drm_match_cea_mode(const struct drm_display_mode *to_match)
> >   {
> > +   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
> > DRM_MODE_MATCH_FLAGS;
> > u8 vic;
> >   
> > if (!to_match->clock)
> > return 0;
> >   
> > +   if (to_match->picture_aspect_ratio)
> > +   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> > +
> How about stereo flags ? CEA modes can be 3d and in that case we might 
> want to add DRM_MODE_MATCH_3D_FLAGS here

There are no separate VICs for stereo vs. no stereo. So ignoring the
stereo flags here seems like the correct thing to do.

> 
> - Shashank
> > for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
> > struct drm_display_mode cea_mode = edid_cea_modes[vic];
> > unsigned int clock1, clock2;
> > @@ -2961,7 +2969,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
> > *to_match)
> > continue;
> >   
> > do {
> > -   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
> > _mode))
> > +   if (drm_mode_match(to_match, _mode, match_flags))
> > return vic;
> > } while (cea_mode_alternate_timings(vic, _mode));
> > }
> > @@ -3008,6 +3016,7 @@ hdmi_mode_alternate_clock(const struct 
> > drm_display_mode *hdmi_mode)
> >   static u8 drm_match_hdmi_mode_clock_tolerance(const struct 
> > drm_display_mode *to_match,
> >   unsigned int clock_tolerance)
> >   {
> > +   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
> > DRM_MODE_MATCH_FLAGS;
> > u8 vic;
> >   
> > if (!to_match->clock)
> > @@ -3025,7 +3034,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
> > struct drm_display_mode *to_
> > abs(to_match->clock - clock2) > clock_tolerance)
> > continue;
> >   

[Bug 104611] [fiji] BUG: unable to handle kernel NULL pointer dereference when waking up displays with amdgpu.dc=1

[bugzilla-daemon]

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

--- Comment #3 from Vedran Miletić  ---
(In reply to Harry Wentland from comment #1)
> Does this reproduce consistently or intermittently?

No, but I just got it on RX 580: 

[ 3582.972912] BUG: unable to handle kernel NULL pointer dereference at
0208
[ 3582.972982] IP: create_stream_for_sink+0x1cc/0x3c0 [amdgpu]
[ 3582.972985] PGD 8003b3e7b067 P4D 8003b3e7b067 PUD 3d0c0a067 PMD 0 
[ 3582.972992] Oops:  [#1] SMP PTI
[ 3582.972995] Modules linked in: fuse rpcsec_gss_krb5 nfsv4 dns_resolver nfs
lockd grace fscache intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp
snd_hda_codec_realtek snd_hda_codec_generic kvm snd_hda_codec_hdmi irqbypass
joydev snd_hda_intel snd_hda_codec crct10dif_pclmul crc32_pclmul snd_hda_core
eeepc_wmi ghash_clmulni_intel intel_cstate snd_hwdep intel_uncore snd_seq
snd_seq_device asus_wmi sparse_keymap snd_pcm mei_wdt intel_rapl_perf rfkill
iTCO_wdt iTCO_vendor_support snd_timer snd wmi_bmof ppdev soundcore mei_me wmi
lpc_ich mei i2c_i801 parport_pc parport video shpchp binfmt_misc auth_rpcgss
sunrpc amdkfd amd_iommu_v2 amdgpu chash i2c_algo_bit drm_kms_helper ttm
crc32c_intel drm r8169 mii hid_cherry
[ 3582.973075] CPU: 3 PID: 4419 Comm: Xorg Not tainted
4.15.0-0.rc7.git4.1.fc28.x86_64 #1
[ 3582.973077] Hardware name: Transtec AG/B85M-E, BIOS 3507 07/21/2017
[ 3582.973130] RIP: 0010:create_stream_for_sink+0x1cc/0x3c0 [amdgpu]
[ 3582.973132] RSP: 0018:aa8402503900 EFLAGS: 00010286
[ 3582.973136] RAX: 0870 RBX: 8d4f472aa000 RCX:

[ 3582.973138] RDX: 0013 RSI: 0002 RDI:
8d4f0373f48c
[ 3582.973140] RBP: aa8402503a40 R08:  R09:
0f00
[ 3582.973142] R10: 8d4f0373f400 R11: 0870 R12:
8d4f0373f400
[ 3582.973143] R13:  R14: 8d4f0c16fe80 R15:
8d4f03739800
[ 3582.973146] FS:  7efef37f6a80() GS:8d4f4cc0()
knlGS:
[ 3582.973148] CS:  0010 DS:  ES:  CR0: 80050033
[ 3582.973150] CR2: 0208 CR3: 0003cc198001 CR4:
001606e0
[ 3582.973152] Call Trace:
[ 3582.973159]  ? __lock_is_held+0x65/0xb0
[ 3582.973215]  dm_update_crtcs_state+0xef/0x3a0 [amdgpu]
[ 3582.973262]  ? dm_update_crtcs_state+0xef/0x3a0 [amdgpu]
[ 3582.973310]  ? dc_resource_state_copy_construct+0xcc/0x110 [amdgpu]
[ 3582.973356]  amdgpu_dm_atomic_check+0x210/0x480 [amdgpu]
[ 3582.973377]  drm_atomic_check_only+0x387/0x560 [drm]
[ 3582.973389]  ? drm_connector_list_iter_end+0x5a/0x70 [drm]
[ 3582.973402]  drm_atomic_commit+0x18/0x50 [drm]
[ 3582.973413]  drm_atomic_connector_commit_dpms+0xef/0x100 [drm]
[ 3582.973425]  set_property_atomic+0xce/0x150 [drm]
[ 3582.973440]  drm_mode_obj_set_property_ioctl+0xf9/0x1b0 [drm]
[ 3582.973451]  ? drm_mode_connector_set_obj_prop+0x80/0x80 [drm]
[ 3582.973461]  drm_mode_connector_property_set_ioctl+0x3f/0x60 [drm]
[ 3582.973472]  drm_ioctl_kernel+0x5d/0xb0 [drm]
[ 3582.973483]  drm_ioctl+0x31b/0x3d0 [drm]
[ 3582.973492]  ? drm_mode_connector_set_obj_prop+0x80/0x80 [drm]
[ 3582.973499]  ? trace_hardirqs_on_caller+0xf4/0x190
[ 3582.973502]  ? trace_hardirqs_on+0xd/0x10
[ 3582.973533]  amdgpu_drm_ioctl+0x4f/0x90 [amdgpu]
[ 3582.973538]  do_vfs_ioctl+0xa6/0x6c0
[ 3582.973544]  ? __fget+0x124/0x210
[ 3582.973548]  SyS_ioctl+0x79/0x90
[ 3582.973554]  entry_SYSCALL_64_fastpath+0x25/0x9c
[ 3582.973557] RIP: 0033:0x7efef0af1877
[ 3582.973559] RSP: 002b:7ffd548f2768 EFLAGS: 0246 ORIG_RAX:
0010
[ 3582.973562] RAX: ffda RBX: 01763a10 RCX:
7efef0af1877
[ 3582.973564] RDX: 7ffd548f27a0 RSI: c01064ab RDI:
000c
[ 3582.973566] RBP: 01a07140 R08: 021a4bd0 R09:
0020
[ 3582.973568] R10: 0005 R11: 0246 R12:
00847360
[ 3582.973570] R13: 0001 R14: 0004 R15:
7ffd548f31c0
[ 3582.973576] Code: da 4c 89 e7 e8 56 fc ff ff 4c 89 f6 4c 89 ef 4c 89 e2 e8
28 f0 ff ff 4c 8b ab c0 04 00 00 49 8d bc 24 8c 00 00 00 ba 13 00 00 00 <41> 0f
b7 85 08 02 00 00 49 8d b5 12 02 00 00 41 89 84 24 a0 00 
[ 3582.973687] RIP: create_stream_for_sink+0x1cc/0x3c0 [amdgpu] RSP:
aa8402503900
[ 3582.973689] CR2: 0208
[ 3582.973711] ---[ end trace db6ecfa1f0babe6e ]---

(In reply to Roman Li from comment #2)
> I cannot reproduce it on v4.15-rc7 (git#1545dec46db3)
> Vedran, can you  provide more info on your setup:
> - display and connector types
> - window manager
> - dmesg with amdgpu.dc_log=1

2xDell P2715Q hooked over DP.
GNOME 3 on Fedora 27.
I will provide dmesg.

-- 
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 v3 1/8] drm/modes: Introduce drm_mode_match()

[Ville Syrjälä]

On Wed, Jan 17, 2018 at 02:11:55PM +0530, Sharma, Shashank wrote:
> 
> 
> On 1/12/2018 11:51 AM, Nautiyal, Ankit K wrote:
> > From: Ville Syrjälä 
> >
> > Make mode matching less confusing by allowing the caller to specify
> > which parts of the modes should match via some flags.
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/drm_modes.c | 134 
> > ++--
> >   include/drm/drm_modes.h |   9 +++
> >   2 files changed, 112 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > index 4a3f68a..8128dbb 100644
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -940,17 +940,68 @@ struct drm_display_mode *drm_mode_duplicate(struct 
> > drm_device *dev,
> >   }
> >   EXPORT_SYMBOL(drm_mode_duplicate);
> >   
> > +static bool drm_mode_match_timings(const struct drm_display_mode *mode1,
> > +  const struct drm_display_mode *mode2)
> Shouldn't the second parameter be aligned to next char after the opening 
> bracket in above line (instead of being align to the bracket) ?

It is. The extra junk at the start of the line is causing the alignment
to look wrong when it's not because the tab stops are still aligned to
the start of the line. This is one reason why I think that using tabs
for alignment isn't a particularly great idea.

> I have this same comment for most of the functions in this patch.
> > +{
> > +   return mode1->hdisplay == mode2->hdisplay &&
> > +   mode1->hsync_start == mode2->hsync_start &&
> > +   mode1->hsync_end == mode2->hsync_end &&
> > +   mode1->htotal == mode2->htotal &&
> > +   mode1->hskew == mode2->hskew &&
> > +   mode1->vdisplay == mode2->vdisplay &&
> > +   mode1->vsync_start == mode2->vsync_start &&
> > +   mode1->vsync_end == mode2->vsync_end &&
> > +   mode1->vtotal == mode2->vtotal &&
> > +   mode1->vscan == mode2->vscan;
> > +}
> > +
> > +static bool drm_mode_match_clock(const struct drm_display_mode *mode1,
> > + const struct drm_display_mode *mode2)
> > +{
> > +   /*
> > +* do clock check convert to PICOS
> > +* so fb modes get matched the same
> > +*/
> > +   if (mode1->clock && mode2->clock)
> > +   return KHZ2PICOS(mode1->clock) == KHZ2PICOS(mode2->clock);
> > +   else
> > +   return mode1->clock == mode2->clock;
> > +}
> > +
> > +static bool drm_mode_match_flags(const struct drm_display_mode *mode1,
> Should we call it drm_mode_match_flag_no_stereo ?

It's not really "no stereo", rather it's "check all the flags not being
checked by something more specific".

> > +const struct drm_display_mode *mode2)
> > +{
> > +   return (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
> > +   (mode2->flags & ~DRM_MODE_FLAG_3D_MASK);
> > +}
> > +
> > +static bool drm_mode_match_3d_flags(const struct drm_display_mode *mode1,
> > +   const struct drm_display_mode *mode2)
> > +{
> > +   return (mode1->flags & DRM_MODE_FLAG_3D_MASK) ==
> > +   (mode2->flags & DRM_MODE_FLAG_3D_MASK);
> > +}
> > +
> > +static bool drm_mode_match_aspect_ratio(const struct drm_display_mode 
> > *mode1,
> > +   const struct drm_display_mode *mode2)
> > +{
> > +   return mode1->picture_aspect_ratio == mode2->picture_aspect_ratio;
> > +}
> > +
> >   /**
> > - * drm_mode_equal - test modes for equality
> > + * drm_mode_match - test modes for (partial) equality
> >* @mode1: first mode
> >* @mode2: second mode
> > + * @match_flags: which parts need to match (DRM_MODE_MATCH_*)
> >*
> >* Check to see if @mode1 and @mode2 are equivalent.
> >*
> >* Returns:
> > - * True if the modes are equal, false otherwise.
> > + * True if the modes are (partially) equal, false otherwise.
> >*/
> > -bool drm_mode_equal(const struct drm_display_mode *mode1, const struct 
> > drm_display_mode *mode2)
> > +bool drm_mode_match(const struct drm_display_mode *mode1,
> > +   const struct drm_display_mode *mode2,
> > +   unsigned int match_flags)
> >   {
> > if (!mode1 && !mode2)
> > return true;
> > @@ -958,15 +1009,48 @@ bool drm_mode_equal(const struct drm_display_mode 
> > *mode1, const struct drm_displ
> > if (!mode1 || !mode2)
> > return false;
> >   
> > -   /* do clock check convert to PICOS so fb modes get matched
> > -* the same */
> > -   if (mode1->clock && mode2->clock) {
> > -   if (KHZ2PICOS(mode1->clock) != KHZ2PICOS(mode2->clock))
> > -   return false;
> > -   } else if (mode1->clock != mode2->clock)
> > +   if (match_flags & DRM_MODE_MATCH_TIMINGS &&
> > +   !drm_mode_match_timings(mode1, mode2))
> > +   return false;
> > +
> > +   if (match_flags & 

[PATCH] drm/vmwgfx: fix memory corruption with legacy/sou connectors

[Rob Clark]

From: Rob Clark 

It looks like in all cases 'struct vmw_connector_state' is used.  But
only in stdu connectors, was atomic_{duplicate,destroy}_state() properly
subclassed.  Leading to writes beyond the end of the allocated connector
state block and all sorts of fun memory corruption related crashes.

Fixes: d7721ca71126 "drm/vmwgfx: Connector atomic state"
Cc: 
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  | 4 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index b8a09807c5de..3824595fece1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -266,8 +266,8 @@ static const struct drm_connector_funcs 
vmw_legacy_connector_funcs = {
.set_property = vmw_du_connector_set_property,
.destroy = vmw_ldu_connector_destroy,
.reset = vmw_du_connector_reset,
-   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
-   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+   .atomic_duplicate_state = vmw_du_connector_duplicate_state,
+   .atomic_destroy_state = vmw_du_connector_destroy_state,
.atomic_set_property = vmw_du_connector_atomic_set_property,
.atomic_get_property = vmw_du_connector_atomic_get_property,
 };
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index bc5f6026573d..63a4cd794b73 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -420,8 +420,8 @@ static const struct drm_connector_funcs 
vmw_sou_connector_funcs = {
.set_property = vmw_du_connector_set_property,
.destroy = vmw_sou_connector_destroy,
.reset = vmw_du_connector_reset,
-   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
-   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+   .atomic_duplicate_state = vmw_du_connector_duplicate_state,
+   .atomic_destroy_state = vmw_du_connector_destroy_state,
.atomic_set_property = vmw_du_connector_atomic_set_property,
.atomic_get_property = vmw_du_connector_atomic_get_property,
 };
-- 
2.14.3

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

Re: [PATCH 1/6] backlight: Nuke unused backlight.props.state states

[Daniel Thompson]

On 17/01/18 14:01, Daniel Vetter wrote:

The backlight power state handling is supremely confusing. We have:
- props.power, using FB_BLANK_* defines
- props.fb_blank, using the same, but deprecated int favour of
   props.state
- props.state, using the BL_CORE_* defines
- and finally a bunch of backlight drivers treat brightness == 0 as
   off. But of course not all of them.

This is way too much confusion to fix in a simple patch, but at least
prevent more hilarity from spreading by removing the unused BL_CORE_*
defines. I have no idea why exactly anyone would need that.

Wrt the ideal state, we really just want a boolean state. The 4 power
saving states that the fbdev subsystem uses are overkill in todays hw
(this was only relevant for VGA and similar analog circuits like
TV-out), the new drm atomic modeset api simplified even the uapi to a
simple bool. And there was never a valid technical reason to have the
intermediate fbdev power states for backlights (those really only can
be either off or on).

Cleanup motivated by Meghana's questions about all this.

Cc: Lee Jones 
Cc: Daniel Thompson 
Cc: Jingoo Han 
Cc: Meghana Madhyastha 
Signed-off-by: Daniel Vetter 


Acked-by: Daniel Thompson 

Daniel: Ack is info for Lee J, not to imply you should take it through
one of your trees.


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

Re: [PATCH] [RESEND] drm/gma500: initialize gma_clock_t structures

[Daniel Vetter]

On Wed, Jan 17, 2018 at 3:36 PM, Arnd Bergmann  wrote:
> On Wed, Jan 17, 2018 at 9:27 AM, Daniel Vetter  wrote:
>> On Tue, Jan 16, 2018 at 03:57:10PM +0100, Arnd Bergmann wrote:
>>> The two functions pass a partially initialized structure back to the
>>> caller after a memset() on the destination.
>>>
>>> This is not entirely well-defined, most compilers are sensible enough
>>> to either keep the zero-initialization for the uninitialized members,
>>> but gcc-4.4 does not, and it warns about this:
>>>
>>> drivers/gpu/drm/gma500/oaktrail_crtc.c: In function 
>>> 'mrst_sdvo_find_best_pll':
>>> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.vco' may be 
>>> used uninitialized in this function
>>> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.dot' may be 
>>> used uninitialized in this function
>>> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.p2' may be used 
>>> uninitialized in this function
>>> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.m2' may be used 
>>> uninitialized in this function
>>> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.m1' may be used 
>>> uninitialized in this function
>>> drivers/gpu/drm/gma500/oaktrail_crtc.c: In function 
>>> 'mrst_lvds_find_best_pll':
>>> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.p' may be used 
>>> uninitialized in this function
>>> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.vco' may be 
>>> used uninitialized in this function
>>> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.p2' may be used 
>>> uninitialized in this function
>>> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.m2' may be used 
>>> uninitialized in this function
>>> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.m1' may be used 
>>> uninitialized in this function
>>> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.n' may be used 
>>> uninitialized in this function
>>>
>>> This adds an initialization at declaration time to avoid the warning
>>> and make it well-defined on all compiler versions.
>>>
>>> Signed-off-by: Arnd Bergmann 
>>
>> Applied to drm-misc-next-fixes for 4.16, thx for your patch.
>
> Thanks!
>
>> Aside: Still don't want commit rights? :-)
>
> I think I'm fine without. While I do tend to have a backlog on DRM
> patches that I'd
> like to get merged, they are generally of the kind that I should not
> apply myself
> without the maintainer being involved in some form, and then they can commit
> it themselves.

Commit rights isn't for pushing unreviewed stuff (our scripts will
remind you of that if you try). But you could just volunteer someone
to review the entire pile and then push it, instead of nagging every
single slacking maintainer individually.
-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] [RESEND] drm/gma500: initialize gma_clock_t structures

[Arnd Bergmann]

On Wed, Jan 17, 2018 at 9:27 AM, Daniel Vetter  wrote:
> On Tue, Jan 16, 2018 at 03:57:10PM +0100, Arnd Bergmann wrote:
>> The two functions pass a partially initialized structure back to the
>> caller after a memset() on the destination.
>>
>> This is not entirely well-defined, most compilers are sensible enough
>> to either keep the zero-initialization for the uninitialized members,
>> but gcc-4.4 does not, and it warns about this:
>>
>> drivers/gpu/drm/gma500/oaktrail_crtc.c: In function 
>> 'mrst_sdvo_find_best_pll':
>> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.vco' may be used 
>> uninitialized in this function
>> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.dot' may be used 
>> uninitialized in this function
>> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.p2' may be used 
>> uninitialized in this function
>> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.m2' may be used 
>> uninitialized in this function
>> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.m1' may be used 
>> uninitialized in this function
>> drivers/gpu/drm/gma500/oaktrail_crtc.c: In function 
>> 'mrst_lvds_find_best_pll':
>> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.p' may be used 
>> uninitialized in this function
>> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.vco' may be used 
>> uninitialized in this function
>> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.p2' may be used 
>> uninitialized in this function
>> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.m2' may be used 
>> uninitialized in this function
>> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.m1' may be used 
>> uninitialized in this function
>> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.n' may be used 
>> uninitialized in this function
>>
>> This adds an initialization at declaration time to avoid the warning
>> and make it well-defined on all compiler versions.
>>
>> Signed-off-by: Arnd Bergmann 
>
> Applied to drm-misc-next-fixes for 4.16, thx for your patch.

Thanks!

> Aside: Still don't want commit rights? :-)

I think I'm fine without. While I do tend to have a backlog on DRM
patches that I'd
like to get merged, they are generally of the kind that I should not
apply myself
without the maintainer being involved in some form, and then they can commit
it themselves.

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

Re: [PATCH 2/6] backlight/generic-bl: remove DRIVER1 state

[Emil Velikov]

On 17 January 2018 at 14:01, Daniel Vetter  wrote:
> Nothing in the entire tree ever sets this, which means this is dead
> code. Remove it.
>
> Cc: Lee Jones 
> Cc: Daniel Thompson 
> Cc: Jingoo Han 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/video/backlight/generic_bl.c | 5 -

Fly-by comment, while waiting for coffee to kick-in.
I think this patch should be after pandora/others have stopped abusing
BL_CORE_DRIVER1.

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

[PATCH] drm: arc: Don't set connector DPMS handler

[Laurent Pinchart]

The connector .dpms operation is only used by the legacy helpers. The
arc driver being fully atomic, the operation isn't needed anymore.
Remove it.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/arc/arcpgu_sim.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c b/drivers/gpu/drm/arc/arcpgu_sim.c
index bca3a678c955..1d4d5dd7e763 100644
--- a/drivers/gpu/drm/arc/arcpgu_sim.c
+++ b/drivers/gpu/drm/arc/arcpgu_sim.c
@@ -53,7 +53,6 @@ arcpgu_drm_connector_helper_funcs = {
 };
 
 static const struct drm_connector_funcs arcpgu_drm_connector_funcs = {
-   .dpms = drm_helper_connector_dpms,
.reset = drm_atomic_helper_connector_reset,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = arcpgu_drm_connector_destroy,
-- 
Regards,

Laurent Pinchart

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

[PATCH] drm/arcpgu: remove drm_encoder_slave

[Daniel Vetter]

drm_encoder_slave is the old way to write bridge drivers, for i2c
bridges only. It's deprecated, and definitely should not be used in
new drivers. This has absolutely nothing to do with the new bridge
driver infrastructure implemented by drm_bridge.

What's even strange is that arcpgu doesn't even use any of this, it
really only wants a plain normal drm_encoder. Nuke all the surplus
real estate.

v2: Actually git add after compile testing ...

v3: Clarify commit message and stop including drm_encoder_slave.h.

Cc: Laurent Pinchart 
Cc: Alexey Brodkin 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/arc/arcpgu_hdmi.c |  3 ++-
 drivers/gpu/drm/arc/arcpgu_sim.c  | 16 ++--
 2 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_hdmi.c 
b/drivers/gpu/drm/arc/arcpgu_hdmi.c
index 0ce7f398bcff..977dfa55162f 100644
--- a/drivers/gpu/drm/arc/arcpgu_hdmi.c
+++ b/drivers/gpu/drm/arc/arcpgu_hdmi.c
@@ -15,7 +15,8 @@
  */
 
 #include 
-#include 
+#include 
+#include 
 
 #include "arcpgu.h"
 
diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c b/drivers/gpu/drm/arc/arcpgu_sim.c
index bca3a678c955..b8f6f9a5dfbe 100644
--- a/drivers/gpu/drm/arc/arcpgu_sim.c
+++ b/drivers/gpu/drm/arc/arcpgu_sim.c
@@ -15,7 +15,6 @@
  */
 
 #include 
-#include 
 #include 
 
 #include "arcpgu.h"
@@ -29,7 +28,6 @@
 
 struct arcpgu_drm_connector {
struct drm_connector connector;
-   struct drm_encoder_slave *encoder_slave;
 };
 
 static int arcpgu_drm_connector_get_modes(struct drm_connector *connector)
@@ -68,7 +66,7 @@ static struct drm_encoder_funcs arcpgu_drm_encoder_funcs = {
 int arcpgu_drm_sim_init(struct drm_device *drm, struct device_node *np)
 {
struct arcpgu_drm_connector *arcpgu_connector;
-   struct drm_encoder_slave *encoder;
+   struct drm_encoder *encoder;
struct drm_connector *connector;
int ret;
 
@@ -76,10 +74,10 @@ int arcpgu_drm_sim_init(struct drm_device *drm, struct 
device_node *np)
if (encoder == NULL)
return -ENOMEM;
 
-   encoder->base.possible_crtcs = 1;
-   encoder->base.possible_clones = 0;
+   encoder->possible_crtcs = 1;
+   encoder->possible_clones = 0;
 
-   ret = drm_encoder_init(drm, >base, _drm_encoder_funcs,
+   ret = drm_encoder_init(drm, encoder, _drm_encoder_funcs,
   DRM_MODE_ENCODER_VIRTUAL, NULL);
if (ret)
return ret;
@@ -101,21 +99,19 @@ int arcpgu_drm_sim_init(struct drm_device *drm, struct 
device_node *np)
goto error_encoder_cleanup;
}
 
-   ret = drm_mode_connector_attach_encoder(connector, >base);
+   ret = drm_mode_connector_attach_encoder(connector, encoder);
if (ret < 0) {
dev_err(drm->dev, "could not attach connector to encoder\n");
drm_connector_unregister(connector);
goto error_connector_cleanup;
}
 
-   arcpgu_connector->encoder_slave = encoder;
-
return 0;
 
 error_connector_cleanup:
drm_connector_cleanup(connector);
 
 error_encoder_cleanup:
-   drm_encoder_cleanup(>base);
+   drm_encoder_cleanup(encoder);
return ret;
 }
-- 
2.15.1

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

Re: [PATCH] drm: Don't include drm/drm_encoder_slave.h when not needed

[Daniel Vetter]

On Wed, Jan 17, 2018 at 03:57:52PM +0200, Laurent Pinchart wrote:
> The dw-hdmi, kirin and imx drivers include the drm/drm_encoder_slave.h
> header but don't use the encoder slave API. Remove it or replace it with
> drm/drm_encoder.h as needed.
> 
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Daniel Vetter 

Pls push to drm-misc-next (you haz commit rights ...).
-Daniel

> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c| 1 -
>  drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 2 +-
>  drivers/gpu/drm/imx/dw_hdmi-imx.c| 2 +-
>  3 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index a38db40ce990..e20cc16be087 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -27,7 +27,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  #include 
> diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c 
> b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
> index b4c7af3ab6ae..a02a200dc3b2 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
> @@ -21,7 +21,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  
>  #include "dw_dsi_reg.h"
> diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
> b/drivers/gpu/drm/imx/dw_hdmi-imx.c
> index b62763aa8706..45d9826a0cc4 100644
> --- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
> +++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
> @@ -18,7 +18,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  #include "imx-drm.h"
>  
> -- 
> Regards,
> 
> Laurent Pinchart
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH] drm/arcpgu: remove drm_encoder_slave

[Daniel Vetter]

On Wed, Jan 17, 2018 at 01:55:55PM +, Alexey Brodkin wrote:
> Hi Daniel,
> 
> On Wed, 2018-01-17 at 14:43 +0100, Daniel Vetter wrote:
> > drm_encoder_slave is the old way to write bridge drivers, for i2c
> > bridges only. It's deprecated, and definitely should not be used in
> > new drivers.
> > 
> > What's even strange is that arcpgu doesn't even use any of this, it
> > really only wants a plain normal drm_encoder. Nuke all the surplus
> > real estate.
> 
> As of today we use either use adv7511 encoder or dw-hdmi.
> And I guess proposed change is OK for both bridge versions, rigth?

drm_encoder_slave is something completely different from drm_bridge. The
latter will keep working.
-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 5/6] backlight: Also nuke BL_CORE_DRIVER1

[Daniel Vetter]

Now that the 3 drivers using this are cleaned up we can also remove
this final bit of confusion of leaking driver internals into the
backlight power interface.

The backlight power interface itself is still a massive mess.

Cc: Lee Jones 
Cc: Daniel Thompson 
Cc: Jingoo Han 
Signed-off-by: Daniel Vetter 
---
 include/linux/backlight.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 9776edb0ff06..b6f7c99d1c8e 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -84,7 +84,6 @@ struct backlight_properties {
 
 #define BL_CORE_SUSPENDED  (1 << 0)/* backlight is suspended */
 #define BL_CORE_FBBLANK(1 << 1)/* backlight is under 
an fb blank event */
-#define BL_CORE_DRIVER1(1 << 31)   /* reserved for driver 
specific use */
 
 };
 
-- 
2.15.1

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

[PATCH 4/6] staging/fbtft: Stop using BL_CORE_DRIVER1

[Daniel Vetter]

Leaking driver internal tracking into the already massively confusing
backlight power tracking is really confusing.

Luckily we have already a drvdata structure, so fixing this is really
easy.

Cc: Lee Jones 
Cc: Daniel Thompson 
Cc: Jingoo Han 
Cc: Thomas Petazzoni 
Signed-off-by: Daniel Vetter 
---
 drivers/staging/fbtft/fbtft-core.c | 4 ++--
 drivers/staging/fbtft/fbtft.h  | 1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/fbtft/fbtft-core.c 
b/drivers/staging/fbtft/fbtft-core.c
index 6d0363deba61..448929cc7ba1 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -255,7 +255,7 @@ static int fbtft_request_gpios_dt(struct fbtft_par *par)
 static int fbtft_backlight_update_status(struct backlight_device *bd)
 {
struct fbtft_par *par = bl_get_data(bd);
-   bool polarity = !!(bd->props.state & BL_CORE_DRIVER1);
+   bool polarity = par->polarity;
 
fbtft_par_dbg(DEBUG_BACKLIGHT, par,
"%s: polarity=%d, power=%d, fb_blank=%d\n",
@@ -305,7 +305,7 @@ void fbtft_register_backlight(struct fbtft_par *par)
/* Assume backlight is off, get polarity from current state of pin */
bl_props.power = FB_BLANK_POWERDOWN;
if (!gpio_get_value(par->gpio.led[0]))
-   bl_props.state |= BL_CORE_DRIVER1;
+   par->polarity = true;
 
bd = backlight_device_register(dev_driver_string(par->info->device),
   par->info->device, par,
diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h
index 488ab788138e..54de7cdfdff7 100644
--- a/drivers/staging/fbtft/fbtft.h
+++ b/drivers/staging/fbtft/fbtft.h
@@ -240,6 +240,7 @@ struct fbtft_par {
ktime_t update_time;
bool bgr;
void *extra;
+   bool polarity;
 };
 
 #define NUMARGS(...)  (sizeof((int[]){__VA_ARGS__})/sizeof(int))
-- 
2.15.1

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

[PATCH 1/6] backlight: Nuke unused backlight.props.state states

[Daniel Vetter]

The backlight power state handling is supremely confusing. We have:
- props.power, using FB_BLANK_* defines
- props.fb_blank, using the same, but deprecated int favour of
  props.state
- props.state, using the BL_CORE_* defines
- and finally a bunch of backlight drivers treat brightness == 0 as
  off. But of course not all of them.

This is way too much confusion to fix in a simple patch, but at least
prevent more hilarity from spreading by removing the unused BL_CORE_*
defines. I have no idea why exactly anyone would need that.

Wrt the ideal state, we really just want a boolean state. The 4 power
saving states that the fbdev subsystem uses are overkill in todays hw
(this was only relevant for VGA and similar analog circuits like
TV-out), the new drm atomic modeset api simplified even the uapi to a
simple bool. And there was never a valid technical reason to have the
intermediate fbdev power states for backlights (those really only can
be either off or on).

Cleanup motivated by Meghana's questions about all this.

Cc: Lee Jones 
Cc: Daniel Thompson 
Cc: Jingoo Han 
Cc: Meghana Madhyastha 
Signed-off-by: Daniel Vetter 
---
 include/linux/backlight.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index af7003548593..9776edb0ff06 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -84,9 +84,6 @@ struct backlight_properties {
 
 #define BL_CORE_SUSPENDED  (1 << 0)/* backlight is suspended */
 #define BL_CORE_FBBLANK(1 << 1)/* backlight is under 
an fb blank event */
-#define BL_CORE_DRIVER4(1 << 28)   /* reserved for driver 
specific use */
-#define BL_CORE_DRIVER3(1 << 29)   /* reserved for driver 
specific use */
-#define BL_CORE_DRIVER2(1 << 30)   /* reserved for driver 
specific use */
 #define BL_CORE_DRIVER1(1 << 31)   /* reserved for driver 
specific use */
 
 };
-- 
2.15.1

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

[PATCH 3/6] backlight/pandora: Stop using BL_CORE_DRIVER1

[Daniel Vetter]

Leaking driver internal tracking into the already massively confusing
backlight power tracking is really confusing.

Stop that by allocating a tiny driver private data structure instead.

Cc: Lee Jones 
Cc: Daniel Thompson 
Cc: Jingoo Han 
Signed-off-by: Daniel Vetter 
---
 drivers/video/backlight/pandora_bl.c | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/video/backlight/pandora_bl.c 
b/drivers/video/backlight/pandora_bl.c
index a186bc677c7d..6bd159946a47 100644
--- a/drivers/video/backlight/pandora_bl.c
+++ b/drivers/video/backlight/pandora_bl.c
@@ -35,11 +35,15 @@
 #define MAX_VALUE 63
 #define MAX_USER_VALUE (MAX_VALUE - MIN_VALUE)
 
-#define PANDORABL_WAS_OFF BL_CORE_DRIVER1
+struct pandora_private {
+   unsigned old_state;
+#define PANDORABL_WAS_OFF 1
+};
 
 static int pandora_backlight_update_status(struct backlight_device *bl)
 {
int brightness = bl->props.brightness;
+   struct pandora_private *priv = bl_get_data(bl);
u8 r;
 
if (bl->props.power != FB_BLANK_UNBLANK)
@@ -53,7 +57,7 @@ static int pandora_backlight_update_status(struct 
backlight_device *bl)
brightness = MAX_USER_VALUE;
 
if (brightness == 0) {
-   if (bl->props.state & PANDORABL_WAS_OFF)
+   if (priv->old_state & PANDORABL_WAS_OFF)
goto done;
 
/* first disable PWM0 output, then clock */
@@ -66,7 +70,7 @@ static int pandora_backlight_update_status(struct 
backlight_device *bl)
goto done;
}
 
-   if (bl->props.state & PANDORABL_WAS_OFF) {
+   if (priv->old_state & PANDORABL_WAS_OFF) {
/*
 * set PWM duty cycle to max. TPS61161 seems to use this
 * to calibrate it's PWM sensitivity when it starts.
@@ -93,9 +97,9 @@ static int pandora_backlight_update_status(struct 
backlight_device *bl)
 
 done:
if (brightness != 0)
-   bl->props.state &= ~PANDORABL_WAS_OFF;
+   priv->old_state 0;
else
-   bl->props.state |= PANDORABL_WAS_OFF;
+   priv->old_state = PANDORABL_WAS_OFF;
 
return 0;
 }
@@ -109,15 +113,23 @@ static int pandora_backlight_probe(struct platform_device 
*pdev)
 {
struct backlight_properties props;
struct backlight_device *bl;
+   struct pandora_private *priv;
u8 r;
 
+   priv = devm_kmalloc(>dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv) {
+   dev_err(>dev, "failed to allocate driver private data\n");
+   return -ENOMEM;
+   }
+
memset(, 0, sizeof(props));
props.max_brightness = MAX_USER_VALUE;
props.type = BACKLIGHT_RAW;
bl = devm_backlight_device_register(>dev, pdev->name, >dev,
-   NULL, _backlight_ops, );
+   priv, _backlight_ops, );
if (IS_ERR(bl)) {
dev_err(>dev, "failed to register backlight\n");
+   kfree(priv);
return PTR_ERR(bl);
}
 
@@ -126,7 +138,7 @@ static int pandora_backlight_probe(struct platform_device 
*pdev)
/* 64 cycle period, ON position 0 */
twl_i2c_write_u8(TWL_MODULE_PWM, 0x80, TWL_PWM0_ON);
 
-   bl->props.state |= PANDORABL_WAS_OFF;
+   priv->old_state = PANDORABL_WAS_OFF;
bl->props.brightness = MAX_USER_VALUE;
backlight_update_status(bl);
 
-- 
2.15.1

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

[PATCH 6/6] MAINTAINERS: add dri-devel for backlight subsystem patches

[Daniel Vetter]

For the same reasons we've added dri-devel for all fbdev patches: Most
of the actively developed drivers using this infrastructure are in
drivers/gpu/. It just makes sense to cross-post patches and keep
aligned. And total activity in the backlight subsystem is miniscule
compared to drm overall.

Cc: Lee Jones 
Cc: Daniel Thompson 
Cc: Jingoo Han 
Signed-off-by: Daniel Vetter 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7691e1025708..6534517f53b6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2546,6 +2546,7 @@ BACKLIGHT CLASS/SUBSYSTEM
 M: Lee Jones 
 M: Daniel Thompson 
 M: Jingoo Han 
+L: dri-devel@lists.freedesktop.org
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git
 S: Maintained
 F: drivers/video/backlight/
-- 
2.15.1

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

[PATCH 2/6] backlight/generic-bl: remove DRIVER1 state

[Daniel Vetter]

Nothing in the entire tree ever sets this, which means this is dead
code. Remove it.

Cc: Lee Jones 
Cc: Daniel Thompson 
Cc: Jingoo Han 
Signed-off-by: Daniel Vetter 
---
 drivers/video/backlight/generic_bl.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/video/backlight/generic_bl.c 
b/drivers/video/backlight/generic_bl.c
index 67dfb939a514..4dea91acea13 100644
--- a/drivers/video/backlight/generic_bl.c
+++ b/drivers/video/backlight/generic_bl.c
@@ -21,9 +21,6 @@ static int genericbl_intensity;
 static struct backlight_device *generic_backlight_device;
 static struct generic_bl_info *bl_machinfo;
 
-/* Flag to signal when the battery is low */
-#define GENERICBL_BATTLOW   BL_CORE_DRIVER1
-
 static int genericbl_send_intensity(struct backlight_device *bd)
 {
int intensity = bd->props.brightness;
@@ -34,8 +31,6 @@ static int genericbl_send_intensity(struct backlight_device 
*bd)
intensity = 0;
if (bd->props.state & BL_CORE_SUSPENDED)
intensity = 0;
-   if (bd->props.state & GENERICBL_BATTLOW)
-   intensity &= bl_machinfo->limit_mask;
 
bl_machinfo->set_bl_intensity(intensity);
 
-- 
2.15.1

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

Re: [PATCH] drm/arcpgu: remove drm_encoder_slave

[Laurent Pinchart]

Hi Daniel,

Thank you for the patch.

On Wednesday, 17 January 2018 15:53:07 EET Daniel Vetter wrote:
> drm_encoder_slave is the old way to write bridge drivers, for i2c
> bridges only. It's deprecated, and definitely should not be used in
> new drivers.
> 
> What's even strange is that arcpgu doesn't even use any of this, it
> really only wants a plain normal drm_encoder. Nuke all the surplus
> real estate.
> 
> v2: Actually git add after compile testing ...
> 
> Cc: Laurent Pinchart 
> Cc: Alexey Brodkin 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Laurent Pinchart 

Could you merge this along with "[PATCH] drm: Don't include drm/
drm_encoder_slave.h when not needed" ? We will then only have two users of the 
encoder slave API left, nouveau and armada (and of course the encoder slave 
drivers themselves), and no stray occurrence of the encoder slave term in 
other source files.

> ---
>  drivers/gpu/drm/arc/arcpgu_sim.c | 15 ++-
>  1 file changed, 6 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c
> b/drivers/gpu/drm/arc/arcpgu_sim.c index bca3a678c955..19f5a781666d 100644
> --- a/drivers/gpu/drm/arc/arcpgu_sim.c
> +++ b/drivers/gpu/drm/arc/arcpgu_sim.c
> @@ -29,7 +29,6 @@
> 
>  struct arcpgu_drm_connector {
>   struct drm_connector connector;
> - struct drm_encoder_slave *encoder_slave;
>  };
> 
>  static int arcpgu_drm_connector_get_modes(struct drm_connector *connector)
> @@ -68,7 +67,7 @@ static struct drm_encoder_funcs arcpgu_drm_encoder_funcs =
> { int arcpgu_drm_sim_init(struct drm_device *drm, struct device_node *np) {
>   struct arcpgu_drm_connector *arcpgu_connector;
> - struct drm_encoder_slave *encoder;
> + struct drm_encoder *encoder;
>   struct drm_connector *connector;
>   int ret;
> 
> @@ -76,10 +75,10 @@ int arcpgu_drm_sim_init(struct drm_device *drm, struct
> device_node *np) if (encoder == NULL)
>   return -ENOMEM;
> 
> - encoder->base.possible_crtcs = 1;
> - encoder->base.possible_clones = 0;
> + encoder->possible_crtcs = 1;
> + encoder->possible_clones = 0;
> 
> - ret = drm_encoder_init(drm, >base, _drm_encoder_funcs,
> + ret = drm_encoder_init(drm, encoder, _drm_encoder_funcs,
>  DRM_MODE_ENCODER_VIRTUAL, NULL);
>   if (ret)
>   return ret;
> @@ -101,21 +100,19 @@ int arcpgu_drm_sim_init(struct drm_device *drm, struct
> device_node *np) goto error_encoder_cleanup;
>   }
> 
> - ret = drm_mode_connector_attach_encoder(connector, >base);
> + ret = drm_mode_connector_attach_encoder(connector, encoder);
>   if (ret < 0) {
>   dev_err(drm->dev, "could not attach connector to encoder\n");
>   drm_connector_unregister(connector);
>   goto error_connector_cleanup;
>   }
> 
> - arcpgu_connector->encoder_slave = encoder;
> -
>   return 0;
> 
>  error_connector_cleanup:
>   drm_connector_cleanup(connector);
> 
>  error_encoder_cleanup:
> - drm_encoder_cleanup(>base);
> + drm_encoder_cleanup(encoder);
>   return ret;
>  }

-- 
Regards,

Laurent Pinchart

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

[PATCH] drm: Don't include drm/drm_encoder_slave.h when not needed

[Laurent Pinchart]

The dw-hdmi, kirin and imx drivers include the drm/drm_encoder_slave.h
header but don't use the encoder slave API. Remove it or replace it with
drm/drm_encoder.h as needed.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c| 1 -
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 2 +-
 drivers/gpu/drm/imx/dw_hdmi-imx.c| 2 +-
 3 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index a38db40ce990..e20cc16be087 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c 
b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
index b4c7af3ab6ae..a02a200dc3b2 100644
--- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -21,7 +21,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include "dw_dsi_reg.h"
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index b62763aa8706..45d9826a0cc4 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -18,7 +18,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "imx-drm.h"
 
-- 
Regards,

Laurent Pinchart

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

[PATCH] drm/arcpgu: remove drm_encoder_slave

[Daniel Vetter]

drm_encoder_slave is the old way to write bridge drivers, for i2c
bridges only. It's deprecated, and definitely should not be used in
new drivers.

What's even strange is that arcpgu doesn't even use any of this, it
really only wants a plain normal drm_encoder. Nuke all the surplus
real estate.

v2: Actually git add after compile testing ...

Cc: Laurent Pinchart 
Cc: Alexey Brodkin 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/arc/arcpgu_sim.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c b/drivers/gpu/drm/arc/arcpgu_sim.c
index bca3a678c955..19f5a781666d 100644
--- a/drivers/gpu/drm/arc/arcpgu_sim.c
+++ b/drivers/gpu/drm/arc/arcpgu_sim.c
@@ -29,7 +29,6 @@
 
 struct arcpgu_drm_connector {
struct drm_connector connector;
-   struct drm_encoder_slave *encoder_slave;
 };
 
 static int arcpgu_drm_connector_get_modes(struct drm_connector *connector)
@@ -68,7 +67,7 @@ static struct drm_encoder_funcs arcpgu_drm_encoder_funcs = {
 int arcpgu_drm_sim_init(struct drm_device *drm, struct device_node *np)
 {
struct arcpgu_drm_connector *arcpgu_connector;
-   struct drm_encoder_slave *encoder;
+   struct drm_encoder *encoder;
struct drm_connector *connector;
int ret;
 
@@ -76,10 +75,10 @@ int arcpgu_drm_sim_init(struct drm_device *drm, struct 
device_node *np)
if (encoder == NULL)
return -ENOMEM;
 
-   encoder->base.possible_crtcs = 1;
-   encoder->base.possible_clones = 0;
+   encoder->possible_crtcs = 1;
+   encoder->possible_clones = 0;
 
-   ret = drm_encoder_init(drm, >base, _drm_encoder_funcs,
+   ret = drm_encoder_init(drm, encoder, _drm_encoder_funcs,
   DRM_MODE_ENCODER_VIRTUAL, NULL);
if (ret)
return ret;
@@ -101,21 +100,19 @@ int arcpgu_drm_sim_init(struct drm_device *drm, struct 
device_node *np)
goto error_encoder_cleanup;
}
 
-   ret = drm_mode_connector_attach_encoder(connector, >base);
+   ret = drm_mode_connector_attach_encoder(connector, encoder);
if (ret < 0) {
dev_err(drm->dev, "could not attach connector to encoder\n");
drm_connector_unregister(connector);
goto error_connector_cleanup;
}
 
-   arcpgu_connector->encoder_slave = encoder;
-
return 0;
 
 error_connector_cleanup:
drm_connector_cleanup(connector);
 
 error_encoder_cleanup:
-   drm_encoder_cleanup(>base);
+   drm_encoder_cleanup(encoder);
return ret;
 }
-- 
2.15.1

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

[Bug 198123] Console is the wrong color at boot with radeon 6670

[bugzilla-daemon]

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

--- Comment #19 from Daniel Vetter (dan...@ffwll.ch) ---
Yeah test result on latest -rc8 is needed, since maybe there's some other bug
somewhere ...

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

Re: [PATCH v3 09/13] drm/sun4i: backend: Wire in the frontend

[Chen-Yu Tsai]

On Tue, Jan 9, 2018 at 6:09 PM, Maxime Ripard
 wrote:
> Now that we have a driver, we can make use of it. This is done by
> adding a flag to our custom plane state that will trigger whether we should
> use the frontend on that particular plane or not.
>
> The rest is just plumbing to set up the backend to not perform the DMA but
> receive its data from the frontend.
>
> Note that we're still not making any use of the frontend itself, as no one
> is setting the flag yet.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/sun4i/sun4i_backend.c | 90 -
>  drivers/gpu/drm/sun4i/sun4i_backend.h |  8 ++-
>  drivers/gpu/drm/sun4i/sun4i_crtc.c|  1 +-
>  drivers/gpu/drm/sun4i/sun4i_layer.c   | 33 +-
>  drivers/gpu/drm/sun4i/sun4i_layer.h   |  1 +-
>  5 files changed, 130 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
> b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index f971d3fb5ee4..29e1ca7e01fe 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -26,6 +26,7 @@
>
>  #include "sun4i_backend.h"
>  #include "sun4i_drv.h"
> +#include "sun4i_frontend.h"
>  #include "sun4i_layer.h"
>  #include "sunxi_engine.h"
>
> @@ -203,6 +204,30 @@ int sun4i_backend_update_layer_formats(struct 
> sun4i_backend *backend,
> return 0;
>  }
>
> +int sun4i_backend_update_layer_frontend(struct sun4i_backend *backend,
> +   int layer, uint32_t fmt)
> +{
> +   u32 val;
> +   int ret;
> +
> +   ret = sun4i_backend_drm_format_to_layer(NULL, fmt, );
> +   if (ret) {
> +   DRM_DEBUG_DRIVER("Invalid format\n");
> +   return ret;
> +   }
> +
> +   regmap_update_bits(backend->engine.regs,
> +  SUN4I_BACKEND_ATTCTL_REG0(layer),
> +  SUN4I_BACKEND_ATTCTL_REG0_LAY_VDOEN,
> +  SUN4I_BACKEND_ATTCTL_REG0_LAY_VDOEN);
> +
> +   regmap_update_bits(backend->engine.regs,
> +  SUN4I_BACKEND_ATTCTL_REG1(layer),
> +  SUN4I_BACKEND_ATTCTL_REG1_LAY_FBFMT, val);
> +
> +   return 0;
> +}
> +
>  int sun4i_backend_update_layer_buffer(struct sun4i_backend *backend,
>   int layer, struct drm_plane *plane)
>  {
> @@ -246,6 +271,36 @@ int sun4i_backend_update_layer_buffer(struct 
> sun4i_backend *backend,
> return 0;
>  }
>
> +static void sun4i_backend_vblank_quirk(struct sunxi_engine *engine)
> +{
> +   struct sun4i_backend *backend = engine_to_sun4i_backend(engine);
> +   struct sun4i_frontend *frontend = backend->frontend;
> +
> +   if (!frontend)
> +   return;
> +
> +   /*
> +* In a teardown scenario with the frontend involved, we have
> +* to keep the frontend enabled until the next vblank, and
> +* only then disable it.
> +*
> +* This is due to the fact that the backend will not take into
> +* account the new configuration (with the plane that used to
> +* be fed by the frontend now disabled) until we write to the
> +* commit bit and the hardware fetches the new configuration
> +* during the next vblank.
> +*
> +* So we keep the frontend around in order to prevent any
> +* visual artifacts.
> +*/
> +   spin_lock(>frontend_lock);
> +   if (backend->frontend_teardown) {
> +   sun4i_frontend_exit(frontend);
> +   backend->frontend_teardown = false;
> +   }
> +   spin_unlock(>frontend_lock);
> +};
> +
>  static int sun4i_backend_init_sat(struct device *dev) {
> struct sun4i_backend *backend = dev_get_drvdata(dev);
> int ret;
> @@ -330,11 +385,40 @@ static int sun4i_backend_of_get_id(struct device_node 
> *node)
> return ret;
>  }
>
> +static struct sun4i_frontend *sun4i_backend_find_frontend(struct sun4i_drv 
> *drv,
> + struct device_node 
> *node)
> +{
> +   struct device_node *port, *ep, *remote;
> +   struct sun4i_frontend *frontend;
> +
> +   port = of_graph_get_port_by_id(node, 0);
> +   if (!port)
> +   return ERR_PTR(-EINVAL);
> +
> +   for_each_available_child_of_node(port, ep) {
> +   remote = of_graph_get_remote_port_parent(ep);
> +   if (!remote)
> +   continue;
> +
> +   /* does this node match any registered engines? */
> +   list_for_each_entry(frontend, >frontend_list, list) {
> +   if (remote == frontend->node) {
> +   of_node_put(remote);
> +   of_node_put(port);
> +   return frontend;
> +   }
> +   }

I assume that 

Re: [PATCH v3 08/13] drm/sun4i: Add a driver for the display frontend

[Chen-Yu Tsai]

On Tue, Jan 9, 2018 at 6:09 PM, Maxime Ripard
 wrote:
> The display frontend is an hardware block that can be used to implement
> some more advanced features like hardware scaling or colorspace
> conversions. It can also be used to implement the output format of the VPU.
>
> Let's create a minimal driver for it that will only enable the hardware
> scaling features.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/sun4i/Makefile |   3 +-
>  drivers/gpu/drm/sun4i/sun4i_drv.c  |  27 +-
>  drivers/gpu/drm/sun4i/sun4i_drv.h  |   1 +-
>  drivers/gpu/drm/sun4i/sun4i_frontend.c | 384 ++-
>  drivers/gpu/drm/sun4i/sun4i_frontend.h |  99 +++-
>  5 files changed, 509 insertions(+), 5 deletions(-)
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_frontend.c
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_frontend.h
>
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index 0c2f8c7facae..b660d82011f4 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -1,5 +1,6 @@
>  # SPDX-License-Identifier: GPL-2.0
>  sun4i-backend-y+= sun4i_backend.o sun4i_layer.o
> +sun4i-frontend-y   += sun4i_frontend.o
>
>  sun4i-drm-y+= sun4i_drv.o
>  sun4i-drm-y+= sun4i_framebuffer.o
> @@ -21,6 +22,6 @@ obj-$(CONFIG_DRM_SUN4I)   += sun4i-tcon.o
>  obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o
>  obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o
>
> -obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o
> +obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o sun4i-frontend.o
>  obj-$(CONFIG_DRM_SUN4I_HDMI)   += sun4i-drm-hdmi.o
>  obj-$(CONFIG_DRM_SUN8I_MIXER)  += sun8i-mixer.o
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
> b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 75c76cdd82bc..42e68cf3a2e8 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -23,6 +23,7 @@
>  #include 
>
>  #include "sun4i_drv.h"
> +#include "sun4i_frontend.h"
>  #include "sun4i_framebuffer.h"
>  #include "sun4i_tcon.h"
>
> @@ -98,6 +99,7 @@ static int sun4i_drv_bind(struct device *dev)
> goto free_drm;
> }
> drm->dev_private = drv;
> +   INIT_LIST_HEAD(>frontend_list);
> INIT_LIST_HEAD(>engine_list);
> INIT_LIST_HEAD(>tcon_list);
>
> @@ -185,6 +187,14 @@ static bool sun4i_drv_node_is_frontend(struct 
> device_node *node)
> of_device_is_compatible(node, 
> "allwinner,sun8i-a33-display-frontend");
>  }
>
> +static bool sun4i_drv_node_is_supported_frontend(struct device_node *node)
> +{
> +   if (IS_ENABLED(CONFIG_DRM_SUN4I_BACKEND))
> +   return !!of_match_node(sun4i_frontend_of_table, node);
> +
> +   return false;
> +}
> +
>  static bool sun4i_drv_node_is_tcon(struct device_node *node)
>  {
> return of_device_is_compatible(node, "allwinner,sun4i-a10-tcon") ||
> @@ -239,9 +249,11 @@ static int sun4i_drv_add_endpoints(struct device *dev,
> int count = 0;
>
> /*
> -* We don't support the frontend for now, so we will never
> -* have a device bound. Just skip over it, but we still want
> -* the rest our pipeline to be added.
> +* The frontend has been disabled in some of our old device
> +* trees. If we find a node that is the frontend and is
> +* disabled, we should just follow through and parse its
> +* child, but without adding it to the component list.
> +* Otherwise, we obviously want to add it to the list.
>  */
> if (!sun4i_drv_node_is_frontend(node) &&
> !of_device_is_available(node))
> @@ -254,7 +266,14 @@ static int sun4i_drv_add_endpoints(struct device *dev,
> if (sun4i_drv_node_is_connector(node))
> return 0;
>
> -   if (!sun4i_drv_node_is_frontend(node)) {
> +   /*
> +* If the device is either just a regular device, or an
> +* enabled frontend supported by the driver, we add it to our
> +* component list.
> +*/
> +   if (!sun4i_drv_node_is_frontend(node) ||
> +   (sun4i_drv_node_is_supported_frontend(node) &&
> +of_device_is_available(node))) {

Nit: sun4i_drv_node_is_supported_frontend should be a subset of
sun4i_drv_node_is_frontend, so of_device_is_available should always
be true at this point.

> /* Add current component */
> DRM_DEBUG_DRIVER("Adding component %pOF\n", node);
> drm_of_component_match_add(dev, match, compare_of, node);
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.h 
> b/drivers/gpu/drm/sun4i/sun4i_drv.h
> index a960c89270cc..9c26a345f85c 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.h
> @@ -19,6 +19,7 @@
>
>  struct sun4i_drv 

[PATCH] drm/arcpgu: remove drm_encoder_slave

[Daniel Vetter]

drm_encoder_slave is the old way to write bridge drivers, for i2c
bridges only. It's deprecated, and definitely should not be used in
new drivers.

What's even strange is that arcpgu doesn't even use any of this, it
really only wants a plain normal drm_encoder. Nuke all the surplus
real estate.

Cc: Alexey Brodkin 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/arc/arcpgu_sim.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c b/drivers/gpu/drm/arc/arcpgu_sim.c
index bca3a678c955..d01f7743b63d 100644
--- a/drivers/gpu/drm/arc/arcpgu_sim.c
+++ b/drivers/gpu/drm/arc/arcpgu_sim.c
@@ -29,7 +29,6 @@
 
 struct arcpgu_drm_connector {
struct drm_connector connector;
-   struct drm_encoder_slave *encoder_slave;
 };
 
 static int arcpgu_drm_connector_get_modes(struct drm_connector *connector)
@@ -68,7 +67,7 @@ static struct drm_encoder_funcs arcpgu_drm_encoder_funcs = {
 int arcpgu_drm_sim_init(struct drm_device *drm, struct device_node *np)
 {
struct arcpgu_drm_connector *arcpgu_connector;
-   struct drm_encoder_slave *encoder;
+   struct drm_encoder *encoder;
struct drm_connector *connector;
int ret;
 
@@ -76,10 +75,10 @@ int arcpgu_drm_sim_init(struct drm_device *drm, struct 
device_node *np)
if (encoder == NULL)
return -ENOMEM;
 
-   encoder->base.possible_crtcs = 1;
-   encoder->base.possible_clones = 0;
+   encoder->possible_crtcs = 1;
+   encoder->possible_clones = 0;
 
-   ret = drm_encoder_init(drm, >base, _drm_encoder_funcs,
+   ret = drm_encoder_init(drm, encoder, _drm_encoder_funcs,
   DRM_MODE_ENCODER_VIRTUAL, NULL);
if (ret)
return ret;
@@ -101,15 +100,13 @@ int arcpgu_drm_sim_init(struct drm_device *drm, struct 
device_node *np)
goto error_encoder_cleanup;
}
 
-   ret = drm_mode_connector_attach_encoder(connector, >base);
+   ret = drm_mode_connector_attach_encoder(connector, encoder);
if (ret < 0) {
dev_err(drm->dev, "could not attach connector to encoder\n");
drm_connector_unregister(connector);
goto error_connector_cleanup;
}
 
-   arcpgu_connector->encoder_slave = encoder;
-
return 0;
 
 error_connector_cleanup:
-- 
2.15.1

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

Re: [PATCH] drm/arm/malidp: Disable pixel alpha blending for colors that do not have alpha

[Liviu Dudau]

Hi Ayan,

On Fri, Jan 12, 2018 at 04:33:07PM +, Ayan Halder wrote:
> Mali dp needs to disable pixel alpha blending (use layer alpha blending) to
> display color formats that do not contain alpha bits per pixel

In the future, please mention any dependencies on other patches that are
not part of a series. In this case one needs your other patch, "drm: add
drm_format_alpha_bits".

Anyway, looks good to me.

Signed-off-by: Liviu Dudau 

Many thanks,
Liviu

> 
> Signed-off-by: Ayan Kumar Halder 
> ---
>  drivers/gpu/drm/arm/malidp_planes.c | 27 ++-
>  1 file changed, 22 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
> b/drivers/gpu/drm/arm/malidp_planes.c
> index e741979..4d7d564 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -35,6 +35,9 @@
>  #define   LAYER_COMP_MASK(0x3 << 12)
>  #define   LAYER_COMP_PIXEL   (0x3 << 12)
>  #define   LAYER_COMP_PLANE   (0x2 << 12)
> +#define   LAYER_ALPHA_OFFSET (16)
> +#define   LAYER_ALPHA_MASK   (0xff)
> +#defineLAYER_ALPHA(x)(((x) & LAYER_ALPHA_MASK) << 
> LAYER_ALPHA_OFFSET)
>  #define MALIDP_LAYER_COMPOSE 0x008
>  #define MALIDP_LAYER_SIZE0x00c
>  #define   LAYER_H_VAL(x) (((x) & 0x1fff) << 0)
> @@ -268,6 +271,7 @@ static void malidp_de_plane_update(struct drm_plane 
> *plane,
>   struct malidp_plane_state *ms = to_malidp_plane_state(plane->state);
>   u32 src_w, src_h, dest_w, dest_h, val;
>   int i;
> + u8 alpha_bits = plane->state->fb->format->alpha;
>  
>   mp = to_malidp_plane(plane);
>  
> @@ -319,12 +323,25 @@ static void malidp_de_plane_update(struct drm_plane 
> *plane,
>   if (plane->state->rotation & DRM_MODE_REFLECT_Y)
>   val |= LAYER_V_FLIP;
>  
> - /*
> -  * always enable pixel alpha blending until we have a way to change
> -  * blend modes
> -  */
>   val &= ~LAYER_COMP_MASK;
> - val |= LAYER_COMP_PIXEL;
> + if (alpha_bits > 0) {
> +
> + /*
> +  * always enable pixel alpha blending until we have a way to 
> change
> +  * blend modes
> +  */
> + val |= LAYER_COMP_PIXEL;
> + } else {
> +
> + /*
> +  * do not enable pixel alpha blending as the color channel does 
> not
> +  * have any alpha information
> +  */
> + val |= LAYER_COMP_PLANE;
> +
> + /* Set layer alpha coefficient to 0xff ie fully opaque */
> + val |= LAYER_ALPHA(0xff);
> + }
>  
>   val &= ~LAYER_FLOWCFG(LAYER_FLOWCFG_MASK);
>   if (plane->state->crtc) {
> -- 
> 2.7.4
> 

-- 

| 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] drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

[Maarten Lankhorst]

From: "Leo (Sunpeng) Li" 

During a non-blocking commit, it is possible to return before the
commit_tail work is queued (-ERESTARTSYS, for example).

Since a reference on the crtc commit object is obtained for the pending
vblank event when preparing the commit, the above situation will leave
us with an extra reference.

Therefore, if the commit_tail worker has not consumed the event at the
end of a commit, release it's reference.

Changes since v1:
- Also check for state->event->base.completion being set, to
  handle the case where stall_checks() fails in setup_crtc_commit().
Changes since v2:
- Add a flag to drm_crtc_commit, to prevent dereferencing a freed event.
  i915 may unreference the state in a worker.

Fixes: 24835e442f28 ("drm: reference count event->completion")
Cc:  # v4.11+
Signed-off-by: Leo (Sunpeng) Li 
Acked-by: Harry Wentland  #v1
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic_helper.c | 15 +++
 include/drm/drm_atomic.h|  9 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index ab4032167094..ae3cbfe9e01c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1878,6 +1878,8 @@ int drm_atomic_helper_setup_commit(struct 
drm_atomic_state *state,
new_crtc_state->event->base.completion = >flip_done;
new_crtc_state->event->base.completion_release = 
release_crtc_commit;
drm_crtc_commit_get(commit);
+
+   commit->abort_completion = true;
}
 
for_each_oldnew_connector_in_state(state, conn, old_conn_state, 
new_conn_state, i) {
@@ -3421,8 +3423,21 @@ EXPORT_SYMBOL(drm_atomic_helper_crtc_duplicate_state);
 void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc_state *state)
 {
if (state->commit) {
+   /*
+* In the event that a non-blocking commit returns
+* -ERESTARTSYS before the commit_tail work is queued, we will
+* have an extra reference to the commit object. Release it, if
+* the event has not been consumed by the worker.
+*
+* state->event may be freed, so we can't directly look at
+* state->event->base.completion.
+*/
+   if (state->event && state->commit->abort_completion)
+   drm_crtc_commit_put(state->commit);
+
kfree(state->commit->event);
state->commit->event = NULL;
+
drm_crtc_commit_put(state->commit);
}
 
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 1c27526c499e..cf13842a6dbd 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -134,6 +134,15 @@ struct drm_crtc_commit {
 * _pending_vblank_event pointer to clean up private events.
 */
struct drm_pending_vblank_event *event;
+
+   /**
+* @abort_completion:
+*
+* A flag that's set after drm_atomic_helper_setup_commit takes a second
+* reference for the completion of $drm_crtc_state.event. It's used by
+* the free code to remove the second reference if commit fails.
+*/
+   bool abort_completion;
 };
 
 struct __drm_planes_state {
-- 
2.15.1

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

[Bug 104655] AMD R9 Fury + BenQ XL2546: Setting 240 Hz results in screen distortion

[bugzilla-daemon]

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

--- Comment #4 from omin...@autistici.org ---
Created attachment 136806
  --> https://bugs.freedesktop.org/attachment.cgi?id=136806=edit
dmesg

-- 
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 104655] AMD R9 Fury + BenQ XL2546: Setting 240 Hz results in screen distortion

[bugzilla-daemon]

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

Nicolai Hähnle  changed:

   What|Removed |Added

 QA Contact|mesa-dev@lists.freedesktop. |
   |org |
  Component|Other   |DRM/AMDgpu
Product|Mesa|DRI
   Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
   |org |.org

--- Comment #3 from Nicolai Hähnle  ---
This is probably a display driver bug, not a Mesa bug.

Please provide your kernel version and dmesg output.

-- 
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: [Intel-gfx] IGT news - New mailing list, switching to meson

[Daniel Vetter]

Cc'ing dri-devel.
-Daniel

On Mon, Jan 15, 2018 at 04:06:01PM +0200, Petri Latvala wrote:
> 
> New mailing list
> 
> 
> 
> IGT now has its own mailing list. For a transition period, patches on
> both the new mailing list and intel-gfx (with the appropriate patch
> subjectprefix) get tested on their own respective Patchwork
> instances. Patches that are sent to both lists will get deduplicated
> so they only appear in one Patchwork instance, so feel free to send
> patches to both lists if you have a need to do so.
> 
> As IGT is no longer just an Intel-specific framework, the new mailing
> list is one step towards reducing false associations.
> 
> Current subscribers to intel-gfx are not automatically subscribed to
> the new mailing list. Please subscribe on the below list page
> yourself.
> 
> 
> 
> Mailing list information:
> 
> Subscribe page, archives, etc:
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
> 
> Header field for mail filtering:
> List-Id: Development mailing list for IGT GPU Tools 
> 
> 
> Subject prefix:
> [igt-dev]
> 
> Patchwork url:
> https://patchwork.freedesktop.org/project/igt/series/
> 
> 
> 
> CI to use meson for building
> 
> 
> 
> In the near future, CI will build IGT with Meson instead of
> Autotools. Meson is now the main supported build system, with
> Autotools still kept around and maintained on a best-effort basis
> until stated otherwise.
> 
> This will mean that if your patch doesn't build with Meson, it doesn't
> get tested. If you're still using Autotools for your development,
> now is a good time to switch. For getting started, refer to the README
> file, section "Meson build system support".
> 
> 
> 
> -- 
> Petri Latvala
> ___
> 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

[PATCH 7/7] dt-bindings: display: msm/dsi: Add updates for SDM845

[Archit Taneja]

SDM845 uses a newer revision (v2.0+) of the 6G DSI controller. This
revision has another clock input at the block boundary called the byte
interface clock. Specify this new clock in the binding.

A 10nm DSI PHY is used along with the controller. Add a compatible
string for it and specify its base address/regulator supply needs.

Cc: Rob Herring 
Cc: devicet...@vger.kernel.org
Signed-off-by: Archit Taneja 
---
 Documentation/devicetree/bindings/display/msm/dsi.txt | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt 
b/Documentation/devicetree/bindings/display/msm/dsi.txt
index 26a1796b7145..518e9cdf0d4b 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -20,6 +20,8 @@ Required properties:
   * "core"
   For DSIv2, we need an additional clock:
* "src"
+  For DSI6G v2.0 onwards, we need also need the clock:
+   * "byte_intf"
 - assigned-clocks: Parents of "byte" and "pixel" for the given platform.
 - assigned-clock-parents: The Byte clock and Pixel clock PLL outputs provided
   by a DSI PHY block. See [1] for details on clock bindings.
@@ -87,6 +89,7 @@ Required properties:
   * "qcom,dsi-phy-20nm"
   * "qcom,dsi-phy-28nm-8960"
   * "qcom,dsi-phy-14nm"
+  * "qcom,dsi-phy-10nm"
 - reg: Physical base address and length of the registers of PLL, PHY. Some
   revisions require the PHY regulator base address, whereas others require the
   PHY lane base address. See below for each PHY revision.
@@ -95,7 +98,7 @@ Required properties:
   * "dsi_pll"
   * "dsi_phy"
   * "dsi_phy_regulator"
-  For DSI 14nm PHY:
+  For DSI 14nm and 10nm PHYs:
   * "dsi_pll"
   * "dsi_phy"
   * "dsi_phy_lane"
@@ -112,6 +115,8 @@ Required properties:
 - vcca-supply: phandle to vcca regulator device node
   For 14nm PHY:
 - vcca-supply: phandle to vcca regulator device node
+  For 10nm PHY:
+- vdds-supply: phandle to vdds regulator device node
 
 Optional properties:
 - qcom,dsi-phy-regulator-ldo-mode: Boolean value indicating if the LDO mode PHY
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

[PATCH 3/7] drm/msm/dsi: Add byte_intf_clk

[Archit Taneja]

DSI6G v2.0+ blocks have a new clock input to them called
byte_intf_clk. It's rate is to be set as byte_clk / 2.

Within the clock controller (CC) subsystem, this clock is a
child/descendant of the byte_clk.

Set it up as an optional clock in the DSI host driver. Make sure
that we enable/set its rate only after we configure byte_clk.
This is required for the ancestor clocks in the CC to be
configured correctly.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 7611fe014036..f675975c2655 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -115,6 +115,7 @@ struct msm_dsi_host {
struct clk *pixel_clk;
struct clk *byte_clk_src;
struct clk *pixel_clk_src;
+   struct clk *byte_intf_clk;
 
u32 byte_clk_rate;
u32 esc_clk_rate;
@@ -377,6 +378,14 @@ static int dsi_clk_init(struct msm_dsi_host *msm_host)
goto exit;
}
 
+   msm_host->byte_intf_clk = msm_clk_get(pdev, "byte_intf");
+   if (IS_ERR(msm_host->byte_intf_clk)) {
+   ret = PTR_ERR(msm_host->byte_intf_clk);
+   pr_debug("%s: can't find byte_intf clock. ret=%d\n",
+__func__, ret);
+   msm_host->byte_intf_clk = NULL;
+   }
+
msm_host->byte_clk_src = clk_get_parent(msm_host->byte_clk);
if (!msm_host->byte_clk_src) {
ret = -ENODEV;
@@ -502,6 +511,16 @@ static int dsi_link_clk_enable_6g(struct msm_dsi_host 
*msm_host)
goto error;
}
 
+   if (msm_host->byte_intf_clk) {
+   ret = clk_set_rate(msm_host->byte_intf_clk,
+  msm_host->byte_clk_rate / 2);
+   if (ret) {
+   pr_err("%s: Failed to set rate byte intf clk, %d\n",
+  __func__, ret);
+   goto error;
+   }
+   }
+
ret = clk_prepare_enable(msm_host->esc_clk);
if (ret) {
pr_err("%s: Failed to enable dsi esc clk\n", __func__);
@@ -520,8 +539,19 @@ static int dsi_link_clk_enable_6g(struct msm_dsi_host 
*msm_host)
goto pixel_clk_err;
}
 
+   if (msm_host->byte_intf_clk) {
+   ret = clk_prepare_enable(msm_host->byte_intf_clk);
+   if (ret) {
+   pr_err("%s: Failed to enable byte intf clk\n",
+  __func__);
+   goto byte_intf_clk_err;
+   }
+   }
+
return 0;
 
+byte_intf_clk_err:
+   clk_disable_unprepare(msm_host->pixel_clk);
 pixel_clk_err:
clk_disable_unprepare(msm_host->byte_clk);
 byte_clk_err:
@@ -615,6 +645,8 @@ static void dsi_link_clk_disable(struct msm_dsi_host 
*msm_host)
if (cfg_hnd->major == MSM_DSI_VER_MAJOR_6G) {
clk_disable_unprepare(msm_host->esc_clk);
clk_disable_unprepare(msm_host->pixel_clk);
+   if (msm_host->byte_intf_clk)
+   clk_disable_unprepare(msm_host->byte_intf_clk);
clk_disable_unprepare(msm_host->byte_clk);
} else {
clk_disable_unprepare(msm_host->pixel_clk);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

[PATCH 4/7] dt-bindings: display: msm/dsi: Remove unused properties

[Archit Taneja]

"qcom,dsi-host-index" and "qcom,dsi-phy-index" DT props aren't
acceptable and have never been used in any DT files. Remove them.

Cc: Rob Herring 
Cc: devicet...@vger.kernel.org
Signed-off-by: Archit Taneja 
---
 Documentation/devicetree/bindings/display/msm/dsi.txt | 4 
 1 file changed, 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt 
b/Documentation/devicetree/bindings/display/msm/dsi.txt
index a6671bd2c85a..457c688736be 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -7,8 +7,6 @@ Required properties:
 - reg: Physical base address and length of the registers of controller
 - reg-names: The names of register regions. The following regions are required:
   * "dsi_ctrl"
-- qcom,dsi-host-index: The ID of DSI controller hardware instance. This should
-  be 0 or 1, since we have 2 DSI controllers at most for now.
 - interrupts: The interrupt signal from the DSI block.
 - power-domains: Should be < MDSS_GDSC>.
 - clocks: Phandles to device clocks.
@@ -96,8 +94,6 @@ Required properties:
   * "dsi_phy_regulator"
 - clock-cells: Must be 1. The DSI PHY block acts as a clock provider, creating
   2 clocks: A byte clock (index 0), and a pixel clock (index 1).
-- qcom,dsi-phy-index: The ID of DSI PHY hardware instance. This should
-  be 0 or 1, since we have 2 DSI PHYs at most for now.
 - power-domains: Should be < MDSS_GDSC>.
 - clocks: Phandles to device clocks. See [1] for details on clock bindings.
 - clock-names: the following clocks are required:
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

[PATCH 6/7] dt-bindings: display: msm/dsi: Add compatible for 14nm DSI PHY

[Archit Taneja]

Add the compatible string for 14nm DSI PHY (used in MSM8996/APQ8096).
From 14nm PHY onwards, the "dsi_phy_regulator" reg-name is not required,
but "dsi_phy_lane" reg-name is. Update the doc to specify the reg-names
each PHY revision needs.

Cc: Rob Herring 
Cc: devicet...@vger.kernel.org
Signed-off-by: Archit Taneja 
---
 Documentation/devicetree/bindings/display/msm/dsi.txt | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt 
b/Documentation/devicetree/bindings/display/msm/dsi.txt
index 9c3ad6bbb9f0..26a1796b7145 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -86,12 +86,19 @@ Required properties:
   * "qcom,dsi-phy-28nm-lp"
   * "qcom,dsi-phy-20nm"
   * "qcom,dsi-phy-28nm-8960"
-- reg: Physical base address and length of the registers of PLL, PHY and PHY
-  regulator
+  * "qcom,dsi-phy-14nm"
+- reg: Physical base address and length of the registers of PLL, PHY. Some
+  revisions require the PHY regulator base address, whereas others require the
+  PHY lane base address. See below for each PHY revision.
 - reg-names: The names of register regions. The following regions are required:
+  For DSI 28nm HPM/LP/8960 PHYs and 20nm PHY:
   * "dsi_pll"
   * "dsi_phy"
   * "dsi_phy_regulator"
+  For DSI 14nm PHY:
+  * "dsi_pll"
+  * "dsi_phy"
+  * "dsi_phy_lane"
 - clock-cells: Must be 1. The DSI PHY block acts as a clock provider, creating
   2 clocks: A byte clock (index 0), and a pixel clock (index 1).
 - power-domains: Should be < MDSS_GDSC>.
@@ -102,6 +109,8 @@ Required properties:
 - vddio-supply: phandle to vdd-io regulator device node
   For 20nm PHY:
 - vddio-supply: phandle to vdd-io regulator device node
+- vcca-supply: phandle to vcca regulator device node
+  For 14nm PHY:
 - vcca-supply: phandle to vcca regulator device node
 
 Optional properties:
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

[PATCH 5/7] dt-bindings: display: msm/dsi: Fix the PHY regulator supply props

[Archit Taneja]

The PHY regulator supply names vary across different PHY versions.
Mention explicitly which PHYs require which supplies.

Cc: Rob Herring 
Cc: devicet...@vger.kernel.org
Signed-off-by: Archit Taneja 
---
 Documentation/devicetree/bindings/display/msm/dsi.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt 
b/Documentation/devicetree/bindings/display/msm/dsi.txt
index 457c688736be..9c3ad6bbb9f0 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -98,7 +98,11 @@ Required properties:
 - clocks: Phandles to device clocks. See [1] for details on clock bindings.
 - clock-names: the following clocks are required:
   * "iface"
+  For 28nm HPM/LP, 28nm 8960 PHYs:
 - vddio-supply: phandle to vdd-io regulator device node
+  For 20nm PHY:
+- vddio-supply: phandle to vdd-io regulator device node
+- vcca-supply: phandle to vcca regulator device node
 
 Optional properties:
 - qcom,dsi-phy-regulator-ldo-mode: Boolean value indicating if the LDO mode PHY
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

[PATCH 1/7] drm/msm/dsi: Use msm_clk_get in dsi_get_config

[Archit Taneja]

We try to get the interface clock in dsi_get_config early during DSI's
component bind. Try getting both the "iface" and "iface_clk" clock name
variants so that we are compatible with both new and legacy DT.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 0f7324a686ca..7611fe014036 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -214,7 +214,7 @@ static const struct msm_dsi_cfg_handler *dsi_get_config(
goto exit;
}
 
-   ahb_clk = clk_get(dev, "iface_clk");
+   ahb_clk = msm_clk_get(msm_host->pdev, "iface");
if (IS_ERR(ahb_clk)) {
pr_err("%s: cannot get interface clock\n", __func__);
goto put_gdsc;
@@ -225,7 +225,7 @@ static const struct msm_dsi_cfg_handler *dsi_get_config(
ret = regulator_enable(gdsc_reg);
if (ret) {
pr_err("%s: unable to enable gdsc\n", __func__);
-   goto put_clk;
+   goto put_gdsc;
}
 
ret = clk_prepare_enable(ahb_clk);
@@ -249,8 +249,6 @@ static const struct msm_dsi_cfg_handler *dsi_get_config(
 disable_gdsc:
regulator_disable(gdsc_reg);
pm_runtime_put_sync(dev);
-put_clk:
-   clk_put(ahb_clk);
 put_gdsc:
regulator_put(gdsc_reg);
 exit:
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

[PATCH 0/7] drm/msm/dsi: SDM845 DSI host controller and DT updates

[Archit Taneja]

This series adds some of the host controller changes needed for SDM845.\
The DT patches in the series do some minor clean ups and add missing
bindings for 14nm DSI PHY (8x96) and new bindings for 10nm PHY.

Archit Taneja (7):
  drm/msm/dsi: Use msm_clk_get in dsi_get_config
  drm/msm/dsi: Add SDM845 in dsi_cfg
  drm/msm/dsi: Add byte_intf_clk
  dt-bindings: display: msm/dsi: Remove unused properties
  dt-bindings: display: msm/dsi: Fix the PHY regulator supply props
  dt-bindings: display: msm/dsi: Add compatible for 14nm DSI PHY
  dt-bindings: display: msm/dsi: Add updates for SDM845

 .../devicetree/bindings/display/msm/dsi.txt| 26 +++
 drivers/gpu/drm/msm/dsi/dsi_cfg.c  | 19 +++
 drivers/gpu/drm/msm/dsi/dsi_cfg.h  |  1 +
 drivers/gpu/drm/msm/dsi/dsi_host.c | 38 +++---
 4 files changed, 74 insertions(+), 10 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

[PATCH 2/7] drm/msm/dsi: Add SDM845 in dsi_cfg

[Archit Taneja]

SDM845 contains 2 DSI6G v2.2.1 host controllers. Add them in dsi_cfg.

Cc: Jordan Crouse 
Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/dsi/dsi_cfg.c | 19 +++
 drivers/gpu/drm/msm/dsi/dsi_cfg.h |  1 +
 2 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 65c1dfbbe019..0327bb54b01b 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -118,6 +118,24 @@ static const struct msm_dsi_config msm8996_dsi_cfg = {
.num_dsi = 2,
 };
 
+static const char * const dsi_sdm845_bus_clk_names[] = {
+   "iface", "bus",
+};
+
+static const struct msm_dsi_config sdm845_dsi_cfg = {
+   .io_offset = DSI_6G_REG_SHIFT,
+   .reg_cfg = {
+   .num = 1,
+   .regs = {
+   {"vdda", 21800, 4 },/* 1.2 V */
+   },
+   },
+   .bus_clk_names = dsi_sdm845_bus_clk_names,
+   .num_bus_clks = ARRAY_SIZE(dsi_sdm845_bus_clk_names),
+   .io_start = { 0xae94000, 0xae96000 },
+   .num_dsi = 2,
+};
+
 static const struct msm_dsi_cfg_handler dsi_cfg_handlers[] = {
{MSM_DSI_VER_MAJOR_V2, MSM_DSI_V2_VER_MINOR_8064, _dsi_cfg},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_0,
@@ -131,6 +149,7 @@ static const struct msm_dsi_cfg_handler dsi_cfg_handlers[] 
= {
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3, _dsi_cfg},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3_1, _dsi_cfg},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_4_1, _dsi_cfg},
+   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_2_1, _dsi_cfg},
 };
 
 const struct msm_dsi_cfg_handler *msm_dsi_cfg_get(u32 major, u32 minor)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.h 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
index 00a5da2663c6..9cfdcf1c95d5 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
@@ -25,6 +25,7 @@
 #define MSM_DSI_6G_VER_MINOR_V1_3  0x1003
 #define MSM_DSI_6G_VER_MINOR_V1_3_10x10030001
 #define MSM_DSI_6G_VER_MINOR_V1_4_10x10040001
+#define MSM_DSI_6G_VER_MINOR_V2_2_10x20020001
 
 #define MSM_DSI_V2_VER_MINOR_8064  0x0
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

Re: [PATCH] drm/ttm: add VADDR_FLAG_UPDATED_COUNT to correctly update dma_page global count

[Christian König]

Am 17.01.2018 um 09:59 schrieb Roger He:

add this for correctly updating global mem count in ttm_mem_zone.
before that when ttm_mem_global_alloc_page fails, we would update all
dma_page's global mem count in ttm_dma->pages_list. but actually here
we should not update for the last dma_page.

v2: only the update of last dma_page is not right
v3: use lower bits of dma_page vaddr

Signed-off-by: Roger He 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 55 +---
  1 file changed, 29 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index c7f01a4..a880515 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -61,6 +61,7 @@
  #define SMALL_ALLOCATION  4
  #define FREE_ALL_PAGES(~0U)
  #define VADDR_FLAG_HUGE_POOL  1UL
+#define VADDR_FLAG_UPDATED_COUNT   2UL
  
  enum pool_type {

IS_UNDEFINED= 0,
@@ -874,18 +875,18 @@ static int ttm_dma_page_pool_fill_locked(struct dma_pool 
*pool,
  }
  
  /*

- * @return count of pages still required to fulfill the request.
   * The populate list is actually a stack (not that is matters as TTM
   * allocates one page at a time.
+ * return dma_page pointer if success, otherwise NULL.
   */
-static int ttm_dma_pool_get_pages(struct dma_pool *pool,
+static struct dma_page *ttm_dma_pool_get_pages(struct dma_pool *pool,
  struct ttm_dma_tt *ttm_dma,
  unsigned index)
  {
-   struct dma_page *d_page;
+   struct dma_page *d_page = NULL;
struct ttm_tt *ttm = _dma->ttm;
unsigned long irq_flags;
-   int count, r = -ENOMEM;
+   int count;
  
  	spin_lock_irqsave(>lock, irq_flags);

count = ttm_dma_page_pool_fill_locked(pool, _flags);
@@ -894,12 +895,11 @@ static int ttm_dma_pool_get_pages(struct dma_pool *pool,
ttm->pages[index] = d_page->p;
ttm_dma->dma_address[index] = d_page->dma;
list_move_tail(_page->page_list, _dma->pages_list);
-   r = 0;
pool->npages_in_use += 1;
pool->npages_free -= 1;
}
spin_unlock_irqrestore(>lock, irq_flags);
-   return r;
+   return d_page;
  }
  
  static gfp_t ttm_dma_pool_gfp_flags(struct ttm_dma_tt *ttm_dma, bool huge)

@@ -934,6 +934,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
struct ttm_mem_global *mem_glob = ttm->glob->mem_glob;
unsigned long num_pages = ttm->num_pages;
struct dma_pool *pool;
+   struct dma_page *d_page;
enum pool_type type;
unsigned i;
int ret;
@@ -962,8 +963,8 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
while (num_pages >= HPAGE_PMD_NR) {
unsigned j;
  
-		ret = ttm_dma_pool_get_pages(pool, ttm_dma, i);

-   if (ret != 0)
+   d_page = ttm_dma_pool_get_pages(pool, ttm_dma, i);
+   if (!d_page)
break;
  
  		ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],

@@ -973,6 +974,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
return -ENOMEM;
}
  
+		d_page->vaddr |= VADDR_FLAG_UPDATED_COUNT;

for (j = i + 1; j < (i + HPAGE_PMD_NR); ++j) {
ttm->pages[j] = ttm->pages[j - 1] + 1;
ttm_dma->dma_address[j] = ttm_dma->dma_address[j - 1] +
@@ -996,8 +998,8 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
}
  
  	while (num_pages) {

-   ret = ttm_dma_pool_get_pages(pool, ttm_dma, i);
-   if (ret != 0) {
+   d_page = ttm_dma_pool_get_pages(pool, ttm_dma, i);
+   if (!d_page) {
ttm_dma_unpopulate(ttm_dma, dev);
return -ENOMEM;
}
@@ -1009,6 +1011,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
return -ENOMEM;
}
  
+		d_page->vaddr |= VADDR_FLAG_UPDATED_COUNT;

++i;
--num_pages;
}
@@ -1049,8 +1052,11 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, 
struct device *dev)
continue;
  
  			count++;

-   ttm_mem_global_free_page(ttm->glob->mem_glob,
-d_page->p, pool->size);
+   if (d_page->vaddr & VADDR_FLAG_UPDATED_COUNT) {
+   ttm_mem_global_free_page(ttm->glob->mem_glob,
+d_page->p, pool->size);
+   d_page->vaddr &= 

Re: [PATCH libdrm] drm: fix return value

[Daniel Vetter]

On Wed, Jan 17, 2018 at 05:26:41PM +0800, Chunming Zhou wrote:
> 
> 
> On 2018年01月17日 17:24, Christian König wrote:
> > Am 17.01.2018 um 09:53 schrieb Chunming Zhou:
> > > 
> > > 
> > > On 2018年01月17日 16:21, Daniel Vetter wrote:
> > > > On Tue, Jan 16, 2018 at 02:01:40PM +, Zhou, David(ChunMing) wrote:
> > > > > Can your guys help me push it and last vamgr patches to upstream?
> > > > > My new count request for libdrm still is under pending.
> > > > Or hand out commmit rights? That's easier long-term imo ...
> > > That's not true, we need to track the commit for driver release, if
> > > we have no permission to push it, we often need to check the patch
> > > status to see if it's already in there.
> > > Are you admin for count request? if you are, and approve my count
> > > request, I greatly appreciate your approval.
> > 
> > David, sounds like a misunderstanding. What Daniel suggested was that
> > you should get commit rights, so that you can commit it yourself :)
> > 
> > But that's actually what we are already trying to do. It's just that the
> > account request seems to take a while.
> > 
> > If Alex hasn't already forwarded the request to the Admins please post
> > the link once more and I or Daniel can take care of it.
> https://bugs.freedesktop.org/show_bug.cgi?id=104631
> Michel and Alex have committed.

fd.o admins are drowning a bit under meltdown/spectre (and there's
apparently a pile more serious exploits that need to be patched asap).

I'd ping them next week on #freedesktop if it hasn't happened by then.
-Daniel

> 
> Thanks,
> David Zhou
> > 
> > Regards,
> > Christian.
> > 
> > > 
> > > Regards,
> > > David Zhou
> > > > -Daniel
> > > > 
> > > > > Thanks,
> > > > > David Zhou
> > > > > 
> > > > > 
> > > > > 发自坚果 Pro
> > > > > 
> > > > > Christian K鰊ig  于
> > > > > 2018年1月16日 下午4:56写道：
> > > > > 
> > > > > Apart from that a good catch and Reviewed-by: Christian König
> > > > > .
> > > > > 
> > > > > Regards,
> > > > > Christian.
> > > > > 
> > > > > Am 16.01.2018 um 09:49 schrieb Michel Dänzer:
> > > > > > Moving from the amd-gfx list to dri-devel, since this
> > > > > > isn't amdgpu specific.
> > > > > > 
> > > > > > 
> > > > > > On 2018-01-16 03:54 AM, Chunming Zhou wrote:
> > > > > > > otherwise -ETIME is missed.
> > > > > > > 
> > > > > > > Change-Id: Ic5580a74d8027cc468c6135f8cf2f81817993423
> > > > > > > Signed-off-by: Chunming Zhou 
> > > > > > > ---
> > > > > > >    xf86drm.c | 2 +-
> > > > > > >    1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > 
> > > > > > > diff --git a/xf86drm.c b/xf86drm.c
> > > > > > > index 8a327170..3881bd9f 100644
> > > > > > > --- a/xf86drm.c
> > > > > > > +++ b/xf86drm.c
> > > > > > > @@ -4241,7 +4241,7 @@ int drmSyncobjWait(int fd,
> > > > > > > uint32_t *handles, unsigned num_handles,
> > > > > > > 
> > > > > > >    ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_WAIT, );
> > > > > > >    if (ret < 0)
> > > > > > > -    return ret;
> > > > > > > +    return -errno;
> > > > > > > 
> > > > > > >    if (first_signaled)
> > > > > > >    *first_signaled = args.first_signaled;
> > > > > > > 
> > > > > ___
> > > > > 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
> > 
> 

-- 
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 06/19] drm/blend: Add a generic alpha property

[Daniel Vetter]

On Wed, Jan 17, 2018 at 10:20:24AM +0100, Maxime Ripard wrote:
> On Thu, Jan 11, 2018 at 08:34:58PM +0200, Laurent Pinchart wrote:
> > Hi Daniel,
> > 
> > On Thursday, 11 January 2018 18:36:10 EET Daniel Vetter wrote:
> > > On Thu, Jan 11, 2018 at 4:58 PM, Maxime Ripard wrote:
> > > > On Tue, Jan 09, 2018 at 03:28:34PM +0100, Daniel Vetter wrote:
> > > >> On Tue, Jan 09, 2018 at 02:53:22PM +0100, Maxime Ripard wrote:
> > > >>> On Tue, Jan 09, 2018 at 01:32:41PM +0100, Daniel Vetter wrote:
> > >  On Tue, Jan 09, 2018 at 11:56:25AM +0100, Maxime Ripard wrote:
> > > > Some drivers duplicate the logic to create a property to store a
> > > > per-plane alpha.
> > > > 
> > > > Let's create a helper in order to move that to the core.
> > > > 
> > > > Cc: Boris Brezillon 
> > > > Cc: Laurent Pinchart 
> > > > Signed-off-by: Maxime Ripard 
> > >  
> > >  Do we have userspace for this?
> > > >>> 
> > > >>> Wayland seems to be on its way to implement this, with ChromeOS using
> > > >>> it:
> > > >>> https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741
> > > >>> .html
> > > >>> 
> > > >>> and more specifically:
> > > >>> https://chromium.googlesource.com/chromium/src/+/master/third_party/way
> > > >>> land-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1
> > > >>> .xml#118
> > > >> 
> > > >> Yay, would be good to include these links in the patch description.
> > > >> Really happy we're having a real standard now used by multiple people.
> > > > 
> > > > I will.
> > > > 
> > > >> > > Is encoding a fixed 0-255 range really the best idea?
> > > >> > 
> > > >> > I don't really know, is there hardware or formats where there is more
> > > >> > than 255? Or did you mean less than that?
> > > >> 
> > > >> 30bit I'd assume wants more alpha. In the past we've done some
> > > >> fixed-point stuff (e.g. for LUT), using the 0.0-1.0 float range. Using
> > > >> that for the blend equation docs is also what I recommend (and that we
> > > >> map from 0-255 to 0.0-1.0 logically). Ofc the hw might not do any of 
> > > >> that
> > > >> ... I think 0.16 fixed point, stored in a u16 is probably best. That's
> > > >> what we're doing for gamma tables already, and that way drivers can
> > > >> simply throw away the lower bits.
> > > > 
> > > > But that would also break the two users of that property that won't be
> > > > able to move to the generic property (with the same name) without
> > > > breaking userspace. The point of that patch was to allow some code
> > > > consolidation, and that would mean failing to do so here :/
> > > 
> > > Let me try to clarify:
> > > - We'll keep the exact existing property semantics with the 0-255
> > > range for the userspace visible property.
> > > 
> > > - But internally, in the decode value that we store into
> > > drm_plane_state, we'll do the slightly more future proof thing with a
> > > few more bits.
> > > 
> > > That gives us the option of exposing those bits in the future without
> > > having to change all the drivers again (which we have to do for this
> > > series here already anyway, since the decoded value moves into
> > > drm_plane_state from driver subclasses).
> > > 
> > > Definitely not asking to break userspace here :-)
> > 
> > As the property range is available to userspace, we could allow drivers to 
> > expose a driver-dependent number of bits for the alpha value without 
> > breaking 
> > anything. We can even require new drivers to expose 16 bits regardless of 
> > the 
> > number of bits that the hardware can handle, or we could keep that driver-
> > specific.
> > 
> > Please note, however, that U0.16 can only represent [0.0, 0.84741...] 
> > while we need [0.0, 1.0]. As all the hardware I know map the full range of 
> > values ([0, 255] for 8-bit for instance) to [0.0, 1.0] I wouldn't pretend 
> > that 
> > the 16-bit value exposed to userspace is U0.16.
> 
> So this would involve not changing too much the current patch, but
> instead extending the type from an u8 to an u16. Would that work for
> you Daniel?

Yeah, Laurent's clarification is what I've meant ... And hopefully it's
enough future-proofing that we don't need to redo this all again.
-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: [Nouveau] [PATCH] drm/nouveau/bar/gk20a: Avoid bar teardown during init

[Guillaume Tucker]

On 10/01/18 12:20, Thierry Reding wrote:

On Thu, Jan 04, 2018 at 11:29:09AM +, Jon Hunter wrote:

Commit bbb163e18960 ("drm/nouveau/bar: implement bar1 teardown")
introduced add a teardown helper function for BAR1. During
initialisation of the Nouveau, initially all the teardown helpers are
called once, before calling their init counterparts. For gk20a, after
the BAR1 teardown function is called, the device is hanging during the
initialisation of the FB sub-device. At this point it is unclear why
this is happening and this is still under investigation. However, this
change is preventing Tegra124 devices from booting when Nouveau is
enabled. To allow Tegra124 to boot, remove the teardown helper for
gk20a.

This is based upon a previous patch by Guillaume Tucker but limits
the workaround to only gk20a GPUs.

Fixes: bbb163e18960 ("drm/nouveau/bar: implement bar1 teardown")
Reported-by: Guillaume Tucker 
Signed-off-by: Jon Hunter 
---
I am not happy that we do not yet fully understand the cause of
the hang, but I am talking with a few people at NVIDIA about this
and have a few things to look into. However, given that we are
close to v4.15 being released and I am not sure we will have a
proper fix in place before, I think it is best to workaround
this for now.

  drivers/gpu/drm/nouveau/nvkm/subdev/bar/base.c  | 3 ++-
  drivers/gpu/drm/nouveau/nvkm/subdev/bar/gk20a.c | 1 -
  2 files changed, 2 insertions(+), 2 deletions(-)


Acked-by: Thierry Reding 


Tested-by: Guillaume Tucker 

  https://lava.collabora.co.uk/scheduler/job/1047172

Thanks for this workaround.  Looking forward to having this
platform back on track in mainline.  I'm happy to run this boot
test again with a proper fix in future patches, let me know if I
can be of any help.

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

[PULL] drm-misc-fixes

[Daniel Vetter]

Hi Dave,

drm-misc-fixes-2018-01-17:
Final 4.15 drm-misc pull:

Just 3 sun4i patches to fix clock computation/checks.

Cheers, Daniel

The following changes since commit b0bb222440a5c8273f67dd37946707e6ba6ad832:

  Merge branch 'linux-4.15' of git://github.com/skeggsb/linux into drm-fixes 
(2018-01-09 12:03:10 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-01-17

for you to fetch changes up to 3b9c57cef4de80f29885e1edf69828de8d3fae6b:

  drm/sun4i: hdmi: Add missing rate halving check in sun4i_tmds_determine_rate 
(2018-01-11 13:25:43 +0100)


Final 4.15 drm-misc pull:

Just 3 sun4i patches to fix clock computation/checks.


Jonathan Liu (3):
  drm/sun4i: hdmi: Check for unset best_parent in sun4i_tmds_determine_rate
  drm/sun4i: hdmi: Fix incorrect assignment in sun4i_tmds_determine_rate
  drm/sun4i: hdmi: Add missing rate halving check in 
sun4i_tmds_determine_rate

 drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

-- 
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 libdrm] drm: fix return value

[Chunming Zhou]

On 2018年01月17日 17:24, Christian König wrote:

Am 17.01.2018 um 09:53 schrieb Chunming Zhou:



On 2018年01月17日 16:21, Daniel Vetter wrote:

On Tue, Jan 16, 2018 at 02:01:40PM +, Zhou, David(ChunMing) wrote:

Can your guys help me push it and last vamgr patches to upstream?
My new count request for libdrm still is under pending.

Or hand out commmit rights? That's easier long-term imo ...
That's not true, we need to track the commit for driver release, if 
we have no permission to push it, we often need to check the patch 
status to see if it's already in there.
Are you admin for count request? if you are, and approve my count 
request, I greatly appreciate your approval.


David, sounds like a misunderstanding. What Daniel suggested was that 
you should get commit rights, so that you can commit it yourself :)


But that's actually what we are already trying to do. It's just that 
the account request seems to take a while.


If Alex hasn't already forwarded the request to the Admins please post 
the link once more and I or Daniel can take care of it.

https://bugs.freedesktop.org/show_bug.cgi?id=104631
Michel and Alex have committed.

Thanks,
David Zhou


Regards,
Christian.



Regards,
David Zhou

-Daniel


Thanks,
David Zhou


发自坚果 Pro

Christian K鰊ig  于 2018年1月16日 
下午4:56写道：


Apart from that a good catch and Reviewed-by: Christian König
.

Regards,
Christian.

Am 16.01.2018 um 09:49 schrieb Michel Dänzer:
Moving from the amd-gfx list to dri-devel, since this isn't amdgpu 
specific.



On 2018-01-16 03:54 AM, Chunming Zhou wrote:

otherwise -ETIME is missed.

Change-Id: Ic5580a74d8027cc468c6135f8cf2f81817993423
Signed-off-by: Chunming Zhou 
---
   xf86drm.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xf86drm.c b/xf86drm.c
index 8a327170..3881bd9f 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -4241,7 +4241,7 @@ int drmSyncobjWait(int fd, uint32_t 
*handles, unsigned num_handles,


   ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_WAIT, );
   if (ret < 0)
-    return ret;
+    return -errno;

   if (first_signaled)
   *first_signaled = args.first_signaled;


___
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




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

Re: [PATCH libdrm] drm: fix return value

[Christian König]

Am 17.01.2018 um 09:53 schrieb Chunming Zhou:



On 2018年01月17日 16:21, Daniel Vetter wrote:

On Tue, Jan 16, 2018 at 02:01:40PM +, Zhou, David(ChunMing) wrote:

Can your guys help me push it and last vamgr patches to upstream?
My new count request for libdrm still is under pending.

Or hand out commmit rights? That's easier long-term imo ...
That's not true, we need to track the commit for driver release, if we 
have no permission to push it, we often need to check the patch status 
to see if it's already in there.
Are you admin for count request? if you are, and approve my count 
request, I greatly appreciate your approval.


David, sounds like a misunderstanding. What Daniel suggested was that 
you should get commit rights, so that you can commit it yourself :)


But that's actually what we are already trying to do. It's just that the 
account request seems to take a while.


If Alex hasn't already forwarded the request to the Admins please post 
the link once more and I or Daniel can take care of it.


Regards,
Christian.



Regards,
David Zhou

-Daniel


Thanks,
David Zhou


发自坚果 Pro

Christian K鰊ig  于 2018年1月16日 
下午4:56写道：


Apart from that a good catch and Reviewed-by: Christian König
.

Regards,
Christian.

Am 16.01.2018 um 09:49 schrieb Michel Dänzer:
Moving from the amd-gfx list to dri-devel, since this isn't amdgpu 
specific.



On 2018-01-16 03:54 AM, Chunming Zhou wrote:

otherwise -ETIME is missed.

Change-Id: Ic5580a74d8027cc468c6135f8cf2f81817993423
Signed-off-by: Chunming Zhou 
---
   xf86drm.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xf86drm.c b/xf86drm.c
index 8a327170..3881bd9f 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -4241,7 +4241,7 @@ int drmSyncobjWait(int fd, uint32_t 
*handles, unsigned num_handles,


   ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_WAIT, );
   if (ret < 0)
-    return ret;
+    return -errno;

   if (first_signaled)
   *first_signaled = args.first_signaled;


___
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


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

Re: [PATCH 06/19] drm/blend: Add a generic alpha property

[Maxime Ripard]

On Thu, Jan 11, 2018 at 08:34:58PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
> 
> On Thursday, 11 January 2018 18:36:10 EET Daniel Vetter wrote:
> > On Thu, Jan 11, 2018 at 4:58 PM, Maxime Ripard wrote:
> > > On Tue, Jan 09, 2018 at 03:28:34PM +0100, Daniel Vetter wrote:
> > >> On Tue, Jan 09, 2018 at 02:53:22PM +0100, Maxime Ripard wrote:
> > >>> On Tue, Jan 09, 2018 at 01:32:41PM +0100, Daniel Vetter wrote:
> >  On Tue, Jan 09, 2018 at 11:56:25AM +0100, Maxime Ripard wrote:
> > > Some drivers duplicate the logic to create a property to store a
> > > per-plane alpha.
> > > 
> > > Let's create a helper in order to move that to the core.
> > > 
> > > Cc: Boris Brezillon 
> > > Cc: Laurent Pinchart 
> > > Signed-off-by: Maxime Ripard 
> >  
> >  Do we have userspace for this?
> > >>> 
> > >>> Wayland seems to be on its way to implement this, with ChromeOS using
> > >>> it:
> > >>> https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741
> > >>> .html
> > >>> 
> > >>> and more specifically:
> > >>> https://chromium.googlesource.com/chromium/src/+/master/third_party/way
> > >>> land-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1
> > >>> .xml#118
> > >> 
> > >> Yay, would be good to include these links in the patch description.
> > >> Really happy we're having a real standard now used by multiple people.
> > > 
> > > I will.
> > > 
> > >> > > Is encoding a fixed 0-255 range really the best idea?
> > >> > 
> > >> > I don't really know, is there hardware or formats where there is more
> > >> > than 255? Or did you mean less than that?
> > >> 
> > >> 30bit I'd assume wants more alpha. In the past we've done some
> > >> fixed-point stuff (e.g. for LUT), using the 0.0-1.0 float range. Using
> > >> that for the blend equation docs is also what I recommend (and that we
> > >> map from 0-255 to 0.0-1.0 logically). Ofc the hw might not do any of that
> > >> ... I think 0.16 fixed point, stored in a u16 is probably best. That's
> > >> what we're doing for gamma tables already, and that way drivers can
> > >> simply throw away the lower bits.
> > > 
> > > But that would also break the two users of that property that won't be
> > > able to move to the generic property (with the same name) without
> > > breaking userspace. The point of that patch was to allow some code
> > > consolidation, and that would mean failing to do so here :/
> > 
> > Let me try to clarify:
> > - We'll keep the exact existing property semantics with the 0-255
> > range for the userspace visible property.
> > 
> > - But internally, in the decode value that we store into
> > drm_plane_state, we'll do the slightly more future proof thing with a
> > few more bits.
> > 
> > That gives us the option of exposing those bits in the future without
> > having to change all the drivers again (which we have to do for this
> > series here already anyway, since the decoded value moves into
> > drm_plane_state from driver subclasses).
> > 
> > Definitely not asking to break userspace here :-)
> 
> As the property range is available to userspace, we could allow drivers to 
> expose a driver-dependent number of bits for the alpha value without breaking 
> anything. We can even require new drivers to expose 16 bits regardless of the 
> number of bits that the hardware can handle, or we could keep that driver-
> specific.
> 
> Please note, however, that U0.16 can only represent [0.0, 0.84741...] 
> while we need [0.0, 1.0]. As all the hardware I know map the full range of 
> values ([0, 255] for 8-bit for instance) to [0.0, 1.0] I wouldn't pretend 
> that 
> the 16-bit value exposed to userspace is U0.16.

So this would involve not changing too much the current patch, but
instead extending the type from an u8 to an u16. Would that work for
you Daniel?

Thanks!
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: [Intel-gfx] [PATCH] drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig

[Hans de Goede]

Hi,

On 17-01-18 09:48, Daniel Vetter wrote:

On Wed, Jan 17, 2018 at 9:42 AM, Hans de Goede  wrote:

Hi,

On 17-01-18 09:40, Daniel Vetter wrote:


On Wed, Jan 17, 2018 at 09:10:32AM +0100, Hans de Goede wrote:


All Kconfig menu menu entries should have a depends on MENU_OPTION, the
menu stops after the first Kconfig entry without this depends on.

Since the PANEL_ORIENTATION_QUIRKS option is also used outside of DRM,
it deliberately does not have a depends on DRM, but this causes all
items after it to show as separate items rather then under the DRM
menuconfig.

This commit moves PANEL_ORIENTATION_QUIRKS to the end of the drm Kconfig
file, grouping it with DRM_LIB_RANDOM which also does not depend on DRM,
fixing the DRM menuconfig.

Fixes: 404d1a3edc38 ("drm: Add panel orientation quirks, v6.")
Cc: Chris Wilson 
Reported-by: Chris Wilson 
Signed-off-by: Hans de Goede 



Reviewed-by: Daniel Vetter 

Probably best if you push to to drm-misc-next-fixes so it gets into 4.16
still.



Ok, does that mean I need to push it to 2 branches, or will it automatically
and up in drm-misc-next if I push it to drm-misc-next-fixes?



Only one branch. We'll do a backmerge eventually to sync up
drm-misc-next with the other branches. Or if you need it right away,
you can request that from the -next maintainer for that cycle (Sean
this time around).


Ok, pushed to drm-misc-next-fixes and as always thank you for your
help.

Regards,

Hans



---
   drivers/gpu/drm/Kconfig | 8 
   1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 0bc374459440..deeefa7a1773 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -27,10 +27,6 @@ config DRM_MIPI_DSI
 bool
 depends on DRM
   -# Separate option because drm_panel_orientation_quirks.c is shared
with fbdev
-config DRM_PANEL_ORIENTATION_QUIRKS
-   tristate
-
   config DRM_DP_AUX_CHARDEV
 bool "DRM DP AUX Interface"
 depends on DRM
@@ -372,6 +368,10 @@ config DRM_SAVAGE
 endif # DRM_LEGACY
   +# Separate option because drm_panel_orientation_quirks.c is shared
with fbdev
+config DRM_PANEL_ORIENTATION_QUIRKS
+   tristate
+
   config DRM_LIB_RANDOM
 bool
 default n
--
2.14.3

___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx










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

Re: [PATCH v3 4/8] drm: Add DRM client cap for aspect-ratio

[Sharma, Shashank]

Regards

Shashank


On 1/12/2018 11:51 AM, Nautiyal, Ankit K wrote:

From: Ankit Nautiyal 

A new drm client cap is required to enable user-space to advertise
if it supports modes with aspect-ratio. Based on this cap value, the
kernel will take a call on exposing the aspect ratio information in
modes or not.

This patch adds the client cap for aspect-ratio.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Signed-off-by: Ankit Nautiyal 

V3: rebase
---
  drivers/gpu/drm/drm_ioctl.c | 5 +
  include/drm/drm_file.h  | 7 +++
  include/uapi/drm/drm.h  | 7 +++
  3 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 4aafe48..e092550 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -325,6 +325,11 @@ drm_setclientcap(struct drm_device *dev, void *data, 
struct drm_file *file_priv)
file_priv->atomic = req->value;
file_priv->universal_planes = req->value;
break;
+   case DRM_CLIENT_CAP_ASPECT_RATIO:
+   if (req->value > 1)
+   return -EINVAL;
+   file_priv->aspect_ratio_allowed = req->value;
+   break;
default:
return -EINVAL;
}
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 0e0c868..6e0e435 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -182,6 +182,13 @@ struct drm_file {
unsigned atomic:1;
  
  	/**

+* @aspect_ratio_allowed:
+*
+* True if client has asked to expose the aspect-ratio flags with mode.
Minor reword, may be "True if client can handle picture aspect ratios, 
and has requested to pass this information along with the mode"

+*/
+   unsigned aspect_ratio_allowed:1;
+
+   /**
 * @is_master:
 *
 * This client is the creator of @master. Protected by struct
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 6fdff59..fe5f531 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -680,6 +680,13 @@ struct drm_get_cap {
   */
  #define DRM_CLIENT_CAP_ATOMIC 3
  
+/**

+ * DRM_CLIENT_CAP_ASPECT_RATIO
+ *
+ * If set to 1, the DRM core will expose aspect ratio flags to userspace.
+ */
Again "If set to 1, the DRM core will provide aspect ratio information 
in modes"

+#define DRM_CLIENT_CAP_ASPECT_RATIO4
+
  /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
  struct drm_set_client_cap {
__u64 capability;

With these optional review comments, please feel free to use
Reviewed-by: Shashank Sharma 

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

Re: [PATCH v3 3/8] drm/edid: Fix cea mode aspect ratio handling

[Sharma, Shashank]

Regards

Shashank


On 1/12/2018 11:51 AM, Nautiyal, Ankit K wrote:

From: Ville Syrjälä 

commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.

Let's handle this by considering the aspect ratio as a requirement
for cea mode matching only if the passed in mode actually has a
non-zero aspect ratio field. This will keep userspace that doesn't
provide an aspect ratio working as before by matching it to the
first otherwise equal cea mode. And once userspace starts to
provide the aspect ratio it will be considerd a hard requirement
for the match.

Also change the hdmi mode matching to use drm_mode_match() for
consistency, but we don't match on aspect ratio there since the
spec doesn't list a specific aspect ratio for those modes.

Cc: Shashank Sharma 
Cc: "Lin, Jia" 
Cc: Akashdeep Sharma 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/drm_edid.c | 18 ++
  1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1818a71..3d57c41 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2908,11 +2908,15 @@ cea_mode_alternate_timings(u8 vic, struct 
drm_display_mode *mode)
  static u8 drm_match_cea_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
 unsigned int clock_tolerance)
  {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
  
  	if (!to_match->clock)

return 0;
  
+	if (to_match->picture_aspect_ratio)

+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
+
for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2926,7 +2930,7 @@ static u8 drm_match_cea_mode_clock_tolerance(const struct 
drm_display_mode *to_m
continue;
  
  		do {

-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -2943,11 +2947,15 @@ static u8 drm_match_cea_mode_clock_tolerance(const 
struct drm_display_mode *to_m
   */
  u8 drm_match_cea_mode(const struct drm_display_mode *to_match)
  {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
  
  	if (!to_match->clock)

return 0;
  
+	if (to_match->picture_aspect_ratio)

+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
+
How about stereo flags ? CEA modes can be 3d and in that case we might 
want to add DRM_MODE_MATCH_3D_FLAGS here


- Shashank

for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2961,7 +2969,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
continue;
  
  		do {

-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -3008,6 +3016,7 @@ hdmi_mode_alternate_clock(const struct drm_display_mode 
*hdmi_mode)
  static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
  unsigned int clock_tolerance)
  {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
  
  	if (!to_match->clock)

@@ -3025,7 +3034,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
abs(to_match->clock - clock2) > clock_tolerance)
continue;
  
-		if (drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode))

+   if (drm_mode_match(to_match, hdmi_mode, match_flags))
return vic;
}
  
@@ -3042,6 +3051,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode *to_

   */
  static u8 drm_match_hdmi_mode(const struct drm_display_mode *to_match)
  {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
  
  	if (!to_match->clock)

@@ -3057,7 +3067,7 @@ static 

[PATCH] drm/ttm: add VADDR_FLAG_UPDATED_COUNT to correctly update dma_page global count

[Roger He]

add this for correctly updating global mem count in ttm_mem_zone.
before that when ttm_mem_global_alloc_page fails, we would update all
dma_page's global mem count in ttm_dma->pages_list. but actually here
we should not update for the last dma_page.

v2: only the update of last dma_page is not right
v3: use lower bits of dma_page vaddr

Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 55 +---
 1 file changed, 29 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index c7f01a4..a880515 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -61,6 +61,7 @@
 #define SMALL_ALLOCATION   4
 #define FREE_ALL_PAGES (~0U)
 #define VADDR_FLAG_HUGE_POOL   1UL
+#define VADDR_FLAG_UPDATED_COUNT   2UL
 
 enum pool_type {
IS_UNDEFINED= 0,
@@ -874,18 +875,18 @@ static int ttm_dma_page_pool_fill_locked(struct dma_pool 
*pool,
 }
 
 /*
- * @return count of pages still required to fulfill the request.
  * The populate list is actually a stack (not that is matters as TTM
  * allocates one page at a time.
+ * return dma_page pointer if success, otherwise NULL.
  */
-static int ttm_dma_pool_get_pages(struct dma_pool *pool,
+static struct dma_page *ttm_dma_pool_get_pages(struct dma_pool *pool,
  struct ttm_dma_tt *ttm_dma,
  unsigned index)
 {
-   struct dma_page *d_page;
+   struct dma_page *d_page = NULL;
struct ttm_tt *ttm = _dma->ttm;
unsigned long irq_flags;
-   int count, r = -ENOMEM;
+   int count;
 
spin_lock_irqsave(>lock, irq_flags);
count = ttm_dma_page_pool_fill_locked(pool, _flags);
@@ -894,12 +895,11 @@ static int ttm_dma_pool_get_pages(struct dma_pool *pool,
ttm->pages[index] = d_page->p;
ttm_dma->dma_address[index] = d_page->dma;
list_move_tail(_page->page_list, _dma->pages_list);
-   r = 0;
pool->npages_in_use += 1;
pool->npages_free -= 1;
}
spin_unlock_irqrestore(>lock, irq_flags);
-   return r;
+   return d_page;
 }
 
 static gfp_t ttm_dma_pool_gfp_flags(struct ttm_dma_tt *ttm_dma, bool huge)
@@ -934,6 +934,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
struct ttm_mem_global *mem_glob = ttm->glob->mem_glob;
unsigned long num_pages = ttm->num_pages;
struct dma_pool *pool;
+   struct dma_page *d_page;
enum pool_type type;
unsigned i;
int ret;
@@ -962,8 +963,8 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
while (num_pages >= HPAGE_PMD_NR) {
unsigned j;
 
-   ret = ttm_dma_pool_get_pages(pool, ttm_dma, i);
-   if (ret != 0)
+   d_page = ttm_dma_pool_get_pages(pool, ttm_dma, i);
+   if (!d_page)
break;
 
ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],
@@ -973,6 +974,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
return -ENOMEM;
}
 
+   d_page->vaddr |= VADDR_FLAG_UPDATED_COUNT;
for (j = i + 1; j < (i + HPAGE_PMD_NR); ++j) {
ttm->pages[j] = ttm->pages[j - 1] + 1;
ttm_dma->dma_address[j] = ttm_dma->dma_address[j - 1] +
@@ -996,8 +998,8 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
}
 
while (num_pages) {
-   ret = ttm_dma_pool_get_pages(pool, ttm_dma, i);
-   if (ret != 0) {
+   d_page = ttm_dma_pool_get_pages(pool, ttm_dma, i);
+   if (!d_page) {
ttm_dma_unpopulate(ttm_dma, dev);
return -ENOMEM;
}
@@ -1009,6 +1011,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
return -ENOMEM;
}
 
+   d_page->vaddr |= VADDR_FLAG_UPDATED_COUNT;
++i;
--num_pages;
}
@@ -1049,8 +1052,11 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, 
struct device *dev)
continue;
 
count++;
-   ttm_mem_global_free_page(ttm->glob->mem_glob,
-d_page->p, pool->size);
+   if (d_page->vaddr & VADDR_FLAG_UPDATED_COUNT) {
+   ttm_mem_global_free_page(ttm->glob->mem_glob,
+d_page->p, pool->size);
+   d_page->vaddr &= ~VADDR_FLAG_UPDATED_COUNT;
+   }

Re: [PATCH v3 2/8] drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy

[Sharma, Shashank]

Regards
Shashank

On 1/12/2018 11:51 AM, Nautiyal, Ankit K wrote:

From: Ville Syrjälä 

Use drm_mode_equal_no_clocks_no_stereo() in
drm_match_hdmi_mode_clock_tolerance() for consistency as we
also use it in drm_match_hdmi_mode() and the cea mode matching
functions.

This doesn't actually change anything since the input mode
comes from detailed timings and we match it against
edid_4k_modes[] which. So none of those modes can have stereo
flags set.

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/drm_edid.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ddd5379..1818a71 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3025,7 +3025,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
abs(to_match->clock - clock2) > clock_tolerance)
continue;
  
-		if (drm_mode_equal_no_clocks(to_match, hdmi_mode))

+   if (drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode))
return vic;
}

Reviewed-by: Shashank Sharma 
  


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

Re: [PATCH libdrm] drm: fix return value

[Chunming Zhou]

On 2018年01月17日 16:21, Daniel Vetter wrote:

On Tue, Jan 16, 2018 at 02:01:40PM +, Zhou, David(ChunMing) wrote:

Can your guys help me push it and last vamgr patches to upstream?
My new count request for libdrm still is under pending.

Or hand out commmit rights? That's easier long-term imo ...
That's not true, we need to track the commit for driver release, if we 
have no permission to push it, we often need to check the patch status 
to see if it's already in there.
Are you admin for count request? if you are, and approve my count 
request, I greatly appreciate your approval.


Regards,
David Zhou

-Daniel


Thanks,
David Zhou


发自坚果 Pro

Christian K鰊ig  于 2018年1月16日 下午4:56写道：

Apart from that a good catch and Reviewed-by: Christian König
.

Regards,
Christian.

Am 16.01.2018 um 09:49 schrieb Michel Dänzer:

Moving from the amd-gfx list to dri-devel, since this isn't amdgpu specific.


On 2018-01-16 03:54 AM, Chunming Zhou wrote:

otherwise -ETIME is missed.

Change-Id: Ic5580a74d8027cc468c6135f8cf2f81817993423
Signed-off-by: Chunming Zhou 
---
   xf86drm.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xf86drm.c b/xf86drm.c
index 8a327170..3881bd9f 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -4241,7 +4241,7 @@ int drmSyncobjWait(int fd, uint32_t *handles, unsigned 
num_handles,

   ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_WAIT, );
   if (ret < 0)
-return ret;
+return -errno;

   if (first_signaled)
   *first_signaled = args.first_signaled;


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




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

Re: [Intel-gfx] [PATCH] drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig

[Hans de Goede]

Hi,

On 17-01-18 09:40, Daniel Vetter wrote:

On Wed, Jan 17, 2018 at 09:10:32AM +0100, Hans de Goede wrote:

All Kconfig menu menu entries should have a depends on MENU_OPTION, the
menu stops after the first Kconfig entry without this depends on.

Since the PANEL_ORIENTATION_QUIRKS option is also used outside of DRM,
it deliberately does not have a depends on DRM, but this causes all
items after it to show as separate items rather then under the DRM
menuconfig.

This commit moves PANEL_ORIENTATION_QUIRKS to the end of the drm Kconfig
file, grouping it with DRM_LIB_RANDOM which also does not depend on DRM,
fixing the DRM menuconfig.

Fixes: 404d1a3edc38 ("drm: Add panel orientation quirks, v6.")
Cc: Chris Wilson 
Reported-by: Chris Wilson 
Signed-off-by: Hans de Goede 


Reviewed-by: Daniel Vetter 

Probably best if you push to to drm-misc-next-fixes so it gets into 4.16
still.


Ok, does that mean I need to push it to 2 branches, or will it automatically
and up in drm-misc-next if I push it to drm-misc-next-fixes?

Regards,

Hans




---
  drivers/gpu/drm/Kconfig | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 0bc374459440..deeefa7a1773 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -27,10 +27,6 @@ config DRM_MIPI_DSI
bool
depends on DRM
  
-# Separate option because drm_panel_orientation_quirks.c is shared with fbdev

-config DRM_PANEL_ORIENTATION_QUIRKS
-   tristate
-
  config DRM_DP_AUX_CHARDEV
bool "DRM DP AUX Interface"
depends on DRM
@@ -372,6 +368,10 @@ config DRM_SAVAGE
  
  endif # DRM_LEGACY
  
+# Separate option because drm_panel_orientation_quirks.c is shared with fbdev

+config DRM_PANEL_ORIENTATION_QUIRKS
+   tristate
+
  config DRM_LIB_RANDOM
bool
default n
--
2.14.3

___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx



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

Re: [PATCH] [RESEND] vmwgfx: use monotonic event timestamps

[Woody Suwalski]

Thomas Hellstrom wrote:

Hi, Arnd,

Sinclair's on paternal leave and I thought this patch was already in 
drm-next. My bad.

Dave, is it too late to pull this in for the next merge window?

/Thomas


On 01/16/2018 06:18 PM, Arnd Bergmann wrote:

DRM_VMW_EVENT_FENCE_SIGNALED (struct drm_vmw_event_fence) and
DRM_EVENT_VBLANK (struct drm_event_vblank) pass timestamps in 32-bit
seconds/microseconds format.

As of commit c61eef726a78 ("drm: add support for monotonic vblank
timestamps"), other DRM drivers use monotonic times for 
drm_event_vblank,

but vmwgfx still uses CLOCK_REALTIME for both events, which suffers from
the y2038/y2106 overflow as well as time jumps.

For consistency, this changes vmwgfx to use ktime_get_ts64 as well,
which solves those problems and avoids the deprecated do_gettimeofday()
function.

This should be transparent to to user space, as long as it doesn't
compare the time against the result of gettimeofday().

Link: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.kernel.org_patch_10076599_=DwIBAg=uilaK90D4TOVoH58JNXRgQ=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ=8M6vawBo0zDsjbqhzV0xpOwAzX7Zm-uyGlIDnQ7-Gms=sHGuz0aoE9aLjVp5GALo8mYrN1bwOHW6mGpJIZmhwAc=

Signed-off-by: Arnd Bergmann 
---
Originally sent on Nov 27. Sinclair Yeh said he'd pick it up
for the next pull request, but it's not in linux-next yet.

Resending the unchanged patch, please pick it up when you have time,
or feel free to ignore this email in case it's already in some tree
that just isn't part of linux-next but will be sent during the
next merge window.
---
  drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c

index 6c5c75cf5e6c..9ed544f8958f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -901,11 +901,12 @@ static void 
vmw_event_fence_action_seq_passed(struct vmw_fence_action *action)

  spin_lock_irq(>event_lock);
    if (likely(eaction->tv_sec != NULL)) {
-    struct timeval tv;
+    struct timespec64 ts;
  -    do_gettimeofday();
-    *eaction->tv_sec = tv.tv_sec;
-    *eaction->tv_usec = tv.tv_usec;
+    ktime_get_ts64();
+    /* monotonic time, so no y2038 overflow */
+    *eaction->tv_sec = ts.tv_sec;
+    *eaction->tv_usec = ts.tv_nsec / NSEC_PER_USEC;
  }
    drm_send_event_locked(dev, eaction->event);




Thomas, the same way my DRM patch has disappeared:
Date

Tue, 19 Dec 2017 11:50:57 -0800
FromSinclair Yeh <>
Subject Re: [PATCH v.2] 4.15 vmgfx boot warning




This looks okay to me.

On Mon, Dec 18, 2017 at 07:26:03PM -0500, Woody Suwalski wrote:

The 4.15 drm_atomic_helper driver shows a warning during boot (both 32 and
64 bit x86)
It is caused by a mismatch between the result of vmw_enable_vblank() and
what the drm_atomic_helper expects:
   /...
   ret = drm_crtc_vblank_get(crtc);
   WARN_ONCE(ret != -EINVAL, "driver forgot to call
drm_crtc_vblank_off()\n");
   /...

Signed-off by: Woody Suwalski 

--- a/drivers/gpu/drm/drm_atomic_helper.c    2017-12-16 09:55:33.853374561
-0500
+++ b/drivers/gpu/drm/drm_atomic_helper.c    2017-12-16 10:55:56.089090752
-0500
@@ -889,7 +889,7 @@ disable_outputs(struct drm_device *dev,
         continue;

     ret = drm_crtc_vblank_get(crtc);
-        WARN_ONCE(ret != -EINVAL, "driver forgot to call
drm_crtc_vblank_off()\n");
+        WARN_ONCE((ret != -EINVAL && ret != -ENOSYS), "driver forgot to
call drm_crtc_vblank_off()\n");
     if (ret == 0)
         drm_crtc_vblank_put(crtc);
 }



===

The 4.15 drm_atomic_helper driver shows a warning during boot.
It is caused by a mismatch between the result of vmw_enable_vblank() and
what the drm_atomic_helper expects:
    /...
    ret = drm_crtc_vblank_get(crtc);
    WARN_ONCE(ret != -EINVAL, "driver forgot to call drm_crtc_vblank_off()\n");
    /...

Signed-off by: Woody Suwalski 

--- a/drivers/gpu/drm/drm_atomic_helper.c   2017-12-16 09:55:33.853374561 
-0500
+++ b/drivers/gpu/drm/drm_atomic_helper.c   2017-12-16 10:55:56.089090752 
-0500
@@ -889,7 +889,7 @@ disable_outputs(struct drm_device *dev,
continue;
 
 		ret = drm_crtc_vblank_get(crtc);

-   WARN_ONCE(ret != -EINVAL, "driver forgot to call 
drm_crtc_vblank_off()\n");
+   WARN_ONCE((ret != -EINVAL && ret != -ENOSYS), "driver forgot to call 
drm_crtc_vblank_off()\n");
if (ret == 0)
drm_crtc_vblank_put(crtc);
}

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

[PATCH] drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig

[Hans de Goede]

All Kconfig menu menu entries should have a depends on MENU_OPTION, the
menu stops after the first Kconfig entry without this depends on.

Since the PANEL_ORIENTATION_QUIRKS option is also used outside of DRM,
it deliberately does not have a depends on DRM, but this causes all
items after it to show as separate items rather then under the DRM
menuconfig.

This commit moves PANEL_ORIENTATION_QUIRKS to the end of the drm Kconfig
file, grouping it with DRM_LIB_RANDOM which also does not depend on DRM,
fixing the DRM menuconfig.

Fixes: 404d1a3edc38 ("drm: Add panel orientation quirks, v6.")
Cc: Chris Wilson 
Reported-by: Chris Wilson 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/Kconfig | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 0bc374459440..deeefa7a1773 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -27,10 +27,6 @@ config DRM_MIPI_DSI
bool
depends on DRM
 
-# Separate option because drm_panel_orientation_quirks.c is shared with fbdev
-config DRM_PANEL_ORIENTATION_QUIRKS
-   tristate
-
 config DRM_DP_AUX_CHARDEV
bool "DRM DP AUX Interface"
depends on DRM
@@ -372,6 +368,10 @@ config DRM_SAVAGE
 
 endif # DRM_LEGACY
 
+# Separate option because drm_panel_orientation_quirks.c is shared with fbdev
+config DRM_PANEL_ORIENTATION_QUIRKS
+   tristate
+
 config DRM_LIB_RANDOM
bool
default n
-- 
2.14.3

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

Re: [PATCH] drm/vmwgfx: Fix a boot time warning

[Thomas Hellstrom]

On 01/17/2018 09:47 AM, Daniel Vetter wrote:

On Wed, Jan 17, 2018 at 09:21:25AM +0100, Thomas Hellstrom wrote:

From: Woody Suwalski 

The 4.15 vmwgfx driver shows a warning during boot.
It is caused by a mismatch between the result of vmw_enable_vblank()
and what the drm_atomic_helper expects.

Signed-off by: Woody Suwalski 
Signed-off-by: Thomas Hellstrom 

Just curious question, but why do you even have all that code? Not
enabling any of the vblank stuff should also work with atomic drivers, and
would require much less boilerplate ...

Either way: Reviewed-by: Daniel Vetter 


To be honest, nobody here has really looked at exactly what parts are 
needed when we don't have the vblank interrupt.

We'll put that on the to-do list.

Thanks,

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

Re: [Intel-gfx] [PATCH] drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig

[Daniel Vetter]

On Wed, Jan 17, 2018 at 9:42 AM, Hans de Goede  wrote:
> Hi,
>
> On 17-01-18 09:40, Daniel Vetter wrote:
>>
>> On Wed, Jan 17, 2018 at 09:10:32AM +0100, Hans de Goede wrote:
>>>
>>> All Kconfig menu menu entries should have a depends on MENU_OPTION, the
>>> menu stops after the first Kconfig entry without this depends on.
>>>
>>> Since the PANEL_ORIENTATION_QUIRKS option is also used outside of DRM,
>>> it deliberately does not have a depends on DRM, but this causes all
>>> items after it to show as separate items rather then under the DRM
>>> menuconfig.
>>>
>>> This commit moves PANEL_ORIENTATION_QUIRKS to the end of the drm Kconfig
>>> file, grouping it with DRM_LIB_RANDOM which also does not depend on DRM,
>>> fixing the DRM menuconfig.
>>>
>>> Fixes: 404d1a3edc38 ("drm: Add panel orientation quirks, v6.")
>>> Cc: Chris Wilson 
>>> Reported-by: Chris Wilson 
>>> Signed-off-by: Hans de Goede 
>>
>>
>> Reviewed-by: Daniel Vetter 
>>
>> Probably best if you push to to drm-misc-next-fixes so it gets into 4.16
>> still.
>
>
> Ok, does that mean I need to push it to 2 branches, or will it automatically
> and up in drm-misc-next if I push it to drm-misc-next-fixes?


Only one branch. We'll do a backmerge eventually to sync up
drm-misc-next with the other branches. Or if you need it right away,
you can request that from the -next maintainer for that cycle (Sean
this time around).
-Daniel

>
> Regards,
>
> Hans
>
>
>
>
>>> ---
>>>   drivers/gpu/drm/Kconfig | 8 
>>>   1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>>> index 0bc374459440..deeefa7a1773 100644
>>> --- a/drivers/gpu/drm/Kconfig
>>> +++ b/drivers/gpu/drm/Kconfig
>>> @@ -27,10 +27,6 @@ config DRM_MIPI_DSI
>>> bool
>>> depends on DRM
>>>   -# Separate option because drm_panel_orientation_quirks.c is shared
>>> with fbdev
>>> -config DRM_PANEL_ORIENTATION_QUIRKS
>>> -   tristate
>>> -
>>>   config DRM_DP_AUX_CHARDEV
>>> bool "DRM DP AUX Interface"
>>> depends on DRM
>>> @@ -372,6 +368,10 @@ config DRM_SAVAGE
>>> endif # DRM_LEGACY
>>>   +# Separate option because drm_panel_orientation_quirks.c is shared
>>> with fbdev
>>> +config DRM_PANEL_ORIENTATION_QUIRKS
>>> +   tristate
>>> +
>>>   config DRM_LIB_RANDOM
>>> bool
>>> default n
>>> --
>>> 2.14.3
>>>
>>> ___
>>> Intel-gfx mailing list
>>> intel-...@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
>>
>



-- 
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] drm/vmwgfx: Fix a boot time warning

[Daniel Vetter]

On Wed, Jan 17, 2018 at 09:21:25AM +0100, Thomas Hellstrom wrote:
> From: Woody Suwalski 
> 
> The 4.15 vmwgfx driver shows a warning during boot.
> It is caused by a mismatch between the result of vmw_enable_vblank()
> and what the drm_atomic_helper expects.
> 
> Signed-off by: Woody Suwalski 
> Signed-off-by: Thomas Hellstrom 

Just curious question, but why do you even have all that code? Not
enabling any of the vblank stuff should also work with atomic drivers, and
would require much less boilerplate ...

Either way: Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index 641294a..fcd5814 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -1863,7 +1863,7 @@ u32 vmw_get_vblank_counter(struct drm_device *dev, 
> unsigned int pipe)
>   */
>  int vmw_enable_vblank(struct drm_device *dev, unsigned int pipe)
>  {
> - return -ENOSYS;
> + return -EINVAL;
>  }
>  
>  /**
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH v3 1/8] drm/modes: Introduce drm_mode_match()

[Sharma, Shashank]

On 1/12/2018 11:51 AM, Nautiyal, Ankit K wrote:

From: Ville Syrjälä 

Make mode matching less confusing by allowing the caller to specify
which parts of the modes should match via some flags.

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/drm_modes.c | 134 ++--
  include/drm/drm_modes.h |   9 +++
  2 files changed, 112 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 4a3f68a..8128dbb 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -940,17 +940,68 @@ struct drm_display_mode *drm_mode_duplicate(struct 
drm_device *dev,
  }
  EXPORT_SYMBOL(drm_mode_duplicate);
  
+static bool drm_mode_match_timings(const struct drm_display_mode *mode1,

+  const struct drm_display_mode *mode2)
Shouldn't the second parameter be aligned to next char after the opening 
bracket in above line (instead of being align to the bracket) ?

I have this same comment for most of the functions in this patch.

+{
+   return mode1->hdisplay == mode2->hdisplay &&
+   mode1->hsync_start == mode2->hsync_start &&
+   mode1->hsync_end == mode2->hsync_end &&
+   mode1->htotal == mode2->htotal &&
+   mode1->hskew == mode2->hskew &&
+   mode1->vdisplay == mode2->vdisplay &&
+   mode1->vsync_start == mode2->vsync_start &&
+   mode1->vsync_end == mode2->vsync_end &&
+   mode1->vtotal == mode2->vtotal &&
+   mode1->vscan == mode2->vscan;
+}
+
+static bool drm_mode_match_clock(const struct drm_display_mode *mode1,
+ const struct drm_display_mode *mode2)
+{
+   /*
+* do clock check convert to PICOS
+* so fb modes get matched the same
+*/
+   if (mode1->clock && mode2->clock)
+   return KHZ2PICOS(mode1->clock) == KHZ2PICOS(mode2->clock);
+   else
+   return mode1->clock == mode2->clock;
+}
+
+static bool drm_mode_match_flags(const struct drm_display_mode *mode1,

Should we call it drm_mode_match_flag_no_stereo ?

+const struct drm_display_mode *mode2)
+{
+   return (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
+   (mode2->flags & ~DRM_MODE_FLAG_3D_MASK);
+}
+
+static bool drm_mode_match_3d_flags(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2)
+{
+   return (mode1->flags & DRM_MODE_FLAG_3D_MASK) ==
+   (mode2->flags & DRM_MODE_FLAG_3D_MASK);
+}
+
+static bool drm_mode_match_aspect_ratio(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2)
+{
+   return mode1->picture_aspect_ratio == mode2->picture_aspect_ratio;
+}
+
  /**
- * drm_mode_equal - test modes for equality
+ * drm_mode_match - test modes for (partial) equality
   * @mode1: first mode
   * @mode2: second mode
+ * @match_flags: which parts need to match (DRM_MODE_MATCH_*)
   *
   * Check to see if @mode1 and @mode2 are equivalent.
   *
   * Returns:
- * True if the modes are equal, false otherwise.
+ * True if the modes are (partially) equal, false otherwise.
   */
-bool drm_mode_equal(const struct drm_display_mode *mode1, const struct 
drm_display_mode *mode2)
+bool drm_mode_match(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2,
+   unsigned int match_flags)
  {
if (!mode1 && !mode2)
return true;
@@ -958,15 +1009,48 @@ bool drm_mode_equal(const struct drm_display_mode 
*mode1, const struct drm_displ
if (!mode1 || !mode2)
return false;
  
-	/* do clock check convert to PICOS so fb modes get matched

-* the same */
-   if (mode1->clock && mode2->clock) {
-   if (KHZ2PICOS(mode1->clock) != KHZ2PICOS(mode2->clock))
-   return false;
-   } else if (mode1->clock != mode2->clock)
+   if (match_flags & DRM_MODE_MATCH_TIMINGS &&
+   !drm_mode_match_timings(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_CLOCK &&
+   !drm_mode_match_clock(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_FLAGS &&
+   !drm_mode_match_flags(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_3D_FLAGS &&
+   !drm_mode_match_3d_flags(mode1, mode2))
return false;
  
-	return drm_mode_equal_no_clocks(mode1, mode2);

+   if (match_flags & DRM_MODE_MATCH_ASPECT_RATIO &&
+   !drm_mode_match_aspect_ratio(mode1, mode2))
+   return false;
+
+   return true;
+}
+EXPORT_SYMBOL(drm_mode_match);
+
+/**
+ * drm_mode_equal - test modes for equality
+ * @mode1: first mode
+ 

[git pull] vmwgfx-fixes-4.15 for -rc9 / final

[Thomas Hellstrom]

Dave,

A last minute minimal fix to kill a warning introduced in a helper in 4.15.

The following changes since commit 0d9cac0ca0429830c40fe1a4e50e60f6221fd7b6:

  drm/vmwgfx: Potential off by one in vmw_view_add() (2018-01-10 15:21:39 +0100)

are available in the git repository at:

  git://people.freedesktop.org/~thomash/linux vmwgfx-fixes-4.15

for you to fetch changes up to 2b0bc6870f1a61b90b49012e917eea4cb251:

  drm/vmwgfx: Fix a boot time warning (2018-01-17 09:09:27 +0100)


Woody Suwalski (1):
  drm/vmwgfx: Fix a boot time warning

 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig

[Daniel Vetter]

On Wed, Jan 17, 2018 at 09:10:32AM +0100, Hans de Goede wrote:
> All Kconfig menu menu entries should have a depends on MENU_OPTION, the
> menu stops after the first Kconfig entry without this depends on.
> 
> Since the PANEL_ORIENTATION_QUIRKS option is also used outside of DRM,
> it deliberately does not have a depends on DRM, but this causes all
> items after it to show as separate items rather then under the DRM
> menuconfig.
> 
> This commit moves PANEL_ORIENTATION_QUIRKS to the end of the drm Kconfig
> file, grouping it with DRM_LIB_RANDOM which also does not depend on DRM,
> fixing the DRM menuconfig.
> 
> Fixes: 404d1a3edc38 ("drm: Add panel orientation quirks, v6.")
> Cc: Chris Wilson 
> Reported-by: Chris Wilson 
> Signed-off-by: Hans de Goede 

Reviewed-by: Daniel Vetter 

Probably best if you push to to drm-misc-next-fixes so it gets into 4.16
still.
-Daniel

> ---
>  drivers/gpu/drm/Kconfig | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 0bc374459440..deeefa7a1773 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -27,10 +27,6 @@ config DRM_MIPI_DSI
>   bool
>   depends on DRM
>  
> -# Separate option because drm_panel_orientation_quirks.c is shared with fbdev
> -config DRM_PANEL_ORIENTATION_QUIRKS
> - tristate
> -
>  config DRM_DP_AUX_CHARDEV
>   bool "DRM DP AUX Interface"
>   depends on DRM
> @@ -372,6 +368,10 @@ config DRM_SAVAGE
>  
>  endif # DRM_LEGACY
>  
> +# Separate option because drm_panel_orientation_quirks.c is shared with fbdev
> +config DRM_PANEL_ORIENTATION_QUIRKS
> + tristate
> +
>  config DRM_LIB_RANDOM
>   bool
>   default n
> -- 
> 2.14.3
> 
> ___
> 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 4/4] drm/vgem: flush page during page fault

[Daniel Vetter]

On Tue, Jan 16, 2018 at 04:35:59PM -0800, Gurchetan Singh wrote:
> This is required to use buffers allocated by vgem on AMD and ARM devices.
> We're experiencing a case where eviction of the cache races with userspace
> writes. To fix this, flush the cache after retrieving a page.
> 
> Signed-off-by: Gurchetan Singh 
> ---
>  drivers/gpu/drm/vgem/vgem_drv.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index 35bfdfb746a7..fb263969f02d 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -112,6 +112,7 @@ static int vgem_gem_fault(struct vm_fault *vmf)
>   break;
>   }
>  
> + drm_flush_pages(obj->base.dev->dev, , 1);

Uh ... what exactly are you doing?

Asking because the entire "who's responsible for coherency" story is
entirely undefined still when doing buffer sharing :-/ What is clear is
that currently vgem entirely ignores this (there's not
begin/end_cpu_access callback), mostly because the shared dma-buf support
in drm_prime.c also entirely ignores this. And doing a one-time only
flushing in your fault handler is definitely not going to fix this (at
least not if you do anything else than one-shot uploads).
-Daniel

>   }
>   return ret;
>  }
> -- 
> 2.13.5
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH 3/4] drm: add ARM flush implementations

[Daniel Vetter]

On Tue, Jan 16, 2018 at 04:35:58PM -0800, Gurchetan Singh wrote:
> The DMA API can be used to flush scatter gather tables and physical
> pages on ARM devices.
> 
> Signed-off-by: Gurchetan Singh 
> ---
>  drivers/gpu/drm/drm_cache.c | 17 +
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.c |  7 ++-
>  drivers/gpu/drm/tegra/gem.c |  6 +-
>  3 files changed, 20 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
> index 3d2bb9d71a60..98d6ebb40e96 100644
> --- a/drivers/gpu/drm/drm_cache.c
> +++ b/drivers/gpu/drm/drm_cache.c
> @@ -105,6 +105,18 @@ drm_flush_pages(struct device *dev, struct page *pages[],
>  (unsigned long)page_virtual + PAGE_SIZE);
>   kunmap_atomic(page_virtual);
>   }
> +#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64)
> + unsigned long i;
> + dma_addr_t dma_handle;
> +
> + if (!dev)
> + return;
> +
> + for (i = 0; i < num_pages; i++) {
> + dma_handle = phys_to_dma(drm->dev, page_to_phys(pages[i]));
> + dma_sync_single_for_device(dev, dma_handle, PAGE_SIZE,
> +DMA_TO_DEVICE);

Erm no. These functions here are super-low-level functions used by drivers
which know exactly what they're doing. Which is reimplementing half of the
dma api behind the dma api's back because the dma api just isn't quite
sufficient for implementing fast gpu drivers.

If all you end up doing is calling the dma api again, then pls just call
it directly.

And just to make it clear: I'd be perfectly fine with adding arm support
here, but then it'd need to directly flush cpu caches and bypass the dma
api. Otherwise this is pointless.
-Daniel

> + }
>  #else
>   pr_err("Architecture has no drm_cache.c support\n");
>   WARN_ON_ONCE(1);
> @@ -136,6 +148,11 @@ drm_flush_sg(struct device *dev, struct sg_table *st)
>  
>   if (wbinvd_on_all_cpus())
>   pr_err("Timed out waiting for cache flush\n");
> +#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64)
> + if (!dev)
> + return;
> +
> + dma_sync_sg_for_device(dev, st->sgl, st->nents, DMA_TO_DEVICE);
>  #else
>   pr_err("Architecture has no drm_cache.c support\n");
>   WARN_ON_ONCE(1);
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> index 8ac7eb25e46d..0157f90b5d10 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> @@ -14,6 +14,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -99,15 +100,11 @@ static int rockchip_gem_get_pages(struct 
> rockchip_gem_object *rk_obj)
>   /*
>* Fake up the SG table so that dma_sync_sg_for_device() can be used
>* to flush the pages associated with it.
> -  *
> -  * TODO: Replace this by drm_flush_sg() once it can be implemented
> -  * without relying on symbols that are not exported.
>*/
>   for_each_sg(rk_obj->sgt->sgl, s, rk_obj->sgt->nents, i)
>   sg_dma_address(s) = sg_phys(s);
>  
> - dma_sync_sg_for_device(drm->dev, rk_obj->sgt->sgl, rk_obj->sgt->nents,
> -DMA_TO_DEVICE);
> + drm_flush_sg(drm->dev, rk_obj->sgt);
>  
>   return 0;
>  
> diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
> index ab1e53d434e8..9945fd2f6bd6 100644
> --- a/drivers/gpu/drm/tegra/gem.c
> +++ b/drivers/gpu/drm/tegra/gem.c
> @@ -230,15 +230,11 @@ static int tegra_bo_get_pages(struct drm_device *drm, 
> struct tegra_bo *bo)
>   /*
>* Fake up the SG table so that dma_sync_sg_for_device() can be used
>* to flush the pages associated with it.
> -  *
> -  * TODO: Replace this by drm_clflash_sg() once it can be implemented
> -  * without relying on symbols that are not exported.
>*/
>   for_each_sg(bo->sgt->sgl, s, bo->sgt->nents, i)
>   sg_dma_address(s) = sg_phys(s);
>  
> - dma_sync_sg_for_device(drm->dev, bo->sgt->sgl, bo->sgt->nents,
> -DMA_TO_DEVICE);
> + drm_flush_sg(drm->dev, bo->sgt);
>  
>   return 0;
>  
> -- 
> 2.13.5
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: drm: fix vmwgfx boot warning WAS Re: [PATCH] [RESEND] vmwgfx: use monotonic event timestamps

[Thomas Hellstrom]

On 01/17/2018 07:33 AM, Thomas Hellstrom wrote:

Hi, Woody,

On 01/16/2018 10:39 PM, Woody Suwalski wrote:

Thomas, the same way my DRM patch has disappeared:
Date

Tue, 19 Dec 2017 11:50:57 -0800
From Sinclair Yeh <>
Subject Re: [PATCH v.2] 4.15 vmgfx boot warning




This looks okay to me.


Since this is a core DRM patch I think Sinclair was expecting it to be 
pulled in using the drm-misc tree. Did you get a comment from Daniel 
on this patch?


Thanks,
Thomas



Actually, checkpatch.pl complains about -ENOSYS, so I'm sending a pull 
request for v1 of this patch instead, to make everybody happy. I've 
rephrased the commit log somewhat. Hope that's OK.


/Thomas

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

Re: [PATCH] [RESEND] drm/gma500: initialize gma_clock_t structures

[Daniel Vetter]

On Tue, Jan 16, 2018 at 03:57:10PM +0100, Arnd Bergmann wrote:
> The two functions pass a partially initialized structure back to the
> caller after a memset() on the destination.
> 
> This is not entirely well-defined, most compilers are sensible enough
> to either keep the zero-initialization for the uninitialized members,
> but gcc-4.4 does not, and it warns about this:
> 
> drivers/gpu/drm/gma500/oaktrail_crtc.c: In function 'mrst_sdvo_find_best_pll':
> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.vco' may be used 
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.dot' may be used 
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.p2' may be used 
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.m2' may be used 
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.m1' may be used 
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c: In function 'mrst_lvds_find_best_pll':
> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.p' may be used 
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.vco' may be used 
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.p2' may be used 
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.m2' may be used 
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.m1' may be used 
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.n' may be used 
> uninitialized in this function
> 
> This adds an initialization at declaration time to avoid the warning
> and make it well-defined on all compiler versions.
> 
> Signed-off-by: Arnd Bergmann 

Applied to drm-misc-next-fixes for 4.16, thx for your patch. Aside: Still
don't want commit rights? :-)

Cheers, Daniel
> ---
> Originally submitted on Sep 15, 2017, but got no reply. Resending unchanged.
> ---
>  drivers/gpu/drm/gma500/oaktrail_crtc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/gma500/oaktrail_crtc.c 
> b/drivers/gpu/drm/gma500/oaktrail_crtc.c
> index 0fff269d3fe6..b49fe79c3f44 100644
> --- a/drivers/gpu/drm/gma500/oaktrail_crtc.c
> +++ b/drivers/gpu/drm/gma500/oaktrail_crtc.c
> @@ -134,7 +134,7 @@ static bool mrst_sdvo_find_best_pll(const struct 
> gma_limit_t *limit,
>   struct drm_crtc *crtc, int target,
>   int refclk, struct gma_clock_t *best_clock)
>  {
> - struct gma_clock_t clock;
> + struct gma_clock_t clock = {};
>   u32 target_vco, actual_freq;
>   s32 freq_error, min_error = 10;
>  
> @@ -191,7 +191,7 @@ static bool mrst_lvds_find_best_pll(const struct 
> gma_limit_t *limit,
>   struct drm_crtc *crtc, int target,
>   int refclk, struct gma_clock_t *best_clock)
>  {
> - struct gma_clock_t clock;
> + struct gma_clock_t clock = {};
>   int err = target;
>  
>   memset(best_clock, 0, sizeof(*best_clock));
> -- 
> 2.9.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH 6/7] drm/vmwgfx: Send the correct nonblock option for atomic_commit

[Daniel Vetter]

On Tue, Jan 16, 2018 at 02:34:33PM +0100, Thomas Hellstrom wrote:
> From: Deepak Rawat 
> 
> Page flip can be slow for vmwgfx in some cases, like need to do surface
> copy to different surface or waiting for IN_FENCE_FD. Enabling
> nonblocking commits for vmwgfx in case userspace request it.
> 
> Signed-off-by: Deepak Rawat 
> Reviewed-by: Sinclair Yeh 
> Signed-off-by: Thomas Hellstrom 

yay for the seemingly well-working generic nonblocking commit. I looked
through your other patches and didn't spot anything in need of rectifying,
so fwiw Acked-by: Daniel Vetter 

Cheers, Daniel
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 27 +--
>  1 file changed, 1 insertion(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index a7e7863..3f1ed51 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -1548,35 +1548,10 @@ vmw_kms_atomic_check_modeset(struct drm_device *dev,
>   return drm_atomic_helper_check(dev, state);
>  }
>  
> -
> -/**
> - * vmw_kms_atomic_commit - Perform an atomic state commit
> - *
> - * @dev: DRM device
> - * @state: the driver state object
> - * @nonblock: Whether nonblocking behaviour is requested
> - *
> - * This is a simple wrapper around drm_atomic_helper_commit() for
> - * us to clear the nonblocking value.
> - *
> - * Nonblocking commits currently cause synchronization issues
> - * for vmwgfx.
> - *
> - * RETURNS
> - * Zero for success or negative error code on failure.
> - */
> -int vmw_kms_atomic_commit(struct drm_device *dev,
> -   struct drm_atomic_state *state,
> -   bool nonblock)
> -{
> - return drm_atomic_helper_commit(dev, state, false);
> -}
> -
> -
>  static const struct drm_mode_config_funcs vmw_kms_funcs = {
>   .fb_create = vmw_kms_fb_create,
>   .atomic_check = vmw_kms_atomic_check_modeset,
> - .atomic_commit = vmw_kms_atomic_commit,
> + .atomic_commit = drm_atomic_helper_commit,
>  };
>  
>  static int vmw_kms_generic_present(struct vmw_private *dev_priv,
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH] [RESEND] drm/gma500: initialize gma_clock_t structures

[Patrik Jakobsson]

On Tue, Jan 16, 2018 at 3:57 PM, Arnd Bergmann  wrote:
> The two functions pass a partially initialized structure back to the
> caller after a memset() on the destination.
>
> This is not entirely well-defined, most compilers are sensible enough
> to either keep the zero-initialization for the uninitialized members,
> but gcc-4.4 does not, and it warns about this:
>
> drivers/gpu/drm/gma500/oaktrail_crtc.c: In function 'mrst_sdvo_find_best_pll':
> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.vco' may be used 
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.dot' may be used 
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.p2' may be used 
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.m2' may be used 
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.m1' may be used 
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c: In function 'mrst_lvds_find_best_pll':
> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.p' may be used 
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.vco' may be used 
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.p2' may be used 
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.m2' may be used 
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.m1' may be used 
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.n' may be used 
> uninitialized in this function
>
> This adds an initialization at declaration time to avoid the warning
> and make it well-defined on all compiler versions.
>
> Signed-off-by: Arnd Bergmann 

Dave or Daniel, I'm on sick leave and will be for some time to come.
Can one of you pick up this patch? Thanks.

Reviewed-by: Patrik Jakobsson 

> ---
> Originally submitted on Sep 15, 2017, but got no reply. Resending unchanged.
> ---
>  drivers/gpu/drm/gma500/oaktrail_crtc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/oaktrail_crtc.c 
> b/drivers/gpu/drm/gma500/oaktrail_crtc.c
> index 0fff269d3fe6..b49fe79c3f44 100644
> --- a/drivers/gpu/drm/gma500/oaktrail_crtc.c
> +++ b/drivers/gpu/drm/gma500/oaktrail_crtc.c
> @@ -134,7 +134,7 @@ static bool mrst_sdvo_find_best_pll(const struct 
> gma_limit_t *limit,
> struct drm_crtc *crtc, int target,
> int refclk, struct gma_clock_t 
> *best_clock)
>  {
> -   struct gma_clock_t clock;
> +   struct gma_clock_t clock = {};
> u32 target_vco, actual_freq;
> s32 freq_error, min_error = 10;
>
> @@ -191,7 +191,7 @@ static bool mrst_lvds_find_best_pll(const struct 
> gma_limit_t *limit,
> struct drm_crtc *crtc, int target,
> int refclk, struct gma_clock_t 
> *best_clock)
>  {
> -   struct gma_clock_t clock;
> +   struct gma_clock_t clock = {};
> int err = target;
>
> memset(best_clock, 0, sizeof(*best_clock));
> --
> 2.9.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/vmwgfx: Fix a boot time warning

[Thomas Hellstrom]

From: Woody Suwalski 

The 4.15 vmwgfx driver shows a warning during boot.
It is caused by a mismatch between the result of vmw_enable_vblank()
and what the drm_atomic_helper expects.

Signed-off by: Woody Suwalski 
Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 641294a..fcd5814 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1863,7 +1863,7 @@ u32 vmw_get_vblank_counter(struct drm_device *dev, 
unsigned int pipe)
  */
 int vmw_enable_vblank(struct drm_device *dev, unsigned int pipe)
 {
-   return -ENOSYS;
+   return -EINVAL;
 }
 
 /**
-- 
2.7.4

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

Re: [PATCH libdrm] drm: fix return value

[Daniel Vetter]

On Tue, Jan 16, 2018 at 02:01:40PM +, Zhou, David(ChunMing) wrote:
> Can your guys help me push it and last vamgr patches to upstream?
> My new count request for libdrm still is under pending.

Or hand out commmit rights? That's easier long-term imo ...
-Daniel

> 
> Thanks,
> David Zhou
> 
> 
> 发自坚果 Pro
> 
> Christian K鰊ig  于 2018年1月16日 下午4:56写道：
> 
> Apart from that a good catch and Reviewed-by: Christian König
> .
> 
> Regards,
> Christian.
> 
> Am 16.01.2018 um 09:49 schrieb Michel Dänzer:
> > Moving from the amd-gfx list to dri-devel, since this isn't amdgpu specific.
> >
> >
> > On 2018-01-16 03:54 AM, Chunming Zhou wrote:
> >> otherwise -ETIME is missed.
> >>
> >> Change-Id: Ic5580a74d8027cc468c6135f8cf2f81817993423
> >> Signed-off-by: Chunming Zhou 
> >> ---
> >>   xf86drm.c | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/xf86drm.c b/xf86drm.c
> >> index 8a327170..3881bd9f 100644
> >> --- a/xf86drm.c
> >> +++ b/xf86drm.c
> >> @@ -4241,7 +4241,7 @@ int drmSyncobjWait(int fd, uint32_t *handles, 
> >> unsigned num_handles,
> >>
> >>   ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_WAIT, );
> >>   if (ret < 0)
> >> -return ret;
> >> +return -errno;
> >>
> >>   if (first_signaled)
> >>   *first_signaled = args.first_signaled;
> >>
> >
> 

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


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