Hi Michael, On Monday 24 January 2011 15:16:28 Michael Jones wrote: > On 01/24/2011 02:57 PM, Laurent Pinchart wrote: > <snip> > > >>> As the lane shifter is located at the CCDC input, it might be easier to > >>> implement support for this using the CCDC input format. ispvideo.c > >>> would need to validate the pipeline when the output of the entity > >>> connected to the CCDC input (parallel sensor, CCP2 or CSI2) is > >>> configured with a format that can be shifted to the format at the CCDC > >>> input. > >> > >> This crossed my mind, but it seems illogical to have a link with a > >> different format at each of its ends. > > > > I agree in theory, but it might be problematic for the CCDC. Right now > > the CCDC can write to memory or send the data to the preview engine, but > > not both at the same time. That's something that I'd like to change in > > the future. What happens if the user then sets different widths on the > > output pads ? > > Shouldn't we prohibit the user from doing this in ccdc_[try/set]_format > in the first place? By "prohibit", I mean shouldn't we be sure that the > pixel format on pad 1 is always the same as on pad 2? Yes we should (although we could have a larger width on the memory write port, as the video port can further shift the data). > Downside: this suggests that set_fmt on pad 2 could change the fmt on pad 1, > which may be unexpected. But that does at least reflect the reality of the > hardware, right? I don't think it would be a good idea to silently change formats on pad 1 when setting the format on pad 2. Applications don't expect that. That's why I've proposed changing the format on pad 0 instead. I agree that it would be better to have the same format on the sensor output and on CCDC pad 0 though. -- Regards, Laurent Pinchart -- 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
