1. 31 Jul, 2018 1 commit
  2. 25 Jul, 2018 12 commits
    • Mikulas Patocka's avatar
      udlfb: use spin_lock_irq instead of spin_lock_irqsave · cb782a3f
      Mikulas Patocka authored
      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: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      cb782a3f
    • Mikulas Patocka's avatar
      udlfb: avoid prefetch · 037dde41
      Mikulas Patocka authored
      Modern processors can detect linear memory accesses and prefetch data
      automatically, so there's no need to use prefetch.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      037dde41
    • Mikulas Patocka's avatar
      udlfb: optimization - test the backing buffer · 8f3c39b8
      Mikulas Patocka authored
      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: default avatarMikulas Patocka <mpatocka@redhat.com>
      [b.zolnierkie: fix code indent]
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      8f3c39b8
    • Mikulas Patocka's avatar
      udlfb: allow reallocating the framebuffer · 7433914e
      Mikulas Patocka authored
      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: default avatarMikulas Patocka <mpatocka@redhat.com>
      [b.zolnierkie: sparse fixes]
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      7433914e
    • Mikulas Patocka's avatar
      udlfb: set line_length in dlfb_ops_set_par · 0ac319b7
      Mikulas Patocka authored
      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: default avatarMikulas Patocka <mpatocka@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      0ac319b7
    • Mikulas Patocka's avatar
      udlfb: handle allocation failure · 080fb524
      Mikulas Patocka authored
      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: default avatarMikulas Patocka <mpatocka@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      080fb524
    • Mikulas Patocka's avatar
      udlfb: set optimal write delay · bb24153a
      Mikulas Patocka authored
      The default delay 5 jiffies is too much when the kernel is compiled with
      HZ=100 - 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 HZ=1000, 10ms is acceptable,
      but with HZ=250 or HZ=300, we need 4ms, so that the video is played
      without any frame skips.
      
      This patch changes the delay to this value.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      bb24153a
    • Mikulas Patocka's avatar
      udlfb: make a local copy of fb_ops · 2c29cfc3
      Mikulas Patocka authored
      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: default avatarMikulas Patocka <mpatocka@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      2c29cfc3
    • Mikulas Patocka's avatar
      udlfb: don't switch if we are switching to the same videomode · 564f1807
      Mikulas Patocka authored
      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: default avatarMikulas Patocka <mpatocka@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      564f1807
    • Mikulas Patocka's avatar
      udlfb: fix display corruption of the last line · 4e705e17
      Mikulas Patocka authored
      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: default avatarMikulas Patocka <mpatocka@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      4e705e17
    • Mikulas Patocka's avatar
      udlfb: fix semaphore value leak · 9d0aa601
      Mikulas Patocka authored
      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" immediately, 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: default avatarMikulas Patocka <mpatocka@redhat.com>
      Cc: stable@vger.kernel.org
      [b.zolnierkie: fix immediatelly -> immediately typo]
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      9d0aa601
    • Mikulas Patocka's avatar
      fb: fix lost console when the user unplugs a USB adapter · 8c5b0442
      Mikulas Patocka authored
      I have a USB display adapter using the udlfb driver and I use it on an ARM
      board that doesn't have any graphics card. When I plug the adapter in, the
      console is properly displayed, however when I unplug and re-plug the
      adapter, the console is not displayed and I can't access it until I reboot
      the board.
      
      The reason is this:
      When the adapter is unplugged, dlfb_usb_disconnect calls
      unlink_framebuffer, then it waits until the reference count drops to zero
      and then it deallocates the framebuffer. However, the console that is
      attached to the framebuffer device keeps the reference count non-zero, so
      the framebuffer device is never destroyed. When the USB adapter is plugged
      again, it creates a new device /dev/fb1 and the console is not attached to
      it.
      
      This patch fixes the bug by unbinding the console from unlink_framebuffer.
      The code to unbind the console is moved from do_unregister_framebuffer to
      a function unbind_console. When the console is unbound, the reference
      count drops to zero and the udlfb driver frees the framebuffer. When the
      adapter is plugged back, a new framebuffer is created and the console is
      attached to it.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Bernie Thompson <bernie@plugable.com>
      Cc: Ladislav Michl <ladis@linux-mips.org>
      Cc: stable@vger.kernel.org
      [b.zolnierkie: preserve old behavior for do_unregister_framebuffer()]
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      8c5b0442
  3. 24 Jul, 2018 24 commits
  4. 03 Jul, 2018 3 commits