On Wed, Jan 04, 2012 at 05:10:40PM +0800, Scott Jiang wrote: > 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. I think a more generic solution would be preferrable. If that causes ignoring real errors, that's of course bad. I wonder if there would be a way around that. Is there a publicly available datasheet for the bridge that I could take a look at? -- 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
