From: tomi.valkeinen@ti•com (Tomi Valkeinen)
To: linux-arm-kernel@lists•infradead.org
Subject: OMAP display subsystem - does it work?
Date: Wed, 18 Dec 2013 18:03:11 +0200 [thread overview]
Message-ID: <52B1C73F.40604@ti.com> (raw)
In-Reply-To: <20131218152927.GC32243@n2100.arm.linux.org.uk>
On 2013-12-18 17:29, Russell King - ARM Linux wrote:
> On Wed, Dec 18, 2013 at 03:54:42PM +0200, Tomi Valkeinen wrote:
>> On 2013-12-18 14:00, Russell King - ARM Linux wrote:
>>> For the SDP4430, it used to detect the displays, even though nothing has
>>> ever been displayed on them. Now it just spits out this:
>>
>> Those particular LCDs are supposed to be updated manually using custom ioctl,
>> so normal software using fb won't put anything on the display. For testing
>> purposes, a SW based automatic update (~20 fps) can be enabled by kernel
>> cmdline parameter "omapfb.auto_update" or via sysfs:
>>
>> echo 1 > /sys/class/graphics/fb0/update_mode
>
> I'm confused. How then can the original kernel which came with the board
> run two gstreamer videos on these displays by just talking to the
> framebuffers and play it back smoothly given that we're talking about
> video at normal fps settings?
>
> When I received the board, that's exactly what it did at boot up - it
> played back two different video trailers, one on each LCD, and the
> playback was smooth, just like you'd expect from watching a DVD on your
> TV. No missing frames, which is what you'd get if you tried to update
> at 20fps.
We once had auto-update support in omapdss in the early versions. It was
removed quite a while ago, as it was a burden to maintain. Either the
kernel you talk about had the auto-update support, or the userspace has
support for manual-update displays.
The thing is, these LCDs are not meant to be used in auto-update mode.
The main point with LCDs with their own framebuffer is that they are
only updated when needed. So a production device would not need
auto-update support. Furthermore, as these LCDs are quite rare, and
4430SDP is the only one we support having these displays, and that board
itself is not exactly a common one, it was decided that the maintenance
burden is not worth it.
I have been thinking of improving the auto-update in omapfb, but it has
never been on the top of my list (or even middle). The current code
basically does just queue_delayed_work() 20 times per second, so it's
just a hack for testing.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131218/e518498b/attachment.sig>
next prev parent reply other threads:[~2013-12-18 16:03 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-18 12:00 OMAP display subsystem - does it work? Russell King - ARM Linux
2013-12-18 13:54 ` Tomi Valkeinen
2013-12-18 15:29 ` Russell King - ARM Linux
2013-12-18 16:03 ` Tomi Valkeinen [this message]
2013-12-18 18:23 ` Tony Lindgren
2013-12-19 5:23 ` Tomi Valkeinen
2013-12-19 16:56 ` Tony Lindgren
2013-12-20 7:45 ` Tomi Valkeinen
2013-12-19 17:56 ` Russell King - ARM Linux
2013-12-19 18:22 ` Tony Lindgren
2013-12-20 11:27 ` Russell King - ARM Linux
2013-12-20 11:48 ` Russell King - ARM Linux
2013-12-20 13:43 ` Tomi Valkeinen
2013-12-20 16:04 ` Tony Lindgren
2013-12-20 16:55 ` Tony Lindgren
2013-12-21 0:59 ` Russell King - ARM Linux
2013-12-28 23:30 ` Russell King - ARM Linux
2013-12-23 7:53 ` Tomi Valkeinen
2013-12-27 18:11 ` Tony Lindgren
2013-12-23 7:49 ` Tomi Valkeinen
2013-12-20 16:10 ` Tony Lindgren
2013-12-19 17:53 ` Russell King - ARM Linux
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=52B1C73F.40604@ti.com \
--to=tomi.valkeinen@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox