On Mon, Apr 18, 2011 at 1:43 PM, Bastian Hecht <hechtb@xxxxxxxxxxxxxx> wrote:
> 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.
I may assume you are mentioning a pipeline which includes camera
sensor + ISP. In this case there should be no data.
Regards,
David
>
> 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
