Re: [PATCH v3 6/8] drm: Expose modes with aspect ratio, only if requested

2018-01-31 Thread Nautiyal, Ankit K

Hi Ville,

Thanks for the comments and suggestions.

Please find my response inline:


On 1/30/2018 12:28 AM, Ville Syrjälä wrote:

On Fri, Jan 12, 2018 at 11:51:34AM +0530, Nautiyal, Ankit K wrote:

From: Ankit Nautiyal 

We parse the EDID and add all the modes in the connector's
modelist. This adds CEA modes with aspect ratio information
too, regadless of if user space requested this information or
not.

This patch prunes the modes with aspect-ratio information, from
a connector's modelist, if the user-space has not set the aspect
ratio DRM client cap.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Cc: Jose Abreu 

Signed-off-by: Ankit Nautiyal 

V3: As suggested by Ville, modified the mechanism of pruning of
modes with aspect-ratio, if the aspect-ratio is not supported.
Instead of straight away pruning such a mode, the mode is
retained with aspect-ratio bits set to zero, provided it is
unique.
---
  drivers/gpu/drm/drm_connector.c | 31 +++
  1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b85a774..d968ec3 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1502,7 +1502,8 @@ static struct drm_encoder 
*drm_connector_get_encoder(struct drm_connector *conne
return connector->encoder;
  }
  
-static bool drm_mode_expose_to_userspace(const struct drm_display_mode *mode,

+static bool drm_mode_expose_to_userspace(const struct drm_display_mode 
*last_mode,
+const struct drm_display_mode *mode,
 const struct drm_file *file_priv)
  {
/*
@@ -1511,6 +1512,18 @@ static bool drm_mode_expose_to_userspace(const struct 
drm_display_mode *mode,
 */
if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode))
return false;
+   /*
+* If user-space hasn't configured the driver to expose the modes
+* with aspect-ratio, don't expose them.
+*/
+   if (!file_priv->aspect_ratio_allowed &&
+   mode->picture_aspect_ratio != HDMI_PICTURE_ASPECT_NONE &&
+   drm_mode_match(mode, last_mode,
+  DRM_MODE_MATCH_TIMINGS |
+  DRM_MODE_MATCH_CLOCK |
+  DRM_MODE_MATCH_FLAGS |
+  DRM_MODE_MATCH_3D_FLAGS))
+   return false;
  
  	return true;

  }
@@ -1522,6 +1535,7 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
struct drm_connector *connector;
struct drm_encoder *encoder;
struct drm_display_mode *mode;
+   struct drm_display_mode last_valid_mode;

A pointer should be sufficient.


Thanks for pointing that out, will just save the address of last valid mode.




int mode_count = 0;
int encoders_count = 0;
int ret = 0;
@@ -1577,9 +1591,12 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
out_resp->connection = connector->status;
  
  	/* delayed so we get modes regardless of pre-fill_modes state */

+   memset(&last_valid_mode, 0, sizeof(struct drm_display_mode));
list_for_each_entry(mode, &connector->modes, head)
-   if (drm_mode_expose_to_userspace(mode, file_priv))
+   if (drm_mode_expose_to_userspace(&last_valid_mode, mode, 
file_priv)) {
mode_count++;
+   drm_mode_copy(&last_valid_mode, mode);
+   }
  
  	/*

 * This ioctl is called twice, once to determine how much space is
@@ -1588,10 +1605,16 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
if ((out_resp->count_modes >= mode_count) && mode_count) {
copied = 0;
mode_ptr = (struct drm_mode_modeinfo __user *)(unsigned 
long)out_resp->modes_ptr;
+   memset(&last_valid_mode, 0, sizeof(struct drm_display_mode));
list_for_each_entry(mode, &connector->modes, head) {
-   if (!drm_mode_expose_to_userspace(mode, file_priv))
+   if (!drm_mode_expose_to_userspace(&last_valid_mode,
+ mode,
+ file_priv))
continue;
-
+   if (!file_priv->aspect_ratio_allowed)
+   mode->picture_aspect_ratio =
+   HDMI_PICTURE_ASPECT_NONE;

Here you're clobbering the internal mode structure. That's not
acceptable.


I assumed, that the usermode, and the internal mode structure both 
should have aspect ratio

info as none, if the user does not support aspect ratio.
If that's not required, I can set the aspect ratio flags in usermode 
after the call

to drm_mode_convert_to_umode().

-Ankit





+   drm_mode_copy(&last_valid_mode, mode);
  

[PATCH v2] drm/stm: check pitch and size calculations even if !CONFIG_MMU

2018-01-31 Thread Benjamin Gaignard
In all cases we have to check pitch and size calculations to speed up
data transfer.

Fixes: 21f815bf773c ("drm/stm: drv: Improve data transfers")

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/stm/drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
index 8bc7e8418b8d..9ab00a87f7cc 100644
--- a/drivers/gpu/drm/stm/drv.c
+++ b/drivers/gpu/drm/stm/drv.c
@@ -35,7 +35,6 @@ static int stm_gem_cma_dumb_create(struct drm_file *file,
   struct drm_device *dev,
   struct drm_mode_create_dumb *args)
 {
-#ifdef CONFIG_MMU
unsigned int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
 
/*
@@ -44,7 +43,6 @@ static int stm_gem_cma_dumb_create(struct drm_file *file,
 */
args->pitch = roundup(min_pitch, 128);
args->height = roundup(args->height, 4);
-#endif
 
return drm_gem_cma_dumb_create_internal(file, dev, args);
 }
-- 
2.15.0

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


Re: [PATCH] drm: Print the pid when debug logging an ioctl error.

2018-01-31 Thread Daniel Vetter
On Tue, Jan 30, 2018 at 01:56:43PM -0800, Eric Anholt wrote:
> When we debug print what ioctl we're calling into, we include the pid.
> If you have multiple processes rendering simulataneously, the error
> return also needs the pid so you can see which of the ioctl calls was
> the one to fail.
> 
> Signed-off-by: Eric Anholt 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_ioctl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index a9ae6dd2d593..38c302607738 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -842,7 +842,7 @@ long drm_ioctl(struct file *filp,
>   if (kdata != stack_kdata)
>   kfree(kdata);
>   if (retcode)
> - DRM_DEBUG("ret = %d\n", retcode);
> + DRM_DEBUG("pid=%d, ret = %d\n", task_pid_nr(current), retcode);
>   return retcode;
>  }
>  EXPORT_SYMBOL(drm_ioctl);
> -- 
> 2.15.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] mm/swap: add function get_total_swap_pages to expose total_swap_pages

2018-01-31 Thread He, Roger
I think this patch isn't need at all. You can directly read 
total_swap_pages variable in TTM.

Because the variable is not exported by EXPORT_SYMBOL_GPL. So direct using will 
result in:
"WARNING: "total_swap_pages" [drivers/gpu/drm/ttm/ttm.ko] undefined!".

Thanks
Roger(Hongbo.He)
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Chunming Zhou
Sent: Wednesday, January 31, 2018 3:15 PM
To: He, Roger ; dri-devel@lists.freedesktop.org
Cc: linux...@kvack.org; linux-ker...@vger.kernel.org; Koenig, Christian 

Subject: Re: [PATCH] mm/swap: add function get_total_swap_pages to expose 
total_swap_pages

Hi Roger,

I think this patch isn't need at all. You can directly read total_swap_pages 
variable in TTM. See the comment:

/* protected with swap_lock. reading in vm_swap_full() doesn't need lock */ 
long total_swap_pages;

there are many places using it directly, you just couldn't change its value. 
Reading it doesn't need lock.


Regards,

David Zhou


On 2018年01月29日 16:29, Roger He wrote:
> ttm module needs it to determine its internal parameter setting.
>
> Signed-off-by: Roger He 
> ---
>   include/linux/swap.h |  6 ++
>   mm/swapfile.c| 15 +++
>   2 files changed, 21 insertions(+)
>
> diff --git a/include/linux/swap.h b/include/linux/swap.h
> index c2b8128..708d66f 100644
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -484,6 +484,7 @@ extern int try_to_free_swap(struct page *);
>   struct backing_dev_info;
>   extern int init_swap_address_space(unsigned int type, unsigned long 
> nr_pages);
>   extern void exit_swap_address_space(unsigned int type);
> +extern long get_total_swap_pages(void);
>   
>   #else /* CONFIG_SWAP */
>   
> @@ -516,6 +517,11 @@ static inline void show_swap_cache_info(void)
>   {
>   }
>   
> +long get_total_swap_pages(void)
> +{
> + return 0;
> +}
> +
>   #define free_swap_and_cache(e) ({(is_migration_entry(e) || 
> is_device_private_entry(e));})
>   #define swapcache_prepare(e) ({(is_migration_entry(e) || 
> is_device_private_entry(e));})
>   
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> index 3074b02..a0062eb 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -98,6 +98,21 @@ static atomic_t proc_poll_event = ATOMIC_INIT(0);
>   
>   atomic_t nr_rotate_swap = ATOMIC_INIT(0);
>   
> +/*
> + * expose this value for others use
> + */
> +long get_total_swap_pages(void)
> +{
> + long ret;
> +
> + spin_lock(&swap_lock);
> + ret = total_swap_pages;
> + spin_unlock(&swap_lock);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(get_total_swap_pages);
> +
>   static inline unsigned char swap_count(unsigned char ent)
>   {
>   return ent & ~SWAP_HAS_CACHE;   /* may include SWAP_HAS_CONT flag */

___
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

2018-01-31 Thread Daniel Vetter
On Wed, Jan 31, 2018 at 10:49:47AM +0800, Chunming Zhou wrote:
> 
> 
> On 2018年01月17日 17:31, Daniel Vetter wrote:
> > 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.
> Hi Daniel,
> 
> My account requesting still is under pending, Could you help it?
> https://bugs.freedesktop.org/show_bug.cgi?id=104631

Looks all ready for fd.o admins to take action. Perhaps ping them on
#freedesktop irc channel? I'm not an admin myself.
-Daniel


> 
> 
> Thanks in advance,
> David Zhou
> > -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, &args);
> > > > > > > > >     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] drm: rcar-du: Remove zpos field from rcar_du_vsp_plane_state structure

2018-01-31 Thread Daniel Vetter
On Wed, Jan 17, 2018 at 08:44:29PM +0200, Laurent Pinchart wrote:
> Since commit 2fc4d838aaf2 ("drm: rcar: use generic code for managing
> zpos plane property") the rcar-du driver stores the plane zpos in the
> drm_plane_state structure. The commit however forgot to remove the zpos
> field from the rcar_du_vsp_plane_state structure. Remove it.
> 
> Fixes: 2fc4d838aaf2 ("drm: rcar: use generic code for managing zpos plane 
> property")
> Signed-off-by: Laurent Pinchart 

More Cc: helps sometimes, e.g. dim fixes autoadds all you ever want :-)

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h 
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> index f876c512163c..4c5d7bbce6aa 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> @@ -45,7 +45,6 @@ static inline struct rcar_du_vsp_plane 
> *to_rcar_vsp_plane(struct drm_plane *p)
>   * @format: information about the pixel format used by the plane
>   * @sg_tables: scatter-gather tables for the frame buffer memory
>   * @alpha: value of the plane alpha property
> - * @zpos: value of the plane zpos property
>   */
>  struct rcar_du_vsp_plane_state {
>   struct drm_plane_state state;
> @@ -54,7 +53,6 @@ struct rcar_du_vsp_plane_state {
>   struct sg_table sg_tables[3];
>  
>   unsigned int alpha;
> - unsigned int zpos;
>  };
>  
>  static inline struct rcar_du_vsp_plane_state *
> -- 
> 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] mm/swap: add function get_total_swap_pages to expose total_swap_pages

2018-01-31 Thread Christian König
Yeah, indeed. But what we could do is to rely on a fixed limit like the 
Intel driver does and I suggested before.


E.g. don't copy anything into a shmemfile when there is only x MB of 
swap space left.


Roger can you test that approach once more with your fix for the OOM 
issues in the page fault handler?


Thanks,
Christian.

Am 31.01.2018 um 09:08 schrieb He, Roger:

I think this patch isn't need at all. You can directly read 
total_swap_pages variable in TTM.

Because the variable is not exported by EXPORT_SYMBOL_GPL. So direct using will 
result in:
"WARNING: "total_swap_pages" [drivers/gpu/drm/ttm/ttm.ko] undefined!".

Thanks
Roger(Hongbo.He)
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Chunming Zhou
Sent: Wednesday, January 31, 2018 3:15 PM
To: He, Roger ; dri-devel@lists.freedesktop.org
Cc: linux...@kvack.org; linux-ker...@vger.kernel.org; Koenig, Christian 

Subject: Re: [PATCH] mm/swap: add function get_total_swap_pages to expose 
total_swap_pages

Hi Roger,

I think this patch isn't need at all. You can directly read total_swap_pages 
variable in TTM. See the comment:

/* protected with swap_lock. reading in vm_swap_full() doesn't need lock */ 
long total_swap_pages;

there are many places using it directly, you just couldn't change its value. 
Reading it doesn't need lock.


Regards,

David Zhou


On 2018年01月29日 16:29, Roger He wrote:

ttm module needs it to determine its internal parameter setting.

Signed-off-by: Roger He 
---
   include/linux/swap.h |  6 ++
   mm/swapfile.c| 15 +++
   2 files changed, 21 insertions(+)

diff --git a/include/linux/swap.h b/include/linux/swap.h
index c2b8128..708d66f 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -484,6 +484,7 @@ extern int try_to_free_swap(struct page *);
   struct backing_dev_info;
   extern int init_swap_address_space(unsigned int type, unsigned long 
nr_pages);
   extern void exit_swap_address_space(unsigned int type);
+extern long get_total_swap_pages(void);
   
   #else /* CONFIG_SWAP */
   
@@ -516,6 +517,11 @@ static inline void show_swap_cache_info(void)

   {
   }
   
+long get_total_swap_pages(void)

+{
+   return 0;
+}
+
   #define free_swap_and_cache(e) ({(is_migration_entry(e) || 
is_device_private_entry(e));})
   #define swapcache_prepare(e) ({(is_migration_entry(e) || 
is_device_private_entry(e));})
   
diff --git a/mm/swapfile.c b/mm/swapfile.c

index 3074b02..a0062eb 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -98,6 +98,21 @@ static atomic_t proc_poll_event = ATOMIC_INIT(0);
   
   atomic_t nr_rotate_swap = ATOMIC_INIT(0);
   
+/*

+ * expose this value for others use
+ */
+long get_total_swap_pages(void)
+{
+   long ret;
+
+   spin_lock(&swap_lock);
+   ret = total_swap_pages;
+   spin_unlock(&swap_lock);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(get_total_swap_pages);
+
   static inline unsigned char swap_count(unsigned char ent)
   {
return ent & ~SWAP_HAS_CACHE;   /* may include SWAP_HAS_CONT flag */

___
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] drm: Check for lessee in DROP_MASTER ioctl

2018-01-31 Thread Daniel Vetter
On Tue, Jan 30, 2018 at 11:55:01AM -0800, Keith Packard wrote:
> Daniel Vetter  writes:
> 
> > On Thu, Jan 18, 2018 at 05:51:59PM -0800, Keith Packard wrote:
> >> Don't let a lessee control what the current DRM master is set to;
> >> that's the job of the "real" master. Otherwise, the lessee would
> >> disable all access to master operations for the owner and all lessees
> >> under it.
> >> 
> >> This matches the same check made in the SET_MASTER ioctl.
> >> 
> >> Signed-off-by: Keith Packard 
> >
> > Similar check for setmaster already exists, so looks all good. Do we have
> > an igt for all this? Iirc there was one floating around, but no idea
> > what's the status. Might also be good to resubmit them so i915 CI can run
> > the tests (now that the code has landed).
> 
> I've got IGT tests for leasing which have been posted to dri-devel but I
> don't think they've been reviewed. Looks like they could use some more
> test cases; I didn't catch this one until I was playing with my 'xlease'
> hack, which runs the X server on a leased FD.

Can you pls resubmit (preferrably with the new nasty tests added) to
igt-...@lists.freedesktop.org (we have a new m-l for igt stuff)?

> > On the patch itself, minus lack of testcases:
> >
> > Reviewed-by: Daniel Vetter 
> 
> Thanks!

Realized I should better apply this, and done :-)
-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 v3 33/43] drm/panel: simple: Change mode for Sharp lq123p1jx31

2018-01-31 Thread Thierry Escande
From: Sean Paul 

Change the mode for Sharp lq123p1jx31 panel to something more
rockchip-friendly such that we can use the fixed PLLs to
generate the pixel clock

Cc: Chris Zhong 
Cc: Stéphane Marchesin 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/panel/panel-simple.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 5591984a392b..a4a6ea3ca0e6 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1742,17 +1742,18 @@ static const struct panel_desc sharp_lq101k1ly04 = {
 };
 
 static const struct drm_display_mode sharp_lq123p1jx31_mode = {
-   .clock = 252750,
+   .clock = 27,
.hdisplay = 2400,
.hsync_start = 2400 + 48,
.hsync_end = 2400 + 48 + 32,
-   .htotal = 2400 + 48 + 32 + 80,
+   .htotal = 2400 + 48 + 32 + 139,
.vdisplay = 1600,
.vsync_start = 1600 + 3,
.vsync_end = 1600 + 3 + 10,
-   .vtotal = 1600 + 3 + 10 + 33,
+   .vtotal = 1600 + 3 + 10 + 84,
.vrefresh = 60,
.flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+   .type = DRM_MODE_TYPE_PREFERRED | DRM_MODE_TYPE_DRIVER,
 };
 
 static const struct panel_desc sharp_lq123p1jx31 = {
-- 
2.14.1

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


Re: [PATCH v3] Fix loading of module radeonfb on PowerMac

2018-01-31 Thread Mathieu Malaterre
Bartlomiej,

On Wed, Jan 3, 2018 at 3:47 PM, Bartlomiej Zolnierkiewicz
 wrote:
>
> On Thursday, December 21, 2017 11:07:56 PM Mathieu Malaterre wrote:
>> When the linux kernel is build with (typical kernel ship with Debian
>> installer):
>>
>> CONFIG_FB_OF=y
>> CONFIG_VT_HW_CONSOLE_BINDING=y
>> CONFIG_FB_RADEON=m
>>
>> The offb driver takes precedence over module radeonfb. It is then
>> impossible to load the module, error reported is:
>>
>> [   96.551486] radeonfb :00:10.0: enabling device (0006 -> 0007)
>> [   96.551526] radeonfb :00:10.0: BAR 0: can't reserve [mem 
>> 0x9800-0x9fff pref]
>> [   96.551531] radeonfb (:00:10.0): cannot request region 0.
>> [   96.551545] radeonfb: probe of :00:10.0 failed with error -16
>>
>> This patch reproduce the behavior of the module radeon, so as to make it
>> possible to load radeonfb when offb is first loaded.
>>
>> It should be noticed that `offb_destroy` is never called which explain the
>> need to skip error detection on the radeon side.
>
> This still needs to be explained more, from my last mail:
>
> "The last put_fb_info() on fb_info should call ->fb_destroy
> (offb_destroy in our case) and remove_conflicting_framebuffers()
> is calling put_fb_info() so there is some extra reference on
> fb_info somewhere preventing it from going away.
>
> Please look into fixing this."

I am not familiar with the fb stuff internals but here is what I see:

# modprobe radeonfb

leads to:

[   52.058546] bus: 'pci': add driver radeonfb
[   52.058588] bus: 'pci': driver_probe_device: matched device
:00:10.0 with driver radeonfb
[   52.058595] bus: 'pci': really_probe: probing driver radeonfb with
device :00:10.0
[   52.058608] devices_kset: Moving :00:10.0 to end of list
[   52.058613] radeonfb_pci_register BEGIN
[   52.058634] radeonfb :00:10.0: enabling device (0006 -> 0007)

[   52.058666] checking generic (9c008000 96000) vs hw (9800 800)
[   52.058667] fb: switching to radeonfb from OFfb ATY,RockHo
[   52.058844] Console: switching to colour dummy device 80x25
[   52.058860] device: 'fb0': device_unregister
[   52.058956] PM: Removing info for No Bus:fb0
[   52.059014] device: 'fb0': device_create_release


[   52.059048] device: 'vtcon1': device_unregister
[   52.059076] PM: Removing info for No Bus:vtcon1
[   52.059091] device: 'vtcon1': device_create_release
[   52.059107] radeonfb :00:10.0: BAR 0: can't reserve [mem
0x9800-0x9fff pref]
[   52.256151] aper_base: 9800 MC_FB_LOC to: 9bff9800, MC_AGP_LOC
to: a000
[   52.256157] radeonfb (:00:10.0): Found 32768k of DDR 64 bits
wide videoram

I can confirm that offb_destroy is never called (not sure exactly
why), but in any case the call to radeon_kick_out_firmware_fb happen
much earlier, at least before the put_fb_info.

Could you describe a bit more the chain of calls you were thinking of ?

>> Signed-off-by: Mathieu Malaterre 
>> Link: https://bugs.debian.org/826629#57
>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=119741
>> Suggested-by: Lennart Sorensen 
>> ---
>> v2: Only fails when CONFIG_PCC is not set
>> v3: Only fails when CONFIG_FB_OF is not set, CONFIG_PCC was too broad. Since 
>> the conflicts in region is due to OFfb explicitly refers to it.
>
> It seems that there may still be configurations when this is
> incorrect -> when offb drives primary (non-radeon) card and radeonfb
> drives secondary (radeon) card..
>
>>  drivers/video/fbdev/aty/radeon_base.c | 26 ++
>>  1 file changed, 26 insertions(+)
>>
>> diff --git a/drivers/video/fbdev/aty/radeon_base.c 
>> b/drivers/video/fbdev/aty/radeon_base.c
>> index 4d77daeecf99..221879196531 100644
>> --- a/drivers/video/fbdev/aty/radeon_base.c
>> +++ b/drivers/video/fbdev/aty/radeon_base.c
>> @@ -2259,6 +2259,22 @@ static const struct bin_attribute edid2_attr = {
>>   .read   = radeon_show_edid2,
>>  };
>>
>> +static int radeon_kick_out_firmware_fb(struct pci_dev *pdev)
>> +{
>> + struct apertures_struct *ap;
>> +
>> + ap = alloc_apertures(1);
>> + if (!ap)
>> + return -ENOMEM;
>> +
>> + ap->ranges[0].base = pci_resource_start(pdev, 0);
>> + ap->ranges[0].size = pci_resource_len(pdev, 0);
>> +
>> + remove_conflicting_framebuffers(ap, KBUILD_MODNAME, false);
>> + kfree(ap);
>> +
>> + return 0;
>> +}
>>
>>  static int radeonfb_pci_register(struct pci_dev *pdev,
>>const struct pci_device_id *ent)
>> @@ -2312,19 +2328,27 @@ static int radeonfb_pci_register(struct pci_dev 
>> *pdev,
>>   rinfo->fb_base_phys = pci_resource_start (pdev, 0);
>>   rinfo->mmio_base_phys = pci_resource_start (pdev, 2);
>>
>> + ret = radeon_kick_out_firmware_fb(pdev);
>> + if (ret)
>> + return ret;
>> +
>>   /* request the mem regions */
>>   ret = pci_request_region(pdev, 0, "radeonfb framebuffer");
>>   if (ret < 0) {
>> +#ifndef CONFIG_FB_OF
>>   printk( KERN_ERR "r

[PATCH v3 32/43] drm/bridge: analogix_dp: Properly disable aux chan retries on rockchip

2018-01-31 Thread Thierry Escande
From: Douglas Anderson 

The comments in analogix_dp_init_aux() claim that we're disabling aux
channel retries, but then right below it for Rockchip it sets them to
3.  If we actually need 3 retries for Rockchip then we could adjust
the comment, but it seems more likely that we want the same retry
behavior across all platforms.

Cc: Stéphane Marchesin 
Cc: 征增 王 
Signed-off-by: Douglas Anderson 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 58e8a28e99aa..a5f2763d72e4 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -481,15 +481,16 @@ void analogix_dp_init_aux(struct analogix_dp_device *dp)
 
analogix_dp_reset_aux(dp);
 
-   /* Disable AUX transaction H/W retry */
+   /* AUX_BIT_PERIOD_EXPECTED_DELAY doesn't apply to Rockchip IP */
if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
-   reg = AUX_BIT_PERIOD_EXPECTED_DELAY(0) |
- AUX_HW_RETRY_COUNT_SEL(3) |
- AUX_HW_RETRY_INTERVAL_600_MICROSECONDS;
+   reg = 0;
else
-   reg = AUX_BIT_PERIOD_EXPECTED_DELAY(3) |
- AUX_HW_RETRY_COUNT_SEL(0) |
- AUX_HW_RETRY_INTERVAL_600_MICROSECONDS;
+   reg = AUX_BIT_PERIOD_EXPECTED_DELAY(3);
+
+   /* Disable AUX transaction H/W retry */
+   reg |= AUX_HW_RETRY_COUNT_SEL(0) |
+  AUX_HW_RETRY_INTERVAL_600_MICROSECONDS;
+
writel(reg, dp->reg_base + ANALOGIX_DP_AUX_HW_RETRY_CTL);
 
/* Receive AUX Channel DEFER commands equal to DEFFER_COUNT*64 */
-- 
2.14.1

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


[PATCH v3 14/43] drm/bridge: analogix_dp: Check AUX_EN status when doing AUX transfer

2018-01-31 Thread Thierry Escande
From: Lin Huang 

We should check AUX_EN bit to confirm the AUX CH operation is completed.

Cc: Stéphane Marchesin 
Signed-off-by: Lin Huang 
Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 25 +--
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 9df2f3ef000c..e78c861b9e06 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -1073,9 +1073,9 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
 {
u32 reg;
u8 *buffer = msg->buffer;
-   int timeout_loop = 0;
unsigned int i;
int num_transferred = 0;
+   int ret;
 
/* Buffer size of AUX CH is 16 bytes */
if (WARN_ON(msg->size > 16))
@@ -1139,17 +1139,20 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
 
writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
 
-   /* Is AUX CH command reply received? */
+   ret = readx_poll_timeout(readl, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2,
+reg, !(reg & AUX_EN), 25, 500 * 1000);
+   if (ret) {
+   dev_err(dp->dev, "AUX CH enable timeout!\n");
+   return -ETIMEDOUT;
+   }
+
/* TODO: Wait for an interrupt instead of looping? */
-   reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
-   while (!(reg & RPLY_RECEIV)) {
-   timeout_loop++;
-   if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
-   dev_err(dp->dev, "AUX CH command reply failed!\n");
-   return -ETIMEDOUT;
-   }
-   reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
-   usleep_range(10, 11);
+   /* Is AUX CH command reply received? */
+   ret = readx_poll_timeout(readl, dp->reg_base + ANALOGIX_DP_INT_STA,
+reg, reg & RPLY_RECEIV, 10, 20 * 1000);
+   if (ret) {
+   dev_err(dp->dev, "AUX CH cmd reply timeout!\n");
+   return -ETIMEDOUT;
}
 
/* Clear interrupt source for AUX CH command reply */
-- 
2.14.1

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


[PATCH v2] drm/edid: use true and false for boolean values

2018-01-31 Thread Gustavo A. R. Silva
Assign true or false to boolean variables instead of an integer value.

This issue was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
Changes in v2:
 - Use true for boolean value in add_detailed_mode as suggested by Daniel
   Vetter.
 - Update subject.

 drivers/gpu/drm/drm_edid.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ddd5379..b1cb262 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2767,7 +2767,7 @@ do_detailed_mode(struct detailed_timing *timing, void *c)
 
drm_mode_probed_add(closure->connector, newmode);
closure->modes++;
-   closure->preferred = 0;
+   closure->preferred = false;
}
 }
 
@@ -2784,7 +2784,7 @@ add_detailed_modes(struct drm_connector *connector, 
struct edid *edid,
struct detailed_mode_closure closure = {
.connector = connector,
.edid = edid,
-   .preferred = 1,
+   .preferred = true,
.quirks = quirks,
};
 
-- 
2.7.4

___
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

2018-01-31 Thread Alexey Brodkin
Hi Daniel,

On Tue, 2018-01-30 at 10:15 +0100, Daniel Vetter wrote:
> On Wed, Jan 17, 2018 at 03:17:55PM +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. 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 
> 
> I assumed this is ok and applied it to drm-misc-next.
> -Daniel

Not sure but I still cannot see anything arcpgu-related here
https://cgit.freedesktop.org/drm-misc/log/

Am I looking at the wrong place?

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

2018-01-31 Thread Alexey Brodkin
Hi Daniel,

On Tue, 2018-01-30 at 18:07 +0100, Daniel Vetter wrote:
> On Tue, Jan 30, 2018 at 5:44 PM, Alexey Brodkin
>  wrote:
> > Hi Daniel,
> > 
> > On Tue, 2018-01-30 at 10:15 +0100, Daniel Vetter wrote:
> > > On Wed, Jan 17, 2018 at 03:17:55PM +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. 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 
> > > 
> > > I assumed this is ok and applied it to drm-misc-next.
> > > -Daniel
> > 
> > Not sure but I still cannot see anything arcpgu-related here
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__cgit.freedesktop.org_drm-2Dmisc_log_&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656e
> > ViXO7breS55ytWkhpk5R81I&m=ZsFKo3w8gSf8Ul8_sl5RG8BACV1SwqgPV3wf6m4YtVM&s=f9P3-3L_o6CCd_1IQjGPNtAPAOtlO8rj2D2X8T5v_xw&e=
> > 
> > Am I looking at the wrong place?
> 
> Build test script got stuck, pushed for real now.

Thanks!

Gave it a try and it works perfectly fine.
If it still makes any sense...

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


[PATCH v3 06/43] drm/rockchip: Don't use atomic constructs for psr

2018-01-31 Thread Thierry Escande
From: Sean Paul 

Instead of using timer and spinlocks, use delayed_work and
mutexes for rockchip psr. This allows us to make blocking
calls when enabling/disabling psr (which is sort of important
given we're talking over dpcd to the display).

Cc: Caesar Wang 
Cc: 征增 王 
Cc: Stéphane Marchesin 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 68 -
 3 files changed, 31 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 88084ca15115..0609113d6a71 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -134,7 +134,7 @@ static int rockchip_drm_bind(struct device *dev)
drm_dev->dev_private = private;
 
INIT_LIST_HEAD(&private->psr_list);
-   spin_lock_init(&private->psr_list_lock);
+   mutex_init(&private->psr_list_lock);
 
ret = rockchip_drm_init_iommu(drm_dev);
if (ret)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 498dfbc52cec..9c064a40458b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -55,7 +55,7 @@ struct rockchip_drm_private {
struct mutex mm_lock;
struct drm_mm mm;
struct list_head psr_list;
-   spinlock_t psr_list_lock;
+   struct mutex psr_list_lock;
 };
 
 int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index b3fb99c5b1fd..b339ca943139 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -18,7 +18,7 @@
 #include "rockchip_drm_drv.h"
 #include "rockchip_drm_psr.h"
 
-#define PSR_FLUSH_TIMEOUT  msecs_to_jiffies(100)
+#define PSR_FLUSH_TIMEOUT_MS   100
 
 enum psr_state {
PSR_FLUSH,
@@ -30,11 +30,11 @@ struct psr_drv {
struct list_headlist;
struct drm_encoder  *encoder;
 
-   spinlock_t  lock;
+   struct mutexlock;
boolactive;
enum psr_state  state;
 
-   struct timer_list   flush_timer;
+   struct delayed_work flush_work;
 
void (*set)(struct drm_encoder *encoder, bool enable);
 };
@@ -43,9 +43,8 @@ static struct psr_drv *find_psr_by_crtc(struct drm_crtc *crtc)
 {
struct rockchip_drm_private *drm_drv = crtc->dev->dev_private;
struct psr_drv *psr;
-   unsigned long flags;
 
-   spin_lock_irqsave(&drm_drv->psr_list_lock, flags);
+   mutex_lock(&drm_drv->psr_list_lock);
list_for_each_entry(psr, &drm_drv->psr_list, list) {
if (psr->encoder->crtc == crtc)
goto out;
@@ -53,7 +52,7 @@ static struct psr_drv *find_psr_by_crtc(struct drm_crtc *crtc)
psr = ERR_PTR(-ENODEV);
 
 out:
-   spin_unlock_irqrestore(&drm_drv->psr_list_lock, flags);
+   mutex_unlock(&drm_drv->psr_list_lock);
return psr;
 }
 
@@ -61,9 +60,8 @@ static struct psr_drv *find_psr_by_encoder(struct drm_encoder 
*encoder)
 {
struct rockchip_drm_private *drm_drv = encoder->dev->dev_private;
struct psr_drv *psr;
-   unsigned long flags;
 
-   spin_lock_irqsave(&drm_drv->psr_list_lock, flags);
+   mutex_lock(&drm_drv->psr_list_lock);
list_for_each_entry(psr, &drm_drv->psr_list, list) {
if (psr->encoder == encoder)
goto out;
@@ -71,7 +69,7 @@ static struct psr_drv *find_psr_by_encoder(struct drm_encoder 
*encoder)
psr = ERR_PTR(-ENODEV);
 
 out:
-   spin_unlock_irqrestore(&drm_drv->psr_list_lock, flags);
+   mutex_unlock(&drm_drv->psr_list_lock);
return psr;
 }
 
@@ -112,23 +110,21 @@ static void psr_set_state_locked(struct psr_drv *psr, 
enum psr_state state)
 
 static void psr_set_state(struct psr_drv *psr, enum psr_state state)
 {
-   unsigned long flags;
-
-   spin_lock_irqsave(&psr->lock, flags);
+   mutex_lock(&psr->lock);
psr_set_state_locked(psr, state);
-   spin_unlock_irqrestore(&psr->lock, flags);
+   mutex_unlock(&psr->lock);
 }
 
-static void psr_flush_handler(struct timer_list *t)
+static void psr_flush_handler(struct work_struct *work)
 {
-   struct psr_drv *psr = from_timer(psr, t, flush_timer);
-   unsigned long flags;
+   struct psr_drv *psr = container_of(to_delayed_work(work),
+  struct psr_drv, flush_work);
 
/* If the state has changed since we initiated the flush, do nothing */
-   spin_lock_irqsave(&psr->lock, flags);
+   mutex_lock(&psr->lock);
if (psr->state == PSR_FLUSH)
p

[PATCH v3 02/43] drm/rockchip: support prime import sg table

2018-01-31 Thread Thierry Escande
From: Haixia Shi 

The prime fd to handle ioctl was not used with rockchip before. Support
was added in order to pass graphics_Gbm and to support potential uses
within Chrome OS (e.g. zero-copy video decode, camera).

Signed-off-by: Haixia Shi 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Tested-by: Heiko Stuebner 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 118 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h |   5 +-
 3 files changed, 115 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index d85431400a0d..88084ca15115 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -230,6 +230,7 @@ static struct drm_driver rockchip_drm_driver = {
.gem_prime_import   = drm_gem_prime_import,
.gem_prime_export   = drm_gem_prime_export,
.gem_prime_get_sg_table = rockchip_gem_prime_get_sg_table,
+   .gem_prime_import_sg_table  = rockchip_gem_prime_import_sg_table,
.gem_prime_vmap = rockchip_gem_prime_vmap,
.gem_prime_vunmap   = rockchip_gem_prime_vunmap,
.gem_prime_mmap = rockchip_gem_mmap_buf,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 1d9655576b6e..5d52020deca1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -16,6 +16,8 @@
 #include 
 #include 
 #include 
+
+#include 
 #include 
 
 #include "rockchip_drm_drv.h"
@@ -309,12 +311,10 @@ static void rockchip_gem_release_object(struct 
rockchip_gem_object *rk_obj)
 }
 
 struct rockchip_gem_object *
-   rockchip_gem_create_object(struct drm_device *drm, unsigned int size,
-  bool alloc_kmap)
+   rockchip_gem_alloc_object(struct drm_device *drm, unsigned int size)
 {
struct rockchip_gem_object *rk_obj;
struct drm_gem_object *obj;
-   int ret;
 
size = round_up(size, PAGE_SIZE);
 
@@ -326,6 +326,20 @@ struct rockchip_gem_object *
 
drm_gem_object_init(drm, obj, size);
 
+   return rk_obj;
+}
+
+struct rockchip_gem_object *
+rockchip_gem_create_object(struct drm_device *drm, unsigned int size,
+  bool alloc_kmap)
+{
+   struct rockchip_gem_object *rk_obj;
+   int ret;
+
+   rk_obj = rockchip_gem_alloc_object(drm, size);
+   if (IS_ERR(rk_obj))
+   return rk_obj;
+
ret = rockchip_gem_alloc_buf(rk_obj, alloc_kmap);
if (ret)
goto err_free_rk_obj;
@@ -343,11 +357,21 @@ struct rockchip_gem_object *
  */
 void rockchip_gem_free_object(struct drm_gem_object *obj)
 {
-   struct rockchip_gem_object *rk_obj;
-
-   rk_obj = to_rockchip_obj(obj);
+   struct drm_device *drm = obj->dev;
+   struct rockchip_drm_private *private = drm->dev_private;
+   struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
 
-   rockchip_gem_free_buf(rk_obj);
+   if (obj->import_attach) {
+   if (private->domain) {
+   rockchip_gem_iommu_unmap(rk_obj);
+   } else {
+   dma_unmap_sg(drm->dev, rk_obj->sgt->sgl,
+rk_obj->sgt->nents, DMA_BIDIRECTIONAL);
+   }
+   drm_prime_gem_destroy(obj, rk_obj->sgt);
+   } else {
+   rockchip_gem_free_buf(rk_obj);
+   }
 
rockchip_gem_release_object(rk_obj);
 }
@@ -451,6 +475,86 @@ struct sg_table *rockchip_gem_prime_get_sg_table(struct 
drm_gem_object *obj)
return sgt;
 }
 
+static unsigned long rockchip_sg_get_contiguous_size(struct sg_table *sgt,
+int count)
+{
+   struct scatterlist *s;
+   dma_addr_t expected = sg_dma_address(sgt->sgl);
+   unsigned int i;
+   unsigned long size = 0;
+
+   for_each_sg(sgt->sgl, s, count, i) {
+   if (sg_dma_address(s) != expected)
+   break;
+   expected = sg_dma_address(s) + sg_dma_len(s);
+   size += sg_dma_len(s);
+   }
+   return size;
+}
+
+static int
+rockchip_gem_iommu_map_sg(struct drm_device *drm,
+ struct dma_buf_attachment *attach,
+ struct sg_table *sg,
+ struct rockchip_gem_object *rk_obj)
+{
+   rk_obj->sgt = sg;
+   return rockchip_gem_iommu_map(rk_obj);
+}
+
+static int
+rockchip_gem_dma_map_sg(struct drm_device *drm,
+   struct dma_buf_attachment *attach,
+   struct sg_table *sg,
+   struct rockchip_gem_object *rk_obj)
+{
+   int count = dma_map_sg(drm->dev, sg->sgl, sg->nents,
+  DMA_BIDIRECTIONAL);
+   if (!count)
+ 

[PATCH v3 04/43] drm/bridge: analogix_dp: set psr activate/deactivate when enable/disable bridge

2018-01-31 Thread Thierry Escande
From: zain wang 

There's a race between when bridge_disable and when vop_crtc_disable
are called. If the flush timer triggers a new psr work between these,
we will operate eDP without power shutdowned by bridge_disable. In this
case, moving activate/deactivate to enable/disable bridge to avoid it.

Cc: Stéphane Marchesin 
Signed-off-by: zain wang 
Signed-off-by: Caesar Wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c |  7 +-
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 30 -
 drivers/gpu/drm/rockchip/rockchip_drm_psr.h |  4 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  4 
 4 files changed, 32 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index eb88c52336a7..7d76ff47028d 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -150,12 +150,17 @@ static int rockchip_dp_poweron(struct 
analogix_dp_plat_data *plat_data)
return ret;
}
 
-   return 0;
+   return rockchip_drm_psr_activate(&dp->encoder);
 }
 
 static int rockchip_dp_powerdown(struct analogix_dp_plat_data *plat_data)
 {
struct rockchip_dp_device *dp = to_dp(plat_data);
+   int ret;
+
+   ret = rockchip_drm_psr_deactivate(&dp->encoder);
+   if (ret != 0)
+   return ret;
 
clk_disable_unprepare(dp->pclk);
 
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index 3acfd576b7df..b3fb99c5b1fd 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -57,6 +57,24 @@ static struct psr_drv *find_psr_by_crtc(struct drm_crtc 
*crtc)
return psr;
 }
 
+static struct psr_drv *find_psr_by_encoder(struct drm_encoder *encoder)
+{
+   struct rockchip_drm_private *drm_drv = encoder->dev->dev_private;
+   struct psr_drv *psr;
+   unsigned long flags;
+
+   spin_lock_irqsave(&drm_drv->psr_list_lock, flags);
+   list_for_each_entry(psr, &drm_drv->psr_list, list) {
+   if (psr->encoder == encoder)
+   goto out;
+   }
+   psr = ERR_PTR(-ENODEV);
+
+out:
+   spin_unlock_irqrestore(&drm_drv->psr_list_lock, flags);
+   return psr;
+}
+
 static void psr_set_state_locked(struct psr_drv *psr, enum psr_state state)
 {
/*
@@ -115,14 +133,14 @@ static void psr_flush_handler(struct timer_list *t)
 
 /**
  * rockchip_drm_psr_activate - activate PSR on the given pipe
- * @crtc: CRTC to obtain the PSR encoder
+ * @encoder: encoder to obtain the PSR encoder
  *
  * Returns:
  * Zero on success, negative errno on failure.
  */
-int rockchip_drm_psr_activate(struct drm_crtc *crtc)
+int rockchip_drm_psr_activate(struct drm_encoder *encoder)
 {
-   struct psr_drv *psr = find_psr_by_crtc(crtc);
+   struct psr_drv *psr = find_psr_by_encoder(encoder);
unsigned long flags;
 
if (IS_ERR(psr))
@@ -138,14 +156,14 @@ EXPORT_SYMBOL(rockchip_drm_psr_activate);
 
 /**
  * rockchip_drm_psr_deactivate - deactivate PSR on the given pipe
- * @crtc: CRTC to obtain the PSR encoder
+ * @encoder: encoder to obtain the PSR encoder
  *
  * Returns:
  * Zero on success, negative errno on failure.
  */
-int rockchip_drm_psr_deactivate(struct drm_crtc *crtc)
+int rockchip_drm_psr_deactivate(struct drm_encoder *encoder)
 {
-   struct psr_drv *psr = find_psr_by_crtc(crtc);
+   struct psr_drv *psr = find_psr_by_encoder(encoder);
unsigned long flags;
 
if (IS_ERR(psr))
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
index b420cf1bf902..b1ea0155e57c 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
@@ -18,8 +18,8 @@
 void rockchip_drm_psr_flush_all(struct drm_device *dev);
 int rockchip_drm_psr_flush(struct drm_crtc *crtc);
 
-int rockchip_drm_psr_activate(struct drm_crtc *crtc);
-int rockchip_drm_psr_deactivate(struct drm_crtc *crtc);
+int rockchip_drm_psr_activate(struct drm_encoder *encoder);
+int rockchip_drm_psr_deactivate(struct drm_encoder *encoder);
 
 int rockchip_drm_psr_register(struct drm_encoder *encoder,
void (*psr_set)(struct drm_encoder *, bool enable));
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 7a137bc5708c..31304434847a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -577,8 +577,6 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
 
WARN_ON(vop->event);
 
-   rockchip_drm_psr_deactivate(&vop->crtc);
-
drm_crtc_vblank_off(crtc);
 
/*
@@ -951,8 +949,6 @@ static void vop_crtc_atomic_enable(struct drm_crtc *crtc,
clk_

[PATCH 02/10] video: fbdev: kconfig: Remove empty help text

2018-01-31 Thread Ulf Magnusson
In preparation for adding a warning ("kconfig: Warn if help text is
blank"): https://lkml.org/lkml/2018/1/30/516

Signed-off-by: Ulf Magnusson 
---
 drivers/video/fbdev/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 6962b4583fd7..11e699f1062b 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1156,7 +1156,6 @@ config FB_I810_I2C
bool "Enable DDC Support"
depends on FB_I810 && FB_I810_GTF
select FB_DDC
-   help
 
 config FB_LE80578
tristate "Intel LE80578 (Vermilion) support"
-- 
2.14.1

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


[PATCH v3 16/43] drm/bridge: analogix_dp: Retry bridge enable when it failed

2018-01-31 Thread Thierry Escande
From: zain wang 

When we enable bridge failed, we have to retry it, otherwise we would get
the abnormal display.

Cc: Stéphane Marchesin 
Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 65 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  3 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  5 +-
 3 files changed, 56 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 179c2106b8a2..ba2506e17f6d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -43,8 +43,10 @@ struct bridge_init {
struct device_node *node;
 };
 
-static void analogix_dp_init_dp(struct analogix_dp_device *dp)
+static int analogix_dp_init_dp(struct analogix_dp_device *dp)
 {
+   int ret;
+
analogix_dp_reset(dp);
 
analogix_dp_swreset(dp);
@@ -56,10 +58,13 @@ static void analogix_dp_init_dp(struct analogix_dp_device 
*dp)
analogix_dp_enable_sw_function(dp);
 
analogix_dp_config_interrupt(dp);
-   analogix_dp_init_analog_func(dp);
+   ret = analogix_dp_init_analog_func(dp);
+   if (ret)
+   return ret;
 
analogix_dp_init_hpd(dp);
analogix_dp_init_aux(dp);
+   return 0;
 }
 
 static int analogix_dp_detect_hpd(struct analogix_dp_device *dp)
@@ -922,7 +927,7 @@ static irqreturn_t analogix_dp_irq_thread(int irq, void 
*arg)
return IRQ_HANDLED;
 }
 
-static void analogix_dp_commit(struct analogix_dp_device *dp)
+static int analogix_dp_commit(struct analogix_dp_device *dp)
 {
int ret;
 
@@ -932,11 +937,10 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
DRM_ERROR("failed to disable the panel\n");
}
 
-   ret = readx_poll_timeout(analogix_dp_train_link, dp, ret, !ret, 100,
-DP_TIMEOUT_TRAINING_US * 5);
+   ret = analogix_dp_train_link(dp);
if (ret) {
dev_err(dp->dev, "unable to do link train, ret=%d\n", ret);
-   return;
+   return ret;
}
 
analogix_dp_enable_scramble(dp, 1);
@@ -957,6 +961,7 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
dp->psr_enable = analogix_dp_detect_sink_psr(dp);
if (dp->psr_enable)
analogix_dp_enable_sink_psr(dp);
+   return 0;
 }
 
 /*
@@ -1150,12 +1155,9 @@ static void analogix_dp_bridge_pre_enable(struct 
drm_bridge *bridge)
DRM_ERROR("failed to setup the panel ret = %d\n", ret);
 }
 
-static void analogix_dp_bridge_enable(struct drm_bridge *bridge)
+static int analogix_dp_set_bridge(struct analogix_dp_device *dp)
 {
-   struct analogix_dp_device *dp = bridge->driver_private;
-
-   if (dp->dpms_mode == DRM_MODE_DPMS_ON)
-   return;
+   int ret;
 
pm_runtime_get_sync(dp->dev);
 
@@ -1163,11 +1165,46 @@ static void analogix_dp_bridge_enable(struct drm_bridge 
*bridge)
dp->plat_data->power_on(dp->plat_data);
 
phy_power_on(dp->phy);
-   analogix_dp_init_dp(dp);
+
+   ret = analogix_dp_init_dp(dp);
+   if (ret)
+   goto out_dp_init;
+
+   ret = analogix_dp_commit(dp);
+   if (ret)
+   goto out_dp_init;
+
enable_irq(dp->irq);
-   analogix_dp_commit(dp);
+   return 0;
 
-   dp->dpms_mode = DRM_MODE_DPMS_ON;
+out_dp_init:
+   phy_power_off(dp->phy);
+   if (dp->plat_data->power_off)
+   dp->plat_data->power_off(dp->plat_data);
+   pm_runtime_put_sync(dp->dev);
+
+   return ret;
+}
+
+static void analogix_dp_bridge_enable(struct drm_bridge *bridge)
+{
+   struct analogix_dp_device *dp = bridge->driver_private;
+   int timeout_loop = 0;
+
+   if (dp->dpms_mode == DRM_MODE_DPMS_ON)
+   return;
+
+   while (timeout_loop < MAX_PLL_LOCK_LOOP) {
+   if (analogix_dp_set_bridge(dp) == 0) {
+   dp->dpms_mode = DRM_MODE_DPMS_ON;
+   return;
+   }
+   dev_err(dp->dev, "failed to set bridge, retry: %d\n",
+   timeout_loop);
+   timeout_loop++;
+   usleep_range(10, 11);
+   }
+   dev_err(dp->dev, "too many times retry set bridge, give it up\n");
 }
 
 static void analogix_dp_bridge_disable(struct drm_bridge *bridge)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 403ff853464b..769255dc6e99 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -19,6 +19,7 @@
 #define DP_TIMEOUT_LOOP_COUNT 100
 #define MAX_CR_LOOP 5
 #define MAX_EQ_LOOP 5
+#define MAX_PL

[PATCH v3 10/43] drm/rockchip: add mutex vop lock

2018-01-31 Thread Thierry Escande
From: zain wang 

Add a lock to vop to avoid disabling the crtc while waiting for a line
flag while enabling psr. If we disable in the middle of waiting for the
line flag, we'll end up timing out or worse.

Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 30 +++--
 1 file changed, 24 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 31304434847a..bf4b1a2f3fa4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -117,6 +117,8 @@ struct vop {
spinlock_t reg_lock;
/* lock vop irq reg */
spinlock_t irq_lock;
+   /* protects crtc enable/disable */
+   struct mutex vop_lock;
 
unsigned int irq;
 
@@ -577,6 +579,7 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
 
WARN_ON(vop->event);
 
+   mutex_lock(&vop->vop_lock);
drm_crtc_vblank_off(crtc);
 
/*
@@ -612,6 +615,7 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
clk_disable(vop->aclk);
clk_disable(vop->hclk);
pm_runtime_put(vop->dev);
+   mutex_unlock(&vop->vop_lock);
 
if (crtc->state->event && !crtc->state->active) {
spin_lock_irq(&crtc->dev->event_lock);
@@ -882,10 +886,13 @@ static void vop_crtc_atomic_enable(struct drm_crtc *crtc,
uint32_t pin_pol, val;
int ret;
 
+   mutex_lock(&vop->vop_lock);
+
WARN_ON(vop->event);
 
ret = vop_enable(crtc);
if (ret) {
+   mutex_unlock(&vop->vop_lock);
DRM_DEV_ERROR(vop->dev, "Failed to enable vop (%d)\n", ret);
return;
}
@@ -949,6 +956,7 @@ static void vop_crtc_atomic_enable(struct drm_crtc *crtc,
clk_set_rate(vop->dclk, adjusted_mode->clock * 1000);
 
VOP_REG_SET(vop, common, standby, 0);
+   mutex_unlock(&vop->vop_lock);
 }
 
 static bool vop_fs_irq_is_pending(struct vop *vop)
@@ -1487,15 +1495,21 @@ int rockchip_drm_wait_vact_end(struct drm_crtc *crtc, 
unsigned int mstimeout)
 {
struct vop *vop = to_vop(crtc);
unsigned long jiffies_left;
+   int ret = 0;
 
if (!crtc || !vop->is_enabled)
return -ENODEV;
 
-   if (mstimeout <= 0)
-   return -EINVAL;
+   mutex_lock(&vop->vop_lock);
+   if (mstimeout <= 0) {
+   ret = -EINVAL;
+   goto out;
+   }
 
-   if (vop_line_flag_irq_is_enabled(vop))
-   return -EBUSY;
+   if (vop_line_flag_irq_is_enabled(vop)) {
+   ret = -EBUSY;
+   goto out;
+   }
 
reinit_completion(&vop->line_flag_completion);
vop_line_flag_irq_enable(vop);
@@ -1506,10 +1520,13 @@ int rockchip_drm_wait_vact_end(struct drm_crtc *crtc, 
unsigned int mstimeout)
 
if (jiffies_left == 0) {
DRM_DEV_ERROR(vop->dev, "Timeout waiting for IRQ\n");
-   return -ETIMEDOUT;
+   ret = -ETIMEDOUT;
+   goto out;
}
 
-   return 0;
+out:
+   mutex_unlock(&vop->vop_lock);
+   return ret;
 }
 EXPORT_SYMBOL(rockchip_drm_wait_vact_end);
 
@@ -1559,6 +1576,7 @@ static int vop_bind(struct device *dev, struct device 
*master, void *data)
 
spin_lock_init(&vop->reg_lock);
spin_lock_init(&vop->irq_lock);
+   mutex_init(&vop->vop_lock);
 
ret = devm_request_irq(dev, vop->irq, vop_isr,
   IRQF_SHARED, dev_name(dev), vop);
-- 
2.14.1

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


[PATCH v3 37/43] drm/rockchip: Disable PSR on input events

2018-01-31 Thread Thierry Escande
From: "Kristian H. Kristensen" 

To improve PSR exit latency, we speculatively start exiting when we
receive input events. Occasionally, this may lead to false positives,
but most of the time we get a head start on coming out of PSR. Depending
on how userspace takes to produce a new frame in response to the event,
this can completely hide the exit latency. In case of Chrome OS, we
typically get the input notifier 50ms or more before the dirty_fb
triggered exit.

Signed-off-by: Kristian H. Kristensen 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 134 
 1 file changed, 134 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index 9376f4396b6b..a107845ba97c 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -12,6 +12,8 @@
  * GNU General Public License for more details.
  */
 
+#include 
+
 #include 
 #include 
 
@@ -35,6 +37,9 @@ struct psr_drv {
enum psr_state  state;
 
struct delayed_work flush_work;
+   struct work_struct  disable_work;
+
+   struct input_handlerinput_handler;
 
int (*set)(struct drm_encoder *encoder, bool enable);
 };
@@ -133,6 +138,18 @@ static void psr_flush_handler(struct work_struct *work)
mutex_unlock(&psr->lock);
 }
 
+static void psr_disable_handler(struct work_struct *work)
+{
+   struct psr_drv *psr = container_of(work, struct psr_drv, disable_work);
+
+   /* If the state has changed since we initiated the flush, do nothing */
+   mutex_lock(&psr->lock);
+   if (psr->state == PSR_ENABLE)
+   psr_set_state_locked(psr, PSR_FLUSH);
+   mutex_unlock(&psr->lock);
+   mod_delayed_work(system_wq, &psr->flush_work, PSR_FLUSH_TIMEOUT_MS);
+}
+
 /**
  * rockchip_drm_psr_activate - activate PSR on the given pipe
  * @encoder: encoder to obtain the PSR encoder
@@ -173,6 +190,7 @@ int rockchip_drm_psr_deactivate(struct drm_encoder *encoder)
psr->active = false;
mutex_unlock(&psr->lock);
cancel_delayed_work_sync(&psr->flush_work);
+   cancel_work_sync(&psr->disable_work);
 
return 0;
 }
@@ -226,6 +244,95 @@ void rockchip_drm_psr_flush_all(struct drm_device *dev)
 }
 EXPORT_SYMBOL(rockchip_drm_psr_flush_all);
 
+static void psr_input_event(struct input_handle *handle,
+   unsigned int type, unsigned int code,
+   int value)
+{
+   struct psr_drv *psr = handle->handler->private;
+
+   schedule_work(&psr->disable_work);
+}
+
+static int psr_input_connect(struct input_handler *handler,
+struct input_dev *dev,
+const struct input_device_id *id)
+{
+   struct input_handle *handle;
+   int error;
+
+   handle = kzalloc(sizeof(struct input_handle), GFP_KERNEL);
+   if (!handle)
+   return -ENOMEM;
+
+   handle->dev = dev;
+   handle->handler = handler;
+   handle->name = "rockchip-psr";
+
+   error = input_register_handle(handle);
+   if (error)
+   goto err2;
+
+   error = input_open_device(handle);
+   if (error)
+   goto err1;
+
+   return 0;
+
+err1:
+   input_unregister_handle(handle);
+err2:
+   kfree(handle);
+   return error;
+}
+
+static void psr_input_disconnect(struct input_handle *handle)
+{
+   input_close_device(handle);
+   input_unregister_handle(handle);
+   kfree(handle);
+}
+
+/* Same device ids as cpu-boost */
+static const struct input_device_id psr_ids[] = {
+   {
+   .flags = INPUT_DEVICE_ID_MATCH_EVBIT |
+INPUT_DEVICE_ID_MATCH_ABSBIT,
+   .evbit = { BIT_MASK(EV_ABS) },
+   .absbit = { [BIT_WORD(ABS_MT_POSITION_X)] =
+   BIT_MASK(ABS_MT_POSITION_X) |
+   BIT_MASK(ABS_MT_POSITION_Y) },
+   }, /* multi-touch touchscreen */
+   {
+   .flags = INPUT_DEVICE_ID_MATCH_EVBIT,
+   .evbit = { BIT_MASK(EV_ABS) },
+   .absbit = { [BIT_WORD(ABS_X)] = BIT_MASK(ABS_X) }
+
+   }, /* stylus or joystick device */
+   {
+   .flags = INPUT_DEVICE_ID_MATCH_EVBIT,
+   .evbit = { BIT_MASK(EV_KEY) },
+   .keybit = { [BIT_WORD(BTN_LEFT)] = BIT_MASK(BTN_LEFT) },
+   }, /* pointer (e.g. trackpad, mouse) */
+   {
+   .flags = INPUT_DEVICE_ID_MATCH_EVBIT,
+   .evbit = { BIT_MASK(EV_KEY) },
+   .keybit = { [BIT_WORD(KEY_ESC)] = BIT_MASK(KEY_ESC) },
+   }, /* keyboard */
+   {
+   .flags = INPUT_DEVICE_ID_MATCH_EVBIT |
+   INPUT_DEVICE_ID_MATCH_KEYBIT,
+   .evbit = { BIT_MASK(EV_KEY) },
+   .keybit = {[BIT_WORD(BTN_JOYSTICK)] = BIT_MASK(BTN_JOYSTICK) },
+   }, /

[PATCH v3 20/43] drm/bridge: analogix_dp: Extend hpd check time to 100ms

2018-01-31 Thread Thierry Escande
From: Lin Huang 

There was a 1ms delay to detect the hpd signal, which is too short to
detect a short pulse. This patch extends this delay to 100ms.

Cc: Stéphane Marchesin 
Cc: 征增 王 
Signed-off-by: Lin Huang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index fa4ef28e286f..9df92dc54dbe 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -76,7 +76,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
*dp)
return 0;
 
timeout_loop++;
-   usleep_range(10, 11);
+   usleep_range(1000, 1100);
}
 
/*
-- 
2.14.1

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


[PATCH v3 09/43] drm/bridge: analogix_dp: Don't change psr while bridge is disabled

2018-01-31 Thread Thierry Escande
From: zain wang 

There is a race between AUX CH bring-up and enabling bridge which will
cause link training to fail. To avoid hitting it, don't change psr state
while enabling the bridge.

Cc: Tomeu Vizoso 
Cc: Sean Paul 
Signed-off-by: zain wang 
Signed-off-by: Caesar Wang 
[seanpaul fixed up the commit message a bit and renamed *_supported to 
*_enabled]
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 15 ---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  2 +-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c|  2 +-
 include/drm/bridge/analogix_dp.h   |  2 +-
 4 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index b52de046f5f1..84141571e960 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -98,18 +98,18 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
*dp)
return 0;
 }
 
-int analogix_dp_psr_supported(struct analogix_dp_device *dp)
+int analogix_dp_psr_enabled(struct analogix_dp_device *dp)
 {
 
-   return dp->psr_support;
+   return dp->psr_enable;
 }
-EXPORT_SYMBOL_GPL(analogix_dp_psr_supported);
+EXPORT_SYMBOL_GPL(analogix_dp_psr_enabled);
 
 int analogix_dp_enable_psr(struct analogix_dp_device *dp)
 {
struct edp_vsc_psr psr_vsc;
 
-   if (!dp->psr_support)
+   if (!dp->psr_enable)
return 0;
 
/* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
@@ -131,7 +131,7 @@ int analogix_dp_disable_psr(struct analogix_dp_device *dp)
struct edp_vsc_psr psr_vsc;
int ret;
 
-   if (!dp->psr_support)
+   if (!dp->psr_enable)
return 0;
 
/* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
@@ -875,8 +875,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
/* Enable video */
analogix_dp_start_video(dp);
 
-   dp->psr_support = analogix_dp_detect_sink_psr(dp);
-   if (dp->psr_support)
+   dp->psr_enable = analogix_dp_detect_sink_psr(dp);
+   if (dp->psr_enable)
analogix_dp_enable_sink_psr(dp);
 }
 
@@ -1118,6 +1118,7 @@ static void analogix_dp_bridge_disable(struct drm_bridge 
*bridge)
if (ret)
DRM_ERROR("failed to setup the panel ret = %d\n", ret);
 
+   dp->psr_enable = false;
dp->dpms_mode = DRM_MODE_DPMS_OFF;
 }
 
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index b039b28d8fcc..e135a42cb19e 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -170,7 +170,7 @@ struct analogix_dp_device {
int dpms_mode;
int hpd_gpio;
boolforce_hpd;
-   boolpsr_support;
+   boolpsr_enable;
 
struct mutexpanel_lock;
boolpanel_is_modeset;
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 36334839a3f8..3e8bf79bea58 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -82,7 +82,7 @@ static void analogix_dp_psr_set(struct drm_encoder *encoder, 
bool enabled)
struct rockchip_dp_device *dp = to_dp(encoder);
int ret;
 
-   if (!analogix_dp_psr_supported(dp->adp))
+   if (!analogix_dp_psr_enabled(dp->adp))
return;
 
DRM_DEV_DEBUG(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 5518fc75dd6e..c2788483c882 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -40,7 +40,7 @@ struct analogix_dp_plat_data {
 struct drm_connector *);
 };
 
-int analogix_dp_psr_supported(struct analogix_dp_device *dp);
+int analogix_dp_psr_enabled(struct analogix_dp_device *dp);
 int analogix_dp_enable_psr(struct analogix_dp_device *dp);
 int analogix_dp_disable_psr(struct analogix_dp_device *dp);
 
-- 
2.14.1

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


[PATCH v3 26/43] drm/bridge: analogix_dp: Don't use ANALOGIX_DP_PLL_CTL to control pll

2018-01-31 Thread Thierry Escande
From: zain wang 

There is no register named ANALOGIX_DP_PLL_CTL in Rockchip edp phy reg
list.  We should use BIT_4 in ANALOGIX_DP_PD to control the pll power
instead of ANALOGIX_DP_PLL_CTL.

Cc: Douglas Anderson 
Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 7b7fd227e1f9..02ab1aaa9993 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -230,16 +230,20 @@ enum pll_status analogix_dp_get_pll_lock_status(struct 
analogix_dp_device *dp)
 void analogix_dp_set_pll_power_down(struct analogix_dp_device *dp, bool enable)
 {
u32 reg;
+   u32 mask = DP_PLL_PD;
+   u32 pd_addr = ANALOGIX_DP_PLL_CTL;
 
-   if (enable) {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PLL_CTL);
-   reg |= DP_PLL_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PLL_CTL);
-   } else {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PLL_CTL);
-   reg &= ~DP_PLL_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PLL_CTL);
+   if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
+   pd_addr = ANALOGIX_DP_PD;
+   mask = RK_PLL_PD;
}
+
+   reg = readl(dp->reg_base + pd_addr);
+   if (enable)
+   reg |= mask;
+   else
+   reg &= ~mask;
+   writel(reg, dp->reg_base + pd_addr);
 }
 
 void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,
-- 
2.14.1

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


[PATCH v3 25/43] drm/rockchip: Restore psr->state when enable/disable psr failed

2018-01-31 Thread Thierry Escande
From: zain wang 

If we failed disable psr, it would hang the display until next psr
cycle coming. So we should restore psr->state when it failed.

Cc: Tomasz Figa 
Signed-off-by: zain wang 
Signed-off-by: Douglas Anderson 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  4 +++-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 10 +-
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c| 20 +---
 drivers/gpu/drm/rockchip/rockchip_drm_psr.h|  2 +-
 4 files changed, 22 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 082b4e024052..e925c62eaadb 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -153,8 +153,10 @@ int analogix_dp_disable_psr(struct analogix_dp_device *dp)
psr_vsc.DB1 = 0;
 
ret = drm_dp_dpcd_writeb(&dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
-   if (ret != 1)
+   if (ret != 1) {
dev_err(dp->dev, "Failed to set DP Power0 %d\n", ret);
+   return ret;
+   }
 
return analogix_dp_send_psr_spd(dp, &psr_vsc, false);
 }
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 3e8bf79bea58..8c884f9ce713 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -77,13 +77,13 @@ struct rockchip_dp_device {
struct analogix_dp_plat_data plat_data;
 };
 
-static void analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)
+static int analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)
 {
struct rockchip_dp_device *dp = to_dp(encoder);
int ret;
 
if (!analogix_dp_psr_enabled(dp->adp))
-   return;
+   return 0;
 
DRM_DEV_DEBUG(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
 
@@ -91,13 +91,13 @@ static void analogix_dp_psr_set(struct drm_encoder 
*encoder, bool enabled)
 PSR_WAIT_LINE_FLAG_TIMEOUT_MS);
if (ret) {
DRM_DEV_ERROR(dp->dev, "line flag interrupt did not arrive\n");
-   return;
+   return -ETIMEDOUT;
}
 
if (enabled)
-   analogix_dp_enable_psr(dp->adp);
+   return analogix_dp_enable_psr(dp->adp);
else
-   analogix_dp_disable_psr(dp->adp);
+   return analogix_dp_disable_psr(dp->adp);
 }
 
 static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index b339ca943139..9376f4396b6b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -36,7 +36,7 @@ struct psr_drv {
 
struct delayed_work flush_work;
 
-   void (*set)(struct drm_encoder *encoder, bool enable);
+   int (*set)(struct drm_encoder *encoder, bool enable);
 };
 
 static struct psr_drv *find_psr_by_crtc(struct drm_crtc *crtc)
@@ -93,19 +93,25 @@ static void psr_set_state_locked(struct psr_drv *psr, enum 
psr_state state)
return;
}
 
-   psr->state = state;
-
/* Actually commit the state change to hardware */
-   switch (psr->state) {
+   switch (state) {
case PSR_ENABLE:
-   psr->set(psr->encoder, true);
+   if (psr->set(psr->encoder, true))
+   return;
break;
 
case PSR_DISABLE:
case PSR_FLUSH:
-   psr->set(psr->encoder, false);
+   if (psr->set(psr->encoder, false))
+   return;
break;
+
+   default:
+   pr_err("%s: Unknown state %d\n", __func__, state);
+   return;
}
+
+   psr->state = state;
 }
 
 static void psr_set_state(struct psr_drv *psr, enum psr_state state)
@@ -229,7 +235,7 @@ EXPORT_SYMBOL(rockchip_drm_psr_flush_all);
  * Zero on success, negative errno on failure.
  */
 int rockchip_drm_psr_register(struct drm_encoder *encoder,
-   void (*psr_set)(struct drm_encoder *, bool enable))
+   int (*psr_set)(struct drm_encoder *, bool enable))
 {
struct rockchip_drm_private *drm_drv = encoder->dev->dev_private;
struct psr_drv *psr;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
index b1ea0155e57c..06537ee27565 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
@@ -22,7 +22,7 @@ int rockchip_drm_psr_activate(struct drm_encoder *encoder);
 int rockchip_drm_psr_deactivate(struct drm_encoder *encoder);
 
 int rockchip_drm_psr_register(struct drm_encoder *encoder,
- 

[PATCH v3 43/43] drm/rockchip: psr: Remove flush by CRTC

2018-01-31 Thread Thierry Escande
From: Tomasz Figa 

It is not used anymore after last changes and it was not even correct to
begin with as it assumed a 1:1 relation between a CRTC and encoder,
while in fact a CRTC can be attached to multiple encoders.

Signed-off-by: Tomasz Figa 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 35 -
 drivers/gpu/drm/rockchip/rockchip_drm_psr.h |  1 -
 2 files changed, 36 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index 1bf5cba9a64d..b1988ac758d5 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -40,23 +40,6 @@ struct psr_drv {
int (*set)(struct drm_encoder *encoder, bool enable);
 };
 
-static struct psr_drv *find_psr_by_crtc(struct drm_crtc *crtc)
-{
-   struct rockchip_drm_private *drm_drv = crtc->dev->dev_private;
-   struct psr_drv *psr;
-
-   mutex_lock(&drm_drv->psr_list_lock);
-   list_for_each_entry(psr, &drm_drv->psr_list, list) {
-   if (psr->encoder->crtc == crtc)
-   goto out;
-   }
-   psr = ERR_PTR(-ENODEV);
-
-out:
-   mutex_unlock(&drm_drv->psr_list_lock);
-   return psr;
-}
-
 static struct psr_drv *find_psr_by_encoder(struct drm_encoder *encoder)
 {
struct rockchip_drm_private *drm_drv = encoder->dev->dev_private;
@@ -173,24 +156,6 @@ static void rockchip_drm_do_flush(struct psr_drv *psr)
mutex_unlock(&psr->lock);
 }
 
-/**
- * rockchip_drm_psr_flush - flush a single pipe
- * @crtc: CRTC of the pipe to flush
- *
- * Returns:
- * 0 on success, -errno on fail
- */
-int rockchip_drm_psr_flush(struct drm_crtc *crtc)
-{
-   struct psr_drv *psr = find_psr_by_crtc(crtc);
-   if (IS_ERR(psr))
-   return PTR_ERR(psr);
-
-   rockchip_drm_do_flush(psr);
-   return 0;
-}
-EXPORT_SYMBOL(rockchip_drm_psr_flush);
-
 /**
  * rockchip_drm_psr_flush_all - force to flush all registered PSR encoders
  * @dev: drm device
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
index 40e026c14168..860c62494496 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
@@ -16,7 +16,6 @@
 #define __ROCKCHIP_DRM_PSR___
 
 void rockchip_drm_psr_flush_all(struct drm_device *dev);
-int rockchip_drm_psr_flush(struct drm_crtc *crtc);
 
 int rockchip_drm_psr_inhibit_put(struct drm_encoder *encoder);
 int rockchip_drm_psr_inhibit_get(struct drm_encoder *encoder);
-- 
2.14.1

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


[PATCH v3 41/43] drm/rockchip: Disable PSR from reboot notifier

2018-01-31 Thread Thierry Escande
From: Tomasz Figa 

It looks like the driver subsystem detaches devices from power domains
at shutdown without consent of the drivers. This means that we might have
our power domain turned off behind our back and the only way to avoid
problems is to stop doing any hardware programming at some point before
the power is cut. A reboot notifier, despite being a misnomer and
handling shutdowns as well, is a good place to do it.

Signed-off-by: Tomasz Figa 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index e7e16d92d5a1..1bf5cba9a64d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -13,6 +13,7 @@
  */
 
 #include 
+#include 
 
 #include 
 #include 
@@ -33,6 +34,7 @@ struct psr_drv {
struct delayed_work flush_work;
struct work_struct  disable_work;
 
+   struct notifier_block   reboot_nb;
struct input_handlerinput_handler;
 
int (*set)(struct drm_encoder *encoder, bool enable);
@@ -309,6 +311,24 @@ static const struct input_device_id psr_ids[] = {
{ },
 };
 
+static int rockchip_drm_psr_reboot_notifier(struct notifier_block *nb,
+   unsigned long action, void *data)
+{
+   struct psr_drv *psr = container_of(nb, struct psr_drv, reboot_nb);
+
+   /*
+* It looks like the driver subsystem detaches devices from power
+* domains at shutdown without consent of the drivers. This means
+* that we might have our power domain turned off behind our back
+* and the only way to avoid problems is to stop doing any hardware
+* programming after this point, which is achieved by the unbalanced
+* call below.
+*/
+   rockchip_drm_psr_inhibit_get(psr->encoder);
+
+   return 0;
+}
+
 /**
  * rockchip_drm_psr_register - register encoder to psr driver
  * @encoder: encoder that obtain the PSR function
@@ -361,6 +381,9 @@ int rockchip_drm_psr_register(struct drm_encoder *encoder,
if (error)
goto err1;
 
+   psr->reboot_nb.notifier_call = rockchip_drm_psr_reboot_notifier;
+   register_reboot_notifier(&psr->reboot_nb);
+
mutex_lock(&drm_drv->psr_list_lock);
list_add_tail(&psr->list, &drm_drv->psr_list);
mutex_unlock(&drm_drv->psr_list_lock);
@@ -403,6 +426,7 @@ void rockchip_drm_psr_unregister(struct drm_encoder 
*encoder)
WARN_ON(psr->inhibit_count != 1);
 
list_del(&psr->list);
+   unregister_reboot_notifier(&psr->reboot_nb);
input_unregister_handler(&psr->input_handler);
kfree(psr->input_handler.name);
kfree(psr);
-- 
2.14.1

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


[PATCH v3 00/43] DRM Rockchip rk3399 (Kevin)

2018-01-31 Thread Thierry Escande
Hi,

This patchset includes cleanups, improvements, and bug fixes for
Rockchip DRM driver and PSR support.

this patchset depends and needs to be applied on top of Rockchip rk3399
eDP support [1].

[1] https://lkml.org/lkml/2018/1/10/682

Regards,
Thierry

Changes in v3:
- Addressed some of the comments from Sean on the v2

Changes in v2:
- A few patches have been replaced by newer and cleaner versions from
  the ChromeOS kernel gerrit, especially about disallowing PSR for the
  whole atomic commit.

Douglas Anderson (4):
  drm/bridge: analogix_dp: Reorder plat_data->power_off to happen sooner
  drm/bridge: analogix_dp: Properly log AUX CH errors
  drm/bridge: analogix_dp: Properly disable aux chan retries on rockchip
  drm/bridge: analogix_dp: Split the platform-specific poweron in two
parts

Haixia Shi (1):
  drm/rockchip: support prime import sg table

Kristian H. Kristensen (1):
  drm/rockchip: Disable PSR on input events

Lin Huang (6):
  drm/bridge: analogix_dp: Move enable video into config_video()
  drm/bridge: analogix_dp: Check AUX_EN status when doing AUX transfer
  drm/bridge: analogix_dp: Ensure edp is disabled when shutting down the
panel
  drm/bridge: analogix_dp: Extend hpd check time to 100ms
  drm/bridge: analogix_dp: Check dpcd write/read status
  drm/bridge: analogix_dp: Reset aux channel if an error occurred

Mark Yao (1):
  drm/rockchip: pre dither down when output bpc is 8bit

Sean Paul (3):
  drm/rockchip: Don't use atomic constructs for psr
  drm/rockchip: Remove analogix psr worker
  drm/panel: simple: Change mode for Sharp lq123p1jx31

Tomasz Figa (8):
  drm/rockchip: Get rid of unnecessary struct fields
  drm/rockchip: analogix_dp: Do not call Analogix code before bind
  drm/rockchip: Cancel PSR enable work before changing the state
  drm/rockchip: psr: Avoid redundant calls to .set() callback
  drm/rockchip: psr: Sanitize semantics of allow/disallow API
  drm/rockchip: Disable PSR from reboot notifier
  drm/rockchip: Disallow PSR for the whole atomic commit
  drm/rockchip: psr: Remove flush by CRTC

Yakir Yang (1):
  drm/bridge: analogix_dp: detect Sink PSR state after configuring the
PSR

zain wang (17):
  drm/bridge: analogix_dp: set psr activate/deactivate when
enable/disable bridge
  drm/bridge: analogix_dp: Don't power bridge in analogix_dp_bind
  drm/bridge: analogix_dp: Don't change psr while bridge is disabled
  drm/rockchip: add mutex vop lock
  drm/bridge: analogix_dp: add fast link train for eDP
  drm/rockchip: Only wait for panel ACK on PSR entry
  drm/bridge: analogix_dp: Don't use fast link training when panel just
powered up
  drm/bridge: analogix_dp: Retry bridge enable when it failed
  drm/bridge: analogix_dp: Wait for HPD signal before configuring link
  drm/bridge: analogix_dp: Set PD_INC_BG first when powering up edp phy
  drm/bridge: analogix_dp: Fix incorrect usage of enhanced mode
  drm/bridge: analogix_dp: Fix AUX_PD bit for Rockchip
  drm/rockchip: Restore psr->state when enable/disable psr failed
  drm/bridge: analogix_dp: Don't use ANALOGIX_DP_PLL_CTL to control pll
  drm/bridge: analogix_dp: Fix timeout of video streamclk config
  drm/bridge: analogix_dp: Fix incorrect operations with register
ANALOGIX_DP_FUNC_EN_1
  drm/bridge: analogix_dp: Move fast link training detect to set_bridge

Ørjan Eide (1):
  drm/rockchip: Respect page offset for PRIME mmap calls

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 475 +++--
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  14 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 274 +++-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h  |   7 +
 drivers/gpu/drm/exynos/exynos_dp.c |   2 +-
 drivers/gpu/drm/panel/panel-simple.c   |   7 +-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c|  73 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|   3 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   3 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c |  61 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c| 125 +-
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h|   5 +-
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c| 361 +++-
 drivers/gpu/drm/rockchip/rockchip_drm_psr.h|   7 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c|  52 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h|   1 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c|   1 +
 include/drm/bridge/analogix_dp.h   |   5 +-
 18 files changed, 1048 insertions(+), 428 deletions(-)

-- 
2.14.1

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


[PATCH v3 42/43] drm/rockchip: Disallow PSR for the whole atomic commit

2018-01-31 Thread Thierry Escande
From: Tomasz Figa 

Currently PSR flush is triggered from CRTC's .atomic_begin() callback,
which is executed after modeset disables and enables and before plane
updates are committed. Since PSR flush and re-enable can be triggered
asynchronously by external sources (input event, delayed work), it can
race with hardware programming done in the aforementioned stages.

This patch blocks the PSR completely before hardware programming part
begins and unblock after it ends. This relies on reference counted PSR
disable introduced with previous patch.

Cc: Kristian H. Kristensen 
Signed-off-by: Tomasz Figa 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  | 61 -
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  7 
 2 files changed, 60 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index e266539e04e5..d4f4118b482d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -167,8 +167,67 @@ rockchip_user_fb_create(struct drm_device *dev, struct 
drm_file *file_priv,
return ERR_PTR(ret);
 }
 
+static void
+rockchip_drm_psr_inhibit_get_state(struct drm_atomic_state *state)
+{
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+   struct drm_encoder *encoder;
+   u32 encoder_mask = 0;
+   int i;
+
+   for_each_old_crtc_in_state(state, crtc, crtc_state, i) {
+   encoder_mask |= crtc_state->encoder_mask;
+   encoder_mask |= crtc->state->encoder_mask;
+   }
+
+   drm_for_each_encoder_mask(encoder, state->dev, encoder_mask)
+   rockchip_drm_psr_inhibit_get(encoder);
+}
+
+static void
+rockchip_drm_psr_inhibit_put_state(struct drm_atomic_state *state)
+{
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+   struct drm_encoder *encoder;
+   u32 encoder_mask = 0;
+   int i;
+
+   for_each_old_crtc_in_state(state, crtc, crtc_state, i) {
+   encoder_mask |= crtc_state->encoder_mask;
+   encoder_mask |= crtc->state->encoder_mask;
+   }
+
+   drm_for_each_encoder_mask(encoder, state->dev, encoder_mask)
+   rockchip_drm_psr_inhibit_put(encoder);
+}
+
+static void
+rockchip_atomic_helper_commit_tail_rpm(struct drm_atomic_state *old_state)
+{
+   struct drm_device *dev = old_state->dev;
+
+   rockchip_drm_psr_inhibit_get_state(old_state);
+
+   drm_atomic_helper_commit_modeset_disables(dev, old_state);
+
+   drm_atomic_helper_commit_modeset_enables(dev, old_state);
+
+   drm_atomic_helper_commit_planes(dev, old_state,
+   DRM_PLANE_COMMIT_ACTIVE_ONLY);
+
+   rockchip_drm_psr_inhibit_put_state(old_state);
+
+   drm_atomic_helper_commit_hw_done(old_state);
+
+   drm_atomic_helper_wait_for_vblanks(dev, old_state);
+
+   drm_atomic_helper_cleanup_planes(dev, old_state);
+}
+
 static const struct drm_mode_config_helper_funcs rockchip_mode_config_helpers 
= {
-   .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
+   .atomic_commit_tail = rockchip_atomic_helper_commit_tail_rpm,
 };
 
 static const struct drm_mode_config_funcs rockchip_drm_mode_config_funcs = {
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 4abb9d72d814..8c11a4dc436e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1041,16 +1041,9 @@ static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
}
 }
 
-static void vop_crtc_atomic_begin(struct drm_crtc *crtc,
- struct drm_crtc_state *old_crtc_state)
-{
-   rockchip_drm_psr_flush(crtc);
-}
-
 static const struct drm_crtc_helper_funcs vop_crtc_helper_funcs = {
.mode_fixup = vop_crtc_mode_fixup,
.atomic_flush = vop_crtc_atomic_flush,
-   .atomic_begin = vop_crtc_atomic_begin,
.atomic_enable = vop_crtc_atomic_enable,
.atomic_disable = vop_crtc_atomic_disable,
 };
-- 
2.14.1

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


[PATCH v3 13/43] drm/bridge: analogix_dp: Move enable video into config_video()

2018-01-31 Thread Thierry Escande
From: Lin Huang 

We need to enable video before analogix_dp_is_video_stream_on(), so
we can get the right video stream status.

Cc: 征增 王 
Cc: Stéphane Marchesin 
Signed-off-by: Lin Huang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 49a05eac41c1..8ef9e31c6713 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -820,11 +820,10 @@ static int analogix_dp_config_video(struct 
analogix_dp_device *dp)
if (analogix_dp_is_slave_video_stream_clock_on(dp) == 0)
break;
if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
-   dev_err(dp->dev, "Timeout of video streamclk ok\n");
+   dev_err(dp->dev, "Timeout of slave video streamclk 
ok\n");
return -ETIMEDOUT;
}
-
-   usleep_range(1, 2);
+   usleep_range(1000, 1001);
}
 
/* Set to use the register calculated M/N video */
@@ -839,6 +838,9 @@ static int analogix_dp_config_video(struct 
analogix_dp_device *dp)
/* Configure video slave mode */
analogix_dp_enable_video_master(dp, 0);
 
+   /* Enable video */
+   analogix_dp_start_video(dp);
+
timeout_loop = 0;
 
for (;;) {
@@ -952,9 +954,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
DRM_ERROR("failed to enable the panel\n");
}
 
-   /* Enable video */
-   analogix_dp_start_video(dp);
-
dp->psr_enable = analogix_dp_detect_sink_psr(dp);
if (dp->psr_enable)
analogix_dp_enable_sink_psr(dp);
-- 
2.14.1

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


[PATCH v3 39/43] drm/rockchip: psr: Avoid redundant calls to .set() callback

2018-01-31 Thread Thierry Escande
From: Tomasz Figa 

The first time after we call rockchip_drm_do_flush() after
rockchip_drm_psr_register(), we go from PSR_DISABLE to PSR_FLUSH. The
difference between PSR_DISABLE and PSR_FLUSH is whether or not we have a
delayed work pending - PSR is off in either state.  However
psr_set_state() only catches the transition from PSR_FLUSH to
PSR_DISABLE (which never happens), while going from PSR_DISABLE to
PSR_FLUSH triggers a call to psr->set() to disable PSR while it's
already disabled. This triggers the eDP PHY power-on sequence without
being shut down first and this seems to occasionally leave the encoder
unable to later enable PSR. Let's just simplify the state machine and
simply consider PSR_DISABLE and PSR_FLUSH the same state. This lets us
represent the hardware state by a simple boolean called "enabled" and,
while at it, rename the misleading "active" boolean to "inhibit", which
represents the purpose much better.

Also, userspace can (and does) trigger the rockchip_drm_do_flush() path
from drmModeDirtyFB() at any time, whether or the encoder is active. If
no mode is set, we call into analogix_dp_psr_set() which returns -EINVAL
because encoder->crtc is NULL. Avoid this by starting out with
psr->allowed set to false.

Signed-off-by: Kristian H. Kristensen 
Signed-off-by: Tomasz Figa 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 79 +
 1 file changed, 23 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index c8655e625ba2..448c5fde241c 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -22,19 +22,13 @@
 
 #define PSR_FLUSH_TIMEOUT_MS   100
 
-enum psr_state {
-   PSR_FLUSH,
-   PSR_ENABLE,
-   PSR_DISABLE,
-};
-
 struct psr_drv {
struct list_headlist;
struct drm_encoder  *encoder;
 
struct mutexlock;
boolactive;
-   enum psr_state  state;
+   boolenabled;
 
struct delayed_work flush_work;
struct work_struct  disable_work;
@@ -78,52 +72,22 @@ static struct psr_drv *find_psr_by_encoder(struct 
drm_encoder *encoder)
return psr;
 }
 
-static void psr_set_state_locked(struct psr_drv *psr, enum psr_state state)
+static int psr_set_state_locked(struct psr_drv *psr, bool enable)
 {
-   /*
-* Allowed finite state machine:
-*
-*   PSR_ENABLE  < = = = = = >  PSR_FLUSH
-*   | ^|
-*   | ||
-*   v ||
-*   PSR_DISABLE < - - - - - - - - -
-*/
-   if (state == psr->state || !psr->active)
-   return;
-
-   /* Already disabled in flush, change the state, but not the hardware */
-   if (state == PSR_DISABLE && psr->state == PSR_FLUSH) {
-   psr->state = state;
-   return;
-   }
+   int ret;
 
-   /* Actually commit the state change to hardware */
-   switch (state) {
-   case PSR_ENABLE:
-   if (psr->set(psr->encoder, true))
-   return;
-   break;
-
-   case PSR_DISABLE:
-   case PSR_FLUSH:
-   if (psr->set(psr->encoder, false))
-   return;
-   break;
-
-   default:
-   pr_err("%s: Unknown state %d\n", __func__, state);
-   return;
-   }
+   if (!psr->active)
+   return -EINVAL;
 
-   psr->state = state;
-}
+   if (enable == psr->enabled)
+   return 0;
 
-static void psr_set_state(struct psr_drv *psr, enum psr_state state)
-{
-   mutex_lock(&psr->lock);
-   psr_set_state_locked(psr, state);
-   mutex_unlock(&psr->lock);
+   ret = psr->set(psr->encoder, enable);
+   if (ret)
+   return ret;
+
+   psr->enabled = enable;
+   return 0;
 }
 
 static void psr_flush_handler(struct work_struct *work)
@@ -131,10 +95,8 @@ static void psr_flush_handler(struct work_struct *work)
struct psr_drv *psr = container_of(to_delayed_work(work),
   struct psr_drv, flush_work);
 
-   /* If the state has changed since we initiated the flush, do nothing */
mutex_lock(&psr->lock);
-   if (psr->state == PSR_FLUSH)
-   psr_set_state_locked(psr, PSR_ENABLE);
+   psr_set_state_locked(psr, true);
mutex_unlock(&psr->lock);
 }
 
@@ -176,6 +138,7 @@ int rockchip_drm_psr_deactivate(struct drm_encoder *encoder)
 
mutex_lock(&psr->lock);
psr->active = false;
+   psr->enabled = false;
mutex_unlock(&psr->lock);
cancel_delayed_work_sync(&psr->flush_work);
cancel_work_sync(&psr->disable_work);
@@ -187,8 +150,12 @@ EXPORT_SYMBOL(rockchip_drm_psr_deactivat

[PATCH v3 05/43] drm/bridge: analogix_dp: Don't power bridge in analogix_dp_bind

2018-01-31 Thread Thierry Escande
From: zain wang 

The bridge does not need to be powered in analogix_dp_bind(), so
remove the calls to pm_runtime_get()/phy_power_on()/analogix_dp_init_dp()
as well as their power-off counterparts.

Cc: Stéphane Marchesin 
Signed-off-by: zain wang 
Signed-off-by: Caesar Wang 
[the patch originally just removed the power_on portion, seanpaul removed
the power off code as well as improved the commit message]
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index cb5e18d6ba04..1477ea9ba85d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1382,11 +1382,6 @@ analogix_dp_bind(struct device *dev, struct drm_device 
*drm_dev,
 
pm_runtime_enable(dev);
 
-   pm_runtime_get_sync(dev);
-   phy_power_on(dp->phy);
-
-   analogix_dp_init_dp(dp);
-
ret = devm_request_threaded_irq(&pdev->dev, dp->irq,
analogix_dp_hardirq,
analogix_dp_irq_thread,
@@ -1414,15 +1409,10 @@ analogix_dp_bind(struct device *dev, struct drm_device 
*drm_dev,
goto err_disable_pm_runtime;
}
 
-   phy_power_off(dp->phy);
-   pm_runtime_put(dev);
-
return dp;
 
 err_disable_pm_runtime:
 
-   phy_power_off(dp->phy);
-   pm_runtime_put(dev);
pm_runtime_disable(dev);
 
return ERR_PTR(ret);
-- 
2.14.1

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


[PATCH v3 18/43] drm/bridge: analogix_dp: Set PD_INC_BG first when powering up edp phy

2018-01-31 Thread Thierry Escande
From: zain wang 

Following the correct power up sequence:
dp_pd=ff => dp_pd=7f => wait 10us => dp_pd=00

Cc: Stéphane Marchesin 
Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 10 --
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h |  3 +++
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index b47c5af43560..bb72f8b0e603 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -321,10 +321,16 @@ void analogix_dp_set_analog_power_down(struct 
analogix_dp_device *dp,
break;
case POWER_ALL:
if (enable) {
-   reg = DP_PHY_PD | AUX_PD | CH3_PD | CH2_PD |
-   CH1_PD | CH0_PD;
+   reg = DP_ALL_PD;
writel(reg, dp->reg_base + phy_pd_addr);
} else {
+   reg = DP_ALL_PD;
+   writel(reg, dp->reg_base + phy_pd_addr);
+   usleep_range(10, 15);
+   reg &= ~DP_INC_BG;
+   writel(reg, dp->reg_base + phy_pd_addr);
+   usleep_range(10, 15);
+
writel(0x00, dp->reg_base + phy_pd_addr);
}
break;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
index 40200c652533..9602668669f4 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
@@ -342,12 +342,15 @@
 #define DP_PLL_REF_BIT_1_2500V (0x7 << 0)
 
 /* ANALOGIX_DP_PHY_PD */
+#define DP_INC_BG  (0x1 << 7)
+#define DP_EXP_BG  (0x1 << 6)
 #define DP_PHY_PD  (0x1 << 5)
 #define AUX_PD (0x1 << 4)
 #define CH3_PD (0x1 << 3)
 #define CH2_PD (0x1 << 2)
 #define CH1_PD (0x1 << 1)
 #define CH0_PD (0x1 << 0)
+#define DP_ALL_PD  (0xff)
 
 /* ANALOGIX_DP_PHY_TEST */
 #define MACRO_RST  (0x1 << 5)
-- 
2.14.1

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


[PATCH v3 31/43] drm/bridge: analogix_dp: Properly log AUX CH errors

2018-01-31 Thread Thierry Escande
From: Douglas Anderson 

The code in analogix_dp_transfer() that was supposed to print out:
  AUX CH error happened

Was actually dead code. That's because the previous check (whether
the interrupt status indicated any errors) would have hit for all
errors anyway.

Let's combine the two error checks so we can actually see AUX CH
errors.  We'll also downgrade the message to a warning since some of
these types of errors might be expected for some displays.  If this
gets too noisy we can downgrade again to debug.

Cc: 征增 王 
Signed-off-by: Douglas Anderson 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 4eae206ec31b..58e8a28e99aa 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -1105,6 +1105,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
 struct drm_dp_aux_msg *msg)
 {
u32 reg;
+   u32 status_reg;
u8 *buffer = msg->buffer;
unsigned int i;
int num_transferred = 0;
@@ -1193,16 +1194,12 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
 
/* Clear interrupt source for AUX CH access error */
reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
-   if (reg & AUX_ERR) {
+   status_reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_STA);
+   if ((reg & AUX_ERR) || (status_reg & AUX_STATUS_MASK)) {
writel(AUX_ERR, dp->reg_base + ANALOGIX_DP_INT_STA);
-   goto aux_error;
-   }
 
-   /* Check AUX CH error access status */
-   reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_STA);
-   if ((reg & AUX_STATUS_MASK)) {
-   dev_err(dp->dev, "AUX CH error happened: %d\n\n",
-   reg & AUX_STATUS_MASK);
+   dev_warn(dp->dev, "AUX CH error happened: %#x (%d)\n",
+status_reg & AUX_STATUS_MASK, !!(reg & AUX_ERR));
goto aux_error;
}
 
-- 
2.14.1

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


[PATCH v3 08/43] drm/rockchip: Remove analogix psr worker

2018-01-31 Thread Thierry Escande
From: Sean Paul 

Now that the spinlocks and timers are gone, we can remove the psr
worker located in rockchip's analogix driver and do the enable/disable
directly. This should simplify the code and remove races on disable.

Cc: 征增 王 
Cc: Stéphane Marchesin 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 31 ++---
 1 file changed, 2 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 7d76ff47028d..36334839a3f8 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -71,10 +71,6 @@ struct rockchip_dp_device {
struct regmap*grf;
struct reset_control *rst;
 
-   struct work_struct   psr_work;
-   struct mutex psr_lock;
-   unsigned int psr_state;
-
const struct rockchip_dp_chip_data *data;
 
struct analogix_dp_device *adp;
@@ -84,28 +80,13 @@ struct rockchip_dp_device {
 static void analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)
 {
struct rockchip_dp_device *dp = to_dp(encoder);
+   int ret;
 
if (!analogix_dp_psr_supported(dp->adp))
return;
 
DRM_DEV_DEBUG(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
 
-   mutex_lock(&dp->psr_lock);
-   if (enabled)
-   dp->psr_state = EDP_VSC_PSR_STATE_ACTIVE;
-   else
-   dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
-
-   schedule_work(&dp->psr_work);
-   mutex_unlock(&dp->psr_lock);
-}
-
-static void analogix_dp_psr_work(struct work_struct *work)
-{
-   struct rockchip_dp_device *dp =
-   container_of(work, typeof(*dp), psr_work);
-   int ret;
-
ret = rockchip_drm_wait_vact_end(dp->encoder.crtc,
 PSR_WAIT_LINE_FLAG_TIMEOUT_MS);
if (ret) {
@@ -113,12 +94,10 @@ static void analogix_dp_psr_work(struct work_struct *work)
return;
}
 
-   mutex_lock(&dp->psr_lock);
-   if (dp->psr_state == EDP_VSC_PSR_STATE_ACTIVE)
+   if (enabled)
analogix_dp_enable_psr(dp->adp);
else
analogix_dp_disable_psr(dp->adp);
-   mutex_unlock(&dp->psr_lock);
 }
 
 static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
@@ -135,8 +114,6 @@ static int rockchip_dp_poweron(struct analogix_dp_plat_data 
*plat_data)
struct rockchip_dp_device *dp = to_dp(plat_data);
int ret;
 
-   cancel_work_sync(&dp->psr_work);
-
ret = clk_prepare_enable(dp->pclk);
if (ret < 0) {
DRM_DEV_ERROR(dp->dev, "failed to enable pclk %d\n", ret);
@@ -355,10 +332,6 @@ static int rockchip_dp_bind(struct device *dev, struct 
device *master,
dp->plat_data.power_off = rockchip_dp_powerdown;
dp->plat_data.get_modes = rockchip_dp_get_modes;
 
-   mutex_init(&dp->psr_lock);
-   dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
-   INIT_WORK(&dp->psr_work, analogix_dp_psr_work);
-
ret = rockchip_drm_psr_register(&dp->encoder, analogix_dp_psr_set);
if (ret < 0)
goto err_cleanup_encoder;
-- 
2.14.1

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


[PATCH v3 19/43] drm/bridge: analogix_dp: Ensure edp is disabled when shutting down the panel

2018-01-31 Thread Thierry Escande
From: Lin Huang 

When panel is shut down, we should make sure edp can be disabled to avoid
undefined behavior.

Cc: Stéphane Marchesin 
Signed-off-by: Lin Huang 
Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index c940a5bb80ac..fa4ef28e286f 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1161,6 +1161,12 @@ static int analogix_dp_set_bridge(struct 
analogix_dp_device *dp)
 
pm_runtime_get_sync(dp->dev);
 
+   ret = clk_prepare_enable(dp->clock);
+   if (ret < 0) {
+   DRM_ERROR("Failed to prepare_enable the clock clk [%d]\n", ret);
+   goto out_dp_clk_pre;
+   }
+
if (dp->plat_data->power_on)
dp->plat_data->power_on(dp->plat_data);
 
@@ -1192,6 +1198,8 @@ static int analogix_dp_set_bridge(struct 
analogix_dp_device *dp)
phy_power_off(dp->phy);
if (dp->plat_data->power_off)
dp->plat_data->power_off(dp->plat_data);
+   clk_disable_unprepare(dp->clock);
+out_dp_clk_pre:
pm_runtime_put_sync(dp->dev);
 
return ret;
@@ -1235,10 +1243,13 @@ static void analogix_dp_bridge_disable(struct 
drm_bridge *bridge)
 
disable_irq(dp->irq);
phy_power_off(dp->phy);
+   analogix_dp_set_analog_power_down(dp, POWER_ALL, 1);
 
if (dp->plat_data->power_off)
dp->plat_data->power_off(dp->plat_data);
 
+   clk_disable_unprepare(dp->clock);
+
pm_runtime_put_sync(dp->dev);
 
ret = analogix_dp_prepare_panel(dp, false, true);
-- 
2.14.1

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


[PATCH v3 23/43] drm/bridge: analogix_dp: Fix AUX_PD bit for Rockchip

2018-01-31 Thread Thierry Escande
From: zain wang 

There are some different bits between Rockchip and Exynos in register
"AUX_PD". This patch fixes the incorrect operations about it.

Cc: Douglas Anderson 
Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 117 --
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h |   2 +
 2 files changed, 65 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index bb72f8b0e603..dee1ba109b5f 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -248,76 +248,85 @@ void analogix_dp_set_analog_power_down(struct 
analogix_dp_device *dp,
 {
u32 reg;
u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
+   u32 mask;
 
if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
phy_pd_addr = ANALOGIX_DP_PD;
 
switch (block) {
case AUX_BLOCK:
-   if (enable) {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg |= AUX_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   } else {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg &= ~AUX_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   }
+   if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+   mask = RK_AUX_PD;
+   else
+   mask = AUX_PD;
+
+   reg = readl(dp->reg_base + phy_pd_addr);
+   if (enable)
+   reg |= mask;
+   else
+   reg &= ~mask;
+   writel(reg, dp->reg_base + phy_pd_addr);
break;
case CH0_BLOCK:
-   if (enable) {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg |= CH0_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   } else {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg &= ~CH0_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   }
+   mask = CH0_PD;
+   reg = readl(dp->reg_base + phy_pd_addr);
+
+   if (enable)
+   reg |= mask;
+   else
+   reg &= ~mask;
+   writel(reg, dp->reg_base + phy_pd_addr);
break;
case CH1_BLOCK:
-   if (enable) {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg |= CH1_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   } else {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg &= ~CH1_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   }
+   mask = CH1_PD;
+   reg = readl(dp->reg_base + phy_pd_addr);
+
+   if (enable)
+   reg |= mask;
+   else
+   reg &= ~mask;
+   writel(reg, dp->reg_base + phy_pd_addr);
break;
case CH2_BLOCK:
-   if (enable) {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg |= CH2_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   } else {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg &= ~CH2_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   }
+   mask = CH2_PD;
+   reg = readl(dp->reg_base + phy_pd_addr);
+
+   if (enable)
+   reg |= mask;
+   else
+   reg &= ~mask;
+   writel(reg, dp->reg_base + phy_pd_addr);
break;
case CH3_BLOCK:
-   if (enable) {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg |= CH3_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   } else {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg &= ~CH3_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   }
+   mask = CH3_PD;
+   reg = readl(dp->reg_base + phy_pd_addr);
+
+   if (enable)
+   reg |= mask;
+   else
+   reg &= ~mask;
+   writel(reg, dp->reg_base + phy_pd_addr);
break;
case ANALOG_TOTAL:
-   if (enable) {
-   reg = readl(dp->reg_base + phy_pd_addr);
-

Re: [PATCH] drm/edid: use false for boolean value

2018-01-31 Thread Gustavo A. R. Silva

Hi Daniel,

Quoting Daniel Vetter :


On Tue, Jan 23, 2018 at 10:46:07AM -0600, Gustavo A. R. Silva wrote:

Assign true or false to boolean variables instead of an integer value.

This issue was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 


Thanks for your patch.


---
 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..45a80d7 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2767,7 +2767,7 @@ do_detailed_mode(struct detailed_timing  
*timing, void *c)


drm_mode_probed_add(closure->connector, newmode);
closure->modes++;
-   closure->preferred = 0;
+   closure->preferred = false;


There's also

.preferred = 1,

in add_detailed_modes. Please fix that one up too for consistency, then
I'll merge your patch.



Sure. I'll send a new patch shortly.

I also need to update the Coccinelle script to catch those cases.

Thanks for the feedback.
--
Gustavo




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


[PATCH v3 28/43] drm/bridge: analogix_dp: Fix incorrect operations with register ANALOGIX_DP_FUNC_EN_1

2018-01-31 Thread Thierry Escande
From: zain wang 

Register ANALOGIX_DP_FUNC_EN_1(offset 0x18), Rockchip is different to
Exynos:

on Exynos edp phy,
BIT 7   MASTER_VID_FUNC_EN_N
BIT 6   reserved
BIT 5   SLAVE_VID_FUNC_EN_N

on Rockchip edp phy,
BIT 7   reserved
BIT 6   RK_VID_CAP_FUNC_EN_N
BIT 5   RK_VID_FIFO_FUNC_EN_N

So, we should do some private operations to Rockchip.

Cc: Tomasz Figa 
Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 19 ++-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h |  2 ++
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 02ab1aaa9993..4eae206ec31b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -126,9 +126,14 @@ void analogix_dp_reset(struct analogix_dp_device *dp)
analogix_dp_stop_video(dp);
analogix_dp_enable_video_mute(dp, 0);
 
-   reg = MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N |
-   AUD_FIFO_FUNC_EN_N | AUD_FUNC_EN_N |
-   HDCP_FUNC_EN_N | SW_FUNC_EN_N;
+   if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+   reg = RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N |
+   SW_FUNC_EN_N;
+   else
+   reg = MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N |
+   AUD_FIFO_FUNC_EN_N | AUD_FUNC_EN_N |
+   HDCP_FUNC_EN_N | SW_FUNC_EN_N;
+
writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
 
reg = SSC_FUNC_EN_N | AUX_FUNC_EN_N |
@@ -971,8 +976,12 @@ void analogix_dp_config_video_slave_mode(struct 
analogix_dp_device *dp)
u32 reg;
 
reg = readl(dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
-   reg &= ~(MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N);
-   reg |= MASTER_VID_FUNC_EN_N;
+   if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
+   reg &= ~(RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N);
+   } else {
+   reg &= ~(MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N);
+   reg |= MASTER_VID_FUNC_EN_N;
+   }
writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
 
reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
index b633a4a5082a..0cf27c731727 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
@@ -127,7 +127,9 @@
 
 /* ANALOGIX_DP_FUNC_EN_1 */
 #define MASTER_VID_FUNC_EN_N   (0x1 << 7)
+#define RK_VID_CAP_FUNC_EN_N   (0x1 << 6)
 #define SLAVE_VID_FUNC_EN_N(0x1 << 5)
+#define RK_VID_FIFO_FUNC_EN_N  (0x1 << 5)
 #define AUD_FIFO_FUNC_EN_N (0x1 << 4)
 #define AUD_FUNC_EN_N  (0x1 << 3)
 #define HDCP_FUNC_EN_N (0x1 << 2)
-- 
2.14.1

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


[PATCH v3 30/43] drm/bridge: analogix_dp: Reorder plat_data->power_off to happen sooner

2018-01-31 Thread Thierry Escande
From: Douglas Anderson 

The current user of the analogix power_off is "analogix_dp-rockchip".
That driver does this:
- deactivate PSR
- turn off a clock

Both of these things (especially deactive PSR) should be done before
we turn the PHY power off and turn off analog power.  Let's move the
callback up.

Note that without this patch (and with
https://patchwork.kernel.org/patch/9553349/ [seanpaul: this patch was
not applied, but it seems like the race can still occur]), I experienced
an error in reboot testing where one thread was at:

  rockchip_drm_psr_deactivate
  rockchip_dp_powerdown
  analogix_dp_bridge_disable
  drm_bridge_disable

...and the other thread was at:

  analogix_dp_send_psr_spd
  analogix_dp_enable_psr
  analogix_dp_psr_set
  psr_flush_handler

The flush handler thread was finding AUX channel errors and eventually
reported "Failed to apply PSR", where I had a kgdb breakpoint. Presumably
the device would have eventually given up and shut down anyway, but it
seems better to fix the order to be more correct.

Cc: Kristian H. Kristensen 
Signed-off-by: Douglas Anderson 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index f82e2a3d13bf..23404de7ffc9 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1341,12 +1341,13 @@ static void analogix_dp_bridge_disable(struct 
drm_bridge *bridge)
}
 
disable_irq(dp->irq);
-   phy_power_off(dp->phy);
-   analogix_dp_set_analog_power_down(dp, POWER_ALL, 1);
 
if (dp->plat_data->power_off)
dp->plat_data->power_off(dp->plat_data);
 
+   phy_power_off(dp->phy);
+   analogix_dp_set_analog_power_down(dp, POWER_ALL, 1);
+
clk_disable_unprepare(dp->clock);
 
pm_runtime_put_sync(dp->dev);
-- 
2.14.1

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


[PATCH v3 22/43] drm/bridge: analogix_dp: Check dpcd write/read status

2018-01-31 Thread Thierry Escande
From: Lin Huang 

We need to check the dpcd write/read return value to see whether the
write/read was successful

Cc: Kristian H. Kristensen 
Signed-off-by: Lin Huang 
Signed-off-by: zain wang 
Signed-off-by: Douglas Anderson 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 182 +++--
 1 file changed, 135 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 846574d0dcb0..082b4e024052 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -160,80 +160,137 @@ int analogix_dp_disable_psr(struct analogix_dp_device 
*dp)
 }
 EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
 
-static bool analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
+static int analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
 {
unsigned char psr_version;
+   int ret;
+
+   ret = drm_dp_dpcd_readb(&dp->aux, DP_PSR_SUPPORT, &psr_version);
+   if (ret != 1) {
+   dev_err(dp->dev, "failed to get PSR version, disable it\n");
+   return ret;
+   }
 
-   drm_dp_dpcd_readb(&dp->aux, DP_PSR_SUPPORT, &psr_version);
dev_dbg(dp->dev, "Panel PSR version : %x\n", psr_version);
 
-   return (psr_version & DP_PSR_IS_SUPPORTED) ? true : false;
+   dp->psr_enable = (psr_version & DP_PSR_IS_SUPPORTED) ? true : false;
+
+   return 0;
 }
 
-static void analogix_dp_enable_sink_psr(struct analogix_dp_device *dp)
+static int analogix_dp_enable_sink_psr(struct analogix_dp_device *dp)
 {
unsigned char psr_en;
+   int ret;
 
/* Disable psr function */
-   drm_dp_dpcd_readb(&dp->aux, DP_PSR_EN_CFG, &psr_en);
+   ret = drm_dp_dpcd_readb(&dp->aux, DP_PSR_EN_CFG, &psr_en);
+   if (ret != 1) {
+   dev_err(dp->dev, "failed to get psr config\n");
+   goto end;
+   }
+
psr_en &= ~DP_PSR_ENABLE;
-   drm_dp_dpcd_writeb(&dp->aux, DP_PSR_EN_CFG, psr_en);
+   ret = drm_dp_dpcd_writeb(&dp->aux, DP_PSR_EN_CFG, psr_en);
+   if (ret != 1) {
+   dev_err(dp->dev, "failed to disable panel psr\n");
+   goto end;
+   }
 
/* Main-Link transmitter remains active during PSR active states */
psr_en = DP_PSR_MAIN_LINK_ACTIVE | DP_PSR_CRC_VERIFICATION;
-   drm_dp_dpcd_writeb(&dp->aux, DP_PSR_EN_CFG, psr_en);
+   ret = drm_dp_dpcd_writeb(&dp->aux, DP_PSR_EN_CFG, psr_en);
+   if (ret != 1) {
+   dev_err(dp->dev, "failed to set panel psr\n");
+   goto end;
+   }
 
/* Enable psr function */
psr_en = DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE |
 DP_PSR_CRC_VERIFICATION;
-   drm_dp_dpcd_writeb(&dp->aux, DP_PSR_EN_CFG, psr_en);
+   ret = drm_dp_dpcd_writeb(&dp->aux, DP_PSR_EN_CFG, psr_en);
+   if (ret != 1) {
+   dev_err(dp->dev, "failed to set panel psr\n");
+   goto end;
+   }
 
analogix_dp_enable_psr_crc(dp);
+
+   return 0;
+end:
+   dev_err(dp->dev, "enable psr fail, force to disable psr\n");
+   dp->psr_enable = false;
+
+   return ret;
 }
 
-static void
+static int
 analogix_dp_enable_rx_to_enhanced_mode(struct analogix_dp_device *dp,
   bool enable)
 {
u8 data;
+   int ret;
 
-   drm_dp_dpcd_readb(&dp->aux, DP_LANE_COUNT_SET, &data);
+   ret = drm_dp_dpcd_readb(&dp->aux, DP_LANE_COUNT_SET, &data);
+   if (ret != 1)
+   return ret;
 
if (enable)
-   drm_dp_dpcd_writeb(&dp->aux, DP_LANE_COUNT_SET,
-  DP_LANE_COUNT_ENHANCED_FRAME_EN |
-   DPCD_LANE_COUNT_SET(data));
+   ret = drm_dp_dpcd_writeb(&dp->aux, DP_LANE_COUNT_SET,
+DP_LANE_COUNT_ENHANCED_FRAME_EN |
+DPCD_LANE_COUNT_SET(data));
else
-   drm_dp_dpcd_writeb(&dp->aux, DP_LANE_COUNT_SET,
-  DPCD_LANE_COUNT_SET(data));
+   ret = drm_dp_dpcd_writeb(&dp->aux, DP_LANE_COUNT_SET,
+DPCD_LANE_COUNT_SET(data));
+
+   return ret < 0 ? ret : 0;
 }
 
-static int analogix_dp_is_enhanced_mode_available(struct analogix_dp_device 
*dp)
+static int analogix_dp_is_enhanced_mode_available(struct analogix_dp_device 
*dp,
+ u8 *enhanced_mode_support)
 {
u8 data;
-   int retval;
+   int ret;
 
-   drm_dp_dpcd_readb(&dp->aux, DP_MAX_LANE_COUNT, &data);
-   retval = DPCD_ENHANCED_FRAME_CAP(data);
+   ret = drm_dp_dpcd_readb(&dp->aux, DP_MAX_LANE_COUNT, &data);
+   if (ret != 1) {
+   *enhanced_mode_support 

[PATCH v2 02/10] video: fbdev: kconfig: Remove empty help text

2018-01-31 Thread Ulf Magnusson
In preparation for adding a warning ("kconfig: Warn if help text is
blank"): https://lkml.org/lkml/2018/1/30/516

Signed-off-by: Ulf Magnusson 
---
 drivers/video/fbdev/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 6962b4583fd7..11e699f1062b 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1156,7 +1156,6 @@ config FB_I810_I2C
bool "Enable DDC Support"
depends on FB_I810 && FB_I810_GTF
select FB_DDC
-   help
 
 config FB_LE80578
tristate "Intel LE80578 (Vermilion) support"
-- 
2.14.1

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


[PATCH v3 15/43] drm/bridge: analogix_dp: Don't use fast link training when panel just powered up

2018-01-31 Thread Thierry Escande
From: zain wang 

Panel would reset its setting when it powers down. It would forget the last
succeeded link training setting. So we can't use the last successful link
training setting to do fast link training. Let's reset fast_train_enable in
analogix_dp_bridge_disable();

Cc: Stéphane Marchesin 
Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 9 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 +-
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 8ef9e31c6713..179c2106b8a2 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -579,14 +579,14 @@ static int analogix_dp_process_equalizer_training(struct 
analogix_dp_device *dp)
if (retval != 1) {
dev_err(dp->dev, "failed to read downspread %d\n",
retval);
-   dp->fast_train_support = false;
+   dp->fast_train_enable = false;
} else {
-   dp->fast_train_support =
+   dp->fast_train_enable =
(spread & DP_NO_AUX_HANDSHAKE_LINK_TRAINING) ?
true : false;
}
dev_dbg(dp->dev, "fast link training %s\n",
-   dp->fast_train_support ? "supported" : "unsupported");
+   dp->fast_train_enable ? "supported" : "unsupported");
 
/* set enhanced mode if available */
analogix_dp_set_enhanced_mode(dp);
@@ -793,7 +793,7 @@ static int analogix_dp_fast_link_train(struct 
analogix_dp_device *dp)
 
 static int analogix_dp_train_link(struct analogix_dp_device *dp)
 {
-   if (dp->fast_train_support)
+   if (dp->fast_train_enable)
return analogix_dp_fast_link_train(dp);
 
return analogix_dp_full_link_train(dp, dp->video_info.max_lane_count,
@@ -1198,6 +1198,7 @@ static void analogix_dp_bridge_disable(struct drm_bridge 
*bridge)
DRM_ERROR("failed to setup the panel ret = %d\n", ret);
 
dp->psr_enable = false;
+   dp->fast_train_enable = false;
dp->dpms_mode = DRM_MODE_DPMS_OFF;
 }
 
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 6a96ef7e6934..403ff853464b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -173,7 +173,7 @@ struct analogix_dp_device {
int hpd_gpio;
boolforce_hpd;
boolpsr_enable;
-   boolfast_train_support;
+   boolfast_train_enable;
 
struct mutexpanel_lock;
boolpanel_is_modeset;
-- 
2.14.1

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


[PATCH v3 11/43] drm/bridge: analogix_dp: add fast link train for eDP

2018-01-31 Thread Thierry Escande
From: zain wang 

We would meet a short black screen when exit PSR with the full link
training, In this case, we should use fast link train instead of full
link training.

Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 142 -
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   3 +
 2 files changed, 114 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 84141571e960..e0775adf80b3 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -10,17 +10,18 @@
 * option) any later version.
 */
 
-#include 
-#include 
-#include 
 #include 
-#include 
+#include 
+#include 
+#include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
-#include 
-#include 
 #include 
+#include 
 
 #include 
 #include 
@@ -35,6 +36,8 @@
 
 #define to_dp(nm)  container_of(nm, struct analogix_dp_device, nm)
 
+static const bool verify_fast_training;
+
 struct bridge_init {
struct i2c_client *client;
struct device_node *node;
@@ -528,7 +531,7 @@ static int analogix_dp_process_equalizer_training(struct 
analogix_dp_device *dp)
 {
int lane, lane_count, retval;
u32 reg;
-   u8 link_align, link_status[2], adjust_request[2];
+   u8 link_align, link_status[2], adjust_request[2], spread;
 
usleep_range(400, 401);
 
@@ -571,6 +574,20 @@ static int analogix_dp_process_equalizer_training(struct 
analogix_dp_device *dp)
dev_dbg(dp->dev, "final lane count = %.2x\n",
dp->link_train.lane_count);
 
+   retval = drm_dp_dpcd_readb(&dp->aux, DP_MAX_DOWNSPREAD,
+  &spread);
+   if (retval != 1) {
+   dev_err(dp->dev, "failed to read downspread %d\n",
+   retval);
+   dp->fast_train_support = false;
+   } else {
+   dp->fast_train_support =
+   (spread & DP_NO_AUX_HANDSHAKE_LINK_TRAINING) ?
+   true : false;
+   }
+   dev_dbg(dp->dev, "fast link training %s\n",
+   dp->fast_train_support ? "supported" : "unsupported");
+
/* set enhanced mode if available */
analogix_dp_set_enhanced_mode(dp);
dp->link_train.lt_state = FINISHED;
@@ -627,10 +644,12 @@ static void analogix_dp_get_max_rx_lane_count(struct 
analogix_dp_device *dp,
*lane_count = DPCD_MAX_LANE_COUNT(data);
 }
 
-static void analogix_dp_init_training(struct analogix_dp_device *dp,
- enum link_lane_count_type max_lane,
- int max_rate)
+static int analogix_dp_full_link_train(struct analogix_dp_device *dp,
+  u32 max_lanes, u32 max_rate)
 {
+   int retval = 0;
+   bool training_finished = false;
+
/*
 * MACRO_RST must be applied after the PLL_LOCK to avoid
 * the DP inter pair skew issue for at least 10 us
@@ -656,18 +675,13 @@ static void analogix_dp_init_training(struct 
analogix_dp_device *dp,
}
 
/* Setup TX lane count & rate */
-   if (dp->link_train.lane_count > max_lane)
-   dp->link_train.lane_count = max_lane;
+   if (dp->link_train.lane_count > max_lanes)
+   dp->link_train.lane_count = max_lanes;
if (dp->link_train.link_rate > max_rate)
dp->link_train.link_rate = max_rate;
 
/* All DP analog module power up */
analogix_dp_set_analog_power_down(dp, POWER_ALL, 0);
-}
-
-static int analogix_dp_sw_link_training(struct analogix_dp_device *dp)
-{
-   int retval = 0, training_finished = 0;
 
dp->link_train.lt_state = START;
 
@@ -702,22 +716,88 @@ static int analogix_dp_sw_link_training(struct 
analogix_dp_device *dp)
return retval;
 }
 
-static int analogix_dp_set_link_train(struct analogix_dp_device *dp,
- u32 count, u32 bwtype)
+static int analogix_dp_fast_link_train(struct analogix_dp_device *dp)
 {
-   int i;
-   int retval;
+   int i, ret;
+   u8 link_align, link_status[2];
+   enum pll_status status;
 
-   for (i = 0; i < DP_TIMEOUT_LOOP_COUNT; i++) {
-   analogix_dp_init_training(dp, count, bwtype);
-   retval = analogix_dp_sw_link_training(dp);
-   if (retval == 0)
-   break;
+   analogix_dp_reset_macro(dp);
 
-   usleep_range(100, 110);
+   analogix_dp_set_link_bandwidth(dp, dp->link_train.link_rate);
+   analogix_dp_set_lane_count(dp, dp->link_train.lane_count);
+
+   for (i = 0; i < dp->link_

[PATCH v3 12/43] drm/rockchip: Only wait for panel ACK on PSR entry

2018-01-31 Thread Thierry Escande
From: zain wang 

We currently wait for the panel to mirror our intended PSR state
before continuing on both PSR enter and PSR exit. This is really
only important to do when we're entering PSR, since we want to
be sure the last frame we pushed is being served from the panel's
internal fb before shutting down the soc blocks (vop/analogix).

This patch changes the behavior such that we only wait for the
panel to complete the PSR transition when we're entering PSR, and
to skip verification when we're exiting.

Cc: Stéphane Marchesin 
Cc: Sonny Rao 
Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 4 ++--
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 5 -
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index e0775adf80b3..49a05eac41c1 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -125,7 +125,7 @@ int analogix_dp_enable_psr(struct analogix_dp_device *dp)
psr_vsc.DB0 = 0;
psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
 
-   return analogix_dp_send_psr_spd(dp, &psr_vsc);
+   return analogix_dp_send_psr_spd(dp, &psr_vsc, true);
 }
 EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
 
@@ -151,7 +151,7 @@ int analogix_dp_disable_psr(struct analogix_dp_device *dp)
if (ret != 1)
dev_err(dp->dev, "Failed to set DP Power0 %d\n", ret);
 
-   return analogix_dp_send_psr_spd(dp, &psr_vsc);
+   return analogix_dp_send_psr_spd(dp, &psr_vsc, false);
 }
 EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
 
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 920607d7eb3e..6a96ef7e6934 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -253,7 +253,7 @@ void analogix_dp_enable_scrambling(struct 
analogix_dp_device *dp);
 void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
 void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp);
 int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
-struct edp_vsc_psr *vsc);
+struct edp_vsc_psr *vsc, bool blocking);
 ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
 struct drm_dp_aux_msg *msg);
 
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 005a3f7005d2..9df2f3ef000c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -1007,7 +1007,7 @@ static ssize_t analogix_dp_get_psr_status(struct 
analogix_dp_device *dp)
 }
 
 int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
-struct edp_vsc_psr *vsc)
+struct edp_vsc_psr *vsc, bool blocking)
 {
unsigned int val;
int ret;
@@ -1053,6 +1053,9 @@ int analogix_dp_send_psr_spd(struct analogix_dp_device 
*dp,
val |= IF_EN;
writel(val, dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
 
+   if (!blocking)
+   return 0;
+
ret = readx_poll_timeout(analogix_dp_get_psr_status, dp, psr_status,
psr_status >= 0 &&
((vsc->DB1 && psr_status == DP_PSR_SINK_ACTIVE_RFB) ||
-- 
2.14.1

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


[PATCH v3 38/43] drm/rockchip: Cancel PSR enable work before changing the state

2018-01-31 Thread Thierry Escande
From: Tomasz Figa 

If we change the state first and reschedule later, we might have the
work executed according to previous scheduled time and end up with PSR
re-enabled instantly. Let's cancel the work before changing the state.

While at it, consolidate psr_disable_handler() to just call
rockchip_drm_do_flush(), as they are both supposed to do the same.

Signed-off-by: Tomasz Figa 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index a107845ba97c..c8655e625ba2 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -138,18 +138,6 @@ static void psr_flush_handler(struct work_struct *work)
mutex_unlock(&psr->lock);
 }
 
-static void psr_disable_handler(struct work_struct *work)
-{
-   struct psr_drv *psr = container_of(work, struct psr_drv, disable_work);
-
-   /* If the state has changed since we initiated the flush, do nothing */
-   mutex_lock(&psr->lock);
-   if (psr->state == PSR_ENABLE)
-   psr_set_state_locked(psr, PSR_FLUSH);
-   mutex_unlock(&psr->lock);
-   mod_delayed_work(system_wq, &psr->flush_work, PSR_FLUSH_TIMEOUT_MS);
-}
-
 /**
  * rockchip_drm_psr_activate - activate PSR on the given pipe
  * @encoder: encoder to obtain the PSR encoder
@@ -198,6 +186,7 @@ EXPORT_SYMBOL(rockchip_drm_psr_deactivate);
 
 static void rockchip_drm_do_flush(struct psr_drv *psr)
 {
+   cancel_delayed_work_sync(&psr->flush_work);
psr_set_state(psr, PSR_FLUSH);
mod_delayed_work(system_wq, &psr->flush_work, PSR_FLUSH_TIMEOUT_MS);
 }
@@ -244,6 +233,13 @@ void rockchip_drm_psr_flush_all(struct drm_device *dev)
 }
 EXPORT_SYMBOL(rockchip_drm_psr_flush_all);
 
+static void psr_disable_handler(struct work_struct *work)
+{
+   struct psr_drv *psr = container_of(work, struct psr_drv, disable_work);
+
+   rockchip_drm_do_flush(psr);
+}
+
 static void psr_input_event(struct input_handle *handle,
unsigned int type, unsigned int code,
int value)
-- 
2.14.1

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


[PATCH v4] Fix loading of module radeonfb on PowerMac

2018-01-31 Thread Mathieu Malaterre
When the linux kernel is build with (typical kernel ship with Debian
installer):

CONFIG_FB_OF=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_FB_RADEON=m

The offb driver takes precedence over module radeonfb. It is then
impossible to load the module, error reported is:

[   96.551486] radeonfb :00:10.0: enabling device (0006 -> 0007)
[   96.551526] radeonfb :00:10.0: BAR 0: can't reserve [mem 
0x9800-0x9fff pref]
[   96.551531] radeonfb (:00:10.0): cannot request region 0.
[   96.551545] radeonfb: probe of :00:10.0 failed with error -16

This patch reproduce the behavior of the module radeon, so as to make it
possible to load radeonfb when offb is first loaded, see commit a56f7428d753
("drm/radeon: Add early unregister of firmware fb's").

It should be noticed that `offb_destroy` is never called which explain the
need to skip error detection on the radeon side.

Signed-off-by: Mathieu Malaterre 
Link: https://bugs.debian.org/826629#57
Link: https://bugzilla.kernel.org/show_bug.cgi?id=119741
Suggested-by: Lennart Sorensen 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Benjamin Herrenschmidt 
Cc: Tomi Valkeinen 
---
v2: Only fails when CONFIG_PCC is not set
v3: Only fails when CONFIG_FB_OF is not set, CONFIG_PCC was too broad. Since 
the conflicts in region is due to OFfb explicitly refers to it.
v4: Use drm_fb_helper_remove_conflicting_framebuffers from drm_fb_helper

 drivers/video/fbdev/aty/radeon_base.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/video/fbdev/aty/radeon_base.c 
b/drivers/video/fbdev/aty/radeon_base.c
index 4d77daeecf99..ae669f424537 100644
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -70,6 +70,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -2259,6 +2260,23 @@ static const struct bin_attribute edid2_attr = {
.read   = radeon_show_edid2,
 };
 
+static int radeon_kick_out_firmware_fb(struct pci_dev *pdev)
+{
+   struct apertures_struct *ap;
+
+   ap = alloc_apertures(1);
+   if (!ap)
+   return -ENOMEM;
+
+   ap->ranges[0].base = pci_resource_start(pdev, 0);
+   ap->ranges[0].size = pci_resource_len(pdev, 0);
+
+   drm_fb_helper_remove_conflicting_framebuffers(ap, KBUILD_MODNAME, 
false);
+
+   kfree(ap);
+
+   return 0;
+}
 
 static int radeonfb_pci_register(struct pci_dev *pdev,
 const struct pci_device_id *ent)
@@ -2312,19 +2330,27 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
rinfo->fb_base_phys = pci_resource_start (pdev, 0);
rinfo->mmio_base_phys = pci_resource_start (pdev, 2);
 
+   ret = radeon_kick_out_firmware_fb(pdev);
+   if (ret)
+   return ret;
+
/* request the mem regions */
ret = pci_request_region(pdev, 0, "radeonfb framebuffer");
if (ret < 0) {
+#ifndef CONFIG_FB_OF
printk( KERN_ERR "radeonfb (%s): cannot request region 0.\n",
pci_name(rinfo->pdev));
goto err_release_fb;
+#endif
}
 
ret = pci_request_region(pdev, 2, "radeonfb mmio");
if (ret < 0) {
+#ifndef CONFIG_FB_OF
printk( KERN_ERR "radeonfb (%s): cannot request region 2.\n",
pci_name(rinfo->pdev));
goto err_release_pci0;
+#endif
}
 
/* map the regions */
@@ -2509,10 +2535,12 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
iounmap(rinfo->mmio_base);
 err_release_pci2:
pci_release_region(pdev, 2);
+#ifndef CONFIG_FB_OF
 err_release_pci0:
pci_release_region(pdev, 0);
 err_release_fb:
 framebuffer_release(info);
+#endif
 err_disable:
 err_out:
return ret;
-- 
2.11.0

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


[PATCH v3 24/43] drm/bridge: analogix_dp: Reset aux channel if an error occurred

2018-01-31 Thread Thierry Escande
From: Lin Huang 

AUX errors are caused by many different reasons. We may not know what
happened in aux channel on failure, so let's reset aux channel if some
errors occurred.

Cc: 征增 王 
Cc: Douglas Anderson 
Signed-off-by: Lin Huang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index dee1ba109b5f..7b7fd227e1f9 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -466,6 +466,10 @@ void analogix_dp_init_aux(struct analogix_dp_device *dp)
reg = RPLY_RECEIV | AUX_ERR;
writel(reg, dp->reg_base + ANALOGIX_DP_INT_STA);
 
+   analogix_dp_set_analog_power_down(dp, AUX_BLOCK, true);
+   usleep_range(10, 11);
+   analogix_dp_set_analog_power_down(dp, AUX_BLOCK, false);
+
analogix_dp_reset_aux(dp);
 
/* Disable AUX transaction H/W retry */
@@ -1159,7 +1163,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
 reg, !(reg & AUX_EN), 25, 500 * 1000);
if (ret) {
dev_err(dp->dev, "AUX CH enable timeout!\n");
-   return -ETIMEDOUT;
+   goto aux_error;
}
 
/* TODO: Wait for an interrupt instead of looping? */
@@ -1168,7 +1172,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
 reg, reg & RPLY_RECEIV, 10, 20 * 1000);
if (ret) {
dev_err(dp->dev, "AUX CH cmd reply timeout!\n");
-   return -ETIMEDOUT;
+   goto aux_error;
}
 
/* Clear interrupt source for AUX CH command reply */
@@ -1178,7 +1182,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
if (reg & AUX_ERR) {
writel(AUX_ERR, dp->reg_base + ANALOGIX_DP_INT_STA);
-   return -EREMOTEIO;
+   goto aux_error;
}
 
/* Check AUX CH error access status */
@@ -1186,7 +1190,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
if ((reg & AUX_STATUS_MASK)) {
dev_err(dp->dev, "AUX CH error happened: %d\n\n",
reg & AUX_STATUS_MASK);
-   return -EREMOTEIO;
+   goto aux_error;
}
 
if (msg->request & DP_AUX_I2C_READ) {
@@ -1212,4 +1216,10 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
msg->reply = DP_AUX_NATIVE_REPLY_ACK;
 
return num_transferred > 0 ? num_transferred : -EBUSY;
+
+aux_error:
+   /* if aux err happen, reset aux */
+   analogix_dp_init_aux(dp);
+
+   return -EREMOTEIO;
 }
-- 
2.14.1

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


[PATCH v3 17/43] drm/bridge: analogix_dp: Wait for HPD signal before configuring link

2018-01-31 Thread Thierry Escande
From: zain wang 

According to DP spec v1.3 chap 3.5.1.2 Link Training, Link Policy Maker
must first detect that the HPD signal is asserted high by the Downstream
Device before establishing a link with it.

Cc: Stéphane Marchesin 
Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index ba2506e17f6d..c940a5bb80ac 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1170,6 +1170,17 @@ static int analogix_dp_set_bridge(struct 
analogix_dp_device *dp)
if (ret)
goto out_dp_init;
 
+   /*
+* According to DP spec v1.3 chap 3.5.1.2 Link Training,
+* We should first make sure the HPD signal is asserted high by device
+* when we want to establish a link with it.
+*/
+   ret = analogix_dp_detect_hpd(dp);
+   if (ret) {
+   DRM_ERROR("failed to get hpd single ret = %d\n", ret);
+   goto out_dp_init;
+   }
+
ret = analogix_dp_commit(dp);
if (ret)
goto out_dp_init;
-- 
2.14.1

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


[PATCH v3 21/43] drm/bridge: analogix_dp: Fix incorrect usage of enhanced mode

2018-01-31 Thread Thierry Escande
From: zain wang 

Enhanced mode is required by the eDP 1.2 specification, and not doing it
early could result in a period of time where we have a link transmitting
idle packets without it. Since there is no reason to disable it, we just
enable it at the beginning of link training and then keep it on all the
time.

Cc: Tomasz Figa 
Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 9df92dc54dbe..846574d0dcb0 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -281,6 +281,8 @@ static int analogix_dp_link_start(struct analogix_dp_device 
*dp)
retval = drm_dp_dpcd_write(&dp->aux, DP_LINK_BW_SET, buf, 2);
if (retval < 0)
return retval;
+   /* set enhanced mode if available */
+   analogix_dp_set_enhanced_mode(dp);
 
/* Set TX pre-emphasis to minimum */
for (lane = 0; lane < lane_count; lane++)
@@ -593,8 +595,6 @@ static int analogix_dp_process_equalizer_training(struct 
analogix_dp_device *dp)
dev_dbg(dp->dev, "fast link training %s\n",
dp->fast_train_enable ? "supported" : "unsupported");
 
-   /* set enhanced mode if available */
-   analogix_dp_set_enhanced_mode(dp);
dp->link_train.lt_state = FINISHED;
 
return 0;
@@ -944,8 +944,6 @@ static int analogix_dp_commit(struct analogix_dp_device *dp)
}
 
analogix_dp_enable_scramble(dp, 1);
-   analogix_dp_enable_rx_to_enhanced_mode(dp, 1);
-   analogix_dp_enable_enhanced_mode(dp, 1);
 
analogix_dp_init_video(dp);
ret = analogix_dp_config_video(dp);
-- 
2.14.1

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


[PATCH v3 07/43] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR

2018-01-31 Thread Thierry Escande
From: Yakir Yang 

Make sure the request PSR state takes effect in analogix_dp_send_psr_spd()
function, or print the sink PSR error state if we failed to apply the
requested PSR setting.

Cc: 征增 王 
Cc: Stéphane Marchesin 
Signed-off-by: Yakir Yang 
[seanpaul changed timeout loop to a readx poll]
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  6 ++--
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  6 ++--
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 35 +++---
 3 files changed, 37 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 1477ea9ba85d..b52de046f5f1 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -122,8 +122,7 @@ int analogix_dp_enable_psr(struct analogix_dp_device *dp)
psr_vsc.DB0 = 0;
psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
 
-   analogix_dp_send_psr_spd(dp, &psr_vsc);
-   return 0;
+   return analogix_dp_send_psr_spd(dp, &psr_vsc);
 }
 EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
 
@@ -149,8 +148,7 @@ int analogix_dp_disable_psr(struct analogix_dp_device *dp)
if (ret != 1)
dev_err(dp->dev, "Failed to set DP Power0 %d\n", ret);
 
-   analogix_dp_send_psr_spd(dp, &psr_vsc);
-   return 0;
+   return analogix_dp_send_psr_spd(dp, &psr_vsc);
 }
 EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
 
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 5c6a28806129..b039b28d8fcc 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -20,6 +20,8 @@
 #define MAX_CR_LOOP 5
 #define MAX_EQ_LOOP 5
 
+#define DP_TIMEOUT_PSR_LOOP_MS 300
+
 /* DP_MAX_LANE_COUNT */
 #define DPCD_ENHANCED_FRAME_CAP(x) (((x) >> 7) & 0x1)
 #define DPCD_MAX_LANE_COUNT(x) ((x) & 0x1f)
@@ -247,8 +249,8 @@ void analogix_dp_config_video_slave_mode(struct 
analogix_dp_device *dp);
 void analogix_dp_enable_scrambling(struct analogix_dp_device *dp);
 void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
 void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp);
-void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
- struct edp_vsc_psr *vsc);
+int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
+struct edp_vsc_psr *vsc);
 ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
 struct drm_dp_aux_msg *msg);
 
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 303083ad28e3..005a3f7005d2 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -10,10 +10,11 @@
  * option) any later version.
  */
 
-#include 
-#include 
 #include 
+#include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -992,10 +993,25 @@ void analogix_dp_enable_psr_crc(struct analogix_dp_device 
*dp)
writel(PSR_VID_CRC_ENABLE, dp->reg_base + ANALOGIX_DP_CRC_CON);
 }
 
-void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
- struct edp_vsc_psr *vsc)
+static ssize_t analogix_dp_get_psr_status(struct analogix_dp_device *dp)
+{
+   ssize_t val;
+   u8 status;
+
+   val = drm_dp_dpcd_readb(&dp->aux, DP_PSR_STATUS, &status);
+   if (val < 0) {
+   dev_err(dp->dev, "PSR_STATUS read failed ret=%zd", val);
+   return val;
+   }
+   return status;
+}
+
+int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
+struct edp_vsc_psr *vsc)
 {
unsigned int val;
+   int ret;
+   ssize_t psr_status;
 
/* don't send info frame */
val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
@@ -1036,6 +1052,17 @@ void analogix_dp_send_psr_spd(struct analogix_dp_device 
*dp,
val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
val |= IF_EN;
writel(val, dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
+
+   ret = readx_poll_timeout(analogix_dp_get_psr_status, dp, psr_status,
+   psr_status >= 0 &&
+   ((vsc->DB1 && psr_status == DP_PSR_SINK_ACTIVE_RFB) ||
+   (!vsc->DB1 && psr_status == DP_PSR_SINK_INACTIVE)), 1500,
+   DP_TIMEOUT_PSR_LOOP_MS * 1000);
+   if (ret) {
+   dev_warn(dp->dev, "Failed to apply PSR %d\n", ret);
+   return ret;
+   }
+   return 0;
 }
 
 ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
-- 
2.14.1

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

[PATCH v3 36/43] drm/rockchip: analogix_dp: Do not call Analogix code before bind

2018-01-31 Thread Thierry Escande
From: Tomasz Figa 

Driver callbacks, such as system suspend or resume can be called any
time, specifically they can be called before the component bind
callback. Let's use dp->adp pointer as a safeguard and skip calling
Analogix entry points if it is an ERR_PTR().

Signed-off-by: Tomasz Figa 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 23317a2269e1..6d45d62466b3 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -368,6 +368,8 @@ static void rockchip_dp_unbind(struct device *dev, struct 
device *master,
analogix_dp_unbind(dp->adp);
rockchip_drm_psr_unregister(&dp->encoder);
dp->encoder.funcs->destroy(&dp->encoder);
+
+   dp->adp = ERR_PTR(-ENODEV);
 }
 
 static const struct component_ops rockchip_dp_component_ops = {
@@ -391,6 +393,7 @@ static int rockchip_dp_probe(struct platform_device *pdev)
return -ENOMEM;
 
dp->dev = dev;
+   dp->adp = ERR_PTR(-ENODEV);
dp->plat_data.panel = panel;
 
ret = rockchip_dp_of_probe(dp);
@@ -414,6 +417,9 @@ static int rockchip_dp_suspend(struct device *dev)
 {
struct rockchip_dp_device *dp = dev_get_drvdata(dev);
 
+   if (IS_ERR(dp->adp))
+   return 0;
+
return analogix_dp_suspend(dp->adp);
 }
 
@@ -421,6 +427,9 @@ static int rockchip_dp_resume(struct device *dev)
 {
struct rockchip_dp_device *dp = dev_get_drvdata(dev);
 
+   if (IS_ERR(dp->adp))
+   return 0;
+
return analogix_dp_resume(dp->adp);
 }
 #endif
-- 
2.14.1

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


[PATCH v3 03/43] drm/rockchip: Respect page offset for PRIME mmap calls

2018-01-31 Thread Thierry Escande
From: Ørjan Eide 

When mapping external DMA-bufs through the PRIME mmap call, we might be
given an offset which has to be respected. However for the internal DRM
GEM mmap path, we have to ignore the fake mmap offset used to identify
the buffer only. Currently the code always zeroes out vma->vm_pgoff,
which breaks the former.

This patch fixes the problem by moving the vm_pgoff assignment to a
function that is used only for GEM mmap path, so that the PRIME path
retains the original offset.

Cc: Daniel Kurtz 
Signed-off-by: Ørjan Eide 
Signed-off-by: Tomasz Figa 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Tested-by: Heiko Stuebner 
---
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 5d52020deca1..074db7a92809 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -264,7 +264,6 @@ static int rockchip_drm_gem_object_mmap(struct 
drm_gem_object *obj,
 * VM_PFNMAP flag that was set by drm_gem_mmap_obj()/drm_gem_mmap().
 */
vma->vm_flags &= ~VM_PFNMAP;
-   vma->vm_pgoff = 0;
 
if (rk_obj->pages)
ret = rockchip_drm_gem_object_mmap_iommu(obj, vma);
@@ -299,6 +298,12 @@ int rockchip_gem_mmap(struct file *filp, struct 
vm_area_struct *vma)
if (ret)
return ret;
 
+   /*
+* Set vm_pgoff (used as a fake buffer offset by DRM) to 0 and map the
+* whole buffer from the start.
+*/
+   vma->vm_pgoff = 0;
+
obj = vma->vm_private_data;
 
return rockchip_drm_gem_object_mmap(obj, vma);
-- 
2.14.1

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


Re: [PATCH 2/5] drm: add ARM flush implementation

2018-01-31 Thread Russell King - ARM Linux
On Tue, Jan 30, 2018 at 11:14:36AM +0100, Daniel Vetter wrote:
> On Tue, Jan 23, 2018 at 06:56:03PM -0800, Gurchetan Singh wrote:
> > The dma_cache_maint_page function is important for cache maintenance on
> > ARM32 (this was determined via testing).
> > 
> > Since we desire direct control of the caches in drm_cache.c, let's make
> > a copy of the function, rename it and use it.
> > 
> > v2: Don't use DMA API, call functions directly (Daniel)
> > 
> > Signed-off-by: Gurchetan Singh 
> 
> fwiw, in principle, this approach has my Ack from the drm side.
> 
> But if we can't get any agreement from the arch side then I guess we'll
> just have to suck it up and mandate that any dma-buf on ARM32 must be wc
> mapped, always. Not sure that's a good idea either, but should at least
> get things moving.

Let me expand on my objection, as I find your tone to be problematical
here.

The patch 2 (which is the earliest patch in this series) makes use of
facilities such as dmac_map_area(), and those are defined as macros in
arch/arm/mm/mm.h.  I see no way that drm_cache.c can pick up on that
_unless_ there's another patch (maybe that's patch 1) which moves the
definition.

dmac_map_area() is non-trivial to export (it's not a function, it's
macro which either points to a function or a function pointer structure
member) so it's likely that this patch also breaks building DRM as a
module.

We've been here before with drivers abusing the architecture private APIs,
which is _exactly_ why dmac_map_area() is defined in arch/arm/mm.h and not
in some kernel-wide asm header file - it's an implementation detail of the
architectures DMA API that drivers have no business mucking about with.

I've always said if the interfaces don't do what you want, talk to
architecture people, don't go poking about in architecture private parts
of the kernel and start abusing stuff.  I say this because years ago, we
had people doing _exactly_ that for the older virtually cached ARMs.  Then
ARMv6 came along, which needed an entire revamp of the architecture cache
interfaces, and lo and behold, drivers got broken because of this kind of
abuse.  IOW, abusing interfaces makes kernel maintenance harder.

For example, interfaces designed for flushing the cache when page tables
get torn down were abused in drivers to flush data for DMA or coherency
purposes, which meant that on ARMv6, where we no longer needed to flush
for page table maintenance, suddenly the interfaces that drivers were
using became no-ops.

In this case, dmac_map_area() exists to perform any cache maintenance
for the kernel view of that memory required for a non-coherent DMA
mapping.  What it does depends on the processsor and the requested
DMA_xxx type - it _may_ invalidate (discard) or clean (writeback but
leave in the cache) cache lines, or do nothing.

dmac_unmap_area() has the same issues - what it does depends on what
operation is being requested and what the processor requires to
achieve coherency.

The two functions are designed to work _together_, dmac_map_area()
before the DMA operation and dmac_unmap_area() after the DMA operation.
Only when they are both used together do you get the correct behaviour.

These functions are only guaranteed to operate on the kernel mapping
passed in as virtual addresses to the dmac_* functions.  They make no
guarantees about other mappings of the same memory elsewhere in the
system, which, depending on the architecture of the caches, may also
contain dirty cache lines (the same comment applies to the DMA API too.)
On certain cache architectures (VIPT) where colouring effects apply,
flushing the kernel mapping may not even be appropriate if the desired
effect is to flush data from a user mapping.

This is exactly why abusing APIs (like what is done in this patch) is
completely unacceptable from the architecture point of view - while
it may _appear_ to work, it may only work for one class of CPU or one
implementation.

Hence why the dmac_{un,}map_area() interfaces are not exported to
drivers.  You can't just abuse one of them.  They are a pair that
must be used together, and the DMA API knows that, and the DMA API
requirements ensure that happens.  It's not really surprising, these
functions were written to support the DMA API, and the DMA API is
the kernel-wide interface to these functions.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 29/43] drm/bridge: analogix_dp: Move fast link training detect to set_bridge

2018-01-31 Thread Thierry Escande
From: zain wang 

It's too early to detect fast link training, if other step after it
failed, we will set fast_link flag to 1, and retry set_bridge again. In
this case we will power down and power up panel power supply, and we
will do fast link training since we have set fast_link flag to 1. In
fact, we should do full link training now, not the fast link training.
So we should move the fast link detection at the end of set_bridge.

Cc: Tomasz Figa 
Signed-off-by: zain wang 
Signed-off-by: Douglas Anderson 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 42 +-
 1 file changed, 26 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index a64f0c3e795c..f82e2a3d13bf 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -601,7 +601,7 @@ static int analogix_dp_process_equalizer_training(struct 
analogix_dp_device *dp)
 {
int lane, lane_count, retval;
u32 reg;
-   u8 link_align, link_status[2], adjust_request[2], spread;
+   u8 link_align, link_status[2], adjust_request[2];
 
usleep_range(400, 401);
 
@@ -645,20 +645,6 @@ static int analogix_dp_process_equalizer_training(struct 
analogix_dp_device *dp)
dev_dbg(dp->dev, "final lane count = %.2x\n",
dp->link_train.lane_count);
 
-   retval = drm_dp_dpcd_readb(&dp->aux, DP_MAX_DOWNSPREAD,
-  &spread);
-   if (retval != 1) {
-   dev_err(dp->dev, "failed to read downspread %d\n",
-   retval);
-   dp->fast_train_enable = false;
-   } else {
-   dp->fast_train_enable =
-   (spread & DP_NO_AUX_HANDSHAKE_LINK_TRAINING) ?
-   true : false;
-   }
-   dev_dbg(dp->dev, "fast link training %s\n",
-   dp->fast_train_enable ? "supported" : "unsupported");
-
dp->link_train.lt_state = FINISHED;
 
return 0;
@@ -1003,6 +989,22 @@ static irqreturn_t analogix_dp_irq_thread(int irq, void 
*arg)
return IRQ_HANDLED;
 }
 
+static int analogix_dp_fast_link_train_detection(struct analogix_dp_device *dp)
+{
+   int ret;
+   u8 spread;
+
+   ret = drm_dp_dpcd_readb(&dp->aux, DP_MAX_DOWNSPREAD, &spread);
+   if (ret != 1) {
+   dev_err(dp->dev, "failed to read downspread %d\n", ret);
+   return ret;
+   }
+   dp->fast_train_enable = !!(spread & DP_NO_AUX_HANDSHAKE_LINK_TRAINING);
+   dev_dbg(dp->dev, "fast link training %s\n",
+   dp->fast_train_enable ? "supported" : "unsupported");
+   return 0;
+}
+
 static int analogix_dp_commit(struct analogix_dp_device *dp)
 {
int ret;
@@ -1045,8 +1047,16 @@ static int analogix_dp_commit(struct analogix_dp_device 
*dp)
if (ret)
return ret;
 
-   if (dp->psr_enable)
+   if (dp->psr_enable) {
ret = analogix_dp_enable_sink_psr(dp);
+   if (ret)
+   return ret;
+   }
+
+   /* Check whether panel supports fast training */
+   ret =  analogix_dp_fast_link_train_detection(dp);
+   if (ret)
+   dp->psr_enable = false;
 
return ret;
 }
-- 
2.14.1

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


[PATCH v3 01/43] drm/rockchip: Get rid of unnecessary struct fields

2018-01-31 Thread Thierry Escande
From: Tomasz Figa 

This patch removes unused fields from vop structure.

Signed-off-by: Tomasz Figa 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index ba7505292b78..7a137bc5708c 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -95,9 +95,6 @@ struct vop {
struct drm_device *drm_dev;
bool is_enabled;
 
-   /* mutex vsync_ work */
-   struct mutex vsync_mutex;
-   bool vsync_work_pending;
struct completion dsp_hold_completion;
 
/* protected by dev->event_lock */
@@ -1567,8 +1564,6 @@ static int vop_bind(struct device *dev, struct device 
*master, void *data)
spin_lock_init(&vop->reg_lock);
spin_lock_init(&vop->irq_lock);
 
-   mutex_init(&vop->vsync_mutex);
-
ret = devm_request_irq(dev, vop->irq, vop_isr,
   IRQF_SHARED, dev_name(dev), vop);
if (ret)
-- 
2.14.1

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


[PATCH v3 27/43] drm/bridge: analogix_dp: Fix timeout of video streamclk config

2018-01-31 Thread Thierry Escande
From: zain wang 

The STRM_VALID bit in register ANALOGIX_DP_SYS_CTL_3 may be unstable,
so we may hit the error log "Timeout of video streamclk ok" since
checked this unstable bit.
In fact, we can go continue and the streamclk is ok if we wait enough time,
it does no effect on display.
Let's change this error to warn.

Cc: Douglas Anderson 
Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index e925c62eaadb..a64f0c3e795c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -921,8 +921,9 @@ static int analogix_dp_config_video(struct 
analogix_dp_device *dp)
done_count = 0;
}
if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
-   dev_err(dp->dev, "Timeout of video streamclk ok\n");
-   return -ETIMEDOUT;
+   dev_warn(dp->dev,
+"Ignoring timeout of video streamclk ok\n");
+   break;
}
 
usleep_range(1000, 1001);
-- 
2.14.1

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


[PATCH v3 40/43] drm/rockchip: psr: Sanitize semantics of allow/disallow API

2018-01-31 Thread Thierry Escande
From: Tomasz Figa 

Currently both rockchip_drm_psr_activate() and _deactivate() only set the
boolean "active" flag without actually making sure that hardware state
complies with it.

Since we are going to extend the usage of this API to properly lock PSR
for the duration of atomic commits, we change the semantics in following
way:
 - a counter is used to track the number of disallow requests,
 - PSR is actually disabled in hardware on first disallow request,
 - PSR enable work is scheduled on last disallow request.

The above allows using the API as a way to deterministically synchronize
PSR state changes with other DRM events, i.e. atomic commits and cursor
updates. As a nice side effect, the naming is sorted out and we have
"inhibit" for stopping the software logic and "enable" for hardware
state.

Signed-off-by: Tomasz Figa 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c |  4 +-
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 57 ++---
 drivers/gpu/drm/rockchip/rockchip_drm_psr.h |  4 +-
 3 files changed, 46 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 6d45d62466b3..080f05352195 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -134,7 +134,7 @@ static int rockchip_dp_poweron_end(struct 
analogix_dp_plat_data *plat_data)
 {
struct rockchip_dp_device *dp = to_dp(plat_data);
 
-   return rockchip_drm_psr_activate(&dp->encoder);
+   return rockchip_drm_psr_inhibit_put(&dp->encoder);
 }
 
 static int rockchip_dp_powerdown(struct analogix_dp_plat_data *plat_data)
@@ -142,7 +142,7 @@ static int rockchip_dp_powerdown(struct 
analogix_dp_plat_data *plat_data)
struct rockchip_dp_device *dp = to_dp(plat_data);
int ret;
 
-   ret = rockchip_drm_psr_deactivate(&dp->encoder);
+   ret = rockchip_drm_psr_inhibit_get(&dp->encoder);
if (ret != 0)
return ret;
 
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index 448c5fde241c..e7e16d92d5a1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -27,7 +27,7 @@ struct psr_drv {
struct drm_encoder  *encoder;
 
struct mutexlock;
-   boolactive;
+   int inhibit_count;
boolenabled;
 
struct delayed_work flush_work;
@@ -76,7 +76,7 @@ static int psr_set_state_locked(struct psr_drv *psr, bool 
enable)
 {
int ret;
 
-   if (!psr->active)
+   if (psr->inhibit_count > 0)
return -EINVAL;
 
if (enable == psr->enabled)
@@ -101,13 +101,18 @@ static void psr_flush_handler(struct work_struct *work)
 }
 
 /**
- * rockchip_drm_psr_activate - activate PSR on the given pipe
+ * rockchip_drm_psr_inhibit_put - release PSR inhibit on given encoder
  * @encoder: encoder to obtain the PSR encoder
  *
+ * Decrements PSR inhibit count on given encoder. Should be called only
+ * for a PSR inhibit count increment done before. If PSR inhibit counter
+ * reaches zero, PSR flush work is scheduled to make the hardware enter
+ * PSR mode in PSR_FLUSH_TIMEOUT_MS.
+ *
  * Returns:
  * Zero on success, negative errno on failure.
  */
-int rockchip_drm_psr_activate(struct drm_encoder *encoder)
+int rockchip_drm_psr_inhibit_put(struct drm_encoder *encoder)
 {
struct psr_drv *psr = find_psr_by_encoder(encoder);
 
@@ -115,21 +120,29 @@ int rockchip_drm_psr_activate(struct drm_encoder *encoder)
return PTR_ERR(psr);
 
mutex_lock(&psr->lock);
-   psr->active = true;
+   --psr->inhibit_count;
+   if (!psr->inhibit_count)
+   mod_delayed_work(system_wq, &psr->flush_work,
+PSR_FLUSH_TIMEOUT_MS);
mutex_unlock(&psr->lock);
 
return 0;
 }
-EXPORT_SYMBOL(rockchip_drm_psr_activate);
+EXPORT_SYMBOL(rockchip_drm_psr_inhibit_put);
 
 /**
- * rockchip_drm_psr_deactivate - deactivate PSR on the given pipe
+ * rockchip_drm_psr_inhibit_get - acquire PSR inhibit on given encoder
  * @encoder: encoder to obtain the PSR encoder
  *
+ * Increments PSR inhibit count on given encoder. This function guarantees
+ * that after it returns PSR is turned off on given encoder and no PSR-related
+ * hardware state change occurs at least until a matching call to
+ * rockchip_drm_psr_inhibit_put() is done.
+ *
  * Returns:
  * Zero on success, negative errno on failure.
  */
-int rockchip_drm_psr_deactivate(struct drm_encoder *encoder)
+int rockchip_drm_psr_inhibit_get(struct drm_encoder *encoder)
 {
struct psr_drv *psr = find_psr_by_encoder(encoder);
 
@@ -137,15 +150,15 @@ int rockchip_drm_psr_deactivate(struct drm_encoder 
*encoder)
return PTR_ERR(psr);
 
 

[PATCH v3 34/43] drm/rockchip: pre dither down when output bpc is 8bit

2018-01-31 Thread Thierry Escande
From: Mark Yao 

Some encoder have a crc verification check, crc check fail if
input and output data is not equal.

That means encoder input and output need use same color depth,
vop can output 10bit data to encoder, but some panel only support
8bit depth, that would make crc check die.

So pre dither down vop data to 8bit if panel's bpc is 8.

Signed-off-by: Mark Yao 
[seanpaul resolved conflict in rockchip_drm_vop.c]
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
---
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 2 ++
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 6 ++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 1 +
 5 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 8c884f9ce713..b3f46ed24cdc 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -218,6 +218,7 @@ rockchip_dp_drm_encoder_atomic_check(struct drm_encoder 
*encoder,
  struct drm_connector_state *conn_state)
 {
struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc_state);
+   struct drm_display_info *di = &conn_state->connector->display_info;
 
/*
 * The hardware IC designed that VOP must output the RGB10 video
@@ -229,6 +230,7 @@ rockchip_dp_drm_encoder_atomic_check(struct drm_encoder 
*encoder,
 
s->output_mode = ROCKCHIP_OUT_MODE_;
s->output_type = DRM_MODE_CONNECTOR_eDP;
+   s->output_bpc = di->bpc;
 
return 0;
 }
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 9c064a40458b..3a6ebfc26036 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -36,6 +36,7 @@ struct rockchip_crtc_state {
struct drm_crtc_state base;
int output_type;
int output_mode;
+   int output_bpc;
 };
 #define to_rockchip_crtc_state(s) \
container_of(s, struct rockchip_crtc_state, base)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index bf4b1a2f3fa4..4abb9d72d814 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -937,6 +937,12 @@ static void vop_crtc_atomic_enable(struct drm_crtc *crtc,
if (s->output_mode == ROCKCHIP_OUT_MODE_ &&
!(vop_data->feature & VOP_FEATURE_OUTPUT_RGB10))
s->output_mode = ROCKCHIP_OUT_MODE_P888;
+
+   if (s->output_mode == ROCKCHIP_OUT_MODE_ && s->output_bpc == 8)
+   VOP_REG_SET(vop, common, pre_dither_down, 1);
+   else
+   VOP_REG_SET(vop, common, pre_dither_down, 0);
+
VOP_REG_SET(vop, common, out_mode, s->output_mode);
 
VOP_REG_SET(vop, modeset, htotal_pw, (htotal << 16) | hsync_len);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 56bbd2e2a8ef..084acdd0019a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -67,6 +67,7 @@ struct vop_common {
struct vop_reg cfg_done;
struct vop_reg dsp_blank;
struct vop_reg data_blank;
+   struct vop_reg pre_dither_down;
struct vop_reg dither_down;
struct vop_reg dither_up;
struct vop_reg gate_en;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 2e4eea3459fe..08023d3ecb76 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -264,6 +264,7 @@ static const struct vop_common rk3288_common = {
.standby = VOP_REG_SYNC(RK3288_SYS_CTRL, 0x1, 22),
.gate_en = VOP_REG(RK3288_SYS_CTRL, 0x1, 23),
.mmu_en = VOP_REG(RK3288_SYS_CTRL, 0x1, 20),
+   .pre_dither_down = VOP_REG(RK3288_DSP_CTRL1, 0x1, 1),
.dither_down = VOP_REG(RK3288_DSP_CTRL1, 0xf, 1),
.dither_up = VOP_REG(RK3288_DSP_CTRL1, 0x1, 6),
.data_blank = VOP_REG(RK3288_DSP_CTRL0, 0x1, 19),
-- 
2.14.1

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


[PATCH v3 35/43] drm/bridge: analogix_dp: Split the platform-specific poweron in two parts

2018-01-31 Thread Thierry Escande
From: Douglas Anderson 

Some of the platform-specific stuff in rockchip_dp_poweron() needs to
happen before the generic code.  Some needs to happen after.  Let's
split the callback in two.

Specifically we can't start doing PSR work until _after_ the whole
controller is up, so don't set the enable until the end.

Cc: Kristian H. Kristensen 
Signed-off-by: Douglas Anderson 
[seanpaul added exynos change]
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  7 +--
 drivers/gpu/drm/exynos/exynos_dp.c |  2 +-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 12 ++--
 include/drm/bridge/analogix_dp.h   |  3 ++-
 4 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 23404de7ffc9..8217c106c72b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1264,8 +1264,8 @@ static int analogix_dp_set_bridge(struct 
analogix_dp_device *dp)
goto out_dp_clk_pre;
}
 
-   if (dp->plat_data->power_on)
-   dp->plat_data->power_on(dp->plat_data);
+   if (dp->plat_data->power_on_start)
+   dp->plat_data->power_on_start(dp->plat_data);
 
phy_power_on(dp->phy);
 
@@ -1290,6 +1290,9 @@ static int analogix_dp_set_bridge(struct 
analogix_dp_device *dp)
goto out_dp_init;
}
 
+   if (dp->plat_data->power_on_end)
+   dp->plat_data->power_on_end(dp->plat_data);
+
enable_irq(dp->irq);
return 0;
 
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c 
b/drivers/gpu/drm/exynos/exynos_dp.c
index 33319a858f3a..b316249a3f89 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -162,7 +162,7 @@ static int exynos_dp_bind(struct device *dev, struct device 
*master, void *data)
dp->drm_dev = drm_dev;
 
dp->plat_data.dev_type = EXYNOS_DP;
-   dp->plat_data.power_on = exynos_dp_poweron;
+   dp->plat_data.power_on_start = exynos_dp_poweron;
dp->plat_data.power_off = exynos_dp_poweroff;
dp->plat_data.attach = exynos_dp_bridge_attach;
dp->plat_data.get_modes = exynos_dp_get_modes;
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index b3f46ed24cdc..23317a2269e1 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -109,7 +109,7 @@ static int rockchip_dp_pre_init(struct rockchip_dp_device 
*dp)
return 0;
 }
 
-static int rockchip_dp_poweron(struct analogix_dp_plat_data *plat_data)
+static int rockchip_dp_poweron_start(struct analogix_dp_plat_data *plat_data)
 {
struct rockchip_dp_device *dp = to_dp(plat_data);
int ret;
@@ -127,6 +127,13 @@ static int rockchip_dp_poweron(struct 
analogix_dp_plat_data *plat_data)
return ret;
}
 
+   return ret;
+}
+
+static int rockchip_dp_poweron_end(struct analogix_dp_plat_data *plat_data)
+{
+   struct rockchip_dp_device *dp = to_dp(plat_data);
+
return rockchip_drm_psr_activate(&dp->encoder);
 }
 
@@ -330,7 +337,8 @@ static int rockchip_dp_bind(struct device *dev, struct 
device *master,
dp->plat_data.encoder = &dp->encoder;
 
dp->plat_data.dev_type = dp->data->chip_type;
-   dp->plat_data.power_on = rockchip_dp_poweron;
+   dp->plat_data.power_on_start = rockchip_dp_poweron_start;
+   dp->plat_data.power_on_end = rockchip_dp_poweron_end;
dp->plat_data.power_off = rockchip_dp_powerdown;
dp->plat_data.get_modes = rockchip_dp_get_modes;
 
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index c2788483c882..b384f7e8d14a 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -32,7 +32,8 @@ struct analogix_dp_plat_data {
struct drm_encoder *encoder;
struct drm_connector *connector;
 
-   int (*power_on)(struct analogix_dp_plat_data *);
+   int (*power_on_start)(struct analogix_dp_plat_data *);
+   int (*power_on_end)(struct analogix_dp_plat_data *);
int (*power_off)(struct analogix_dp_plat_data *);
int (*attach)(struct analogix_dp_plat_data *, struct drm_bridge *,
  struct drm_connector *);
-- 
2.14.1

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


[Bug 104806] plasmashell and other KDE binaries start to segfault after updating Mesa to 18.0.0 (radeon)

2018-01-31 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=104806

--- Comment #15 from Michel Dänzer  ---
(In reply to Matt Turner from comment #14)
> That commit is not in any released version of libdrm. Please do a release
> containing it.

It'll be in the next release. I don't see the need to cut a release
specifically for such a cosmetic issue, but feel free to do it if you disagree.
:)

-- 
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 104876] [CI] incompletes caused by temporary Jenkins configuration problem

2018-01-31 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=104876

Bug ID: 104876
   Summary: [CI] incompletes caused by temporary Jenkins
configuration  problem
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: IGT
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: marta.lofst...@intel.com

Below incompletes on CI_DRM_3697 happen approximately all within 30 seconds
after testing started. Since there was a know Jenkins configuration issue
associated with that runs it is probable that tese incompletes was caused by
Jenkins.

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3697/shard-glkb4/igt@kms_vbl...@pipe-a-ts-continuation-modeset-hang.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3697/shard-snb3/igt@gem_exec_paral...@render.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3697/shard-apl3/igt@kms_chv_cursor_f...@pipe-a-128x128-bottom-edge.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3697/shard-glkb6/igt@gem_cach...@read-writes.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3697/shard-glkb6/i...@testdisplay.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3697/shard-apl4/igt@kms_vbl...@pipe-b-query-idle-hang.html

-- 
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 104876] [CI] incompletes caused by temporary Jenkins configuration problem

2018-01-31 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=104876

Marta Löfstedt  changed:

   What|Removed |Added

 Whiteboard||ReadyForDev

-- 
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 104876] [CI] incompletes caused by temporary Jenkins configuration problem

2018-01-31 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=104876

Marta Löfstedt  changed:

   What|Removed |Added

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

--- Comment #1 from Marta Löfstedt  ---
This early incomplete pattern was not reproduced on runs after CI_DRM_3697.

-- 
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 104876] [CI] incompletes caused by temporary Jenkins configuration problem

2018-01-31 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=104876

Marta Löfstedt  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
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] mm/swap: add function get_total_swap_pages to expose total_swap_pages

2018-01-31 Thread Chunming Zhou
Discussed with Roger just now, we can try "void si_swapinfo(struct 
sysinfo *val)" function to get the total swap space.


Regards,

David Zhou


On 2018年01月31日 16:12, Christian König wrote:
Yeah, indeed. But what we could do is to rely on a fixed limit like 
the Intel driver does and I suggested before.


E.g. don't copy anything into a shmemfile when there is only x MB of 
swap space left.


Roger can you test that approach once more with your fix for the OOM 
issues in the page fault handler?


Thanks,
Christian.

Am 31.01.2018 um 09:08 schrieb He, Roger:
I think this patch isn't need at all. You can directly read 
total_swap_pages variable in TTM.


Because the variable is not exported by EXPORT_SYMBOL_GPL. So direct 
using will result in:

"WARNING: "total_swap_pages" [drivers/gpu/drm/ttm/ttm.ko] undefined!".

Thanks
Roger(Hongbo.He)
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On 
Behalf Of Chunming Zhou

Sent: Wednesday, January 31, 2018 3:15 PM
To: He, Roger ; dri-devel@lists.freedesktop.org
Cc: linux...@kvack.org; linux-ker...@vger.kernel.org; Koenig, 
Christian 
Subject: Re: [PATCH] mm/swap: add function get_total_swap_pages to 
expose total_swap_pages


Hi Roger,

I think this patch isn't need at all. You can directly read 
total_swap_pages variable in TTM. See the comment:


/* protected with swap_lock. reading in vm_swap_full() doesn't need 
lock */ long total_swap_pages;


there are many places using it directly, you just couldn't change its 
value. Reading it doesn't need lock.



Regards,

David Zhou


On 2018年01月29日 16:29, Roger He wrote:

ttm module needs it to determine its internal parameter setting.

Signed-off-by: Roger He 
---
   include/linux/swap.h |  6 ++
   mm/swapfile.c    | 15 +++
   2 files changed, 21 insertions(+)

diff --git a/include/linux/swap.h b/include/linux/swap.h
index c2b8128..708d66f 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -484,6 +484,7 @@ extern int try_to_free_swap(struct page *);
   struct backing_dev_info;
   extern int init_swap_address_space(unsigned int type, unsigned 
long nr_pages);

   extern void exit_swap_address_space(unsigned int type);
+extern long get_total_swap_pages(void);
      #else /* CONFIG_SWAP */
   @@ -516,6 +517,11 @@ static inline void show_swap_cache_info(void)
   {
   }
   +long get_total_swap_pages(void)
+{
+    return 0;
+}
+
   #define free_swap_and_cache(e) ({(is_migration_entry(e) || 
is_device_private_entry(e));})
   #define swapcache_prepare(e) ({(is_migration_entry(e) || 
is_device_private_entry(e));})

   diff --git a/mm/swapfile.c b/mm/swapfile.c
index 3074b02..a0062eb 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -98,6 +98,21 @@ static atomic_t proc_poll_event = ATOMIC_INIT(0);
      atomic_t nr_rotate_swap = ATOMIC_INIT(0);
   +/*
+ * expose this value for others use
+ */
+long get_total_swap_pages(void)
+{
+    long ret;
+
+    spin_lock(&swap_lock);
+    ret = total_swap_pages;
+    spin_unlock(&swap_lock);
+
+    return ret;
+}
+EXPORT_SYMBOL_GPL(get_total_swap_pages);
+
   static inline unsigned char swap_count(unsigned char ent)
   {
   return ent & ~SWAP_HAS_CACHE;    /* may include SWAP_HAS_CONT 
flag */

___
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] dma-fence: add comment for WARN_ON in dma_fence_release()

2018-01-31 Thread Oded Gabbay
On Tue, Jan 30, 2018 at 12:33 PM, Daniel Vetter  wrote:
> On Mon, Jan 29, 2018 at 05:40:02PM +0200, Oded Gabbay wrote:
>> In dma_fence_release() there is a WARN_ON which could be triggered by
>> several cases of wrong dma-fence usage. This patch adds a comment to
>> explain two use-cases to help driver developers that use dma-fence
>> and trigger that WARN_ON to better understand the reasons for it.
>>
>> Signed-off-by: Oded Gabbay 
>
> Not sure how useful this is, trying to do anything with a dma_fence while
> not holding a reference is just plain buggy. If you do that, then all
> kinds of use-after-free hilarity can happen. Trying to enumerate all the
> ways you can get refcounting wrong seems futile.
>
> What we maybe could do is a simple one-line like
>
> /* Failed to signal before release, could be a refcounting issue. */
>
> I think this is generally a true statement and more useful hint for the
> next convoluted scenario (which in all likelihood will be different from
> yours).
> -Daniel
>
>> ---
>>  drivers/dma-buf/dma-fence.c | 33 +
>>  1 file changed, 33 insertions(+)
>>
>> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
>> index 5d101c4053e0..a7170ab23ec0 100644
>> --- a/drivers/dma-buf/dma-fence.c
>> +++ b/drivers/dma-buf/dma-fence.c
>> @@ -171,6 +171,39 @@ void dma_fence_release(struct kref *kref)
>>
>>   trace_dma_fence_destroy(fence);
>>
>> + /*
>> +  * If the WARN_ON below is triggered it could be because the dma fence
>> +  * was not signaled and therefore, the cb list is still not empty
>> +  * because the cb functions were not called.
>> +  *
>> +  * A more subtle case is where the fence got signaled by a thread that
>> +  * didn't hold a ref to the fence. The following describes the 
>> scenario:
>> +  *
>> +  *  Thread AThread B
>> +  *----
>> +  * calls dma_fence_signal() {
>> +  *  set signal bit
>> +  *
>> +  *scheduled out
>> +  *  ---> calls dma_fence_wait_timeout() and
>> +  *   returns immediately
>> +  *
>> +  *   calls dma_fence_put()
>> +  * |
>> +  * |thread A doesn't hold ref
>> +  * |to fence so ref goes to 0
>> +  * |and release is called
>> +  * |
>> +  * -> dma_fence_release()
>> +  *|
>> +  *-> WARN_ON triggered
>> +  *
>> +  *  go over CB list,
>> +  *  call each CB and remove it
>> +  *  }
>> +  *
>> +  *
>> +  */
>>   WARN_ON(!list_empty(&fence->cb_list));
>>
>>   if (fence->ops->release)
>> --
>> 2.14.3
>>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Hi Daniel,
Yeah, I get what you are saying.
Can I add your RB to the one-liner version ?

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


[Bug 104306] Mesa 17.3 breaks Firefox and other Xwayland apps on AMD HD7750

2018-01-31 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=104306

Michel Dänzer  changed:

   What|Removed |Added

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

--- Comment #17 from Michel Dänzer  ---
Thanks for the report, fixed in Git master (and should get backported to a
future 17.3.y release):

Commit: 1cf1bf32eff5ffca0b928c0884b0e792207b61b7
URL:   
http://cgit.freedesktop.org/mesa/mesa/commit/?id=1cf1bf32eff5ffca0b928c0884b0e792207b61b7

Author: Michel Dänzer 
Date:   Fri Jan 26 18:32:32 2018 +0100

winsys/radeon: Compute is_displayable in surf_drm_to_winsys

-- 
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 104880] No sound via DP on R9 Fury (4.14 + DC patches)

2018-01-31 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=104880

Bug ID: 104880
   Summary: No sound via DP on R9 Fury (4.14 + DC patches)
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: lakos...@altlinux.org

Created attachment 137079
  --> https://bugs.freedesktop.org/attachment.cgi?id=137079&action=edit
dmesg

Greetings!

Trying to make DP sound work on my R9 Fury card.

The problem: no sound caps are detected for monitor via DP

Monitor ASUS PB278 supports DP sound playback (tested with nvidia card and
older R9 2x card), but it's not detected during boot or plug/unplug operations

dmesg:
(did unplug and plugged again)
[  175.415648] [drm] Rx Caps: 
[  175.549293] [drm] SADs count is: -2, don't need to read it
[  175.554060] [drm] HBRx4 pass VS=0, PE=0
[  175.554363] [drm] ASUS PB278: [Block 0] 
[  175.554367] [drm] ASUS PB278: [Block 1] 
[  175.554373] [drm] dc_link_detect: manufacturer_id = 6904, product_id = 27A3,
serial_number = 8C18, manufacture_week = 30, manufacture_year = 26,
display_name = ASUS PB278, speaker_flag = 0, audio_mode_count = 0
[  175.554978] [drm] {2560x1440, 2720x1481@241500Khz}
[  175.577625] [drm] HBRx4 pass VS=0, PE=0
[  293.823823] [drm] Rx Caps: 
[  293.952473] [drm] SADs count is: -2, don't need to read it
[  293.957217] [drm] HBRx4 pass VS=0, PE=0
[  293.957516] [drm] ASUS PB278: [Block 0] 
[  293.957520] [drm] ASUS PB278: [Block 1] 
[  293.957526] [drm] dc_link_detect: manufacturer_id = 6904, product_id = 27A3,
serial_number = 8C18, manufacture_week = 30, manufacture_year = 26,
display_name = ASUS PB278, speaker_flag = 0, audio_mode_count = 0
[  293.958130] [drm] {2560x1440, 2720x1481@241500Khz}

As you see speaker_flag and audio_mode_count all zero and /proc/asound/<*>/eld*
info all empty:

[lakostis@lks HDMI]$ fgrep -r monitor eld*
eld#0.0:monitor_present 0
eld#0.1:monitor_present 0
eld#0.2:monitor_present 0
eld#0.3:monitor_present 0
eld#0.4:monitor_present 0
eld#0.5:monitor_present 0

glxinfo:
name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: X.Org (0x1002)
Device: AMD Radeon (TM) R9 Fury Series (FIJI / DRM 3.23.0 /
4.14.0-lks-wks-alt10, LLVM 6.0.0) (0x7300)
Version: 17.3.3
Accelerated: yes
Video memory: 4060MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1
Memory info (GL_ATI_meminfo):
VBO free memory - total: 4059 MB, largest block: 4059 MB
VBO free aux. memory - total: 4092 MB, largest block: 4092 MB
Texture free memory - total: 4059 MB, largest block: 4059 MB
Texture free aux. memory - total: 4092 MB, largest block: 4092 MB
Renderbuffer free memory - total: 4059 MB, largest block: 4059 MB
Renderbuffer free aux. memory - total: 4092 MB, largest block: 4092 MB
Memory info (GL_NVX_gpu_memory_info):
Dedicated video memory: 4060 MB
Total available memory: 8153 MB
Currently available dedicated video memory: 4059 MB
OpenGL vendor string: X.Org
OpenGL renderer string: AMD Radeon (TM) R9 Fury Series (FIJI / DRM 3.23.0 /
4.14.0-lks-wks-alt10, LLVM 6.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.3.3
(git-80f5f27)
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 17.3.3 (git-80f5f27)
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.1 Mesa 17.3.3 (git-80f5f27)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10

Mesalib - 17.3.3
Kernel - 4.14.15 + DC patches till end of Oct 2017.

Module params for amdgpu:
$ cat /etc/modprobe.d/amdgpu.conf
# enable DRM extra debugging messages
#options drm debug=0x1e

options amdgpu si_support=0 dc=1 audio=1
options radeon si_support=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 104880] No sound via DP on R9 Fury (4.14 + DC patches)

2018-01-31 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=104880

Konstantin A. Lepikhov  changed:

   What|Removed |Added

   Hardware|Other   |x86-64 (AMD64)
 OS|All |Linux (All)

-- 
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 104880] No sound via DP on R9 Fury (4.14 + DC patches)

2018-01-31 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=104880

--- Comment #1 from Konstantin A. Lepikhov  ---
Created attachment 137080
  --> https://bugs.freedesktop.org/attachment.cgi?id=137080&action=edit
dmesg w/ drm debug and dc_log=1

Added dmesg with enabled debugging from drm and 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: [PATCH] dma-fence: add comment for WARN_ON in dma_fence_release()

2018-01-31 Thread Daniel Vetter
On Wed, Jan 31, 2018 at 11:03:39AM +0200, Oded Gabbay wrote:
> On Tue, Jan 30, 2018 at 12:33 PM, Daniel Vetter  wrote:
> > On Mon, Jan 29, 2018 at 05:40:02PM +0200, Oded Gabbay wrote:
> >> In dma_fence_release() there is a WARN_ON which could be triggered by
> >> several cases of wrong dma-fence usage. This patch adds a comment to
> >> explain two use-cases to help driver developers that use dma-fence
> >> and trigger that WARN_ON to better understand the reasons for it.
> >>
> >> Signed-off-by: Oded Gabbay 
> >
> > Not sure how useful this is, trying to do anything with a dma_fence while
> > not holding a reference is just plain buggy. If you do that, then all
> > kinds of use-after-free hilarity can happen. Trying to enumerate all the
> > ways you can get refcounting wrong seems futile.
> >
> > What we maybe could do is a simple one-line like
> >
> > /* Failed to signal before release, could be a refcounting issue. */
> >
> > I think this is generally a true statement and more useful hint for the
> > next convoluted scenario (which in all likelihood will be different from
> > yours).
> > -Daniel
> >
> >> ---
> >>  drivers/dma-buf/dma-fence.c | 33 +
> >>  1 file changed, 33 insertions(+)
> >>
> >> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> >> index 5d101c4053e0..a7170ab23ec0 100644
> >> --- a/drivers/dma-buf/dma-fence.c
> >> +++ b/drivers/dma-buf/dma-fence.c
> >> @@ -171,6 +171,39 @@ void dma_fence_release(struct kref *kref)
> >>
> >>   trace_dma_fence_destroy(fence);
> >>
> >> + /*
> >> +  * If the WARN_ON below is triggered it could be because the dma 
> >> fence
> >> +  * was not signaled and therefore, the cb list is still not empty
> >> +  * because the cb functions were not called.
> >> +  *
> >> +  * A more subtle case is where the fence got signaled by a thread 
> >> that
> >> +  * didn't hold a ref to the fence. The following describes the 
> >> scenario:
> >> +  *
> >> +  *  Thread AThread B
> >> +  *----
> >> +  * calls dma_fence_signal() {
> >> +  *  set signal bit
> >> +  *
> >> +  *scheduled out
> >> +  *  ---> calls dma_fence_wait_timeout() 
> >> and
> >> +  *   returns immediately
> >> +  *
> >> +  *   calls dma_fence_put()
> >> +  * |
> >> +  * |thread A doesn't hold ref
> >> +  * |to fence so ref goes to 0
> >> +  * |and release is called
> >> +  * |
> >> +  * -> dma_fence_release()
> >> +  *|
> >> +  *-> WARN_ON triggered
> >> +  *
> >> +  *  go over CB list,
> >> +  *  call each CB and remove it
> >> +  *  }
> >> +  *
> >> +  *
> >> +  */
> >>   WARN_ON(!list_empty(&fence->cb_list));
> >>
> >>   if (fence->ops->release)
> >> --
> >> 2.14.3
> >>
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> 
> Hi Daniel,
> Yeah, I get what you are saying.
> Can I add your RB to the one-liner version ?

Sure.

Reviewed-by: Daniel Vetter 

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


[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

2018-01-31 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=104082

--- Comment #11 from Przemek  ---
Similar with Radeon R4 APU - a6 6310
Kernel 4.15, mesa 17.3.3:

"swiotlb_tbl_map_single: 10 callbacks suppressed
[76882.115961] amdgpu :00:01.0: swiotlb buffer is full (sz: 2097152 bytes)
[76882.115964] swiotlb: coherent allocation failed for device :00:01.0
size=2097152
[76882.115969] CPU: 3 PID: 12480 Comm: kworker/u8:15 Not tainted 4.15.0-gentoo
#4
[76882.115971] Hardware name: LENOVO 80E3/Lancer 5B2, BIOS A2CN45WW(V2.13)
08/04/2016
[76882.115979] Workqueue: events_unbound async_run_entry_fn
[76882.115981] Call Trace:
[76882.115992]  dump_stack+0x46/0x59
[76882.115998]  swiotlb_alloc_coherent+0xdc/0x160
[76882.116004]  ttm_dma_pool_get_pages+0x1ba/0x460
[76882.116009]  ttm_dma_populate+0x24a/0x340
[76882.116012]  ttm_tt_bind+0x24/0x58
[76882.116015]  ttm_bo_handle_move_mem+0x380/0x3b8
[76882.116018]  ? ttm_bo_mem_space+0x397/0x470
[76882.116021]  ttm_bo_evict+0xc9/0x298
[76882.116024]  ? __slab_free+0x146/0x300
[76882.116027]  ? kmem_cache_free+0x138/0x168
[76882.116031]  ? drm_add_edid_modes+0x811/0x1338
[76882.116034]  ttm_mem_evict_first+0x15b/0x1c8
[76882.116037]  ttm_bo_force_list_clean+0x62/0x110
[76882.116040]  amdgpu_device_suspend+0x1db/0x3a8
[76882.116044]  ? pci_pm_freeze+0xc0/0xc0
[76882.116047]  pci_pm_suspend+0x7d/0x138
[76882.116051]  dpm_run_callback+0x28/0xf0
[76882.116055]  __device_suspend+0xdd/0x378
[76882.116058]  async_suspend+0x15/0x88
[76882.116061]  async_run_entry_fn+0x32/0xd8
[76882.116065]  process_one_work+0x1d6/0x3c8
[76882.116069]  worker_thread+0x26/0x3b8
[76882.116073]  ? trace_event_raw_event_workqueue_execute_start+0x88/0x88
[76882.116075]  kthread+0x10e/0x128
[76882.116078]  ? kthread_create_worker_on_cpu+0x48/0x48
[76882.116081]  ret_from_fork+0x22/0x40
[76882.175426] amdgpu :00:01.0: swiotlb buffer is full (sz: 2097152 bytes)
[76882.175429] swiotlb: coherent allocation failed for device :00:01.0
size=2097152
[76882.175433] CPU: 3 PID: 12480 Comm: kworker/u8:15 Not tainted 4.15.0-gentoo
#4
[76882.175435] Hardware name: LENOVO 80E3/Lancer 5B2, BIOS A2CN45WW(V2.13)
08/04/2016
[76882.175444] Workqueue: events_unbound async_run_entry_fn
[76882.175447] Call Trace:
[76882.175456]  dump_stack+0x46/0x59
[76882.175462]  swiotlb_alloc_coherent+0xdc/0x160
[76882.175468]  ttm_dma_pool_get_pages+0x1ba/0x460
[76882.175473]  ttm_dma_populate+0x24a/0x340
[76882.175476]  ttm_tt_bind+0x24/0x58
[76882.175479]  ttm_bo_handle_move_mem+0x380/0x3b8
[76882.175482]  ? ttm_bo_mem_space+0x397/0x470
[76882.175485]  ttm_bo_evict+0xc9/0x298
[76882.175489]  ? __slab_free+0x146/0x300
[76882.175491]  ? kmem_cache_free+0x138/0x168
[76882.175495]  ttm_mem_evict_first+0x15b/0x1c8
[76882.175498]  ttm_bo_force_list_clean+0x62/0x110
[76882.175501]  amdgpu_device_suspend+0x1db/0x3a8
[76882.175505]  ? pci_pm_freeze+0xc0/0xc0
[76882.175507]  pci_pm_suspend+0x7d/0x138
[76882.175512]  dpm_run_callback+0x28/0xf0
[76882.175516]  __device_suspend+0xdd/0x378
[76882.175519]  async_suspend+0x15/0x88
[76882.175522]  async_run_entry_fn+0x32/0xd8
[76882.175527]  process_one_work+0x1d6/0x3c8
[76882.175530]  worker_thread+0x26/0x3b8
[76882.175534]  ? trace_event_raw_event_workqueue_execute_start+0x88/0x88
[76882.175537]  kthread+0x10e/0x128
[76882.175540]  ? kthread_create_worker_on_cpu+0x48/0x48
[76882.175543]  ret_from_fork+0x22/0x40
[76882.205482] amdgpu :00:01.0: swiotlb buffer is full (sz: 2097152 bytes)
[76882.205484] swiotlb: coherent allocation failed for device :00:01.0
size=2097152
[76882.205489] CPU: 3 PID: 12480 Comm: kworker/u8:15 Not tainted 4.15.0-gentoo
#4
[76882.205490] Hardware name: LENOVO 80E3/Lancer 5B2, BIOS A2CN45WW(V2.13)
08/04/2016
[76882.205499] Workqueue: events_unbound async_run_entry_fn
[76882.205502] Call Trace:
[76882.205512]  dump_stack+0x46/0x59
[76882.205518]  swiotlb_alloc_coherent+0xdc/0x160
[76882.205523]  ttm_dma_pool_get_pages+0x1ba/0x460
[76882.205527]  ttm_dma_populate+0x24a/0x340
[76882.205531]  ttm_tt_bind+0x24/0x58
[76882.205534]  ttm_bo_handle_move_mem+0x380/0x3b8
[76882.205537]  ? ttm_bo_mem_space+0x397/0x470
[76882.205540]  ttm_bo_evict+0xc9/0x298
[76882.205543]  ? __slab_free+0x146/0x300
[76882.205546]  ? kmem_cache_free+0x138/0x168
[76882.205549]  ttm_mem_evict_first+0x15b/0x1c8
[76882.205553]  ttm_bo_force_list_clean+0x62/0x110
[76882.205556]  amdgpu_device_suspend+0x1db/0x3a8
[76882.205559]  ? pci_pm_freeze+0xc0/0xc0
[76882.205562]  pci_pm_suspend+0x7d/0x138
[76882.205567]  dpm_run_callback+0x28/0xf0
[76882.205570]  __device_suspend+0xdd/0x378
[76882.205574]  async_suspend+0x15/0x88
[76882.205577]  async_run_entry_fn+0x32/0xd8
[76882.205582]  process_one_work+0x1d6/0x3c8
[76882.205585]  worker_thread+0x26/0x3b8
[76882.205589]  ? trace_event_raw_event_workqueue_execute_start+0x88/0x88
[76882.205591]  kthread+0x10e/0x128
[76882.205595]  ? kthread_create_worker_on_cpu+0x48/0x48
[76882.205598]  ret_from_fork+0x22/0x40
[76882.207492] amdgpu :00:01.0: swiotlb buff

[PATCH] MAINTAINERS: Maarten for drm-misc co-maintainer

2018-01-31 Thread Daniel Vetter
I'm stepping down, also handing all the drm-misc stuff to the new
team. Plan is that Sean handles 4.17, and Maarten then has fun with
4.18 as his first release.

Cc: Maarten Lankhorst 
Cc: David Airlie 
Cc: Gustavo Padovan 
Cc: Sean Paul 
Acked-by: Sean Paul 
Acked-by: Maarten Lankhorst 
Signed-off-by: Daniel Vetter 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2de1d5540abb..617f07ffddbf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4605,8 +4605,8 @@ F:include/uapi/drm/
 F: include/linux/vga*
 
 DRM DRIVERS AND MISC GPU PATCHES
-M: Daniel Vetter 
 M: Gustavo Padovan 
+M: Maarten Lankhorst 
 M: Sean Paul 
 W: https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html
 S: Maintained
-- 
2.15.1

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


Re: [PATCH] dma-buf/dma-fence: Signal all callbacks from dma_fence_release()

2018-01-31 Thread Chris Wilson
Quoting Christian König (2017-08-13 14:04:29)
> Am 11.08.2017 um 19:01 schrieb Chris Wilson:
> > This is an illegal scenario, to free the fence whilst there are pending
> > callbacks. Currently, we emit a WARN and then cast aside the callbacks
> > leaving them dangling. Alternatively, we could set an error on the fence
> > and then signal fence so that any dependency chains from the fence can
> > be tidied up, and if they care they can check for the error.
> >
> > The question is whether or not the cure is worse than the disease
> > (premature fence signaling is never pretty).
> >
> > Signed-off-by: Chris Wilson 
> 
> Not sure if -EDEADLK is the best error code, but in general the approach 
> sounds like the least evil to me.
> 
> Patch is Reviewed-by: Christian König .

Since the spectre of an early dma_fence_release() has shown itself
recently, I thought I'd ping this patch for inclusion along with the new
comment.
-Chris

> > ---
> >   drivers/dma-buf/dma-fence.c | 14 +-
> >   1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> > index 9a302799040e..ed311edbeefa 100644
> > --- a/drivers/dma-buf/dma-fence.c
> > +++ b/drivers/dma-buf/dma-fence.c
> > @@ -172,7 +172,19 @@ void dma_fence_release(struct kref *kref)
> >   
> >   trace_dma_fence_destroy(fence);
> >   
> > - WARN_ON(!list_empty(&fence->cb_list));
> > + if (WARN_ON(!list_empty(&fence->cb_list))) {
> > + unsigned long flags;
> > +
> > + /*
> > +  * This should never happen, but if it does make sure that we
> > +  * don't leave chains dangling. We set the error flag first
> > +  * so that the callbacks know this signal is due to an error.
> > +  */
> > + spin_lock_irqsave(fence->lock, flags);
> > + fence->error = -EDEADLK;
> > + dma_fence_signal_locked(fence);
> > + spin_unlock_irqrestore(fence->lock, flags);
> > + }
> >   
> >   if (fence->ops->release)
> >   fence->ops->release(fence);
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/2] [WIP]drm/ttm: add waiter list to prevent allocation not in order

2018-01-31 Thread Chunming Zhou



On 2018年01月26日 22:35, Christian König wrote:
I just realized that a change I'm thinking about for a while would 
solve your problem as well, but keep concurrent allocation possible.


See ttm_mem_evict_first() unlocks the BO after evicting it:

    ttm_bo_del_from_lru(bo);
    spin_unlock(&glob->lru_lock);

    ret = ttm_bo_evict(bo, ctx);
    if (locked) {
    ttm_bo_unreserve(bo); < here
    } else {
    spin_lock(&glob->lru_lock);
    ttm_bo_add_to_lru(bo);
    spin_unlock(&glob->lru_lock);
    }

    kref_put(&bo->list_kref, ttm_bo_release_list);


The effect is that in your example process C can not only beat process 
B once, but many many times because we run into a ping/pong situation 
where B evicts resources while C moves them back in.
For ping/pong case, I want to disable busy placement for allocation 
period, only enable it for cs bo validation.




For a while now I'm thinking about dropping those reservations only 
after the original allocation succeeded.


The effect would be that process C can still beat process B initially, 
but sooner or process B would evict some resources from process C as 
well and then it can succeed with its allocation.
If it is from process C cs validation, process B still need evict the 
resource only after process C command submission completion.




The problem is for this approach to work we need to core change to the 
ww_mutexes to be able to handle this efficiently.
Yes, ww_mutex doesn't support this net lock, which easily deadlock 
without ticket and class.


So I think preventing validation on same place is a simpler way:
process B bo's place is fpfn~lpfn, it will only try to evict LRU BOs in 
that range, while eviction, we just prevent those validation to this 
range(fpfn~lpfn), if out of this range, the allocation/validation still 
can be go on.


Any negative?

Regards,
David Zhou


Regards,
Christian.

Am 26.01.2018 um 14:59 schrieb Christian König:
I know, but this has the same effect. You prevent concurrent 
allocation from happening.


What we could do is to pipeline reusing of deleted memory as well, 
this makes it less likely to cause the problem you are seeing because 
the evicting processes doesn't need to block for deleted BOs any more.


But that other processes can grab memory during eviction is 
intentional. Otherwise greedy processes would completely dominate 
command submission.


Regards,
Christian.

Am 26.01.2018 um 14:50 schrieb Zhou, David(ChunMing):
I don't want to prevent all, my new approach is to prevent the later 
allocation is trying and ahead of front to get the memory space that 
the front made from eviction.



发自坚果 Pro

Christian K鰊ig  于 2018年1月26日 
下午9:24写道:


Yes, exactly that's the problem.

See when you want to prevent a process B from allocating the memory 
process A has evicted, you need to prevent all concurrent allocation.


And we don't do that because it causes a major performance drop.

Regards,
Christian.

Am 26.01.2018 um 14:21 schrieb Zhou, David(ChunMing):
You patch will prevent concurrent allocation, and will result in 
allocation performance drop much.


发自坚果 Pro

Christian K鰊ig  于 2018年1月26日 
下午9:04写道:


Attached is what you actually want to do cleanly implemented. But 
as I said this is a NO-GO.


Regards,
Christian.

Am 26.01.2018 um 13:43 schrieb Christian König:
After my investigation, this issue should be detect of TTM design 
self, which breaks scheduling balance.

Yeah, but again. This is indented design we can't change easily.

Regards,
Christian.

Am 26.01.2018 um 13:36 schrieb Zhou, David(ChunMing):

I am off work, so reply mail by phone, the format could not be text.

back to topic itself:
the problem indeed happen on amdgpu driver, someone reports me 
that application runs with two instances, the performance are 
different.
I also reproduced the issue with unit test(bo_eviction_test). 
They always think our scheduler isn't working as expected.


After my investigation, this issue should be detect of TTM design 
self, which breaks scheduling balance.


Further, if we run containers for our gpu, container A could run 
high score, container B runs low score with same benchmark.


So this is bug that we need fix.

Regards,
David Zhou

发自坚果 Pro

Christian K鰊ig  于 2018年1月26日 
下午6:31写道:


Am 26.01.2018 um 11:22 schrieb Chunming Zhou:
> there is a scheduling balance issue about get node like:
> a. process A allocates full memory and use it for submission.
> b. process B tries to allocates memory, will wait for process A 
BO idle in eviction.
> c. process A completes the job, process B eviction will put 
process A BO node,
> but in the meantime, process C is comming to allocate BO, whill 
directly get node successfully, and do submission,

> process B will again wait for process C BO idle.
> d. repeat the above setps, process B could be delayed much more.
>
> later allocation must not be ahead of front in same place.

Agai

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

2018-01-31 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=198123

--- Comment #26 from Daniel Vetter (dan...@ffwll.ch) ---
Re #commment 24: crtc_commit is for modesets, the legacy helpers do _not_ call
the DPMS functions in that case. radeon does what every reasonable legacy kms
driver did and calls the dpms function from the prepare/commit hooks, but ast
didn't do that. Hence why my patch fixed ast (but a similar patch for radeon
doesn't make sense).

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


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

2018-01-31 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=198123

--- Comment #27 from Daniel Vetter (dan...@ffwll.ch) ---
Ok I've reviewed all the drivers where Peter Rosin's patch series removed the
load_lut hook:
- ast: fixed with my patch
- mga200g: already has a callchain like crtc_commit -> dpms -> load_lut, so
works correctly already
- cirrus: same bug as ast, I'm typing a patch for that now
- radeon: head-scratcher, I still have no idea what's going on
- amdgpu: should work, but might have the same bug as radeon due to heritage

-- 
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 1/2] [WIP]drm/ttm: add waiter list to prevent allocation not in order

2018-01-31 Thread Christian König

So I think preventing validation on same place is a simpler way:
process B bo's place is fpfn~lpfn, it will only try to evict LRU BOs 
in that range, while eviction, we just prevent those validation to 
this range(fpfn~lpfn), if out of this range, the allocation/validation 
still can be go on.


Any negative?
That won't work either. The most common use of fpfn~lpfn range is to 
limit a BO to visible VRAM, the other use cases are to fullfil hardware 
limitations.


So blocking this would result in blocking all normal GTT and VRAM 
allocations, adding a mutex to validate would have the same effect.


Regards,
Christian.

Am 31.01.2018 um 11:30 schrieb Chunming Zhou:




On 2018年01月26日 22:35, Christian König wrote:
I just realized that a change I'm thinking about for a while would 
solve your problem as well, but keep concurrent allocation possible.


See ttm_mem_evict_first() unlocks the BO after evicting it:

    ttm_bo_del_from_lru(bo);
    spin_unlock(&glob->lru_lock);

    ret = ttm_bo_evict(bo, ctx);
    if (locked) {
    ttm_bo_unreserve(bo); < here
    } else {
    spin_lock(&glob->lru_lock);
    ttm_bo_add_to_lru(bo);
    spin_unlock(&glob->lru_lock);
    }

    kref_put(&bo->list_kref, ttm_bo_release_list);


The effect is that in your example process C can not only beat 
process B once, but many many times because we run into a ping/pong 
situation where B evicts resources while C moves them back in.
For ping/pong case, I want to disable busy placement for allocation 
period, only enable it for cs bo validation.




For a while now I'm thinking about dropping those reservations only 
after the original allocation succeeded.


The effect would be that process C can still beat process B 
initially, but sooner or process B would evict some resources from 
process C as well and then it can succeed with its allocation.
If it is from process C cs validation, process B still need evict the 
resource only after process C command submission completion.




The problem is for this approach to work we need to core change to 
the ww_mutexes to be able to handle this efficiently.
Yes, ww_mutex doesn't support this net lock, which easily deadlock 
without ticket and class.


So I think preventing validation on same place is a simpler way:
process B bo's place is fpfn~lpfn, it will only try to evict LRU BOs 
in that range, while eviction, we just prevent those validation to 
this range(fpfn~lpfn), if out of this range, the allocation/validation 
still can be go on.


Any negative?

Regards,
David Zhou


Regards,
Christian.

Am 26.01.2018 um 14:59 schrieb Christian König:
I know, but this has the same effect. You prevent concurrent 
allocation from happening.


What we could do is to pipeline reusing of deleted memory as well, 
this makes it less likely to cause the problem you are seeing 
because the evicting processes doesn't need to block for deleted BOs 
any more.


But that other processes can grab memory during eviction is 
intentional. Otherwise greedy processes would completely dominate 
command submission.


Regards,
Christian.

Am 26.01.2018 um 14:50 schrieb Zhou, David(ChunMing):
I don't want to prevent all, my new approach is to prevent the 
later allocation is trying and ahead of front to get the memory 
space that the front made from eviction.



发自坚果 Pro

Christian K鰊ig  于 2018年1月26日 
下午9:24写道:


Yes, exactly that's the problem.

See when you want to prevent a process B from allocating the memory 
process A has evicted, you need to prevent all concurrent allocation.


And we don't do that because it causes a major performance drop.

Regards,
Christian.

Am 26.01.2018 um 14:21 schrieb Zhou, David(ChunMing):
You patch will prevent concurrent allocation, and will result in 
allocation performance drop much.


发自坚果 Pro

Christian K鰊ig  于 2018年1月26日 
下午9:04写道:


Attached is what you actually want to do cleanly implemented. But 
as I said this is a NO-GO.


Regards,
Christian.

Am 26.01.2018 um 13:43 schrieb Christian König:
After my investigation, this issue should be detect of TTM 
design self, which breaks scheduling balance.

Yeah, but again. This is indented design we can't change easily.

Regards,
Christian.

Am 26.01.2018 um 13:36 schrieb Zhou, David(ChunMing):

I am off work, so reply mail by phone, the format could not be text.

back to topic itself:
the problem indeed happen on amdgpu driver, someone reports me 
that application runs with two instances, the performance are 
different.
I also reproduced the issue with unit test(bo_eviction_test). 
They always think our scheduler isn't working as expected.


After my investigation, this issue should be detect of TTM 
design self, which breaks scheduling balance.


Further, if we run containers for our gpu, container A could run 
high score, container B runs low score with same benchmark.


So this is bug that we need fix.

Regards,
David Zhou

发自坚果 Pro

Christian 

[Bug 100979] Radeon r4 on a6-6310(BEEMA) APU hard lockup on hibernate and on second resume from suspend

2018-01-31 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100979

--- Comment #9 from Przemek  ---
I have just upgraded kernel to 4.15.
There is a big progress. Laptop can now successfully suspend (S3) and resume 
many times in a row.

_Thank you very much for your hard work_.

But unfortunately hibernate to disk (S4) still does not work as expected.
Process is causing hard lockup (system freeze) just on the first attempt. 

Display goes black (backlight is on), cpu is getting hot (fans are working 100%
rpms), and I can do noting more than press "power button" to hard reset the
machine.

There is no more "amdgpu_atombios_dp_link_train" message in dmesg instead there
are mesages related to "swiotlb buffer is full" and "swiotlb: coherent
allocation failed" as in the bug:
https://bugs.freedesktop.org/show_bug.cgi?id=104082.

Thanks,
Przemek

-- 
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] MAINTAINERS: Maarten for drm-misc co-maintainer

2018-01-31 Thread Gustavo Padovan
2018-01-31 Daniel Vetter :

> I'm stepping down, also handing all the drm-misc stuff to the new
> team. Plan is that Sean handles 4.17, and Maarten then has fun with
> 4.18 as his first release.
> 
> Cc: Maarten Lankhorst 
> Cc: David Airlie 
> Cc: Gustavo Padovan 
> Cc: Sean Paul 
> Acked-by: Sean Paul 
> Acked-by: Maarten Lankhorst 
> Signed-off-by: Daniel Vetter 

Welcome!!

Acked-by: Gustavo Padovan 

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


[PATCH] drm/cirrus: Load lut in crtc_commit

2018-01-31 Thread Daniel Vetter
In the past the ast driver relied upon the fbdev emulation helpers to
call ->load_lut at boot-up. But since

commit b8e2b0199cc377617dc238f5106352c06dcd3fa2
Author: Peter Rosin 
Date:   Tue Jul 4 12:36:57 2017 +0200

drm/fb-helper: factor out pseudo-palette

that's cleaned up and drivers are expected to boot into a consistent
lut state. This patch fixes that.

Fixes: b8e2b0199cc3 ("drm/fb-helper: factor out pseudo-palette")
Cc: Peter Rosin 
Cc: Daniel Vetter 
Cc:  # v4.14+
References: https://bugzilla.kernel.org/show_bug.cgi?id=198123
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/cirrus/cirrus_mode.c | 40 +---
 1 file changed, 23 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c 
b/drivers/gpu/drm/cirrus/cirrus_mode.c
index cd23b1b28259..c91b9b054e3f 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -294,22 +294,7 @@ static void cirrus_crtc_prepare(struct drm_crtc *crtc)
 {
 }
 
-/*
- * This is called after a mode is programmed. It should reverse anything done
- * by the prepare function
- */
-static void cirrus_crtc_commit(struct drm_crtc *crtc)
-{
-}
-
-/*
- * The core can pass us a set of gamma values to program. We actually only
- * use this for 8-bit mode so can't perform smooth fades on deeper modes,
- * but it's a requirement that we provide the function
- */
-static int cirrus_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green,
-u16 *blue, uint32_t size,
-struct drm_modeset_acquire_ctx *ctx)
+static void cirrus_crtc_load_lut(struct drm_crtc *crtc)
 {
struct drm_device *dev = crtc->dev;
struct cirrus_device *cdev = dev->dev_private;
@@ -317,7 +302,7 @@ static int cirrus_crtc_gamma_set(struct drm_crtc *crtc, u16 
*red, u16 *green,
int i;
 
if (!crtc->enabled)
-   return 0;
+   return;
 
r = crtc->gamma_store;
g = r + crtc->gamma_size;
@@ -330,6 +315,27 @@ static int cirrus_crtc_gamma_set(struct drm_crtc *crtc, 
u16 *red, u16 *green,
WREG8(PALETTE_DATA, *g++ >> 8);
WREG8(PALETTE_DATA, *b++ >> 8);
}
+}
+
+/*
+ * This is called after a mode is programmed. It should reverse anything done
+ * by the prepare function
+ */
+static void cirrus_crtc_commit(struct drm_crtc *crtc)
+{
+   cirrus_crtc_load_lut(crtc);
+}
+
+/*
+ * The core can pass us a set of gamma values to program. We actually only
+ * use this for 8-bit mode so can't perform smooth fades on deeper modes,
+ * but it's a requirement that we provide the function
+ */
+static int cirrus_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green,
+u16 *blue, uint32_t size,
+struct drm_modeset_acquire_ctx *ctx)
+{
+   cirrus_crtc_load_lut(crtc);
 
return 0;
 }
-- 
2.15.1

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


Re: [PATCH 1/5] backlight: lp8788: document sysfs attributes

2018-01-31 Thread Daniel Thompson
On Fri, Jan 26, 2018 at 08:20:08PM +0530, Aishwarya Pant wrote:
> Add documentation for sysfs interfaces of lp8788 backlight driver by
> looking through the code and the git commit history.
> 
> Signed-off-by: Aishwarya Pant 
> ---
>  Documentation/ABI/testing/sysfs-class-backlight-lp8788 | 10 ++
>  1 file changed, 10 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-backlight-lp8788
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-backlight-lp8788 
> b/Documentation/ABI/testing/sysfs-class-backlight-lp8788
> new file mode 100644
> index ..c0e565c8d63d
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-backlight-lp8788
> @@ -0,0 +1,10 @@
> +sysfs interface for Texas Instruments lp8788 mfd backlight driver
> +-
> +
> +What:/sys/class/backlight//bl_ctl_mode
> +Date:Feb, 2013
> +KernelVersion:   v3.10
> +Contact: Milo Kim 
> +Description:
> + (RO) Displays whether the brightness is controlled by the PWM
> + input("PWM based") or the I2C register("Register based").

I rather dislike drivers with this type of "bonus" sysfs controls. I'm
struggling to come up with any reason why the userspace would want to
read this control (and I think bl_ctl_mode gets the fewest hits after
searching with google hits of any search I've tried) . It looks to me 
like this is debug information that should never have gone into sysfs 
at all.

So I think this is either something that should go directly into
ABI/obsolete (with a fairly short expiry time) or perhaps simply
remove the property entirely.


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

2018-01-31 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=198123

--- Comment #28 from Daniel Vetter (dan...@ffwll.ch) ---
Created attachment 273941
  --> https://bugzilla.kernel.org/attachment.cgi?id=273941&action=edit
test patch for deposite pirate

Should apply on any recent-ish kernel. Please apply, boot, and grab the
complete dmesg (from kernel loading up to latest message), there should be
plenty of backtraces all around.

-- 
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: [Mesa-dev] [PATCH libdrm] meson: fix libdrm_nouveau pkgconfig include directories

2018-01-31 Thread Eric Engestrom
On Thursday, 2018-01-25 16:14:45 -0800, Dylan Baker wrote:
> Signed-off-by: Dylan Baker 

Reviewed-by: Eric Engestrom 

> ---
> 
> I have tested building every mesa driver against this (with and without udev!)
> so I'm pretty sure that this is the last pkgbuild problem.
> 
> I'm sure I'll be sad in a day or two...
> 
>  nouveau/meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/nouveau/meson.build b/nouveau/meson.build
> index bfecf84b..f031cd63 100644
> --- a/nouveau/meson.build
> +++ b/nouveau/meson.build
> @@ -45,7 +45,7 @@ install_headers(
>  pkg.generate(
>name : 'libdrm_nouveau',
>libraries : libdrm_nouveau,
> -  subdirs : ['.', 'nouveau'],
> +  subdirs : ['.', 'libdrm', 'libdrm/nouveau'],
>version : meson.project_version(),
>requires_private : 'libdrm',
>description : 'Userspace interface to nouveau kernel DRM services',
> -- 
> 2.16.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] MAINTAINERS: Maarten for drm-misc co-maintainer

2018-01-31 Thread Maarten Lankhorst
Op 31-01-18 om 12:02 schreef Gustavo Padovan:
> 2018-01-31 Daniel Vetter :
>
>> I'm stepping down, also handing all the drm-misc stuff to the new
>> team. Plan is that Sean handles 4.17, and Maarten then has fun with
>> 4.18 as his first release.
>>
>> Cc: Maarten Lankhorst 
>> Cc: David Airlie 
>> Cc: Gustavo Padovan 
>> Cc: Sean Paul 
>> Acked-by: Sean Paul 
>> Acked-by: Maarten Lankhorst 
>> Signed-off-by: Daniel Vetter 
> Welcome!!
>
> Acked-by: Gustavo Padovan 
>
> Gustavo

Thanks. :)

~Maarten

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


[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

2018-01-31 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=104082

--- Comment #12 from Przemek  ---
I dont know if it is related, but:
https://lkml.org/lkml/2018/1/16/106

-- 
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] MAINTAINERS: Maarten for drm-misc co-maintainer

2018-01-31 Thread Jani Nikula
On Wed, 31 Jan 2018, Daniel Vetter  wrote:
> I'm stepping down, also handing all the drm-misc stuff to the new
> team. Plan is that Sean handles 4.17, and Maarten then has fun with
> 4.18 as his first release.
>
> Cc: Maarten Lankhorst 
> Cc: David Airlie 
> Cc: Gustavo Padovan 
> Cc: Sean Paul 
> Acked-by: Sean Paul 
> Acked-by: Maarten Lankhorst 
> Signed-off-by: Daniel Vetter 

FWIW,

Acked-by: Jani Nikula 

> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2de1d5540abb..617f07ffddbf 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4605,8 +4605,8 @@ F:  include/uapi/drm/
>  F:   include/linux/vga*
>  
>  DRM DRIVERS AND MISC GPU PATCHES
> -M:   Daniel Vetter 
>  M:   Gustavo Padovan 
> +M:   Maarten Lankhorst 
>  M:   Sean Paul 
>  W:   https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html
>  S:   Maintained

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


[Bug 100979] Radeon r4 on a6-6310(BEEMA) APU hard lockup on hibernate and on second resume from suspend

2018-01-31 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100979

--- Comment #10 from Przemek  ---
After some research I think that messages "swiotlb buffer is full" and
"swiotlb: coherent allocation failed" are not related to this bug:

https://lkml.org/lkml/2018/1/16/106

-- 
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 3/5] backlight: lm3639: document sysfs attributes

2018-01-31 Thread Daniel Thompson
On Fri, Jan 26, 2018 at 08:23:57PM +0530, Aishwarya Pant wrote:
> Add documentation for sysfs interfaces of Texas Instruments lm3639
> backlight + flash led driver chip by looking through git commits and
> reading code.
> 
> Signed-off-by: Aishwarya Pant 
> ---
>  Documentation/ABI/testing/sysfs-class-backlight-lm3639 | 13 +
>  1 file changed, 13 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-backlight-lm3639
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-backlight-lm3639 
> b/Documentation/ABI/testing/sysfs-class-backlight-lm3639
> new file mode 100644
> index ..ec87dc8f4395
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-backlight-lm3639
> @@ -0,0 +1,13 @@
> +sysfs interface for Texas Instruments lm3639 backlight + flash led driver 
> chip
> +--
> +
> +What:/sys/class/backlight//bled_mode
> +Date:Oct, 2012
> +KernelVersion:   v3.10
> +Contact: Lee Jones ,
> + Daniel Thompson ,
> + Jingoo Han 

We've recently added a ML to MAINTAINERS (see
https://patchwork.kernel.org/patch/10169327/ ). I think a better Contact
might simply be:

Contact:dri-devel@lists.freedesktop.org


> +Description:
> + (WO) Write to the backlight mapping mode. The backlight current
> + can be mapped for either exponential (value "0") or linear
> + mapping modes (default).

The ambiguity of meaning w.r.t. linear or exponential is something of a thorn 
in 
the side of backlight... and so long as that ambiguity remains this
control is something the userspace may want to poke (albeit only once
during boot).

If you repost with an updated contact then please add my ack for this patch:
Acked-by: Daniel Thompson 


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


Re: [PATCH 1/5] backlight: lp8788: document sysfs attributes

2018-01-31 Thread Jani Nikula
On Wed, 31 Jan 2018, Daniel Thompson  wrote:
> On Fri, Jan 26, 2018 at 08:20:08PM +0530, Aishwarya Pant wrote:
>> Add documentation for sysfs interfaces of lp8788 backlight driver by
>> looking through the code and the git commit history.
>> 
>> Signed-off-by: Aishwarya Pant 
>> ---
>>  Documentation/ABI/testing/sysfs-class-backlight-lp8788 | 10 ++
>>  1 file changed, 10 insertions(+)
>>  create mode 100644 Documentation/ABI/testing/sysfs-class-backlight-lp8788
>> 
>> diff --git a/Documentation/ABI/testing/sysfs-class-backlight-lp8788 
>> b/Documentation/ABI/testing/sysfs-class-backlight-lp8788
>> new file mode 100644
>> index ..c0e565c8d63d
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-class-backlight-lp8788
>> @@ -0,0 +1,10 @@
>> +sysfs interface for Texas Instruments lp8788 mfd backlight driver
>> +-
>> +
>> +What:   /sys/class/backlight//bl_ctl_mode
>> +Date:   Feb, 2013
>> +KernelVersion:  v3.10
>> +Contact:Milo Kim 
>> +Description:
>> +(RO) Displays whether the brightness is controlled by the PWM
>> +input("PWM based") or the I2C register("Register based").
>
> I rather dislike drivers with this type of "bonus" sysfs controls. I'm
> struggling to come up with any reason why the userspace would want to
> read this control (and I think bl_ctl_mode gets the fewest hits after
> searching with google hits of any search I've tried) . It looks to me 
> like this is debug information that should never have gone into sysfs 
> at all.

Agreed. I think the same holds for the other extra sysfs attributes. At
worst, having these prevents the backlight class from adding the names
later on, which is just backwards.

BR,
Jani.


>
> So I think this is either something that should go directly into
> ABI/obsolete (with a fairly short expiry time) or perhaps simply
> remove the property entirely.
>
>
> Daniel.
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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


Re: [PATCH v3] Fix loading of module radeonfb on PowerMac

2018-01-31 Thread Bartlomiej Zolnierkiewicz
On Tuesday, January 30, 2018 02:14:10 PM Mathieu Malaterre wrote:
> Bartlomiej,
> 
> On Wed, Jan 3, 2018 at 3:47 PM, Bartlomiej Zolnierkiewicz
>  wrote:
> >
> > On Thursday, December 21, 2017 11:07:56 PM Mathieu Malaterre wrote:
> >> When the linux kernel is build with (typical kernel ship with Debian
> >> installer):
> >>
> >> CONFIG_FB_OF=y
> >> CONFIG_VT_HW_CONSOLE_BINDING=y
> >> CONFIG_FB_RADEON=m
> >>
> >> The offb driver takes precedence over module radeonfb. It is then
> >> impossible to load the module, error reported is:
> >>
> >> [   96.551486] radeonfb :00:10.0: enabling device (0006 -> 0007)
> >> [   96.551526] radeonfb :00:10.0: BAR 0: can't reserve [mem 
> >> 0x9800-0x9fff pref]
> >> [   96.551531] radeonfb (:00:10.0): cannot request region 0.
> >> [   96.551545] radeonfb: probe of :00:10.0 failed with error -16
> >>
> >> This patch reproduce the behavior of the module radeon, so as to make it
> >> possible to load radeonfb when offb is first loaded.
> >>
> >> It should be noticed that `offb_destroy` is never called which explain the
> >> need to skip error detection on the radeon side.
> >
> > This still needs to be explained more, from my last mail:
> >
> > "The last put_fb_info() on fb_info should call ->fb_destroy
> > (offb_destroy in our case) and remove_conflicting_framebuffers()
> > is calling put_fb_info() so there is some extra reference on
> > fb_info somewhere preventing it from going away.
> >
> > Please look into fixing this."
> 
> I am not familiar with the fb stuff internals but here is what I see:
> 
> # modprobe radeonfb
> 
> leads to:
> 
> [   52.058546] bus: 'pci': add driver radeonfb
> [   52.058588] bus: 'pci': driver_probe_device: matched device
> :00:10.0 with driver radeonfb
> [   52.058595] bus: 'pci': really_probe: probing driver radeonfb with
> device :00:10.0
> [   52.058608] devices_kset: Moving :00:10.0 to end of list
> [   52.058613] radeonfb_pci_register BEGIN
> [   52.058634] radeonfb :00:10.0: enabling device (0006 -> 0007)
> 
> [   52.058666] checking generic (9c008000 96000) vs hw (9800 800)
> [   52.058667] fb: switching to radeonfb from OFfb ATY,RockHo
> [   52.058844] Console: switching to colour dummy device 80x25
> [   52.058860] device: 'fb0': device_unregister
> [   52.058956] PM: Removing info for No Bus:fb0
> [   52.059014] device: 'fb0': device_create_release
> 
> 
> [   52.059048] device: 'vtcon1': device_unregister
> [   52.059076] PM: Removing info for No Bus:vtcon1
> [   52.059091] device: 'vtcon1': device_create_release
> [   52.059107] radeonfb :00:10.0: BAR 0: can't reserve [mem
> 0x9800-0x9fff pref]
> [   52.256151] aper_base: 9800 MC_FB_LOC to: 9bff9800, MC_AGP_LOC
> to: a000
> [   52.256157] radeonfb (:00:10.0): Found 32768k of DDR 64 bits
> wide videoram
> 
> I can confirm that offb_destroy is never called (not sure exactly
> why), but in any case the call to radeon_kick_out_firmware_fb happen
> much earlier, at least before the put_fb_info.

It is okay, put_fb_info() is called indirectly by radeon_kick_out_firmware_fb()

radeon_kick_out_firmware_fb()
remove_conflicting_framebuffers()
do_remove_conflicting_framebuffers()
do_unregister_framebuffer()
put_fb_info()

offb_destroy() is not called because there is an extra reference on old
fb_info (->count == 2):

static void put_fb_info(struct fb_info *fb_info)
{
if (!atomic_dec_and_test(&fb_info->count))
return;
if (fb_info->fbops->fb_destroy)
fb_info->fbops->fb_destroy(fb_info);
}

The question is why there is an extra reference, probably user-space
is still holding the fb_info reference obtained in fb_open() call and
fb_release() is never called. Besides not calling fbops->fb_destroy()
this also causes missing call of fbops->fb_release() (in fb_release())
which some fb drivers are implementing (but not offb.c).

> Could you describe a bit more the chain of calls you were thinking of ?

Please add WARN_ON(1) to get_fb_info() and put_fb_info() so we can check
from the stacktrace if it is actually fb_open() that holds the extra
old fb_info reference.

drivers/video/fbdev/core/fbmem.c:

static struct fb_info *get_fb_info(unsigned int idx)
{
struct fb_info *fb_info;

if (idx >= FB_MAX)
return ERR_PTR(-ENODEV);

mutex_lock(®istration_lock);
fb_info = registered_fb[idx];
if (fb_info)
atomic_inc(&fb_info->count);

if (fb_info)
WARN_ON(1);

mutex_unlock(®istration_lock);

return fb_info;
}

static void put_fb_info(struct fb_info *fb_info)
{
WARN_ON(1);

if (!atomic_dec_and_test(&fb_info->count))
return;
if (fb_info->fbops->fb_destroy)
fb_info->fbops->fb_destroy(fb_info);
}

> >> Signed-off-by: Mathieu Malaterre 
> >> Link: https://bugs.debian.org/826629#57
> >

[Bug 100979] Radeon r4 on a6-6310(BEEMA) APU hard lockup on hibernate and on second resume from suspend

2018-01-31 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100979

--- Comment #11 from Przemek  ---
Created attachment 137085
  --> https://bugs.freedesktop.org/attachment.cgi?id=137085&action=edit
kernel log during hibernate

Kernel log taken during hibernate process. Netbook was booted up with command
line "initcall_debug" and "no_console_suspend".

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


Re: [PATCH v6 2/6] iommu/arm-smmu: Add pm_runtime/sleep ops

2018-01-31 Thread Robin Murphy

On 19/01/18 11:43, Vivek Gautam wrote:

From: Sricharan R 

The smmu needs to be functional only when the respective
master's using it are active. The device_link feature
helps to track such functional dependencies, so that the
iommu gets powered when the master device enables itself
using pm_runtime. So by adapting the smmu driver for
runtime pm, above said dependency can be addressed.

This patch adds the pm runtime/sleep callbacks to the
driver and also the functions to parse the smmu clocks
from DT and enable them in resume/suspend.

Signed-off-by: Sricharan R 
Signed-off-by: Archit Taneja 
[vivek: Clock rework to request bulk of clocks]
Signed-off-by: Vivek Gautam 
---
  drivers/iommu/arm-smmu.c | 55 ++--
  1 file changed, 53 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 78d4c6b8f1ba..21acffe91a1c 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -48,6 +48,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  
@@ -205,6 +206,9 @@ struct arm_smmu_device {

u32 num_global_irqs;
u32 num_context_irqs;
unsigned int*irqs;
+   struct clk_bulk_data*clocks;
+   int num_clks;
+   const char * const  *clk_names;


This seems unnecessary, as we use it a grand total of of once, during 
initialisation when we have the source data directly to hand. Just pass 
data->clks into arm_smmu_init_clks() as an additional argument.


Otherwise, I think this looks reasonable; it's about as unobtrusive as 
it's going to get.


Robin.


u32 cavium_id_base; /* Specific to Cavium */
  
@@ -1685,6 +1689,25 @@ static int arm_smmu_id_size_to_bits(int size)

}
  }
  
+static int arm_smmu_init_clocks(struct arm_smmu_device *smmu)

+{
+   int i;
+   int num = smmu->num_clks;
+
+   if (num < 1)
+   return 0;
+
+   smmu->clocks = devm_kcalloc(smmu->dev, num,
+   sizeof(*smmu->clocks), GFP_KERNEL);
+   if (!smmu->clocks)
+   return -ENOMEM;
+
+   for (i = 0; i < num; i++)
+   smmu->clocks[i].id = smmu->clk_names[i];
+
+   return devm_clk_bulk_get(smmu->dev, num, smmu->clocks);
+}
+
  static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
  {
unsigned long size;
@@ -1897,10 +1920,12 @@ static int arm_smmu_device_cfg_probe(struct 
arm_smmu_device *smmu)
  struct arm_smmu_match_data {
enum arm_smmu_arch_version version;
enum arm_smmu_implementation model;
+   const char * const *clks;
+   int num_clks;
  };
  
  #define ARM_SMMU_MATCH_DATA(name, ver, imp)	\

-static struct arm_smmu_match_data name = { .version = ver, .model = imp }
+static const struct arm_smmu_match_data name = { .version = ver, .model = imp }
  
  ARM_SMMU_MATCH_DATA(smmu_generic_v1, ARM_SMMU_V1, GENERIC_SMMU);

  ARM_SMMU_MATCH_DATA(smmu_generic_v2, ARM_SMMU_V2, GENERIC_SMMU);
@@ -2001,6 +2026,8 @@ static int arm_smmu_device_dt_probe(struct 
platform_device *pdev,
data = of_device_get_match_data(dev);
smmu->version = data->version;
smmu->model = data->model;
+   smmu->clk_names = data->clks;
+   smmu->num_clks = data->num_clks;
  
  	parse_driver_options(smmu);
  
@@ -2099,6 +2126,10 @@ static int arm_smmu_device_probe(struct platform_device *pdev)

smmu->irqs[i] = irq;
}
  
+	err = arm_smmu_init_clocks(smmu);

+   if (err)
+   return err;
+
err = arm_smmu_device_cfg_probe(smmu);
if (err)
return err;
@@ -2197,7 +2228,27 @@ static int __maybe_unused arm_smmu_pm_resume(struct 
device *dev)
return 0;
  }
  
-static SIMPLE_DEV_PM_OPS(arm_smmu_pm_ops, NULL, arm_smmu_pm_resume);

+static int __maybe_unused arm_smmu_runtime_resume(struct device *dev)
+{
+   struct arm_smmu_device *smmu = dev_get_drvdata(dev);
+
+   return clk_bulk_prepare_enable(smmu->num_clks, smmu->clocks);
+}
+
+static int __maybe_unused arm_smmu_runtime_suspend(struct device *dev)
+{
+   struct arm_smmu_device *smmu = dev_get_drvdata(dev);
+
+   clk_bulk_disable_unprepare(smmu->num_clks, smmu->clocks);
+
+   return 0;
+}
+
+static const struct dev_pm_ops arm_smmu_pm_ops = {
+   SET_SYSTEM_SLEEP_PM_OPS(NULL, arm_smmu_pm_resume)
+   SET_RUNTIME_PM_OPS(arm_smmu_runtime_suspend,
+  arm_smmu_runtime_resume, NULL)
+};
  
  static struct platform_driver arm_smmu_driver = {

.driver = {


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


Re: [PATCH] drm/cirrus: Load lut in crtc_commit

2018-01-31 Thread Gerd Hoffmann
On Wed, Jan 31, 2018 at 12:04:50PM +0100, Daniel Vetter wrote:
> In the past the ast driver relied upon the fbdev emulation helpers to
> call ->load_lut at boot-up. But since
> 
> commit b8e2b0199cc377617dc238f5106352c06dcd3fa2
> Author: Peter Rosin 
> Date:   Tue Jul 4 12:36:57 2017 +0200
> 
> drm/fb-helper: factor out pseudo-palette
> 
> that's cleaned up and drivers are expected to boot into a consistent
> lut state. This patch fixes that.
> 
> Fixes: b8e2b0199cc3 ("drm/fb-helper: factor out pseudo-palette")
> Cc: Peter Rosin 
> Cc: Daniel Vetter 
> Cc:  # v4.14+
> References: https://bugzilla.kernel.org/show_bug.cgi?id=198123
> Signed-off-by: Daniel Vetter 

Pushed to drm-misc-fixes.

thanks,
  Gerd

PS: Was on sick leave for a lng time due to broken finger and
influenza.  Back online now.  If anyone has submitted something
for the qemu drivers (bochs/cirrus/qxl/virtio) in the last two
months which isn't handled yet:  Now would be a good time to
re-send those patches.  Thanks for your patience.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 7/9] dma-buf/dma-fence: Signal all callbacks from dma_fence_release()

2018-01-31 Thread Gustavo Padovan
Hi,

2017-08-11 Jason Ekstrand :

> From: Chris Wilson 
> 
> This is an illegal scenario, to free the fence whilst there are pending
> callbacks. Currently, we emit a WARN and then cast aside the callbacks
> leaving them dangling. Alternatively, we could set an error on the fence
> and then signal fence so that any dependency chains from the fence can
> be tidied up, and if they care they can check for the error.
> 
> The question is whether or not the cure is worse than the disease
> (premature fence signaling is never pretty).
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/dma-buf/dma-fence.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 0cac367..4062708 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -172,7 +172,19 @@ void dma_fence_release(struct kref *kref)
>  
>   trace_dma_fence_destroy(fence);
>  
> - WARN_ON(!list_empty(&fence->cb_list));
> + if (WARN_ON(!list_empty(&fence->cb_list))) {
> + unsigned long flags;
> +
> + /*
> +  * This should never happen, but if it does make sure that we
> +  * don't leave chains dangling. We set the error flag first
> +  * so that the callbacks know this signal is due to an error.
> +  */
> + spin_lock_irqsave(fence->lock, flags);
> + fence->error = -EDEADLK;
> + dma_fence_signal_locked(fence);
> + spin_unlock_irqrestore(fence->lock, flags);
> + }

Thanks for the patch!

Reviewed-by: Gustavo Padovan 

>  
>   if (fence->ops->release)
>   fence->ops->release(fence);
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> 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 v3 33/43] drm/panel: simple: Change mode for Sharp lq123p1jx31

2018-01-31 Thread Lucas Stach
Am Dienstag, den 30.01.2018, 21:29 +0100 schrieb Thierry Escande:
> From: Sean Paul 
> 
> Change the mode for Sharp lq123p1jx31 panel to something more
> rockchip-friendly such that we can use the fixed PLLs to
> generate the pixel clock

This should really switch to a display timing instead of exposing a
single mode. The display timing has min, typical, max tuples for all
the timings values, which would allow the attached driver to vary the
timings inside the allowed bounds if it makes sense.

Trying to hit a specific pixel clock to free up a PLL is exactly one of
the use cases envisioned for the display timings stuff.

Regards,
Lucas
 
> Cc: Chris Zhong 
> Cc: Stéphane Marchesin 
> Signed-off-by: Sean Paul 
> Signed-off-by: Thierry Escande 
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 5591984a392b..a4a6ea3ca0e6 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1742,17 +1742,18 @@ static const struct panel_desc
> sharp_lq101k1ly04 = {
>  };
>  
>  static const struct drm_display_mode sharp_lq123p1jx31_mode = {
> - .clock = 252750,
> + .clock = 27,
>   .hdisplay = 2400,
>   .hsync_start = 2400 + 48,
>   .hsync_end = 2400 + 48 + 32,
> - .htotal = 2400 + 48 + 32 + 80,
> + .htotal = 2400 + 48 + 32 + 139,
>   .vdisplay = 1600,
>   .vsync_start = 1600 + 3,
>   .vsync_end = 1600 + 3 + 10,
> - .vtotal = 1600 + 3 + 10 + 33,
> + .vtotal = 1600 + 3 + 10 + 84,
>   .vrefresh = 60,
>   .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> + .type = DRM_MODE_TYPE_PREFERRED | DRM_MODE_TYPE_DRIVER,
>  };
>  
>  static const struct panel_desc sharp_lq123p1jx31 = {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 104597] [bisected] Compton weird colors

2018-01-31 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=104597

--- Comment #10 from Mario Kleiner  ---
Created attachment 137087
  --> https://bugs.freedesktop.org/attachment.cgi?id=137087&action=edit
Possible fix, tested against server 1.19 branch.

This patch fixes the problem with compton, as tested against server 1.19
branch. Also applies cleanly against master, but i haven't tested it on master
yet.

So far tested with KDE-5, compiz, and compton, on ati-ddx under Radeon gfx,
both screen depth 24 and 30.

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


Re: [PATCH v6 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

2018-01-31 Thread Robin Murphy

On 19/01/18 11:43, Vivek Gautam wrote:

From: Sricharan R 

The smmu device probe/remove and add/remove master device callbacks
gets called when the smmu is not linked to its master, that is without
the context of the master device. So calling runtime apis in those places
separately.

Signed-off-by: Sricharan R 
[vivek: Cleanup pm runtime calls]
Signed-off-by: Vivek Gautam 
---
  drivers/iommu/arm-smmu.c | 45 +
  1 file changed, 41 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 21acffe91a1c..95478bfb182c 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -914,11 +914,15 @@ static void arm_smmu_destroy_domain_context(struct 
iommu_domain *domain)
struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
struct arm_smmu_device *smmu = smmu_domain->smmu;
struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
-   int irq;
+   int ret, irq;
  
  	if (!smmu || domain->type == IOMMU_DOMAIN_IDENTITY)

return;
  
+	ret = pm_runtime_get_sync(smmu->dev);

+   if (ret)
+   return;
+
/*
 * Disable the context bank and free the page tables before freeing
 * it.
@@ -933,6 +937,8 @@ static void arm_smmu_destroy_domain_context(struct 
iommu_domain *domain)
  
  	free_io_pgtable_ops(smmu_domain->pgtbl_ops);

__arm_smmu_free_bitmap(smmu->context_map, cfg->cbndx);
+
+   pm_runtime_put_sync(smmu->dev);
  }
  
  static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)

@@ -1408,12 +1414,20 @@ static int arm_smmu_add_device(struct device *dev)
while (i--)
cfg->smendx[i] = INVALID_SMENDX;
  
-	ret = arm_smmu_master_alloc_smes(dev);

+   ret = pm_runtime_get_sync(smmu->dev);
if (ret)
goto out_cfg_free;
  
+	ret = arm_smmu_master_alloc_smes(dev);

+   if (ret) {
+   pm_runtime_put_sync(smmu->dev);
+   goto out_cfg_free;


Please keep to the existing pattern and put this on the cleanup path 
with a new label, rather than inline.



+   }
+
iommu_device_link(&smmu->iommu, dev);
  
+	pm_runtime_put_sync(smmu->dev);

+
return 0;
  
  out_cfg_free:

@@ -1428,7 +1442,7 @@ static void arm_smmu_remove_device(struct device *dev)
struct iommu_fwspec *fwspec = dev->iommu_fwspec;
struct arm_smmu_master_cfg *cfg;
struct arm_smmu_device *smmu;
-
+   int ret;
  
  	if (!fwspec || fwspec->ops != &arm_smmu_ops)

return;
@@ -1436,8 +1450,21 @@ static void arm_smmu_remove_device(struct device *dev)
cfg  = fwspec->iommu_priv;
smmu = cfg->smmu;
  
+	/*

+* The device link between the master device and
+* smmu is already purged at this point.
+* So enable the power to smmu explicitly.
+*/


I don't understand this comment, especially since we don't even 
introduce device links until the following patch... :/



+
+   ret = pm_runtime_get_sync(smmu->dev);
+   if (ret)
+   return;
+
iommu_device_unlink(&smmu->iommu, dev);
arm_smmu_master_free_smes(fwspec);
+
+   pm_runtime_put_sync(smmu->dev);
+
iommu_group_remove_device(dev);
kfree(fwspec->iommu_priv);
iommu_fwspec_free(dev);
@@ -2130,6 +2157,14 @@ static int arm_smmu_device_probe(struct platform_device 
*pdev)
if (err)
return err;
  
+	platform_set_drvdata(pdev, smmu);

+
+   pm_runtime_enable(dev);
+
+   err = pm_runtime_get_sync(dev);
+   if (err)
+   return err;
+
err = arm_smmu_device_cfg_probe(smmu);
if (err)
return err;
@@ -2171,9 +2206,9 @@ static int arm_smmu_device_probe(struct platform_device 
*pdev)
return err;
}
  
-	platform_set_drvdata(pdev, smmu);

arm_smmu_device_reset(smmu);
arm_smmu_test_smr_masks(smmu);
+   pm_runtime_put_sync(dev);
  
  	/*

 * For ACPI and generic DT bindings, an SMMU will be probed before
@@ -2212,6 +2247,8 @@ static int arm_smmu_device_remove(struct platform_device 
*pdev)
  
  	/* Turn the thing off */

writel(sCR0_CLIENTPD, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0);
+   pm_runtime_force_suspend(smmu->dev);


Why do we need this? I guess it might be a Qualcomm-ism as I don't see 
anyone else calling it from .remove other than a couple of other qcom_* 
drivers. Given that we only get here during system shutdown (or the root 
user intentionally pissing about with driver unbinding), it doesn't seem 
like a point where power saving really matters all that much.


I'd also naively expect that anything this device was the last consumer 
off would get turned off by core code anyway once it's removed, but 
maybe things aren't that slick; I dunno :/


Robin.


+
return 0;
  }
  


___
dri-devel mailing list

  1   2   >