01 Apr, 2019
2 commits
-
Rendering calls may be done simultaneously from the workqueue,
dlfb_ops_write, dlfb_ops_ioctl, dlfb_ops_set_par and dlfb_dpy_deferred_io.
The code is robust enough so that it won't crash on concurrent rendering.However, concurrent rendering may cause display corruption if the same
pixel is simultaneously being rendered. In order to avoid this corruption,
this patch adds a mutex around the rendering calls.Signed-off-by: Mikulas Patocka
Cc: Bernie Thompson
Cc: Ladislav Michl
Cc:
[b.zolnierkie: replace "dlfb:" with "uldfb:" in the patch summary]
Signed-off-by: Bartlomiej Zolnierkiewicz -
If a framebuffer device is used as a console, the rendering calls
(copyarea, fillrect, imageblit) may be done with the console spinlock
held. On udlfb, these function call dlfb_handle_damage that takes a
blocking semaphore before acquiring an URB.In order to fix the bug, this patch changes the calls copyarea, fillrect
and imageblit to offload USB work to a workqueue.A side effect of this patch is 3x improvement in console scrolling speed
because the device doesn't have to be updated after each copyarea call.Signed-off-by: Mikulas Patocka
Cc: Bernie Thompson
Cc: Ladislav Michl
Cc:
Signed-off-by: Bartlomiej Zolnierkiewicz
08 Oct, 2018
1 commit
-
The udlfb driver maintained an open count and cleaned up itself when the
count reached zero. But the console is also counted in the reference count
- so, if the user unplugged the device, the open count would not drop to
zero and the driver stayed loaded with console attached. If the user
re-plugged the adapter, it would create a device /dev/fb1, show green
screen and the access to the console would be lost.The framebuffer subsystem has reference counting on its own - in order to
fix the unplug bug, we rely the framebuffer reference counting. When the
user unplugs the adapter, we call unregister_framebuffer unconditionally.
unregister_framebuffer will unbind the console, wait until all users stop
using the framebuffer and then call the fb_destroy method. The fb_destroy
cleans up the USB driver.This patch makes the following changes:
* Drop dlfb->kref and rely on implicit framebuffer reference counting
instead.
* dlfb_usb_disconnect calls unregister_framebuffer, the rest of driver
cleanup is done in the function dlfb_ops_destroy. dlfb_ops_destroy will
be called by the framebuffer subsystem when no processes have the
framebuffer open or mapped.
* We don't use workqueue during initialization, but initialize directly
from dlfb_usb_probe. The workqueue could race with dlfb_usb_disconnect
and this racing would produce various kinds of memory corruption.
* We use usb_get_dev and usb_put_dev to make sure that the USB subsystem
doesn't free the device under us.Signed-off-by: Mikulas Patocka
cc: Dave Airlie
Cc: Bernie Thompson ,
Cc: Ladislav Michl
Signed-off-by: Bartlomiej Zolnierkiewicz
25 Jul, 2018
5 commits
-
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
[b.zolnierkie: sparse fixes]
Signed-off-by: Bartlomiej Zolnierkiewicz -
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: Mikulas Patocka
Cc: stable@vger.kernel.org
Signed-off-by: Bartlomiej Zolnierkiewicz -
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
Cc: stable@vger.kernel.org
Signed-off-by: Bartlomiej Zolnierkiewicz -
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
Cc: stable@vger.kernel.org
Signed-off-by: Bartlomiej Zolnierkiewicz -
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 2So, 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
Cc: stable@vger.kernel.org
[b.zolnierkie: fix immediatelly -> immediately typo]
Signed-off-by: Bartlomiej Zolnierkiewicz
16 Jan, 2018
2 commits
-
Variable 'dev' is usually used for 'struct device'. Therefore
rename driver private data to dlfb to avoid confusion once
driver will be using dev_*() logging functions.Signed-off-by: Ladislav Michl
Cc: Bernie Thompson
Signed-off-by: Bartlomiej Zolnierkiewicz -
gdev is not really needed as the same content can be read
from udev->dev.Signed-off-by: Ladislav Michl
Cc: Bernie Thompson
Signed-off-by: Bartlomiej Zolnierkiewicz
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
21 Apr, 2017
1 commit
-
Few parts of kernel define their own macro for aligning down so provide
a common define for this, with the same usage and assumptions as existing
ALIGN.Convert also three existing implementations to this one.
Signed-off-by: Krzysztof Kozlowski
Signed-off-by: Herbert Xu
02 Mar, 2012
1 commit
-
Fix race conditions with unplug/replug behavior, in particular
take care not to hold up USB probe/disconnect for long-running
framebuffer operations and rely on usb to handle teardown.Fix for kernel panic reported with new F17 multiseat support.
Reported-by: Kay Sievers
Signed-off-by: Bernie Thompson
24 Aug, 2011
1 commit
-
Fixes earlier problems where monitor would not return from blank
Test with any DisplayLink-based USB 2.0 graphics adapter
sudo nano /sys/class/graphics/fb?/blank
and write out single digit FB_BLANK_* code from include/linux/fb.hSupports on (0), blank (1), suspend (2,3), powerdown (4)
Signed-off-by: Bernie Thompson
Signed-off-by: Florian Tobias Schandinat
06 Jan, 2011
2 commits
-
This kills off all of the dl_xxx() printk wrappers and simply stubs in a
pr_fmt() definition to accomplish the same thing.Signed-off-by: Paul Mundt
-
The edid length is fixed, so use the standard definition consistently.
Signed-off-by: Paul Mundt
16 Nov, 2010
1 commit
-
udlfb has undergone a fair bit of cleanup recently and is effectively at
the point where it can be liberated from staging purgatory and promoted
to a real driver.The outstanding cleanups are all minor, with some of them dependent on
drivers/video headers, so these will be done incrementally from udlfb's
new home.Requested-by: Bernie Thompson
Signed-off-by: Paul Mundt