From: Robert Jarzmik <robert.jarzmik@free.fr>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [BUG, RFC] Different bitfields in documentation and driver
Date: Sat, 08 Aug 2015 16:56:34 +0000 [thread overview]
Message-ID: <87zj21k9bx.fsf@belgarion.home> (raw)
In-Reply-To: <55C503A7.6020304@tul.cz> (Petr Cvek's message of "Fri, 07 Aug 2015 21:14:47 +0200")
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
WARNING: multiple messages have this Message-ID (diff)
From: robert.jarzmik@free.fr (Robert Jarzmik)
To: linux-arm-kernel@lists.infradead.org
Subject: [BUG, RFC] Different bitfields in documentation and driver
Date: Sat, 08 Aug 2015 18:56:34 +0200 [thread overview]
Message-ID: <87zj21k9bx.fsf@belgarion.home> (raw)
In-Reply-To: <55C503A7.6020304@tul.cz> (Petr Cvek's message of "Fri, 07 Aug 2015 21:14:47 +0200")
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
next prev parent reply other threads:[~2015-08-08 16:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2015-08-08 16:56 ` Robert Jarzmik
2015-08-08 17:41 ` Petr Cvek
2015-08-08 17:41 ` Petr Cvek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zj21k9bx.fsf@belgarion.home \
--to=robert.jarzmik@free.fr \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.