2011/4/16 David Cohen <dacohen@xxxxxxxxx>:
> 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?
I formulated my reply a bit strange. I meant that that the ongoing
datastream from my camera module (even when the isp-stack is in
stream_stopped state) produces my problem. The question was if it
should be allowed for the camera to send data all time long or only
when it is told to do so by s_stream.
best regards,
Bastian Hecht
> 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
