Message-ID: <20120807165350.GG18957@n2100.arm.linux.org.uk>
Date:	Tue, 7 Aug 2012 17:53:50 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
Cc:	Arnd Bergmann <arnd@...db.de>, Jason Cooper <jason@...edaemon.net>,
	Andrew Lunn <andrew@...n.ch>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Rabeeh Khoury <rabeeh@...id-run.com>,
	Ian Molton <ian.molton@...ethink.co.uk>,
	Maen Suleiman <maen@...vell.com>,
	Olof Johansson <olof@...om.net>,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
Subject: Re: [PATCH 0/6] ARM: dove: DT support for Marvell Dove

On Mon, Aug 06, 2012 at 04:16:57PM +0200, Sebastian Hesselbarth wrote:
> After that I am definitely fine with removing non-DT support although
> there is neither DT support in u-boot installed on my CuBox nor
> mach-dove support in mainline u-boot.

As I have a Cubox, this is of interest to me.  However, not related to
your patches, here's some news I have on the Cubox.

Firstly, a big thanks to Nicolas Pitre for sending me this cute little
box.  Finally, I see my idea of having an ARM based Linux box as a
media player becoming a reality (I thought maybe the OMAP3430LDP would
do it, or maybe the OMAP4430SDP, but progress on OMAP platforms is
dreadfully slow - and complicated...)

I've recently pushed a fix into mainline (and stable) for VFP support
with Thumb instructions.  I noticed that the Cubox kernel had a different
fix, this "different" fix will need to be removed when Cubox folk update
to the next kernel from mainline.

Video support, not great.  The supplied Ubuntu Lucid stuff install
(including the latest dev kernel from the solid-run folk) doesn't work
with any of the tree HDMI devices I've tried it with:

. A Plasma TV refused to recognise the cubox existing.  Works with a PC
  running Linux.
. A LCD PC monitor with HDMI input.  If the monitor is disconnected, the
  Cubox booted, and the monitor connected, you get a picture, but you
  lose the top, left, bottom and right of the display off the side of the
  monitor.  No amount of adjusting on the monitor fixes this.
. A cheap LCD TV with HDMI input, 1080i (but not properly 1080p capable)
  only works when the Cubox is booted with the TV turned on and HDMI
  input selected.  If the Cubox is booted with the TV off or HDMI input
  deselected, it fails.  Even so, like the LCD PC monitor, the image is
  far too big.  I suspect there's something wrong with the HDMI chip
  setup.

What is obvious is that there is no HDMI hotplug support and reconfiguring
of the display.  So, I've been investigating the Linux DRM/DRI support -
both the kernel and X11 side, and I have something that is getting close
to being ready.  Last night I finally disabled the kernel dovefb driver,
and have X11 using solely my new DRM driver.

This gives us several advantages, not only does the DRM layer generate
hotplug events, but it also doesn't need such a large amount of "video
memory" reserved.  It can dynamically allocate objects for graphics
operations, and such like.  This, along side CMA should allow us to get
rid of quite a bit of the statically claimed RAM areas.  Another
advantage is that we can automatically reconfigure the X11 display on
hotplug to the capabilities of the attached monitor.  This works nicely
here. :)

	This brings up another off-topic point (not just about the
	cubox) - I think more people should be looking at the DRM
	stuff when they're creating video drivers.

The next thing to talk about is video overlay via the X11 Xvideo extension.
Yuck, this is not nice.  It relies upon using the X11 Xvideo SHM support,
using the shared memory as a two way buffer.  This buffer which is supposed
to contain graphic data passed from the app to X is instead used to pass
control and address pointers between the decoding application and the
kernel dovefb driver (!) and back again to the decoding application.  Note
that it doesn't even declare a different format for this kind of thing,
it merely relies on magic numbers and a checksum.

The side effect of that is applications using the Xvideo extension
properly do not work very well, partly because the formats they want to
use aren't presented by the dovefb X11 driver.

Now, when trying vlc on the cubox, it failed totally (the Qt libraries
from Ubuntu Lucid are built with neon support, and the Armada510 has
no Neon support - it is VFPv3 with only 16 double registers.)
Rebuilding libQtGui without Neon support fixes this (the cubox is currently
rebuilding the Qt package at the moment, which is going to take a while).
Next problem is there's something up with mpeg audio decoding, but ogg
decoding in vlc is fine.

With Qt fixed, DRM, and a better X11 driver, I now have vlc able to
reasonably display full screen video on the Cubox - and like on my PC,
it appears to play back at a destination resolution of 624x576 (so SD)
and then scales to the size you want the video to be.  Same for totem
with the same source material.

However, this won't be using the on-chip mpeg decoding (yet).  CPU
usage sits at around 30% while vlc playback is running.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists