<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/include/video, branch v5.0.19</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.0.19</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.0.19'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2019-05-25T16:22:09Z</updated>
<entry>
<title>udlfb: introduce a rendering mutex</title>
<updated>2019-05-25T16:22:09Z</updated>
<author>
<name>Mikulas Patocka</name>
<email>mpatocka@redhat.com</email>
</author>
<published>2019-04-01T15:46:57Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=12db517f8a3e261255601ddf18fe6f0d0097c749'/>
<id>urn:sha1:12db517f8a3e261255601ddf18fe6f0d0097c749</id>
<content type='text'>
commit babc250e278eac7b0e671bdaedf833759b43bb78 upstream.

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 &lt;mpatocka@redhat.com&gt;
Cc: Bernie Thompson &lt;bernie@plugable.com&gt;
Cc: Ladislav Michl &lt;ladis@linux-mips.org&gt;
Cc: &lt;stable@vger.kernel.org&gt;
[b.zolnierkie: replace "dlfb:" with "uldfb:" in the patch summary]
Signed-off-by: Bartlomiej Zolnierkiewicz &lt;b.zolnierkie@samsung.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>udlfb: fix sleeping inside spinlock</title>
<updated>2019-05-25T16:22:09Z</updated>
<author>
<name>Mikulas Patocka</name>
<email>mpatocka@redhat.com</email>
</author>
<published>2019-04-01T15:46:56Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0bd143ed410943f00ea3eddecc209d7d2b308a54'/>
<id>urn:sha1:0bd143ed410943f00ea3eddecc209d7d2b308a54</id>
<content type='text'>
commit 6b11f9d8433b471fdd3ebed232b43a4b723be6ff upstream.

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 &lt;mpatocka@redhat.com&gt;
Cc: Bernie Thompson &lt;bernie@plugable.com&gt;
Cc: Ladislav Michl &lt;ladis@linux-mips.org&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Bartlomiej Zolnierkiewicz &lt;b.zolnierkie@samsung.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/exynos: fimd: Make pixel blend mode configurable</title>
<updated>2018-12-14T06:46:15Z</updated>
<author>
<name>Christoph Manszewski</name>
<email>c.manszewski@samsung.com</email>
</author>
<published>2018-10-25T15:23:50Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3b5129b3a7c62fdec9cc69b1b3f20917c36ab5d4'/>
<id>urn:sha1:3b5129b3a7c62fdec9cc69b1b3f20917c36ab5d4</id>
<content type='text'>
The fimd hardware supports different blend modes. Add pixel blend mode
property and make it configurable, by modifying the blend equation.

Tested on TRATS2 with Exynos 4412 CPU, on top of linux-next-20181019.

Signed-off-by: Christoph Manszewski &lt;c.manszewski@samsung.com&gt;
Signed-off-by: Inki Dae &lt;inki.dae@samsung.com&gt;
</content>
</entry>
<entry>
<title>drm/exynos: fimd: Make plane alpha configurable</title>
<updated>2018-12-14T06:46:15Z</updated>
<author>
<name>Christoph Manszewski</name>
<email>c.manszewski@samsung.com</email>
</author>
<published>2018-10-25T15:23:49Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=6f8ee5c21722f93d486b2ff041c28580c9511349'/>
<id>urn:sha1:6f8ee5c21722f93d486b2ff041c28580c9511349</id>
<content type='text'>
The fimd hardware supports variable plane alpha. Currently planes
are opaque, make this configurable.

Tested on TRATS2 with Exynos 4412 CPU, on top of linux-next-20181019.

Signed-off-by: Christoph Manszewski &lt;c.manszewski@samsung.com&gt;
Signed-off-by: Inki Dae &lt;inki.dae@samsung.com&gt;
</content>
</entry>
<entry>
<title>gpu: ipu-v3: ipu-ic: allow to manually set resize coefficients</title>
<updated>2018-11-05T13:40:06Z</updated>
<author>
<name>Philipp Zabel</name>
<email>p.zabel@pengutronix.de</email>
</author>
<published>2018-09-18T09:34:08Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d0cbc93a0110a82ff9e01d3c21d5a2e2027b706f'/>
<id>urn:sha1:d0cbc93a0110a82ff9e01d3c21d5a2e2027b706f</id>
<content type='text'>
For tiled scaling, we want to compute the scaling coefficients
externally in such a way that the interpolation overshoots tile
boundaries and samples up to the first pixel of the next tile.
Prepare to override the resizing coefficients from the image
conversion code.

Signed-off-by: Philipp Zabel &lt;p.zabel@pengutronix.de&gt;
Acked-by: Steve Longerbeam &lt;slongerbeam@gmail.com&gt;
Tested-by: Steve Longerbeam &lt;slongerbeam@gmail.com&gt;
</content>
</entry>
<entry>
<title>gpu: ipu-v3: Add chroma plane offset overrides to ipu_cpmem_set_image()</title>
<updated>2018-11-05T13:40:06Z</updated>
<author>
<name>Steve Longerbeam</name>
<email>slongerbeam@gmail.com</email>
</author>
<published>2018-10-06T21:45:48Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=dec408fd23ae81338a55556cd570dacd6bf41046'/>
<id>urn:sha1:dec408fd23ae81338a55556cd570dacd6bf41046</id>
<content type='text'>
Allow the caller of ipu_cpmem_set_image() to override the latters
calculation of the chroma plane offsets, by adding override U/V
plane offsets to 'struct ipu_image'.

Signed-off-by: Steve Longerbeam &lt;slongerbeam@gmail.com&gt;
Tested-by: Philipp Zabel &lt;p.zabel@pengutronix.de&gt;
Signed-off-by: Philipp Zabel &lt;p.zabel@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>udlfb: handle unplug properly</title>
<updated>2018-10-08T10:57:34Z</updated>
<author>
<name>Mikulas Patocka</name>
<email>mpatocka@redhat.com</email>
</author>
<published>2018-10-08T10:57:34Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=68a958a915ca912b8ce71b9eea7445996f6e681e'/>
<id>urn:sha1:68a958a915ca912b8ce71b9eea7445996f6e681e</id>
<content type='text'>
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-&gt;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 &lt;mpatocka@redhat.com&gt;
cc: Dave Airlie &lt;airlied@redhat.com&gt;
Cc: Bernie Thompson &lt;bernie@plugable.com&gt;,
Cc: Ladislav Michl &lt;ladis@linux-mips.org&gt;
Signed-off-by: Bartlomiej Zolnierkiewicz &lt;b.zolnierkie@samsung.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'fbdev-v4.19' of https://github.com/bzolnier/linux</title>
<updated>2018-08-23T22:44:58Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2018-08-23T22:44:58Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=06e386a1db54ab6a671e103e929b590f7a88f0e3'/>
<id>urn:sha1:06e386a1db54ab6a671e103e929b590f7a88f0e3</id>
<content type='text'>
Pull fbdev updates from Bartlomiej Zolnierkiewicz:
 "Mostly small fixes and cleanups for fb drivers (the biggest updates
  are for udlfb and pxafb drivers). This also adds deferred console
  takeover support to the console code and efifb driver.

  Summary:

   - add support for deferred console takeover, when enabled defers
     fbcon taking over the console from the dummy console until the
     first text is displayed on the console - together with the "quiet"
     kernel commandline option this allows fbcon to still be used
     together with a smooth graphical bootup (Hans de Goede)

   - improve console locking debugging code (Thomas Zimmermann)

   - copy the ACPI BGRT boot graphics to the framebuffer when deferred
     console takeover support is used in efifb driver (Hans de Goede)

   - update udlfb driver - fix lost console when the user unplugs a USB
     adapter, fix the screen corruption issue, fix locking and add some
     performance optimizations (Mikulas Patocka)

   - update pxafb driver - fix using uninitialized memory, switch to
     devm_* API, handle initialization errors and add support for
     lcd-supply regulator (Daniel Mack)

   - add support for boards booted with a DeviceTree in pxa3xx_gcu
     driver (Daniel Mack)

   - rename omap2 module to omap2fb.ko to avoid conflicts with omap1
     driver (Arnd Bergmann)

   - enable ACPI-based enumeration for goldfishfb driver (Yu Ning)

   - fix goldfishfb driver to make user space Android code use 60 fps
     (Christoffer Dall)

   - print big fat warning when nomodeset kernel parameter is used in
     vgacon driver (Lyude Paul)

   - remove VLA usage from fsl-diu-fb driver (Kees Cook)

   - misc fixes (Julia Lawall, Geert Uytterhoeven, Fredrik Noring,
     Yisheng Xie, Dan Carpenter, Daniel Vetter, Anton Vasilyev, Randy
     Dunlap, Gustavo A. R. Silva, Colin Ian King, Fengguang Wu)

   - misc cleanups (Roman Kiryanov, Yisheng Xie, Colin Ian King)"

* tag 'fbdev-v4.19' of https://github.com/bzolnier/linux: (54 commits)
  Documentation/fb: corrections for fbcon.txt
  fbcon: Do not takeover the console from atomic context
  dummycon: Stop exporting dummycon_[un]register_output_notifier
  fbcon: Only defer console takeover if the current console driver is the dummycon
  fbcon: Only allow FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER if fbdev is builtin
  fbdev: omap2: omapfb: fix ifnullfree.cocci warnings
  fbdev: omap2: omapfb: fix bugon.cocci warnings
  fbdev: omap2: omapfb: fix boolreturn.cocci warnings
  fb: amifb: fix build warnings when not builtin
  fbdev/core: Disable console-lock warnings when fb.lockless_register_fb is set
  console: Replace #if 0 with atomic var 'ignore_console_lock_warning'
  udlfb: use spin_lock_irq instead of spin_lock_irqsave
  udlfb: avoid prefetch
  udlfb: optimization - test the backing buffer
  udlfb: allow reallocating the framebuffer
  udlfb: set line_length in dlfb_ops_set_par
  udlfb: handle allocation failure
  udlfb: set optimal write delay
  udlfb: make a local copy of fb_ops
  udlfb: don't switch if we are switching to the same videomode
  ...
</content>
</entry>
<entry>
<title>udlfb: allow reallocating the framebuffer</title>
<updated>2018-07-25T13:41:56Z</updated>
<author>
<name>Mikulas Patocka</name>
<email>mpatocka@redhat.com</email>
</author>
<published>2018-07-25T13:41:56Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=7433914efd584b22bb49d3e1eee001f5d0525ecd'/>
<id>urn:sha1:7433914efd584b22bb49d3e1eee001f5d0525ecd</id>
<content type='text'>
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-&gt;deferred_free and free it when the driver is unloaded.

Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
[b.zolnierkie: sparse fixes]
Signed-off-by: Bartlomiej Zolnierkiewicz &lt;b.zolnierkie@samsung.com&gt;
</content>
</entry>
<entry>
<title>udlfb: set optimal write delay</title>
<updated>2018-07-25T13:41:55Z</updated>
<author>
<name>Mikulas Patocka</name>
<email>mpatocka@redhat.com</email>
</author>
<published>2018-07-25T13:41:55Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=bb24153a3f13dd0dbc1f8055ad97fe346d598f66'/>
<id>urn:sha1:bb24153a3f13dd0dbc1f8055ad97fe346d598f66</id>
<content type='text'>
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 &lt;mpatocka@redhat.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Bartlomiej Zolnierkiewicz &lt;b.zolnierkie@samsung.com&gt;
</content>
</entry>
</feed>
