2011/4/27 Bastian Hecht <hechtb@xxxxxxxxxxxxxx>: > 2011/4/26 Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>: >> Hi Bastian, >> >> On Tuesday 26 April 2011 17:39:41 Bastian Hecht wrote: >>> 2011/4/21 Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>: >>> > On Tuesday 19 April 2011 09:31:05 Sakari Ailus wrote: >>> >> Laurent Pinchart wrote: >>> >> ... >>> >> >>> >> > That's the ideal situation: sensors should not produce any data (or >>> >> > rather any transition on the VS/HS signals) when they're supposed to >>> >> > be stopped. Unfortunately that's not always easy, as some dumb >>> >> > sensors (or sensor-like hardware) can't be stopped. The ISP driver >>> >> > should be able to cope with that in a way that doesn't kill the >>> >> > system completely. >>> >> > >>> >> > I've noticed the same issue with a Caspa camera module and an >>> >> > OMAP3503-based Gumstix. I'll try to come up with a good fix. >>> >> >>> >> Hi Laurent, others, >>> >> >>> >> Do you think the cause for this is that the system is jammed in handling >>> >> HS_VS interrupts triggered for every HS? >>> > >>> > That was my initial guess, yes. >>> > >>> >> A quick fix for this could be just choosing either VS configuration when >>> >> configuring the CCDC. Alternatively, HS_VS interrupts could be just >>> >> disabled until omap3isp_configure_interface(). >>> >> >>> >> But as the sensor is sending images all the time, proper VS >>> >> configuration would be needed, or the counting of lines in the CCDC >>> >> (VD* interrupts) is affected as well. The VD0 interrupt, which is used >>> >> to trigger an interrupt near the end of the frame, may be triggered one >>> >> line too early on the first frame, or too late. But this is up to a >>> >> configuration. I don't think it's a real issue to trigger it one line >>> >> too early. >>> >> >>> >> Anything else? >>> >>> Hello Laurent, >>> >>> > I've tried delaying the HS_VS interrupt enable to the CCDC configuration >>> > function, after configuring the bridge (and thus the HS/VS interrupt >>> > source selection). To my surprise it didn't fix the problem, I still get >>> > tons of HS_VS interrupts (100000 in about 2.6 seconds) that kill the >>> > system. >>> > >>> > I'll need to hook a scope to the HS and VS signals. >>> >>> have you worked on this problem? Today in my setup I took a longer cable and >>> ran again into the hs/vs interrupt storm (it still works with a short >>> cable). >>> I can tackle this issue too, but to avoid double work I wanted to ask if you >>> worked out something in the meantime. > > >> In my case the issue was caused by a combination of two hardware design >> mistakes. The first one was to use a TXB0801 chip to translate the 3.3V sensor >> levels to the 1.8V OMAP levels. The TXB0801 4kÎ output impedance, combined >> with the OMAP3 100ÂA pull-ups on the HS and VS signals, produces a ~400mV >> voltage for low logic levels. >> >> Then, the XCLKA signal is next to the VS signal on the cable connecting the >> camera module to the OMAP board. When XCLKA is turned on, cross-talk produces >> a 400mV peak-to-peak noise on the VS signal. >> >> The combination of those two effects create a noisy VS signal that crosses the >> OMAP3 input level detection gap at high frequency, leading to an interrupt >> storm. The workaround is to disable the pull-ups on the HS and VS signals, the >> solution is to redesign the hardware to replace the level translators and >> reorganize signals on the camera module cable. > > Hi Laurent, > >> Is your situation any similar ? > > The long data line (~35cm now at 24MHz) certainly can have an impact > but I haven't measured any crosstalk so far. But I'm on another trail > now. I found out that on my board the interrupt line is shared with > Â24: Â Â Â Â Â0 Â Â Â ÂINTC Âomap-iommu.0 > > Is the following scenario possible? > > 1. The omap-iommu isr is registered > 2. The isp gets set up (it enables interrupts and disables them again > at the end of the probe function) > 3. Later I activate the xclk from within my driver > Â3a. isp_set_xclk() gets the lock omap3isp_get(isp) and so > enable_interrupts() is called > Â3b. The new xclk on my chip makes my hardware create a hs/vs int > (either crosstalk, another hardware bug like yours, or simply my chip > sends a spurious interrupt for any reason) > Â3c. Âisp_set_xclk() puts the lock omap3isp_put(isp) and so > disable_interrupts() is called > > Can there exist a race condition between the omap3isp raising the > interrupt pin before 3c or after 3c? Argh... I oversaw that the omap3isp isr handler stays registered all time long so the theory is wrong. > If after 3c the omap-iommu isr loops forever as the omap3isp int flag > is never cleared. > > I keep debbuging and trying to find further clues. > > Best regards, > > Bastian > > >> -- >> 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
