Re: [PATCH v3 6/8] drm: Expose modes with aspect ratio, only if requested
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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()
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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()
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
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)
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)
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)
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()
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)
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
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()
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
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
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
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
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
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 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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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()
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
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
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
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