Re: [PATCH 2/4 v4] i.MX31: Image Processing Unit DMA and IRQ drivers

On Tue, Dec 23, 2008 at 11:50:06AM +0100, Sascha Hauer wrote:

quoted

You mean an output v4l device? I think overlays are handled by framebuffer 
drivers... But I'm also not quite sure about it, however, handling overlay 
as another framebuffer seems logical to me.

Well the DMA engine seems to suggest that frames should be passed around
whereas the framebuffer API only has a single frame. That would fit
better into the v4l API. Also the IPU can do things like colourspace
conversion and hw scaling which would fit into the V4L API.

Looks like a candidate for gstreamer on the userspace end. Can it be
decoupled enough to make proper plugins out of it?

BTW is the overlay framebuffer useful in it's current implementation?
There seems to be no way to adjust the x/y offset or the blending
modes.

The API Eric Miao just posted for the PXA looks sane to me.

quoted

If there are no other problems with v5, could we maybe take it as a
basis and then I would submit a patch to reduce the number of IRQs?

Please understand my concerns with this driver. It's a quite complex
beast and experience shows that once a driver is in the kernel it is
far more complicated to change it than to do it right the first way.

Especially when it comes to userspace visible things.

You know that I'm also interested in having a MX31 framebuffer (and
camera) driver in kernel but I want to make sure that it works
properly and leaves room for feature enhancements without having to
refactor the whole driver.

Yup, looks like it would be better to cook it another round instead of
trying to bring in a half-tested driver with brute-force.

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 |