[PATCH] i.MX23/28 framebuffer driver

On Wednesday 09 February 2011, Sascha Hauer wrote:

The driver patch itself is Cced to linux-fbdev, only the introductory
mail is not.

Ok, I see.

quoted

Did you consider making the driver a KMS driver instead of
a frame buffer? I think the recommendation these days is
to start out with KMS for new drivers, which will be somewhat
simpler and give you a frame buffer device as well. I don't
think that there is a need to change over any drivers from
fb to kms though, since you've already done the work.

I tried doing so for the i.MX51 which supports multiple displays on dvi
and vga outputs and thus could make good use of KMS and friends. Anyway,
I got stuck quite fast. The KMS stuff is tightly coupled with DRM/DRI
and needs many many callbacks to implement. Additionally the userspace
tools expect a nvidia/amd/intel driver and do not have a generic
fallback. I think this stuff is good for implementing a full blown
graphics driver, but is lacking support for simple framebuffer grapics.
I'd love to go this way but it still requires a lot of work.

Ok. This sounds like a lot of upfront work indeed, to make KMS more
generic, though I think a number of driver would benefit from it
eventually. It could be something for the Linaro graphics working
group to look at in the following 11.11 release, depending on how
many other people are interested in getting there.

	Arnd

On Wed, Feb 09, 2011 at 05:31:07PM +0100, Arnd Bergmann wrote:

Ok. This sounds like a lot of upfront work indeed, to make KMS more
generic, though I think a number of driver would benefit from it
eventually. It could be something for the Linaro graphics working
group to look at in the following 11.11 release, depending on how
many other people are interested in getting there.

There is already a blueprint at linaro:
https://blueprints.launchpad.net/linaro-graphics-wg/+spec/multimedia-linaro-dri-1105

We have recently tested the state of Qt acceleration on the MX51, in
order to find out which is the best way to make use of the
possibilities. However, at least at the moment this requires highly
experimental Qt sceenegraph git branches, and even then it results in
lower perfomance than with software rendering ...

But for the long term, the linaro blueprint looks like the way to go.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

On Wed, Feb 9, 2011 at 10:31 AM, Arnd Bergmann [off-list ref] wrote:

On Wednesday 09 February 2011, Sascha Hauer wrote:

quoted

The driver patch itself is Cced to linux-fbdev, only the introductory
mail is not.

Ok, I see.

quoted

quoted

Did you consider making the driver a KMS driver instead of
a frame buffer? I think the recommendation these days is
to start out with KMS for new drivers, which will be somewhat
simpler and give you a frame buffer device as well. I don't
think that there is a need to change over any drivers from
fb to kms though, since you've already done the work.

I tried doing so for the i.MX51 which supports multiple displays on dvi
and vga outputs and thus could make good use of KMS and friends. Anyway,
I got stuck quite fast. The KMS stuff is tightly coupled with DRM/DRI
and needs many many callbacks to implement. Additionally the userspace
tools expect a nvidia/amd/intel driver and do not have a generic
fallback. I think this stuff is good for implementing a full blown
graphics driver, but is lacking support for simple framebuffer grapics.
I'd love to go this way but it still requires a lot of work.

Ok. This sounds like a lot of upfront work indeed, to make KMS more
generic, though I think a number of driver would benefit from it
eventually. It could be something for the Linaro graphics working
group to look at in the following 11.11 release, depending on how
many other people are interested in getting there.

fwiw, it seems to me like xorg could have some more common code to
deal with the KMS part of DRM.. the various userspace xorg drivers end
up having a lot of very similar code to deal with enumerating
CRTCs/outputs and modes, handle hotplug, etc.

I'd been experimenting a bit on the side w/ the DRM driver framework (
http://gitorious.com/~robclark/pandaboard/robclarks-kernel-omap4/commits/omap_gpu
), but had to add a good chunk of mostly boilerplate code to our xorg
driver in order just to test it.  Maybe some generic support for KMS
in xf86-video-fbdev would have made this easier to develop the kernel
part without in parallel having to implement the userspace part.  I'm
not sure if this is the sort of thing the linaro-wg has in mind?

BR,
-R

On Tuesday 15 February 2011, Clark, Rob wrote:

I'd been experimenting a bit on the side w/ the DRM driver framework (
http://gitorious.com/~robclark/pandaboard/robclarks-kernel-omap4/commits/omap_gpu
), but had to add a good chunk of mostly boilerplate code to our xorg
driver in order just to test it.  Maybe some generic support for KMS
in xf86-video-fbdev would have made this easier to develop the kernel
part without in parallel having to implement the userspace part.  I'm
not sure if this is the sort of thing the linaro-wg has in mind?

I'm not sure what the the linaro multimedia wg thinks of this, but the
kernel code you linked looks like it's doing exactly the right thing.

	Arnd