* [BUG, RFC] Different bitfields in documentation and driver
@ 2015-08-07 19:14 ` Petr Cvek
0 siblings, 0 replies; 6+ messages in thread
From: Petr Cvek @ 2015-08-07 19:14 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
It seems that PXA2xx framebuffer has switched bitfields in nonstd definition (when using overlay).
This:
http://lxr.free-electrons.com/source/drivers/video/fbdev/pxafb.h#L80
versus this:
http://lxr.free-electrons.com/source/Documentation/fb/pxafb.txt#L128
Should be this changed in documentation or in driver? I was able to find only one use (in form of little outdated mplayer patch) and it fills both bitfields with zero (so potential change in driver will not break it).
P.S. Lack of overlay2's use is probably caused by errata "E24: LCD: Enabling Overlay 2 for YUV420 hangs LCD controller.", which is not workarounded in this driver. It should be mentioned in documentation and/or code, because the only way to start the LCD again is a full PXA SoC reset.
Petr Cvek
^ permalink raw reply [flat|nested] 6+ messages in thread
* [BUG, RFC] Different bitfields in documentation and driver
@ 2015-08-07 19:14 ` Petr Cvek
0 siblings, 0 replies; 6+ messages in thread
From: Petr Cvek @ 2015-08-07 19:14 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
It seems that PXA2xx framebuffer has switched bitfields in nonstd definition (when using overlay).
This:
http://lxr.free-electrons.com/source/drivers/video/fbdev/pxafb.h#L80
versus this:
http://lxr.free-electrons.com/source/Documentation/fb/pxafb.txt#L128
Should be this changed in documentation or in driver? I was able to find only one use (in form of little outdated mplayer patch) and it fills both bitfields with zero (so potential change in driver will not break it).
P.S. Lack of overlay2's use is probably caused by errata "E24: LCD: Enabling Overlay 2 for YUV420 hangs LCD controller.", which is not workarounded in this driver. It should be mentioned in documentation and/or code, because the only way to start the LCD again is a full PXA SoC reset.
Petr Cvek
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG, RFC] Different bitfields in documentation and driver
2015-08-07 19:14 ` Petr Cvek
@ 2015-08-08 16:56 ` Robert Jarzmik
-1 siblings, 0 replies; 6+ messages in thread
From: Robert Jarzmik @ 2015-08-08 16:56 UTC (permalink / raw)
To: linux-arm-kernel
Petr Cvek <petr.cvek@tul.cz> writes:
> Hello,
> It seems that PXA2xx framebuffer has switched bitfields in nonstd definition (when using overlay).
>
> This:
>
> http://lxr.free-electrons.com/source/drivers/video/fbdev/pxafb.h#L80
>
> versus this:
>
> http://lxr.free-electrons.com/source/Documentation/fb/pxafb.txt#L128
>
> Should be this changed in documentation or in driver? I was able to find only
> one use (in form of little outdated mplayer patch) and it fills both bitfields
> with zero (so potential change in driver will not break it).
I'd rather go for documentation. Not only the driver's way looks more pretty to
me, but it also guarantees compatibility from the kernel side.
> P.S. Lack of overlay2's use is probably caused by errata "E24: LCD: Enabling
> Overlay 2 for YUV420 hangs LCD controller.", which is not workarounded in this
> driver. It should be mentioned in documentation and/or code, because the only
> way to start the LCD again is a full PXA SoC reset.
Ok, do you know if this this true for all pxa variants and steppings or is this
for only a subset of them ?
Cheers.
--
Robert
^ permalink raw reply [flat|nested] 6+ messages in thread
* [BUG, RFC] Different bitfields in documentation and driver
@ 2015-08-08 16:56 ` Robert Jarzmik
0 siblings, 0 replies; 6+ messages in thread
From: Robert Jarzmik @ 2015-08-08 16:56 UTC (permalink / raw)
To: linux-arm-kernel
Petr Cvek <petr.cvek@tul.cz> writes:
> Hello,
> It seems that PXA2xx framebuffer has switched bitfields in nonstd definition (when using overlay).
>
> This:
>
> http://lxr.free-electrons.com/source/drivers/video/fbdev/pxafb.h#L80
>
> versus this:
>
> http://lxr.free-electrons.com/source/Documentation/fb/pxafb.txt#L128
>
> Should be this changed in documentation or in driver? I was able to find only
> one use (in form of little outdated mplayer patch) and it fills both bitfields
> with zero (so potential change in driver will not break it).
I'd rather go for documentation. Not only the driver's way looks more pretty to
me, but it also guarantees compatibility from the kernel side.
> P.S. Lack of overlay2's use is probably caused by errata "E24: LCD: Enabling
> Overlay 2 for YUV420 hangs LCD controller.", which is not workarounded in this
> driver. It should be mentioned in documentation and/or code, because the only
> way to start the LCD again is a full PXA SoC reset.
Ok, do you know if this this true for all pxa variants and steppings or is this
for only a subset of them ?
Cheers.
--
Robert
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG, RFC] Different bitfields in documentation and driver
2015-08-08 16:56 ` Robert Jarzmik
@ 2015-08-08 17:41 ` Petr Cvek
-1 siblings, 0 replies; 6+ messages in thread
From: Petr Cvek @ 2015-08-08 17:41 UTC (permalink / raw)
To: linux-arm-kernel
On 8.8.2015 18:56, Robert Jarzmik wrote:
> Petr Cvek <petr.cvek@tul.cz> writes:
>
>> Hello,
>> It seems that PXA2xx framebuffer has switched bitfields in nonstd definition (when using overlay).
>>
>> This:
>>
>> http://lxr.free-electrons.com/source/drivers/video/fbdev/pxafb.h#L80
>>
>> versus this:
>>
>> http://lxr.free-electrons.com/source/Documentation/fb/pxafb.txt#L128
>>
>> Should be this changed in documentation or in driver? I was able to find only
>> one use (in form of little outdated mplayer patch) and it fills both bitfields
>> with zero (so potential change in driver will not break it).
> I'd rather go for documentation. Not only the driver's way looks more pretty to
> me, but it also guarantees compatibility from the kernel side.
Oh you are right, I forgot to look into SoC datasheet and related register has YX version
(driver side). Will send patch with errata warning.
>
>> P.S. Lack of overlay2's use is probably caused by errata "E24: LCD: Enabling
>> Overlay 2 for YUV420 hangs LCD controller.", which is not workarounded in this
>> driver. It should be mentioned in documentation and/or code, because the only
>> way to start the LCD again is a full PXA SoC reset.
> Ok, do you know if this this true for all pxa variants and steppings or is this
> for only a subset of them ?
According to this:
http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_spec_update.pdf
errata (page 11, errata 24), bug is only for C0 revision (newer are OK, but I would guess most of devices
will have C0). There is some workaround pseudocode, but it seems it does not work with me (only
few tries to implement it, but penalty is reboot ... workaround description is a little bit confusing)
P.S. LCD controller has other errors too (notably E15 (not fixed) and E16).
Petr
>
> Cheers.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [BUG, RFC] Different bitfields in documentation and driver
@ 2015-08-08 17:41 ` Petr Cvek
0 siblings, 0 replies; 6+ messages in thread
From: Petr Cvek @ 2015-08-08 17:41 UTC (permalink / raw)
To: linux-arm-kernel
On 8.8.2015 18:56, Robert Jarzmik wrote:
> Petr Cvek <petr.cvek@tul.cz> writes:
>
>> Hello,
>> It seems that PXA2xx framebuffer has switched bitfields in nonstd definition (when using overlay).
>>
>> This:
>>
>> http://lxr.free-electrons.com/source/drivers/video/fbdev/pxafb.h#L80
>>
>> versus this:
>>
>> http://lxr.free-electrons.com/source/Documentation/fb/pxafb.txt#L128
>>
>> Should be this changed in documentation or in driver? I was able to find only
>> one use (in form of little outdated mplayer patch) and it fills both bitfields
>> with zero (so potential change in driver will not break it).
> I'd rather go for documentation. Not only the driver's way looks more pretty to
> me, but it also guarantees compatibility from the kernel side.
Oh you are right, I forgot to look into SoC datasheet and related register has YX version
(driver side). Will send patch with errata warning.
>
>> P.S. Lack of overlay2's use is probably caused by errata "E24: LCD: Enabling
>> Overlay 2 for YUV420 hangs LCD controller.", which is not workarounded in this
>> driver. It should be mentioned in documentation and/or code, because the only
>> way to start the LCD again is a full PXA SoC reset.
> Ok, do you know if this this true for all pxa variants and steppings or is this
> for only a subset of them ?
According to this:
http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_spec_update.pdf
errata (page 11, errata 24), bug is only for C0 revision (newer are OK, but I would guess most of devices
will have C0). There is some workaround pseudocode, but it seems it does not work with me (only
few tries to implement it, but penalty is reboot ... workaround description is a little bit confusing)
P.S. LCD controller has other errors too (notably E15 (not fixed) and E16).
Petr
>
> Cheers.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-08-08 17:41 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-07 19:14 [BUG, RFC] Different bitfields in documentation and driver Petr Cvek
2015-08-07 19:14 ` Petr Cvek
2015-08-08 16:56 ` Robert Jarzmik
2015-08-08 16:56 ` Robert Jarzmik
2015-08-08 17:41 ` Petr Cvek
2015-08-08 17:41 ` Petr Cvek
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.