On Wed, Oct 05, 2011 at 03:09:48PM +0200, Enrico wrote: > On Wed, Oct 5, 2011 at 12:54 PM, Sakari Ailus <sakari.ailus@xxxxxx> 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. Yeah; cropping should work fine on the CCDC as well but the driver doesn't implement it. -- Sakari Ailus e-mail: sakari.ailus@xxxxxx jabber/XMPP/Gmail: sailus@xxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
