Sakari, > >The bus type should be definitely included. If a bridge has several >different receivers, say parallel, CSI1 and CSI2, which of them should >be configured to receive data unless that's part of the bus configuration? I agree and I have responded to have it included in the RFC. > >> This particular API should just setup the physical bus. Nothing more, >IMHO. > >How would the image format be defined then...? The ISP in this case can >mangle the image format the way it wants so what's coming from the >sensor can be quite different from what's coming out of the ISP. Say, >sensor produces raw bayer and ISP writes YUYV, for example. Usually the >format the sensor outputs is not defined by the input format the user >wants from the device. It is a bit tricky here. In OMAP and DMxxx SOCs of TI, the image processing block comes in between sensor output and SDRAM. I would consider the whole path from input to VPFE or ISP to output to SDRAM as being managed by the bridge device. So S_FMT will handle all the formats that could be output to SDRAM from vpfe or isp. So it is within the bridge device how it manages all the format conversion. So in these cases, the following scenario applies... sensor/decoder -> bus -> vpfe/isp. The bus here could be CSI1 or CSI2 or Raw or YbCr. The bridge device will use appropriate hardware in the pipe line to do the conversion. > >Regards, > >-- >Sakari Ailus >sakari.ailus@xxxxxxxxxxxxxxxxxxxxxxxxxx -- 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
