On Wed, Oct 5, 2011 at 12:54 PM, Sakari Ailus <sakari.ai...@iki.fi> wrote: > On Wed, Oct 05, 2011 at 01:51:29PM +1100, Paul Chiha wrote: >> Thanks for your help. I've updated ispccdc.c to support the _1X16 codes >> and the pipeline seems to work now. However, I needed to take out the >> memcpy in ccdc_try_format(), because otherwise pad 0 format was being >> copied to pad 1 or 2, regardless of what pad 1 or 2 were being set to. I'm >> not sure why it was done that way. I think it's better that the given code >> gets checked to see if it's in the list and if so use it. Do you know of >> any valid reason why this copy is done? > > If I remember corretly, it's because there's nothing the CCDC may do to the > size of the image --- the driver doesn't either support cropping on the > CCDC. The sink format used to be always the same as the source format, the > assumption which no longer is valid when YUYV8_2X8 etc. formats are > supported. This must be taken into account, i.e. YUYV8_2X8 must be converted > to YUYV8_1X16 instead of just copying the format as such.
Looking at omap trm (spruf98t, July 2011) figure 12-103 it seems possible to set some registers (start pixel horizontal/vertical and so on...) to crop the "final" image, but i never tested it. Enrico -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
