Hi Bastian,
On Thu, Apr 14, 2011 at 1:36 PM, Bastian Hecht <hechtb@xxxxxxxxxxxxxx> wrote:
> Yeah!
>
> Soooo... when I initialized the the camera (loading a 108 bytes
> register listing) I just let run the camera and sent images. ÂSo I
> first realized a counter overflow Âif (count++ > 100000) after a few
> seconds. But this seemed to be handled correctly (ignore and delete
> HS_VS_IRQ flag) while after 2 or more yavta calls it made the driver
> hang.
>
> I modified my register listing so that the chip gets "booted" silently.
> In
> static struct v4l2_subdev_video_ops framix_subdev_video_ops = {
>    Â.s_stream    = framix_s_stream, <===============
> };
> I correctly check the stream status now and enable/disable the camera signals.
>
> I am unsure whether the isp should be able to handle an ongoing data
> stream independently of ISP_PIPELINE_STREAM_STOPPED.
streamoff should finish synchronously with last ongoing data. So, it
should have no ongoing data afterwards. Was that your question?
Br,
David Cohen
> If you decide it should, I will gladly help you find out more, just
> ask. It worked on an OMAP3530 before, but I do not know if it is the
> hardware or isp software that changed. Unfortunately I can't get an
> 3530 anymore (I trashed mine...).
>
>
> You helped me so much! Big thanks.
>
> Bastian Hecht
>
>
>
> 2011/4/14 Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>:
>> Hi Bastian,
>>
>> On Thursday 14 April 2011 10:33:12 Bastian Hecht wrote:
>>> 2011/4/13 Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxxxxxxxxxxxxx>:
>>> > Bastian Hecht wrote:
>>> >> Hello people,
>>> >
>>> > Hi Bastian,
>>> >
>>> > I'm cc'ing Laurent.
>>> >
>>> >> I switched to the new DM3730 from IGEP and while it's supposed to be
>>> >> (almost) the same as the 3530 Version the isp deadlocks
>>> >> deterministically after I start capturing the second time with yavta.
>>> >
>>> > Does the capture work the first time w/o issues?
>>>
>>> Yes, I can always run yavta once capturing 4 frames (3 skipped, last
>>> saved). It usually deadlocks when running yavta the second time but I had
>>> 1 successful 2nd try (out of 20 maybe).
>>>
>>> >> All extra locking debug output is enabled in the kernel .config.
>>> >
>>> > I'm not fully certain on what this exactly is that you have below, but
>>> > it looks like your system is staying in interrupt context all the time.
>>> > My guess is that the ISP is producing interrupts that the driver is not
>>> > handling properly, causing the interrupt handler to be called again
>>> > immediately.
>>>
>>> Nice! OK, I'd like to fully understand the panic output, maybe you can
>>> help there:
>>> After
>>> [ Â376.016906] [<c02e3dc4>] (_raw_spin_unlock_irqrestore+0x40/0x44)
>>> from [<bf01f678>] (omap3isp_video_queue_streamon+0x80/0x90
>>> the IRQs get enabled again. Immediately our offending irq wants to get
>>> served but noone is clearing it.
>>> At some time, the timer interrupt triggers the watchdog for a kernel panic.
>>> So the last exception block is the process context that is currently
>>> active. But why are there 2 irq routines displayed? Is the middle one the
>>> hardware handling that causes a software irq to be triggered (upper
>>> block)?
>>>
>>> So my next step could be to find the unhandled irq number?
>>
>> If the problem is caused by an interrupt storm, the following patch will make
>> your system responsive again after a couple of seconds (but will kill the ISP
>> driver :-)). If it doesn't, the problem is likely caused by something else.
>>
>> diff --git a/drivers/media/video/omap3isp/isp.c
>> b/drivers/media/video/omap3isp/isp.c
>> index de2dec5..6497300 100644
>> --- a/drivers/media/video/omap3isp/isp.c
>> +++ b/drivers/media/video/omap3isp/isp.c
>> @@ -462,6 +464,7 @@ static irqreturn_t isp_isr(int irq, void *_isp)
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â IRQ0STATUS_CCDC_VD0_IRQ |
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â IRQ0STATUS_CCDC_VD1_IRQ |
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â IRQ0STATUS_HS_VS_IRQ;
>> + Â Â Â static unsigned int count = 0;
>> Â Â Â Âstruct isp_device *isp = _isp;
>> Â Â Â Âu32 irqstatus;
>> Â Â Â Âint ret;
>> @@ -469,6 +472,11 @@ static irqreturn_t isp_isr(int irq, void *_isp)
>> Â Â Â Âirqstatus = isp_reg_readl(isp, OMAP3_ISP_IOMEM_MAIN, ISP_IRQ0STATUS);
>> Â Â Â Âisp_reg_writel(isp, irqstatus, OMAP3_ISP_IOMEM_MAIN, ISP_IRQ0STATUS);
>>
>> + Â Â Â if (count++ > 100000) {
>> + Â Â Â Â Â Â Â isp_disable_interrupts(isp);
>> + Â Â Â Â Â Â Â return IRQ_HANDLED;
>> + Â Â Â }
>> +
>> Â Â Â Âisp_isr_sbl(isp);
>>
>> Â Â Â Âif (irqstatus & IRQ0STATUS_CSIA_IRQ) {
>>
>>
>>> > Do you have the same sensor working on OMAP 3530?
>>>
>>> I never had this problem on an OMAP 3530, although I better test it
>>> again with the current setup. I try to get my hands on an 3530 today.
>>>
>>> >> I am unsure if this is an ISP thing or a problem in the
>>> >> interrupthandling software.
>>> >
>>> > This has probably something to do with the ISP driver. :-)
>>> >
>>> >> The first block is the watchdog that detects the deadlock. The last
>>> >> block is in the isp-code but how can it hang when trying to UNlock a
>>> >> spinlock? I am unsure about the 2nd block.
>>> >> The assembler code of __irq_svc is located in
>>> >> arch/arm/kernel/entry-armv.S Maybe I should try on
>>> >> linux-arm@xxxxxxxxxxxxxxxxxxxxxx but I thought I give it a shot here
>>> >> first.
>>> >>
>>> >> I use the omap3isp-2.6.35.3-omap3isp branch from Laurent.
>>> >
>>> > Why so old kernel?
>>>
>>> I tried a newer version, but there I couldn't get it booting with my
>>> igep. The kernel unpacked and tried to boot but it froze.
>>> I decided to use a version that is officially is supported by the igep
>>> team.
>>
>> The ttyS* OMAP serial devices have been renamed to ttyO* in 2.6.37. Replace
>> /dev/ttyS2 with /dev/ttyO2 on your kernel command line (either in the kernel
>> config file if you've activated CONFIG_CMDLINE_FORCE, or in the boot loader
>> environment variables) and you should be able to boot 2.6.38 without any
>> issue. Don't forget to modify /etc/inittab as well.
>>
>> --
>> 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
>
--
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
