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

On Tue, Dec 23, 2008 at 01:45:14PM +0100, Guennadi Liakhovetski wrote:

Hi Robert,

On Tue, 23 Dec 2008, Robert Schwebel wrote:

quoted

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

quoted

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?

I think, the question is rather "can a driver be written for IPU to 
support some sane hardware-neutral image data manipulation API, like v4l?" 
Then you can start writing any user-space apps on top of that API. So, as 
long as there is such an API, I think, we can put it on IPU, yes. My 
problems ATM is - no use-case. What concerns overlay, it is not used in 
the current application, as for image format conversion from the camera - 
I only have a Bayer camera to test with. I even cannot test monochrome 
sanely, because of a lack of a cable:-) And Bayer and monochrome don't 
make good candidates for such conversions - they are not supported by the 
IPU.

quoted

quoted

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.

I'll have a look, but as I said: -ENOUSER:-)

quoted

quoted

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.

quoted

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.

Ok, no problem. Let's just decide

1. is the drivers/dma the final location.
2. do dmaengine maintainers accept it in present form or require any 
   amendments.
3. which interrupts we make visible by default for irq_desc[] and what 
   granularity we want to enable the rest (we could even just make 
   CONFIG_ALL_IPU_IRQS and be 95% sure noone will ever need them.)
4. throw away every trace of overlay support - if anyone ever needs it 
   they should be able to dig it out in ML archives.

Or from the Freescale BSP. This sounds good to me. It would also enable
someone to write a v4l2 based overlay driver without interfering with
the existing framebuffer driver.

Sascha

-- 
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 |