<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/video, branch linux-3.17.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>framebuffer: fix border color</title>
<updated>2014-11-14T18:10:26+00:00</updated>
<author>
<name>Mikulas Patocka</name>
<email>mpatocka@redhat.com</email>
</author>
<published>2014-09-16T16:40:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4e3455d02c6d53647ae198e790235350ed54e2d9'/>
<id>4e3455d02c6d53647ae198e790235350ed54e2d9</id>
<content type='text'>
commit f74a289b9480648a654e5afd8458c2263c03a1e1 upstream.

The framebuffer code uses the current background color to fill the border
when switching consoles, however, this results in inconsistent behavior.
For example:
- start Midnigh Commander
- the border is black
- switch to another console and switch back
- the border is cyan
- type something into the command line in mc
- the border is cyan
- switch to another console and switch back
- the border is black
- press F9 to go to menu
- the border is black
- switch to another console and switch back
- the border is dark blue

When switching to a console with Midnight Commander, the border is random
color that was left selected by the slang subsystem.

This patch fixes this inconsistency by always using black as the
background color when switching consoles.

Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f74a289b9480648a654e5afd8458c2263c03a1e1 upstream.

The framebuffer code uses the current background color to fill the border
when switching consoles, however, this results in inconsistent behavior.
For example:
- start Midnigh Commander
- the border is black
- switch to another console and switch back
- the border is cyan
- type something into the command line in mc
- the border is cyan
- switch to another console and switch back
- the border is black
- press F9 to go to menu
- the border is black
- switch to another console and switch back
- the border is dark blue

When switching to a console with Midnight Commander, the border is random
color that was left selected by the slang subsystem.

This patch fixes this inconsistency by always using black as the
background color when switching consoles.

Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>framebuffer: fix screen corruption when copying</title>
<updated>2014-11-14T18:10:26+00:00</updated>
<author>
<name>Mikulas Patocka</name>
<email>mpatocka@redhat.com</email>
</author>
<published>2014-09-16T16:38:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4a3f70d3738224b36d7d67808391648223b6e0a7'/>
<id>4a3f70d3738224b36d7d67808391648223b6e0a7</id>
<content type='text'>
commit 5b789da8a7fc357661fc61faaf853e9161cc9700 upstream.

The function bitcpy_rev has a bug that may result in screen corruption.
The bug happens under these conditions:
* the end of the destination area of a copy operation is aligned on a long
  word boundary
* the end of the source area is not aligned on a long word boundary
* we are copying more than one long word

In this case, the variable shift is non-zero and the variable first is
zero. The statements FB_WRITEL(comp(d0, FB_READL(dst), first), dst) reads
the last long word of the destination and writes it back unchanged
(because first is zero). Correctly, we should write the variable d0 to the
last word of the destination in this case.

This patch fixes the bug by introducing and extra test if first is zero.

The patch also removes the references to fb_memmove in the code that is
commented out because fb_memmove was removed from framebuffer subsystem.

Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5b789da8a7fc357661fc61faaf853e9161cc9700 upstream.

The function bitcpy_rev has a bug that may result in screen corruption.
The bug happens under these conditions:
* the end of the destination area of a copy operation is aligned on a long
  word boundary
* the end of the source area is not aligned on a long word boundary
* we are copying more than one long word

In this case, the variable shift is non-zero and the variable first is
zero. The statements FB_WRITEL(comp(d0, FB_READL(dst), first), dst) reads
the last long word of the destination and writes it back unchanged
(because first is zero). Correctly, we should write the variable d0 to the
last word of the destination in this case.

This patch fixes the bug by introducing and extra test if first is zero.

The patch also removes the references to fb_memmove in the code that is
commented out because fb_memmove was removed from framebuffer subsystem.

Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>video: ARM CLCD: Fix color model capabilities for DT platforms</title>
<updated>2014-09-12T08:45:10+00:00</updated>
<author>
<name>Pawel Moll</name>
<email>pawel.moll@arm.com</email>
</author>
<published>2014-09-10T14:15:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e4cf39ea473329dfc07de1246f97d27b7fc96f79'/>
<id>e4cf39ea473329dfc07de1246f97d27b7fc96f79</id>
<content type='text'>
The DT-based panel capabilities selection was picking up
a subset of available modes based on hardware configuration.
This was wrong, as the capabilities describe available
memory models and adapt the display controller to them
that the RGB output is wired up correctly (as in: R and
B components are not swapped).

This patch fixes it by removing the unnecessary limitation.

Signed-off-by: Pawel Moll &lt;pawel.moll@arm.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The DT-based panel capabilities selection was picking up
a subset of available modes based on hardware configuration.
This was wrong, as the capabilities describe available
memory models and adapt the display controller to them
that the RGB output is wired up correctly (as in: R and
B components are not swapped).

This patch fixes it by removing the unnecessary limitation.

Signed-off-by: Pawel Moll &lt;pawel.moll@arm.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'fbdev-fixes-3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux</title>
<updated>2014-08-29T18:59:46+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-08-29T18:59:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=115619b34f2fd590d2830fd82f9bcb4ca7d9cdd2'/>
<id>115619b34f2fd590d2830fd82f9bcb4ca7d9cdd2</id>
<content type='text'>
Pull fbdev fixes from Tomi Valkeinen:
 "Minor fbdev fixes for da8xx-fb, atmel_lcdfb, arm clcd and chipsfb"

* tag 'fbdev-fixes-3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux:
  video: da8xx-fb: preserve display width when changing HSYNC
  video: of: display_timing: double free on error
  drivers: video: fbdev: atmel_lcdfb.c: fix error return code
  video: ARM CLCD: Fix calculation of bits-per-pixel
  fbdev: Remove __init from chips_hw_init() to fix build failure
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull fbdev fixes from Tomi Valkeinen:
 "Minor fbdev fixes for da8xx-fb, atmel_lcdfb, arm clcd and chipsfb"

* tag 'fbdev-fixes-3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux:
  video: da8xx-fb: preserve display width when changing HSYNC
  video: of: display_timing: double free on error
  drivers: video: fbdev: atmel_lcdfb.c: fix error return code
  video: ARM CLCD: Fix calculation of bits-per-pixel
  fbdev: Remove __init from chips_hw_init() to fix build failure
</pre>
</div>
</content>
</entry>
<entry>
<title>video: da8xx-fb: preserve display width when changing HSYNC</title>
<updated>2014-08-26T12:36:51+00:00</updated>
<author>
<name>Ian Abbott</name>
<email>abbotti@mev.co.uk</email>
</author>
<published>2014-07-03T13:46:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4d4e2c003bd6c6bdd85080bd096d54d5d251defa'/>
<id>4d4e2c003bd6c6bdd85080bd096d54d5d251defa</id>
<content type='text'>
When looking at this driver for a client, I noticed the code that
configures the HSYNC pulse clobbers the display width in the same
register.  It only preserves the MS part of the width in bit 3 and zeros
the LS part of the width in bits 9 to 4.  This doesn't matter during
initialization as the width is configured afterwards, but subsequent use
of the FBIPUT_HSYNC ioctl would clobber the width.

Preserve bits 9 to 0 of LCD_RASTER_TIMING_0_REG when configuring the
horizontal sync.

Signed-off-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When looking at this driver for a client, I noticed the code that
configures the HSYNC pulse clobbers the display width in the same
register.  It only preserves the MS part of the width in bit 3 and zeros
the LS part of the width in bits 9 to 4.  This doesn't matter during
initialization as the width is configured afterwards, but subsequent use
of the FBIPUT_HSYNC ioctl would clobber the width.

Preserve bits 9 to 0 of LCD_RASTER_TIMING_0_REG when configuring the
horizontal sync.

Signed-off-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>video: of: display_timing: double free on error</title>
<updated>2014-08-26T11:23:47+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2014-07-11T09:21:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=62795a0d81970bfdd5866ffd87160c670a6b344c'/>
<id>62795a0d81970bfdd5866ffd87160c670a6b344c</id>
<content type='text'>
The display_timings_release() function frees "disp" and we free it
again on the next line.

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The display_timings_release() function frees "disp" and we free it
again on the next line.

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drivers: video: fbdev: atmel_lcdfb.c: fix error return code</title>
<updated>2014-08-26T10:04:15+00:00</updated>
<author>
<name>Julia Lawall</name>
<email>Julia.Lawall@lip6.fr</email>
</author>
<published>2014-08-06T20:12:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6c131850eca653344c41d68ce87f3ab5a89af89e'/>
<id>6c131850eca653344c41d68ce87f3ab5a89af89e</id>
<content type='text'>
Convert a zero return value on error to a negative one, as returned
elsewhere in the function.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// &lt;smpl&gt;
(
if@p1 (\(ret &lt; 0\|ret != 0\))
 { ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
    when != &amp;ret
*if(...)
{
  ... when != ret = e2
      when forall
 return ret;
}

// &lt;/smpl&gt;

Signed-off-by: Julia Lawall &lt;Julia.Lawall@lip6.fr&gt;
Acked-by: Nicolas Ferre &lt;nicolas.ferre@atmel.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Convert a zero return value on error to a negative one, as returned
elsewhere in the function.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// &lt;smpl&gt;
(
if@p1 (\(ret &lt; 0\|ret != 0\))
 { ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
    when != &amp;ret
*if(...)
{
  ... when != ret = e2
      when forall
 return ret;
}

// &lt;/smpl&gt;

Signed-off-by: Julia Lawall &lt;Julia.Lawall@lip6.fr&gt;
Acked-by: Nicolas Ferre &lt;nicolas.ferre@atmel.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>video: ARM CLCD: Fix calculation of bits-per-pixel</title>
<updated>2014-08-26T09:50:27+00:00</updated>
<author>
<name>Jon Medhurst (Tixy)</name>
<email>tixy@linaro.org</email>
</author>
<published>2014-08-20T12:41:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2b6c53b1504865728a6dfad3e720918a2f89f3a5'/>
<id>2b6c53b1504865728a6dfad3e720918a2f89f3a5</id>
<content type='text'>
If the device-tree specifies a max-memory-bandwidth property then the
CLCD driver uses that to calculate the bits-per-pixel supported,
however, this calculation is faulty for two reasons.

1. It doesn't ensure that the result is a sane value, i.e. a power of 2
   and &lt;= 32 as the rest of the code assumes.

2. It uses the displayed resolution and calculates the average bandwidth
   across the whole frame. It should instead calculate the peak
   bandwidth based on the pixel clock.

This patch fixes both the above.

Signed-off-by: Jon Medhurst &lt;tixy@linaro.org&gt;
Acked-by: Pawel Moll &lt;pawel.moll@arm.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If the device-tree specifies a max-memory-bandwidth property then the
CLCD driver uses that to calculate the bits-per-pixel supported,
however, this calculation is faulty for two reasons.

1. It doesn't ensure that the result is a sane value, i.e. a power of 2
   and &lt;= 32 as the rest of the code assumes.

2. It uses the displayed resolution and calculates the average bandwidth
   across the whole frame. It should instead calculate the peak
   bandwidth based on the pixel clock.

This patch fixes both the above.

Signed-off-by: Jon Medhurst &lt;tixy@linaro.org&gt;
Acked-by: Pawel Moll &lt;pawel.moll@arm.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fbdev: Remove __init from chips_hw_init() to fix build failure</title>
<updated>2014-08-26T09:48:34+00:00</updated>
<author>
<name>Pranith Kumar</name>
<email>bobby.prani@gmail.com</email>
</author>
<published>2014-08-21T12:23:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=754d561ab694ff240ad1615abd0d99f3c1db79a2'/>
<id>754d561ab694ff240ad1615abd0d99f3c1db79a2</id>
<content type='text'>
Fix build failure caused as follows:

The function chipsfb_pci_init() references
the function __init chips_hw_init().
This is often because chipsfb_pci_init lacks a __init
annotation or the annotation of chips_hw_init is wrong.

make: *** [drivers] Error 2

by removing the __init annotation from chips_hw_init(). The other thing that
could have been done was annotating chipsfb_pci_init(). But that cannot be done
since chipsfb_pci_init() is called from non __init functions.

Signed-off-by: Pranith Kumar &lt;bobby.prani@gmail.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix build failure caused as follows:

The function chipsfb_pci_init() references
the function __init chips_hw_init().
This is often because chipsfb_pci_init lacks a __init
annotation or the annotation of chips_hw_init is wrong.

make: *** [drivers] Error 2

by removing the __init annotation from chips_hw_init(). The other thing that
could have been done was annotating chipsfb_pci_init(). But that cannot be done
since chipsfb_pci_init() is called from non __init functions.

Signed-off-by: Pranith Kumar &lt;bobby.prani@gmail.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>pwm-backlight: Fix bogus request for GPIO#0 when instantiated from DT</title>
<updated>2014-08-20T12:23:00+00:00</updated>
<author>
<name>Lothar Waßmann</name>
<email>LW@KARO-electronics.de</email>
</author>
<published>2014-08-20T06:38:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=937222c4dda495277a8dfbc18bf7e54fe670105c'/>
<id>937222c4dda495277a8dfbc18bf7e54fe670105c</id>
<content type='text'>
commit 257462dbf3ed ("pwm-backlight: switch to gpiod interface")
introduced a regression leading to acquiring a bogus GPIO-0 when
configured from DT without an 'enable-gpios' property.
The driver will happily accept the 0 initialized 'enable_gpio' member
of the struct platform_pwm_backlight_data as valid gpio number, and
request this GPIO as enable pin. In case of multiple driver instances,
the second will fail to register with the error message:
pwm-backlight backlight1.23: failed to request GPIO#0: -16

Fix this by setting enable_gpio in the pdata struct to -EINVAL.

Signed-off-by: Lothar Waßmann &lt;LW@KARO-electronics.de&gt;
Acked-by: Thierry Reding &lt;treding@nvidia.com&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 257462dbf3ed ("pwm-backlight: switch to gpiod interface")
introduced a regression leading to acquiring a bogus GPIO-0 when
configured from DT without an 'enable-gpios' property.
The driver will happily accept the 0 initialized 'enable_gpio' member
of the struct platform_pwm_backlight_data as valid gpio number, and
request this GPIO as enable pin. In case of multiple driver instances,
the second will fail to register with the error message:
pwm-backlight backlight1.23: failed to request GPIO#0: -16

Fix this by setting enable_gpio in the pdata struct to -EINVAL.

Signed-off-by: Lothar Waßmann &lt;LW@KARO-electronics.de&gt;
Acked-by: Thierry Reding &lt;treding@nvidia.com&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
