Modern processors can detect linear memory accesses and prefetch data
automatically, so there's no need to use prefetch.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
---
drivers/gpu/drm/udl/udl_transfer.c | 7 -------
1 file changed, 7 deletions(-)
Index: linux-4.16.12/drivers/gpu/drm/udl/udl_transfer.c
=================================--- linux-4.16.12.orig/drivers/gpu/drm/udl/udl_transfer.c 2018-05-31 14:48:12.000000000 +0200
@@ -51,9 +50,6 @@ static int udl_trim_hline(const u8 *bbacintstart=width;intend=width;-prefetch((void*)front);-prefetch((void*)back);-for(j=0;j<width;j++){if(back[j]!=front[j]){start=j;
@@ -140,8 +136,6 @@ static void udl_compress_hline16(constu8*cmd_pixel_start,*cmd_pixel_end=NULL;uint16_tpixel_val16;-prefetchw((void*)cmd);/* pull in one cache line at least */-*cmd++=0xaf;*cmd++=0x6b;*cmd++=(uint8_t)((dev_addr>>16)&0xFF);
The displaylink hardware has such a peculiarity that it doesn't render a
command until next command is received. This produces occasional
corruption, such as when setting 22x11 font on the console, only the first
line of the cursor will be blinking if the cursor is located at some
specific columns.
When we end up with a repeating pixel, the driver has a bug that it leaves
one uninitialized byte after the command (and this byte is enough to flush
the command and render it - thus it fixes the screen corruption), however
whe we end up with a non-repeating pixel, there is no byte appended and
this results in temporary screen corruption.
This patch fixes the screen corruption by always appending a byte 0xAF at
the end of URB. It also removes the uninitialized byte.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
---
drivers/gpu/drm/udl/udl_fb.c | 5 ++++-
drivers/gpu/drm/udl/udl_transfer.c | 11 +++++++----
2 files changed, 11 insertions(+), 5 deletions(-)
Index: linux-4.16.12/drivers/gpu/drm/udl/udl_transfer.c
=================================--- linux-4.16.12.orig/drivers/gpu/drm/udl/udl_transfer.c 2018-05-31 14:47:07.000000000 +0200
I observed that the performance of the udl fb driver degrades over time.
On a freshly booted machine, it takes 6 seconds to do "ls -la /usr/bin";
after some time of use, the same operation takes 14 seconds.
The reason is that the value of "limit_sem" decays over time.
The udl driver uses a semaphore "limit_set" to specify how many free urbs
are there on dlfb->urbs.list. If the count is zero, the "down" operation
will sleep until some urbs are added to the freelist.
In order to avoid some hypothetical deadlock, the driver will not call
"up" immediatelly, but it will offload it to a workqueue. The problem is
that if we call "schedule_delayed_work" on the same work item multiple
times, the work item may only be executed once.
This is happening:
* some urb completes
* dlfb_urb_completion adds it to the free list
* dlfb_urb_completion calls schedule_delayed_work to schedule the function
dlfb_release_urb_work to increase the semaphore count
* as the urb is on the free list, some other task grabs it and submits it
* the submitted urb completes, dlfb_urb_completion is called again
* dlfb_urb_completion calls schedule_delayed_work, but the work is already
scheduled, so it does nothing
* finally, dlfb_release_urb_work is called, it increases the semaphore
count by 1, although it should increase it by 2
So, the semaphore count is decreasing over time, and this causes gradual
performance degradation.
Note that in the current kernel, the "up" function may be called from
interrupt and it may race with the "down" function called by another
thread, so we don't have to offload the call of "up" to a workqueue at
all. This patch removes the workqueue code. The patch also changes
"down_interruptible" to "down" in dlfb_free_urb_list, so that we will
clean up the driver properly even if a signal arrives.
With this patch, the performance of udlfb no longer degrades.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
---
drivers/video/fbdev/udlfb.c | 27 ++-------------------------
include/video/udlfb.h | 1 -
2 files changed, 2 insertions(+), 26 deletions(-)
Index: linux-4.17-rc7/drivers/video/fbdev/udlfb.c
=================================--- linux-4.17-rc7.orig/drivers/video/fbdev/udlfb.c 2018-05-31 12:31:04.000000000 +0200
@@ -1805,16 +1790,11 @@ static void dlfb_free_urb_list(struct dlstructlist_head*node;structurb_node*unode;structurb*urb;-intret;unsignedlongflags;/* keep waiting and freeing, until we've got 'em all */while(count--){--/* Getting interrupted means a leak, but ok at disconnect */-ret=down_interruptible(&dlfb->urbs.limit_sem);-if(ret)-break;+down(&dlfb->urbs.limit_sem);spin_lock_irqsave(&dlfb->urbs.lock,flags);
@@ -1854,9 +1834,6 @@ static int dlfb_alloc_urb_list(struct dlbreak;unode->dlfb=dlfb;-INIT_DELAYED_WORK(&unode->release_urb_work,-dlfb_release_urb_work);-urb=usb_alloc_urb(0,GFP_KERNEL);if(!urb){kfree(unode);
If we leave urbs around, it causes not only leak, but also memory
corruption. This patch fixes the function udl_free_urb_list, so that it
always waits for all urbs that are in progress.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
---
drivers/gpu/drm/udl/udl_main.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
Index: linux-4.16.12/drivers/gpu/drm/udl/udl_main.c
=================================--- linux-4.16.12.orig/drivers/gpu/drm/udl/udl_main.c 2018-05-31 10:23:42.000000000 +0200
@@ -170,18 +170,13 @@ static void udl_free_urb_list(struct drmstructlist_head*node;structurb_node*unode;structurb*urb;-intret;unsignedlongflags;DRM_DEBUG("Waiting for completes and freeing all render urbs\n");/* keep waiting and freeing, until we've got 'em all */while(count--){--/* Getting interrupted means a leak, but ok at shutdown*/-ret=down_interruptible(&udl->urbs.limit_sem);-if(ret)-break;+down(&udl->urbs.limit_sem);spin_lock_irqsave(&udl->urbs.lock,flags);
Modern processors can detect linear memory accesses and prefetch data
automatically, so there's no need to use prefetch.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
---
drivers/video/fbdev/udlfb.c | 8 --------
1 file changed, 8 deletions(-)
Index: linux-4.17-rc7/drivers/video/fbdev/udlfb.c
=================================--- linux-4.17-rc7.orig/drivers/video/fbdev/udlfb.c 2018-05-31 12:48:35.000000000 +0200
@@ -375,9 +374,6 @@ static int dlfb_trim_hline(const u8 *bbaintstart=width;intend=width;-prefetch((void*)front);-prefetch((void*)back);-for(j=0;j<width;j++){if(back[j]!=front[j]){start=j;
@@ -454,8 +450,6 @@ static void dlfb_compress_hline(continue;}-prefetchw((void*)cmd);/* pull in one cache line at least */-*cmd++=0xAF;*cmd++=0x6B;*cmd++=dev_addr>>16;
Division is slow, so it shouldn't be done by the pixel generating code.
The driver supports only 2 or 4 bytes per pixel, so we can replace
division with a shift.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
---
drivers/gpu/drm/udl/udl_drv.h | 2 -
drivers/gpu/drm/udl/udl_fb.c | 15 ++++++++------
drivers/gpu/drm/udl/udl_transfer.c | 39 ++++++++++++++++++-------------------
3 files changed, 30 insertions(+), 26 deletions(-)
Index: linux-4.17-rc7/drivers/gpu/drm/udl/udl_drv.h
=================================--- linux-4.17-rc7.orig/drivers/gpu/drm/udl/udl_drv.h 2018-06-03 13:15:01.000000000 +0200
@@ -179,10 +180,10 @@ static void udl_compress_hline16(if(unlikely(pixel>start+bpp)){/* go back and fill in raw pixel count */*raw_pixels_count_byte=(((start--raw_pixel_start)/bpp)+1)&0xFF;+raw_pixel_start)>>log_bpp)+1)&0xFF;/* immediately after raw data is repeat byte */-*cmd++=(((pixel-start)/bpp)-1)&0xFF;+*cmd++=(((pixel-start)>>log_bpp)-1)&0xFF;/* Then start another raw pixel span */raw_pixel_start=pixel;
@@ -192,14 +193,14 @@ static void udl_compress_hline16(if(pixel>raw_pixel_start){/* finalize last RAW span */-*raw_pixels_count_byte=((pixel-raw_pixel_start)/bpp)&0xFF;+*raw_pixels_count_byte=((pixel-raw_pixel_start)>>log_bpp)&0xFF;}else{/* undo unused byte */cmd--;}-*cmd_pixels_count_byte=((pixel-cmd_pixel_start)/bpp)&0xFF;-dev_addr+=((pixel-cmd_pixel_start)/bpp)*2;+*cmd_pixels_count_byte=((pixel-cmd_pixel_start)>>log_bpp)&0xFF;+dev_addr+=((pixel-cmd_pixel_start)>>log_bpp)*2;}if(cmd_buffer_end<=MIN_RLX_CMD_BYTES+cmd){
Set the variable "line_length" in the function dlfb_ops_set_par. Without
this, we get garbage if we select different videomode with fbset.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
---
drivers/video/fbdev/udlfb.c | 1 +
1 file changed, 1 insertion(+)
Index: linux-4.17-rc7/drivers/video/fbdev/udlfb.c
=================================--- linux-4.17-rc7.orig/drivers/video/fbdev/udlfb.c 2018-05-31 14:50:00.000000000 +0200
Allocations larger than PAGE_ALLOC_COSTLY_ORDER are unreliable and they
may fail anytime. This patch fixes the udl kms driver so that when a large
alloactions fails, it tries to do multiple smaller allocations.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
---
drivers/gpu/drm/udl/udl_main.c | 28 ++++++++++++++++++----------
1 file changed, 18 insertions(+), 10 deletions(-)
Index: linux-4.16.12/drivers/gpu/drm/udl/udl_main.c
=================================--- linux-4.16.12.orig/drivers/gpu/drm/udl/udl_main.c 2018-05-31 11:16:15.000000000 +0200
This patch changes udlfb so that it may reallocate the framebuffer when
setting higher-resolution mode. If we boot the system without monitor
attached, udlfb creates a framebuffer with the size 800x600. This patch
makes it possible to select higher videomode with the fbset command when
a monitor is attached.
Note that there is no reliable way to prevent the system from touching the
old framebuffer, so we must not free it. We add it to the list
dlfb->deferred_free and free it when the driver is unloaded.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
---
drivers/video/fbdev/udlfb.c | 70 +++++++++++++++++++++++++++++---------------
include/video/udlfb.h | 1
2 files changed, 48 insertions(+), 23 deletions(-)
Index: linux-4.17-rc7/drivers/video/fbdev/udlfb.c
=================================--- linux-4.17-rc7.orig/drivers/video/fbdev/udlfb.c 2018-06-03 13:17:41.000000000 +0200
@@ -73,6 +73,13 @@ static bool fb_defio = 1; /* Detect mmastaticboolshadow=1;/* Optionally disable shadow framebuffer */staticintpixel_limit;/* Optionally force a pixel resolution limit */+structdlfb_deferred_free{+structlist_headlist;+void*mem;+};++staticintdlfb_realloc_framebuffer(structdlfb_data*dlfb,structfb_info*info,u32new_len);+/* dlfb keeps a list of urbs for efficient bulk transfers */staticvoiddlfb_urb_completion(structurb*urb);staticstructurb*dlfb_get_urb(structdlfb_data*dlfb);
@@ -1020,10 +1033,6 @@ static int dlfb_ops_check_var(struct fb_structfb_videomodemode;structdlfb_data*dlfb=info->par;-/* TODO: support dynamically changing framebuffer size */-if((var->xres*var->yres*2)>info->fix.smem_len)-return-EINVAL;-/* set device-specific elements of var unrelated to mode */dlfb_var_color_format(var);
@@ -1042,6 +1051,7 @@ static int dlfb_ops_set_par(struct fb_inu16*pix_framebuffer;inti;structfb_var_screeninfofvs;+u32line_length=info->var.xres*(info->var.bits_per_pixel/8);/* clear the activate field because it causes spurious miscompares */fvs=info->var;
@@ -1051,13 +1061,17 @@ static int dlfb_ops_set_par(struct fb_inif(!memcmp(&dlfb->current_mode,&fvs,sizeof(structfb_var_screeninfo)))return0;+result=dlfb_realloc_framebuffer(dlfb,info,info->var.yres*line_length);+if(result)+returnresult;+result=dlfb_set_video_mode(dlfb,&info->var);if(result)returnresult;dlfb->current_mode=fvs;-info->fix.line_length=info->var.xres*(info->var.bits_per_pixel/8);+info->fix.line_length=line_length;if(dlfb->fb_count=0){
@@ -1066,11 +1080,11 @@ static int dlfb_ops_set_par(struct fb_inpix_framebuffer=(u16*)info->screen_base;for(i=0;i<info->fix.smem_len/2;i++)pix_framebuffer[i]=0x37e6;--dlfb_handle_damage(dlfb,0,0,info->var.xres,info->var.yres,-info->screen_base);}+dlfb_handle_damage(dlfb,0,0,info->var.xres,info->var.yres,+info->screen_base);+return0;}
@@ -1596,6 +1617,7 @@ static int dlfb_usb_probe(struct usb_int}kref_init(&dlfb->kref);/* matching kref_put in usb .disconnect fn */+INIT_LIST_HEAD(&dlfb->deferred_free);dlfb->udev=usbdev;usb_set_intfdata(intf,dlfb);
We must use kzalloc when allocating the fb_deferred_io structure.
Otherwise, the field first_io is undefined and it causes a crash.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
---
drivers/gpu/drm/udl/udl_fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-4.16.12/drivers/gpu/drm/udl/udl_fb.c
=================================--- linux-4.16.12.orig/drivers/gpu/drm/udl/udl_fb.c 2018-05-29 17:55:39.000000000 +0200
spin_lock_irqsave and spin_unlock_irqrestore is inteded to be called from
a context where it is unknown if interrupts are enabled or disabled (such
as interrupt handlers). From a process context, we should call
spin_lock_irq and spin_unlock_irq, that avoids the costly pushf and popf
instructions.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
---
drivers/gpu/drm/udl/udl_main.c | 10 ++++------
drivers/gpu/drm/udl/udl_modeset.c | 5 ++---
2 files changed, 6 insertions(+), 9 deletions(-)
Index: linux-4.16.12/drivers/gpu/drm/udl/udl_main.c
=================================--- linux-4.16.12.orig/drivers/gpu/drm/udl/udl_main.c 2018-05-31 11:17:01.000000000 +0200
@@ -170,7 +170,6 @@ static void udl_free_urb_list(struct drmstructlist_head*node;structurb_node*unode;structurb*urb;-unsignedlongflags;DRM_DEBUG("Waiting for completes and freeing all render urbs\n");
@@ -178,12 +177,12 @@ static void udl_free_urb_list(struct drmwhile(count--){down(&udl->urbs.limit_sem);-spin_lock_irqsave(&udl->urbs.lock,flags);+spin_lock_irq(&udl->urbs.lock);node=udl->urbs.list.next;/* have reserved one with sem */list_del_init(node);-spin_unlock_irqrestore(&udl->urbs.lock,flags);+spin_unlock_irq(&udl->urbs.lock);unode=list_entry(node,structurb_node,entry);urb=unode->urb;
@@ -268,7 +267,6 @@ struct urb *udl_get_urb(struct drm_devicstructlist_head*entry;structurb_node*unode;structurb*urb=NULL;-unsignedlongflags;/* Wait for an in-flight buffer to complete and get re-queued */ret=down_timeout(&udl->urbs.limit_sem,GET_URB_TIMEOUT);
@@ -279,14 +277,14 @@ struct urb *udl_get_urb(struct drm_devicgotoerror;}-spin_lock_irqsave(&udl->urbs.lock,flags);+spin_lock_irq(&udl->urbs.lock);BUG_ON(list_empty(&udl->urbs.list));/* reserved one with limit_sem */entry=udl->urbs.list.next;list_del_init(entry);udl->urbs.available--;-spin_unlock_irqrestore(&udl->urbs.lock,flags);+spin_unlock_irq(&udl->urbs.lock);unode=list_entry(entry,structurb_node,entry);urb=unode->urb;
The defio subsystem overwrites the method fb_osp->mmap. That method is
stored in module's static data - and that means that if we have multiple
diplaylink adapters, they will over write each other's method.
In order to avoid interference between multiple adapters, we copy the
fb_ops structure to a device-local memory.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
---
drivers/gpu/drm/udl/udl_fb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux-4.17-rc7/drivers/gpu/drm/udl/udl_fb.c
=================================--- linux-4.17-rc7.orig/drivers/gpu/drm/udl/udl_fb.c 2018-06-03 13:05:20.000000000 +0200
Allocations larger than PAGE_ALLOC_COSTLY_ORDER are unreliable and they
may fail anytime. This patch fixes the udlfb driver so that when a large
alloactions fails, it tries to do multiple smaller allocations.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
---
drivers/video/fbdev/udlfb.c | 26 +++++++++++++++++---------
1 file changed, 17 insertions(+), 9 deletions(-)
Index: linux-4.17-rc7/drivers/video/fbdev/udlfb.c
=================================--- linux-4.17-rc7.orig/drivers/video/fbdev/udlfb.c 2018-06-03 13:17:38.000000000 +0200
The default delay 5 jiffies is too much when the kernel is compiled with
HZ0 - it results in jumpy cursor in Xwindow.
In order to find out the optimal delay, I benchmarked the driver on
1280x720x30fps video. I found out that with HZ00, 10ms is acceptable,
but with HZ%0 or HZ00, we need 4ms, so that the video is played
without any frame skips.
This patch changes the delay to this value.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
---
include/video/udlfb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-4.17-rc7/include/video/udlfb.h
=================================--- linux-4.17-rc7.orig/include/video/udlfb.h 2018-06-03 13:17:37.000000000 +0200
@@ -88,7 +88,7 @@ struct dlfb_data {#define MIN_RAW_PIX_BYTES 2#define MIN_RAW_CMD_BYTES (RAW_HEADER_BYTES + MIN_RAW_PIX_BYTES)-#define DL_DEFIO_WRITE_DELAY 5 /* fb_deferred_io.delay in jiffies */+#define DL_DEFIO_WRITE_DELAY msecs_to_jiffies(HZ <= 300 ? 4 : 10) /* optimal value for 720p video */#define DL_DEFIO_WRITE_DISABLE (HZ*60) /* "disable" with long delay *//* remove these once align.h patch is taken into kernel */
The defio subsystem overwrites the method fb_osp->mmap. That method is
stored in module's static data - and that means that if we have multiple
diplaylink adapters, they will over write each other's method.
In order to avoid interference between multiple adapters, we copy the
fb_ops structure to a device-local memory.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
---
drivers/video/fbdev/udlfb.c | 3 ++-
include/video/udlfb.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
Index: linux-4.17-rc7/drivers/video/fbdev/udlfb.c
=================================--- linux-4.17-rc7.orig/drivers/video/fbdev/udlfb.c 2018-06-03 13:17:33.000000000 +0200
The udl kms driver writes messages to the syslog whenever some application
opens or closes /dev/fb0 and whenever the user switches between the
Xserver and the console.
This patch changes the priority of these messages to debug.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
---
drivers/gpu/drm/udl/udl_fb.c | 6 +++---
drivers/gpu/drm/udl/udl_modeset.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
Index: linux-4.17-rc7/drivers/gpu/drm/udl/udl_fb.c
=================================--- linux-4.17-rc7.orig/drivers/gpu/drm/udl/udl_fb.c 2018-06-03 13:17:58.000000000 +0200
@@ -179,7 +179,7 @@ static int udl_fb_mmap(struct fb_info *ipos=(unsignedlong)info->fix.smem_start+offset;-pr_notice("mmap() framebuffer addr:%lu size:%lu\n",+pr_debug("mmap() framebuffer addr:%lu size:%lu\n",pos,size);/* We don't want the framebuffer to be mapped encrypted */
@@ -243,7 +243,7 @@ static int udl_crtc_write_mode_to_hw(strmemcpy(buf,udl->mode_buf,udl->mode_buf_len);retval=udl_submit_urb(dev,urb,udl->mode_buf_len);-DRM_INFO("write mode info %d\n",udl->mode_buf_len);+DRM_DEBUG("write mode info %d\n",udl->mode_buf_len);returnretval;}
The udlfb driver reprograms the hardware everytime the user switches the
console, that makes quite unusable when working on the console.
This patch makes the driver remember the videomode we are in and avoid
reprogramming the hardware if we switch to the same videomode.
We mask the "activate" field and the "FB_VMODE_SMOOTH_XPAN" flag when
comparing the videomode, because they cause spurious switches when
switching to and from the Xserver.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
---
drivers/video/fbdev/udlfb.c | 18 ++++++++++++++++--
include/video/udlfb.h | 1 +
2 files changed, 17 insertions(+), 2 deletions(-)
Index: linux-4.17-rc7/drivers/video/fbdev/udlfb.c
=================================--- linux-4.17-rc7.orig/drivers/video/fbdev/udlfb.c 2018-05-31 14:49:52.000000000 +0200
@@ -1041,10 +1041,24 @@ static int dlfb_ops_set_par(struct fb_inintresult;u16*pix_framebuffer;inti;+structfb_var_screeninfofvs;++/* clear the activate field because it causes spurious miscompares */+fvs=info->var;+fvs.activate=0;+fvs.vmode&=~FB_VMODE_SMOOTH_XPAN;++if(!memcmp(&dlfb->current_mode,&fvs,sizeof(structfb_var_screeninfo)))+return0;result=dlfb_set_video_mode(dlfb,&info->var);-if((result=0)&&(dlfb->fb_count=0)){+if(result)+returnresult;++dlfb->current_mode=fvs;++if(dlfb->fb_count=0){/* paint greenscreen */
@@ -1056,7 +1070,7 @@ static int dlfb_ops_set_par(struct fb_ininfo->screen_base);}-returnresult;+return0;}/* To fonzi the jukebox (e.g. make blanking changes take effect) */
Currently, the udlfb driver only tests for identical bytes at the
beginning or at the end of a page and renders anything between the first
and last mismatching pixel. But pages are not the same as lines, so this
is quite suboptimal - if there is something modified at the beginning of a
page and at the end of a page, the whole page is rendered, even if most of
the page is not modified.
This patch makes it test for identical pixels at the beginning and end of
each rendering command. This patch improves identical byte detection by
41% when playing video in a window.
This patch also fixes a possible screen corruption if the user is writing
to the framebuffer while dlfb_render_hline is in progress - the pixel data
that is copied to the backbuffer with memcpy may be different from the
pixel data that is actually rendered to the hardware (because the content
of the framebuffer may change between memcpy and the rendering command).
We must make sure that we copy exactly the same pixel as the pixel that is
being rendered.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
---
drivers/video/fbdev/udlfb.c | 45 +++++++++++++++++++++++++++++++++-----------
1 file changed, 34 insertions(+), 11 deletions(-)
Index: linux-4.17-rc7/drivers/video/fbdev/udlfb.c
=================================--- linux-4.17-rc7.orig/drivers/video/fbdev/udlfb.c 2018-05-31 14:51:43.000000000 +0200
@@ -444,6 +446,14 @@ static void dlfb_compress_hline(constuint16_t*raw_pixel_start=NULL;constuint16_t*cmd_pixel_start,*cmd_pixel_end=NULL;+if(back_buffer_offset&&+*pixel=*(u16*)((u8*)pixel+back_buffer_offset)){+pixel++;+dev_addr+=BPP;+(*ident_ptr)++;+continue;+}+prefetchw((void*)cmd);/* pull in one cache line at least */*cmd++=0xAF;
@@ -462,25 +472,37 @@ static void dlfb_compress_hline((unsignedlong)(pixel_end-pixel),(unsignedlong)(cmd_buffer_end-1-cmd)/BPP);+if(back_buffer_offset){+/* note: the framebuffer may change under us, so we must test for underflow */+while(cmd_pixel_end-1>pixel&&+*(cmd_pixel_end-1)=*(u16*)((u8*)(cmd_pixel_end-1)+back_buffer_offset))+cmd_pixel_end--;+}+prefetch_range((void*)pixel,(u8*)cmd_pixel_end-(u8*)pixel);while(pixel<cmd_pixel_end){constuint16_t*constrepeating_pixel=pixel;+u16pixel_value=*pixel;-put_unaligned_be16(*pixel,cmd);+put_unaligned_be16(pixel_value,cmd);+if(back_buffer_offset)+*(u16*)((u8*)pixel+back_buffer_offset)=pixel_value;cmd+=2;pixel++;if(unlikely((pixel<cmd_pixel_end)&&-(*pixel=*repeating_pixel))){+(*pixel=pixel_value))){/* go back and fill in raw pixel count */*raw_pixels_count_byte=((repeating_pixel-raw_pixel_start)+1)&0xFF;-while((pixel<cmd_pixel_end)-&&(*pixel=*repeating_pixel)){-pixel++;-}+do{+if(back_buffer_offset)+*(u16*)((u8*)pixel+back_buffer_offset)=pixel_value;+pixel++;+}while((pixel<cmd_pixel_end)&&+(*pixel=pixel_value));/* immediately after raw data is repeat byte */*cmd++=((pixel-repeating_pixel)-1)&0xFF;
@@ -531,6 +553,7 @@ static int dlfb_render_hline(struct dlfbstructurb*urb=*urb_ptr;u8*cmd=*urb_buf_ptr;u8*cmd_end=(u8*)urb->transfer_buffer+urb->transfer_buffer_length;+unsignedlongback_buffer_offset=0;line_start=(u8*)(front+byte_offset);next_pixel=line_start;
@@ -541,6 +564,8 @@ static int dlfb_render_hline(struct dlfbconstu8*back_start=(u8*)(dlfb->backing_buffer+byte_offset);+back_buffer_offset=(unsignedlong)back_start-(unsignedlong)line_start;+*ident_ptr+=dlfb_trim_hline(back_start,&next_pixel,&byte_width);
@@ -549,16 +574,14 @@ static int dlfb_render_hline(struct dlfbdev_addr+=offset;back_start+=offset;line_start+=offset;--memcpy((char*)back_start,(char*)line_start,-byte_width);}while(next_pixel<line_end){dlfb_compress_hline((constuint16_t**)&next_pixel,(constuint16_t*)line_end,&dev_addr,-(u8**)&cmd,(u8*)cmd_end);+(u8**)&cmd,(u8*)cmd_end,back_buffer_offset,+ident_ptr);if(cmd>=cmd_end){intlen=cmd-(u8*)urb->transfer_buffer;
spin_lock_irqsave and spin_unlock_irqrestore is inteded to be called from
a context where it is unknown if interrupts are enabled or disabled (such
as interrupt handlers). From a process context, we should call
spin_lock_irq and spin_unlock_irq, that avoids the costly pushf and popf
instructions.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
---
drivers/video/fbdev/udlfb.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
Index: linux-4.17-rc7/drivers/video/fbdev/udlfb.c
=================================--- linux-4.17-rc7.orig/drivers/video/fbdev/udlfb.c 2018-06-03 13:17:46.000000000 +0200
@@ -1855,18 +1855,17 @@ static void dlfb_free_urb_list(struct dlstructlist_head*node;structurb_node*unode;structurb*urb;-unsignedlongflags;/* keep waiting and freeing, until we've got 'em all */while(count--){down(&dlfb->urbs.limit_sem);-spin_lock_irqsave(&dlfb->urbs.lock,flags);+spin_lock_irq(&dlfb->urbs.lock);node=dlfb->urbs.list.next;/* have reserved one with sem */list_del_init(node);-spin_unlock_irqrestore(&dlfb->urbs.lock,flags);+spin_unlock_irq(&dlfb->urbs.lock);unode=list_entry(node,structurb_node,entry);urb=unode->urb;
@@ -1944,7 +1943,6 @@ static struct urb *dlfb_get_urb(struct dintret;structlist_head*entry;structurb_node*unode;-unsignedlongflags;/* Wait for an in-flight buffer to complete and get re-queued */ret=down_timeout(&dlfb->urbs.limit_sem,GET_URB_TIMEOUT);
@@ -1956,14 +1954,14 @@ static struct urb *dlfb_get_urb(struct dreturnNULL;}-spin_lock_irqsave(&dlfb->urbs.lock,flags);+spin_lock_irq(&dlfb->urbs.lock);BUG_ON(list_empty(&dlfb->urbs.list));/* reserved one with limit_sem */entry=dlfb->urbs.list.next;list_del_init(entry);dlfb->urbs.available--;-spin_unlock_irqrestore(&dlfb->urbs.lock,flags);+spin_unlock_irq(&dlfb->urbs.lock);unode=list_entry(entry,structurb_node,entry);returnunode->urb;
The displaylink hardware has such a peculiarity that it doesn't render a
command until next command is received. This produces occasional
corruption, such as when setting 22x11 font on the console, only the first
line of the cursor will be blinking if the cursor is located at some
specific columns.
When we end up with a repeating pixel, the driver has a bug that it leaves
one uninitialized byte after the command (and this byte is enough to flush
the command and render it - thus it fixes the screen corruption), however
whe we end up with a non-repeating pixel, there is no byte appended and
this results in temporary screen corruption.
This patch fixes the screen corruption by always appending a byte 0xAF at
the end of URB. It also removes the uninitialized byte.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
---
drivers/video/fbdev/udlfb.c | 30 ++++++++++++++++++++----------
1 file changed, 20 insertions(+), 10 deletions(-)
Index: linux-4.17-rc7/drivers/video/fbdev/udlfb.c
=================================--- linux-4.17-rc7.orig/drivers/video/fbdev/udlfb.c 2018-05-31 14:43:13.000000000 +0200
From: kbuild test robot <hidden> Date: 2018-06-03 19:24:58
Hi Mikulas,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.17-rc7 next-20180601]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Mikulas-Patocka/USB-DisplayLink-patches/20180603-233013
base: git://people.freedesktop.org/~airlied/linux.git drm-next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
vim +1198 drivers/video/fbdev/udlfb.c
1171
1172 /*
1173 * Assumes &info->lock held by caller
1174 * Assumes no active clients have framebuffer open
1175 */
1176 static int dlfb_realloc_framebuffer(struct dlfb_data *dlfb, struct fb_info *info, u32 new_len)
1177 {
1178 u32 old_len = info->fix.smem_len;
1199 }
1200
1201 info->screen_base = new_fb;
1202 info->fix.smem_len = new_len;
1203 info->fix.smem_start = (unsigned long) new_fb;
1204 info->flags = udlfb_info_flags;
1205
1206 /*
1207 * Second framebuffer copy to mirror the framebuffer state
1208 * on the physical USB device. We can function without this.
1209 * But with imperfect damage info we may send pixels over USB
1210 * that were, in fact, unchanged - wasting limited USB bandwidth
1211 */
1212 if (shadow)
1213 new_back = vzalloc(new_len);
1214 if (!new_back)
1215 dev_info(info->dev,
1216 "No shadow/backing buffer allocated\n");
1217 else {
1218 dlfb_deferred_vfree(dlfb, dlfb->backing_buffer);
1219 dlfb->backing_buffer = new_back;
1220 }
1221 }
1222 return 0;
1223 }
1224
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
From: Dave Airlie <airlied@gmail.com> Date: 2018-06-04 01:25:08
On 4 June 2018 at 00:40, Mikulas Patocka [off-list ref] wrote:
Hi
Here I'm sending bug fixes and performance improvements for the USB
DisplayLink framebuffer and modesetting drivers for this merge window.
Hi,
You probably want to split these up into separate series for the kms and fbdev
drivers.
Otherwise at least for drm you've missed this merge window, since it
closes around rc6 of the previous kernel, did you use git send-email
for these patches, at least some of them viewed funny on my phone,
I'll try and look over the kms ones soon. Do you have any numbers for
improvements to the kms ones?
Dave.
On 4 June 2018 at 00:40, Mikulas Patocka [off-list ref] wrote:
quoted
Hi
Here I'm sending bug fixes and performance improvements for the USB
DisplayLink framebuffer and modesetting drivers for this merge window.
Hi,
You probably want to split these up into separate series for the kms and fbdev
drivers.
Otherwise at least for drm you've missed this merge window, since it
closes around rc6 of the previous kernel,
Could you apply at least the fbdefio patches (without them, fbdefio is
unusable due to crashes) and the display corruption of the last line
(because most people will hit it)?
did you use git send-email
for these patches, at least some of them viewed funny on my phone,
I used the command "quilt mail". I use quilt, not git, for management of
my patches.
I'll try and look over the kms ones soon. Do you have any numbers for
improvements to the kms ones?
Dave.
I measured performance improvement on the framebuffer patches. The kms
driver already performs well, there's not much to do.
I'd like to as you if you could review the patch "udl-kms: fix a
linked-list corruption when using fbdefio" - for me it fixes the crashes,
but I am not expert in modesetting drivers and I don't know if some other
part of the kernel assumes that the framebuffer pages must be allocated
with drm_gem_get_pages.
BTW. When I unplug the USB adapter while using the modesetting driver, I
get this warning. Do you have an idea how to fix it?
WARNING: CPU: 0 PID: 61 at drivers/gpu/drm/drm_mode_config.c:439 drm_mode_config_cleanup+0x250/0x2b8 [drm]
Modules linked in: udlfb hid_generic usbhid hid tun bridge stp llc autofs4 binfmt_misc ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipt_REJECT nf_reject_ipv4 xt_conntrack xt_multiport iptable_filter iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_nat xt_tcpudp iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 ip_tables x_tables pppoe pppox af_packet ppp_generic slhc udl drm_kms_helper cfbfillrect cfbimgblt cfbcopyarea drm drm_panel_orientation_quirks syscopyarea sysfillrect sysimgblt fb_sys_fops fb font snd_usb_audio snd_hwdep snd_usbmidi_lib snd_rawmidi snd_pcm snd_timer snd soundcore nf_nat_ftp nf_conntrack_ftp nf_nat nf_conntrack sd_mod ipv6 aes_ce_blk crypto_simd cryptd aes_ce_cipher crc32_ce ghash_ce gf128mul aes_arm64 sha2_ce
sha256_arm64 sha1_ce xhci_plat_hcd xhci_hcd sha1_generic usbcore usb_common ahci_platform libahci_platform libahci mvpp2 unix
CPU: 0 PID: 61 Comm: kworker/0:2 Not tainted 4.17.0-rc7 #1
Hardware name: Marvell 8040 MACCHIATOBin (DT)
Workqueue: usb_hub_wq hub_event [usbcore]
pstate: 80000005 (Nzcv daif -PAN -UAO)
pc : drm_mode_config_cleanup+0x250/0x2b8 [drm]
lr : drm_mode_config_cleanup+0x88/0x2b8 [drm]
sp : ffffffc13a643920
x29: ffffffc13a643920 x28: ffffffc13a63ac00
x27: ffffffc1380962c0 x26: ffffffc11b95f898
x25: ffffff8000afd1d8 x24: ffffffc11b95f800
x23: 0000000000000060 x22: ffffff8000afd240
x21: ffffffc11b95eb38 x20: ffffffc11b95e800
x19: ffffffc11b95eb30 x18: ffffffc11b95ea7c
x17: 0000007fa3591b60 x16: ffffff80081dc178
x15: ffffffc11b95ea78 x14: 0000000000000000
x13: ffffffc12b3fc000 x12: ffffffc12b3fc028
x11: ffffffc12b3fc119 x10: 000000000000001f
x9 : 0000000000000028 x8 : ffffff8000a84000
x7 : 0000000000000000 x6 : 0000000000000001
x5 : 0000000000000002 x4 : 0000000000000001
x3 : 0000000000000002 x2 : 000000000000002f
x1 : ffffffc11b95eaf8 x0 : ffffffc11b978818
Call trace:
drm_mode_config_cleanup+0x250/0x2b8 [drm]
udl_modeset_cleanup+0xc/0x18 [udl]
udl_driver_unload+0x30/0x50 [udl]
drm_dev_unregister+0x3c/0xe8 [drm]
drm_dev_unplug+0x18/0x70 [drm]
udl_usb_disconnect+0x30/0x40 [udl]
usb_unbind_interface+0x6c/0x290 [usbcore]
device_release_driver_internal+0x170/0x200
device_release_driver+0x14/0x20
bus_remove_device+0x118/0x128
device_del+0x110/0x308
usb_disable_device+0x8c/0x1f8 [usbcore]
usb_disconnect+0xb4/0x218 [usbcore]
usb_disconnect+0x9c/0x218 [usbcore]
usb_disconnect+0x9c/0x218 [usbcore]
hub_event+0xf20/0x1020 [usbcore]
process_one_work+0x1c8/0x310
worker_thread+0x44/0x450
kthread+0x118/0x120
ret_from_fork+0x10/0x18
---[ end trace 978a27ff198f1268 ]---
[drm:drm_mode_config_cleanup [drm]] *ERROR* connector DVI-I-1 leaked!
Mikulas
@@ -51,9 +50,6 @@ static int udl_trim_hline(const u8 *bbacintstart=width;intend=width;-prefetch((void*)front);-prefetch((void*)back);
AFAIK prefetcher fetches new data according to a known history... i.e. based on previously
used pattern we'll trying to get the next batch of data.
But the code above is in the very beginning of the data processing routine where
prefetcher doesn't yet have any history to know what and where to prefetch.
So I'd say this particular usage is good.
At least those prefetches shouldn't hurt because typically it
would be just 1 instruction if those exist or nothing if CPU/compiler doesn't
support it.
quoted
for (j = 0; j < width; j++) {
if (back[j] != front[j]) {
start = j;
@@ -140,8 +136,6 @@ static void udl_compress_hline16( const u8 *cmd_pixel_start, *cmd_pixel_end = NULL; uint16_t pixel_val16;- prefetchw((void *) cmd); /* pull in one cache line at least */-
Pretty much the same is here. Obviously on the first iteration prefetcher dosn't
know where to get "cmd". On the next iterations it might be better but given amount
of operation happens further in the cycle (and in inner cycles) I won't be completely
sure that each and every prefetcher will still keep track of "cmd".
Again I'm not sure what we gain removing that code in comparison of possible
performance degradation on simpler CPUs.
And essentially all the same is applicable to UDLFB patch.
Tested this one on AT91SAM9G20 SoC, but couldn't get any measurable difference.
Part of problem is probably that full speed USB is the bottleneck here.
However, the same applies on OMAP3630 based board with high speed USB.
As a side note, I didn't experience any problem those paches are fixing, so
perhaps testcases could be described briefly, preferably with some numbers
(I'm not running console on udlfb, but try to give it a try next week).
Thank you,
ladis
@@ -51,9 +50,6 @@ static int udl_trim_hline(const u8 *bbacintstart=width;intend=width;-prefetch((void*)front);-prefetch((void*)back);
AFAIK prefetcher fetches new data according to a known history... i.e. based on previously
used pattern we'll trying to get the next batch of data.
But the code above is in the very beginning of the data processing routine where
prefetcher doesn't yet have any history to know what and where to prefetch.
So I'd say this particular usage is good.
At least those prefetches shouldn't hurt because typically it
would be just 1 instruction if those exist or nothing if CPU/compiler doesn't
support it.
See this post https://lwn.net/Articles/444336/ where they measured that
prefetch hurts performance. Prefetch shouldn't be used unless you have a
proof that it improves performance.
The problem is that the prefetch instruction causes stalls in the pipeline
when it encounters TLB miss and the automatic prefetcher doesn't.
Mikulas
Hi Mikulas,
On Sun, 2018-06-03 at 16:40 +0200, Mikulas Patocka wrote:
quoted
Hi
Here I'm sending bug fixes and performance improvements for the USB
DisplayLink framebuffer and modesetting drivers for this merge window.
For such a long series it would be very nice to post a link to your git
tree so people may play with your changes easily.
Could you please prepare one?
-Alexey
@@ -51,9 +50,6 @@ static int udl_trim_hline(const u8 *bbacintstart=width;intend=width;-prefetch((void*)front);-prefetch((void*)back);
AFAIK prefetcher fetches new data according to a known history... i.e. based on previously
used pattern we'll trying to get the next batch of data.
But the code above is in the very beginning of the data processing routine where
prefetcher doesn't yet have any history to know what and where to prefetch.
So I'd say this particular usage is good.
At least those prefetches shouldn't hurt because typically it
would be just 1 instruction if those exist or nothing if CPU/compiler doesn't
support it.
See this post https://urldefense.proofpoint.com/v2/url?u=https-3A__lwn.net_Articles_444336_&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656e
ViXO7breS55ytWkhpk5R81I&m¥RaqJtvajFkM1hL7bOKD5jV7cpFfTvG2Y1cYCdBPd0&s=w0W8wFtAgENp8TE6RzdPGhdKRasJc_otIn08V0EkgrY&e= where they measured that
prefetch hurts performance. Prefetch shouldn't be used unless you have a
proof that it improves performance.
The problem is that the prefetch instruction causes stalls in the pipeline
when it encounters TLB miss and the automatic prefetcher doesn't.
Wow, thanks for the link.
I didn't know about that subtle issue with prefetch instructions on ARM and x86.
So OK in case of UDL these prefetches anyways make not not much sense I guess and there's
something worse still, see what I've got from WandBoard Quad running kmscube [1] application
with help of perf utility:
--------------------------->8-------------------------
# Overhead Command Shared Object Symbol
# ........ ....... ....................... ........................................
#
92.93% kmscube [kernel.kallsyms] [k] udl_render_hline
2.51% kmscube [kernel.kallsyms] [k] __divsi3
0.33% kmscube [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore
0.22% kmscube [kernel.kallsyms] [k] lock_acquire
0.19% kmscube [kernel.kallsyms] [k] _raw_spin_unlock_irq
0.17% kmscube [kernel.kallsyms] [k] udl_handle_damage
0.12% kmscube [kernel.kallsyms] [k] v7_dma_clean_range
0.11% kmscube [kernel.kallsyms] [k] l2c210_clean_range
0.06% kmscube [kernel.kallsyms] [k] __memzero
--------------------------->8-------------------------
That said it's not even USB 2.0 which is a bottle-neck but
computations in the udl_render_hline().
[1] https://cgit.freedesktop.org/mesa/kmscube/
-Alexey
Try this patch
http://people.redhat.com/~mpatocka/patches/kernel/udl/udlkms-avoid-division.patch
It is doing a lot of divisions - and WandBoard has Cortex-A9, that doesn't
have division instruction.
BTW. the framebuffer UDL driver (not the modesetting driver) has
performance counters in sysfs. Their location depends on the system, you
can find them with find /sys -name "*metrics*"
The file "metrics_reset" resets the counters, so you can measure if the
prefetch instructions improve performance or not.
Mikulas
1199 }
1200
1201 info->screen_base = new_fb;
1202 info->fix.smem_len = new_len;
1203 info->fix.smem_start = (unsigned long) new_fb;
1204 info->flags = udlfb_info_flags;
1205
1206 /*
1207 * Second framebuffer copy to mirror the framebuffer state
1208 * on the physical USB device. We can function without this.
1209 * But with imperfect damage info we may send pixels over USB
1210 * that were, in fact, unchanged - wasting limited USB bandwidth
1211 */
1212 if (shadow)
1213 new_back = vzalloc(new_len);
1214 if (!new_back)
1215 dev_info(info->dev,
1216 "No shadow/backing buffer allocated\n");
1217 else {
1218 dlfb_deferred_vfree(dlfb, dlfb->backing_buffer);
1219 dlfb->backing_buffer = new_back;
1220 }
1221 }
1222 return 0;
1223 }
1224
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
What is it really complaining about? That URL shows 404 Not Found and this
email has no warnings at all.
screen_base in struct fb_info is annotated with __iomem tag:
...
char __iomem *screen_base; /* Virtual address */
...
and this tag should be preserved (or explicitly casted).
quoted
base: git://people.freedesktop.org/~airlied/linux.git drm-next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
You should be able to reproduce the issue with the above sequence.
quoted
sparse warnings: (new ones prefixed by >>)
[...]
quoted
1178 u32 old_len = info->fix.smem_len;
quoted
1179 unsigned char *old_fb = info->screen_base;
1180 unsigned char *new_fb;
[...]
quoted
1196 if (info->screen_base) {
1197 memcpy(new_fb, old_fb, old_len);
From: Daniel Vetter <hidden> Date: 2018-07-04 08:04:45
On Mon, Jun 04, 2018 at 10:14:02AM -0400, Mikulas Patocka wrote:
On Mon, 4 Jun 2018, Dave Airlie wrote:
quoted
On 4 June 2018 at 00:40, Mikulas Patocka [off-list ref] wrote:
quoted
Hi
Here I'm sending bug fixes and performance improvements for the USB
DisplayLink framebuffer and modesetting drivers for this merge window.
Hi,
You probably want to split these up into separate series for the kms and fbdev
drivers.
Otherwise at least for drm you've missed this merge window, since it
closes around rc6 of the previous kernel,
Could you apply at least the fbdefio patches (without them, fbdefio is
unusable due to crashes) and the display corruption of the last line
(because most people will hit it)?
quoted
did you use git send-email
for these patches, at least some of them viewed funny on my phone,
I used the command "quilt mail". I use quilt, not git, for management of
my patches.
quoted
I'll try and look over the kms ones soon. Do you have any numbers for
improvements to the kms ones?
Dave.
I measured performance improvement on the framebuffer patches. The kms
driver already performs well, there's not much to do.
I'd like to as you if you could review the patch "udl-kms: fix a
linked-list corruption when using fbdefio" - for me it fixes the crashes,
but I am not expert in modesetting drivers and I don't know if some other
part of the kernel assumes that the framebuffer pages must be allocated
with drm_gem_get_pages.
BTW. When I unplug the USB adapter while using the modesetting driver, I
get this warning. Do you have an idea how to fix it?
Probably the driver is missing a proper shutdown call (for atomic drivers
this would be drm_atomic_helper_shutdown), leaving the connector active,
which leaves it's reference count elevated. Or something like that.
Aside: Should we maintain uld as part of drm-misc under the small drivers
topic? Or is this patch pile here more a one-shot effort? See
https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html#small-drivers
Cheers, Daniel
On Tuesday, June 05, 2018 11:34:42 AM Mikulas Patocka wrote:
On Tue, 5 Jun 2018, Alexey Brodkin wrote:
quoted
Hi Mikulas,
On Sun, 2018-06-03 at 16:40 +0200, Mikulas Patocka wrote:
quoted
Hi
Here I'm sending bug fixes and performance improvements for the USB
DisplayLink framebuffer and modesetting drivers for this merge window.
For such a long series it would be very nice to post a link to your git
tree so people may play with your changes easily.
Could you please prepare one?
-Alexey
I've queued fbdev ones for 4.19 (w/ some minor fixes), thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics