2012/1/4 Sakari Ailus <sakari.ailus@xxxxxx>: > Hi Scott, > > On Wed, Jan 04, 2012 at 01:50:17PM +0800, Scott Jiang wrote: >> >> I the case of your bridge, that may not be possible, but that's the only one >> >> I've heard of so I think it's definitely a special case. In that case the >> >> sensor driver can't be allowed to change the blanking periods while >> >> streaming is ongoing. >> > >> > I agree, it's just a matter of adding proper logic at the sensor driver. >> > However it might be a bit tricky, the bridge would have to validate blanking >> > values before actually enabling streaming. >> > >> Yes, this value doesn't affect the result image. The hardware only >> raises a error interrupt to signify that a horizontal tracking >> overflow has >> occurred, that means the programmed number of samples did not match up >> with the actual number of samples counted between assertions of >> HSYNC(I can only set active samples now). > > Is there no way to disable this tracking, and just rely on hsync as everyone > else does? Sounds like the hardware tries to do something it shouldn't... > If I disable this interrupt, other errors like fifo underflow are ignored. Perhaps I can add a parameter in platform data to let user decide to register this interrupt or not. Scott -- 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
