* omap3isp: known causes of "CCDC won't become idle! @ 2011-07-05 11:22 Jonathan Cameron 2011-07-05 12:19 ` Sakari Ailus 0 siblings, 1 reply; 10+ messages in thread From: Jonathan Cameron @ 2011-07-05 11:22 UTC (permalink / raw) To: Linux Media Mailing List, laurent.pinchart Hi Laurent, I'm just trying to get an mt9v034 sensor working on a beagle xm. Everything more or less works, except that after a random number of frames of capture, I tend to get won't become idle messages and the vd0 and vd1 interrupts tend to turn up at same time. I was just wondering if there are any known issues with the ccdc driver / silicon that might explain this? I also note that it appears to be impossible to disable HS_VS_IRQ despite the datasheet claiming this can be done. Is this a known issue? Thanks, Jonathan ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: omap3isp: known causes of "CCDC won't become idle! 2011-07-05 11:22 omap3isp: known causes of "CCDC won't become idle! Jonathan Cameron @ 2011-07-05 12:19 ` Sakari Ailus 2011-07-05 12:25 ` Laurent Pinchart 2011-07-05 13:48 ` Jonathan Cameron 0 siblings, 2 replies; 10+ messages in thread From: Sakari Ailus @ 2011-07-05 12:19 UTC (permalink / raw) To: Jonathan Cameron; +Cc: Linux Media Mailing List, laurent.pinchart On Tue, Jul 05, 2011 at 12:22:06PM +0100, Jonathan Cameron wrote: > Hi Laurent, > > I'm just trying to get an mt9v034 sensor working on a beagle xm. > Everything more or less works, except that after a random number > of frames of capture, I tend to get won't become idle messages > and the vd0 and vd1 interrupts tend to turn up at same time. > > I was just wondering if there are any known issues with the ccdc > driver / silicon that might explain this? > > I also note that it appears to be impossible to disable HS_VS_IRQ > despite the datasheet claiming this can be done. Is this a known > issue? The same interrupt may be used to produce an interrupt per horizontal sync but the driver doesn't use that. I remember of a case where the two sync signals had enough crosstalk to cause vertical sync interrupt per every horizontal sync. (It's been discussed on this list.) This might not be the case here, though: you should be flooded with HS_VS interrupts. The VD* counters are counting and interrupts are produced (AFAIR) even if the CCDC is disabled. Once the CCDC starts receiving a frame, it becomes busy, and becomes idle only when it has received the full frame. For this reason it's important that the full frame is actually received by the CCDC, otherwise this is due to happen when the CCDC is being stopped at the end of the stream. Regards, -- Sakari Ailus sakari.ailus@iki.fi ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: omap3isp: known causes of "CCDC won't become idle! 2011-07-05 12:19 ` Sakari Ailus @ 2011-07-05 12:25 ` Laurent Pinchart 2011-07-05 13:48 ` Jonathan Cameron 1 sibling, 0 replies; 10+ messages in thread From: Laurent Pinchart @ 2011-07-05 12:25 UTC (permalink / raw) To: Sakari Ailus; +Cc: Jonathan Cameron, Linux Media Mailing List Hi Sakari, On Tuesday 05 July 2011 14:19:16 Sakari Ailus wrote: > On Tue, Jul 05, 2011 at 12:22:06PM +0100, Jonathan Cameron wrote: > > Hi Laurent, > > > > I'm just trying to get an mt9v034 sensor working on a beagle xm. > > Everything more or less works, except that after a random number > > of frames of capture, I tend to get won't become idle messages > > and the vd0 and vd1 interrupts tend to turn up at same time. > > > > I was just wondering if there are any known issues with the ccdc > > driver / silicon that might explain this? > > > > I also note that it appears to be impossible to disable HS_VS_IRQ > > despite the datasheet claiming this can be done. Is this a known > > issue? > > The same interrupt may be used to produce an interrupt per horizontal sync > but the driver doesn't use that. I remember of a case where the two sync > signals had enough crosstalk to cause vertical sync interrupt per every > horizontal sync. (It's been discussed on this list.) This might not be the > case here, though: you should be flooded with HS_VS interrupts. It was worse than that, it was crosstalk between the pixel clock and the vsync signal, resulting in one vsync interrupt per pixel. > The VD* counters are counting and interrupts are produced (AFAIR) even if > the CCDC is disabled. If I'm not mistaken the interrupts can be produced if the CCDC is disabled, but clearing the interrupt enable bit for the HS_VS interrupt should prevent them from being generated. > Once the CCDC starts receiving a frame, it becomes busy, and becomes idle > only when it has received the full frame. For this reason it's important > that the full frame is actually received by the CCDC, otherwise this is due > to happen when the CCDC is being stopped at the end of the stream. You also need to make sure that the input stream contains enough vertical blanking, otherwise the ISP driver might not have time to restart the CCDC before the beginning of the next frame, especially under high load conditions. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: omap3isp: known causes of "CCDC won't become idle! 2011-07-05 12:19 ` Sakari Ailus 2011-07-05 12:25 ` Laurent Pinchart @ 2011-07-05 13:48 ` Jonathan Cameron 2011-07-05 14:38 ` Sakari Ailus 1 sibling, 1 reply; 10+ messages in thread From: Jonathan Cameron @ 2011-07-05 13:48 UTC (permalink / raw) To: Sakari Ailus; +Cc: Linux Media Mailing List, laurent.pinchart On 07/05/11 13:19, Sakari Ailus wrote: > On Tue, Jul 05, 2011 at 12:22:06PM +0100, Jonathan Cameron wrote: >> Hi Laurent, >> >> I'm just trying to get an mt9v034 sensor working on a beagle xm. >> Everything more or less works, except that after a random number >> of frames of capture, I tend to get won't become idle messages >> and the vd0 and vd1 interrupts tend to turn up at same time. >> >> I was just wondering if there are any known issues with the ccdc >> driver / silicon that might explain this? >> >> I also note that it appears to be impossible to disable HS_VS_IRQarch/arm/mach-s3c2410/Kconfig:# cpu frequency scaling support >> despite the datasheet claiming this can be done. Is this a known >> issue? > > The same interrupt may be used to produce an interrupt per horizontal sync > but the driver doesn't use that. I remember of a case where the two sync > signals had enough crosstalk to cause vertical sync interrupt per every > horizontal sync. (It's been discussed on this list.) This might not be the > case here, though: you should be flooded with HS_VS interrupts. As far as I can tell, the driver doesn't use either interrupt (except to pass it up as an event). Hence I was trying to mask it purely to cut down on the interrupt load. > > The VD* counters are counting and interrupts are produced (AFAIR) even if > the CCDC is disabled. Oh goody... > > Once the CCDC starts receiving a frame, it becomes busy, and becomes idle > only when it has received the full frame. For this reason it's important > that the full frame is actually received by the CCDC, otherwise this is due > to happen when the CCDC is being stopped at the end of the stream. Fair enough. Is there any software reason why it might think it hasn't received the whole frame? Obviously it could in theory be a hardware issue, but it's a bit odd that it can reliably do a certain number of frames before falling over. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: omap3isp: known causes of "CCDC won't become idle! 2011-07-05 13:48 ` Jonathan Cameron @ 2011-07-05 14:38 ` Sakari Ailus 2011-07-05 15:02 ` Laurent Pinchart 0 siblings, 1 reply; 10+ messages in thread From: Sakari Ailus @ 2011-07-05 14:38 UTC (permalink / raw) To: Jonathan Cameron; +Cc: Linux Media Mailing List, laurent.pinchart On Tue, Jul 05, 2011 at 02:48:57PM +0100, Jonathan Cameron wrote: > On 07/05/11 13:19, Sakari Ailus wrote: > > On Tue, Jul 05, 2011 at 12:22:06PM +0100, Jonathan Cameron wrote: > >> Hi Laurent, > >> > >> I'm just trying to get an mt9v034 sensor working on a beagle xm. > >> Everything more or less works, except that after a random number > >> of frames of capture, I tend to get won't become idle messages > >> and the vd0 and vd1 interrupts tend to turn up at same time. > >> > >> I was just wondering if there are any known issues with the ccdc > >> driver / silicon that might explain this? > >> > >> I also note that it appears to be impossible to disable HS_VS_IRQarch/arm/mach-s3c2410/Kconfig:# cpu frequency scaling support > > >> despite the datasheet claiming this can be done. Is this a known > >> issue? > > > > The same interrupt may be used to produce an interrupt per horizontal sync > > but the driver doesn't use that. I remember of a case where the two sync > > signals had enough crosstalk to cause vertical sync interrupt per every > > horizontal sync. (It's been discussed on this list.) This might not be the > > case here, though: you should be flooded with HS_VS interrupts. > As far as I can tell, the driver doesn't use either interrupt (except to pass > it up as an event). Hence I was trying to mask it purely to cut down on the > interrupt load. It does. This is the only way to detect the CCDC has finished processing a frame. > > The VD* counters are counting and interrupts are produced (AFAIR) even if > > the CCDC is disabled. > Oh goody... > > > > Once the CCDC starts receiving a frame, it becomes busy, and becomes idle > > only when it has received the full frame. For this reason it's important > > that the full frame is actually received by the CCDC, otherwise this is due > > to happen when the CCDC is being stopped at the end of the stream. > Fair enough. Is there any software reason why it might think it hasn't received > the whole frame? Obviously it could in theory be a hardware issue, but it's > a bit odd that it can reliably do a certain number of frames before falling over. Others than those which Laurent already pointed out, one which crosses my mind is the vsync polarity. The Documentation/video4linux/omap3isp.txt does mention it. It _may_ have the effect that one line of input is missed by the VD* counters. Thus the VD* counters might never reach the expected value --- the last line of the frame. -- Sakari Ailus sakari.ailus@iki.fi ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: omap3isp: known causes of "CCDC won't become idle! 2011-07-05 14:38 ` Sakari Ailus @ 2011-07-05 15:02 ` Laurent Pinchart 2011-07-05 15:22 ` Jonathan Cameron 2011-07-05 16:16 ` Sakari Ailus 0 siblings, 2 replies; 10+ messages in thread From: Laurent Pinchart @ 2011-07-05 15:02 UTC (permalink / raw) To: Sakari Ailus; +Cc: Jonathan Cameron, Linux Media Mailing List On Tuesday 05 July 2011 16:38:07 Sakari Ailus wrote: > On Tue, Jul 05, 2011 at 02:48:57PM +0100, Jonathan Cameron wrote: > > On 07/05/11 13:19, Sakari Ailus wrote: > > > On Tue, Jul 05, 2011 at 12:22:06PM +0100, Jonathan Cameron wrote: > > >> Hi Laurent, > > >> > > >> I'm just trying to get an mt9v034 sensor working on a beagle xm. > > >> Everything more or less works, except that after a random number > > >> of frames of capture, I tend to get won't become idle messages > > >> and the vd0 and vd1 interrupts tend to turn up at same time. > > >> > > >> I was just wondering if there are any known issues with the ccdc > > >> driver / silicon that might explain this? > > >> > > >> I also note that it appears to be impossible to disable > > >> HS_VS_IRQarch/arm/mach-s3c2410/Kconfig:# cpu frequency scaling > > >> support > > >> > > >> despite the datasheet claiming this can be done. Is this a known > > >> issue? > > > > > > The same interrupt may be used to produce an interrupt per horizontal > > > sync but the driver doesn't use that. I remember of a case where the > > > two sync signals had enough crosstalk to cause vertical sync interrupt > > > per every horizontal sync. (It's been discussed on this list.) This > > > might not be the case here, though: you should be flooded with HS_VS > > > interrupts. > > > > As far as I can tell, the driver doesn't use either interrupt (except to > > pass it up as an event). Hence I was trying to mask it purely to cut > > down on the interrupt load. > > It does. This is the only way to detect the CCDC has finished processing a > frame. We actually use the VD0 and VD1 interrupts for that, not the HS_VS interrupt. > > > The VD* counters are counting and interrupts are produced (AFAIR) even > > > if the CCDC is disabled. > > > > Oh goody... > > > > > Once the CCDC starts receiving a frame, it becomes busy, and becomes > > > idle only when it has received the full frame. For this reason it's > > > important that the full frame is actually received by the CCDC, > > > otherwise this is due to happen when the CCDC is being stopped at the > > > end of the stream. > > > > Fair enough. Is there any software reason why it might think it hasn't > > received the whole frame? Obviously it could in theory be a hardware > > issue, but it's a bit odd that it can reliably do a certain number of > > frames before falling over. > > Others than those which Laurent already pointed out, one which crosses my > mind is the vsync polarity. The Documentation/video4linux/omap3isp.txt does > mention it. It _may_ have the effect that one line of input is missed by > the VD* counters. Thus the VD* counters might never reach the expected > value --- the last line of the frame. I would first try to increase vertical blanking to see if it helps. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: omap3isp: known causes of "CCDC won't become idle! 2011-07-05 15:02 ` Laurent Pinchart @ 2011-07-05 15:22 ` Jonathan Cameron 2011-07-05 16:35 ` Jonathan Cameron 2011-07-05 16:16 ` Sakari Ailus 1 sibling, 1 reply; 10+ messages in thread From: Jonathan Cameron @ 2011-07-05 15:22 UTC (permalink / raw) To: Laurent Pinchart; +Cc: Sakari Ailus, Linux Media Mailing List On 07/05/11 16:02, Laurent Pinchart wrote: > On Tuesday 05 July 2011 16:38:07 Sakari Ailus wrote: >> On Tue, Jul 05, 2011 at 02:48:57PM +0100, Jonathan Cameron wrote: >>> On 07/05/11 13:19, Sakari Ailus wrote: >>>> On Tue, Jul 05, 2011 at 12:22:06PM +0100, Jonathan Cameron wrote: >>>>> Hi Laurent, >>>>> >>>>> I'm just trying to get an mt9v034 sensor working on a beagle xm. >>>>> Everything more or less works, except that after a random number >>>>> of frames of capture, I tend to get won't become idle messages >>>>> and the vd0 and vd1 interrupts tend to turn up at same time. >>>>> >>>>> I was just wondering if there are any known issues with the ccdc >>>>> driver / silicon that might explain this? >>>>> >>>>> I also note that it appears to be impossible to disable >>>>> HS_VS_IRQarch/arm/mach-s3c2410/Kconfig:# cpu frequency scaling >>>>> support >>>>> >>>>> despite the datasheet claiming this can be done. Is this a known >>>>> issue? >>>> >>>> The same interrupt may be used to produce an interrupt per horizontal >>>> sync but the driver doesn't use that. I remember of a case where the >>>> two sync signals had enough crosstalk to cause vertical sync interrupt >>>> per every horizontal sync. (It's been discussed on this list.) This >>>> might not be the case here, though: you should be flooded with HS_VS >>>> interrupts. >>> >>> As far as I can tell, the driver doesn't use either interrupt (except to >>> pass it up as an event). Hence I was trying to mask it purely to cut >>> down on the interrupt load. >> >> It does. This is the only way to detect the CCDC has finished processing a >> frame. > > We actually use the VD0 and VD1 interrupts for that, not the HS_VS interrupt. > >>>> The VD* counters are counting and interrupts are produced (AFAIR) even >>>> if the CCDC is disabled. >>> >>> Oh goody... >>> >>>> Once the CCDC starts receiving a frame, it becomes busy, and becomes >>>> idle only when it has received the full frame. For this reason it's >>>> important that the full frame is actually received by the CCDC, >>>> otherwise this is due to happen when the CCDC is being stopped at the >>>> end of the stream. >>> >>> Fair enough. Is there any software reason why it might think it hasn't >>> received the whole frame? Obviously it could in theory be a hardware >>> issue, but it's a bit odd that it can reliably do a certain number of >>> frames before falling over. >> >> Others than those which Laurent already pointed out, one which crosses my >> mind is the vsync polarity. The Documentation/video4linux/omap3isp.txt does >> mention it. It _may_ have the effect that one line of input is missed by >> the VD* counters. Thus the VD* counters might never reach the expected >> value --- the last line of the frame. > > I would first try to increase vertical blanking to see if it helps. Have done. No luck as yet. This sensor mt9v034 annoyingly starts live. Right now this means I get two frames with very short vblank (10% ratio, at 60fps, so sub 2 microseonds.) Whilst the failure seems to be at a later time, I'd obviously like to get rid of these. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: omap3isp: known causes of "CCDC won't become idle! 2011-07-05 15:22 ` Jonathan Cameron @ 2011-07-05 16:35 ` Jonathan Cameron 2011-07-06 16:30 ` Jonathan Cameron 0 siblings, 1 reply; 10+ messages in thread From: Jonathan Cameron @ 2011-07-05 16:35 UTC (permalink / raw) To: Laurent Pinchart; +Cc: Sakari Ailus, Linux Media Mailing List On 07/05/11 16:22, Jonathan Cameron wrote: > On 07/05/11 16:02, Laurent Pinchart wrote: >> On Tuesday 05 July 2011 16:38:07 Sakari Ailus wrote: >>> On Tue, Jul 05, 2011 at 02:48:57PM +0100, Jonathan Cameron wrote: >>>> On 07/05/11 13:19, Sakari Ailus wrote: >>>>> On Tue, Jul 05, 2011 at 12:22:06PM +0100, Jonathan Cameron wrote: >>>>>> Hi Laurent, >>>>>> >>>>>> I'm just trying to get an mt9v034 sensor working on a beagle xm. >>>>>> Everything more or less works, except that after a random number >>>>>> of frames of capture, I tend to get won't become idle messages >>>>>> and the vd0 and vd1 interrupts tend to turn up at same time. >>>>>> >>>>>> I was just wondering if there are any known issues with the ccdc >>>>>> driver / silicon that might explain this? >>>>>> >>>>>> I also note that it appears to be impossible to disable >>>>>> HS_VS_IRQarch/arm/mach-s3c2410/Kconfig:# cpu frequency scaling >>>>>> support >>>>>> >>>>>> despite the datasheet claiming this can be done. Is this a known >>>>>> issue? >>>>> >>>>> The same interrupt may be used to produce an interrupt per horizontal >>>>> sync but the driver doesn't use that. I remember of a case where the >>>>> two sync signals had enough crosstalk to cause vertical sync interrupt >>>>> per every horizontal sync. (It's been discussed on this list.) This >>>>> might not be the case here, though: you should be flooded with HS_VS >>>>> interrupts. >>>> >>>> As far as I can tell, the driver doesn't use either interrupt (except to >>>> pass it up as an event). Hence I was trying to mask it purely to cut >>>> down on the interrupt load. >>> >>> It does. This is the only way to detect the CCDC has finished processing a >>> frame. >> >> We actually use the VD0 and VD1 interrupts for that, not the HS_VS interrupt. On that note, the interrupt was being disabled, just not it's value in the register. What I was actually seeing was it combined with one of the others. >> >>>>> The VD* counters are counting and interrupts are produced (AFAIR) even >>>>> if the CCDC is disabled. >>>> >>>> Oh goody... >>>> >>>>> Once the CCDC starts receiving a frame, it becomes busy, and becomes >>>>> idle only when it has received the full frame. For this reason it's >>>>> important that the full frame is actually received by the CCDC, >>>>> otherwise this is due to happen when the CCDC is being stopped at the >>>>> end of the stream. >>>> >>>> Fair enough. Is there any software reason why it might think it hasn't >>>> received the whole frame? Obviously it could in theory be a hardware >>>> issue, but it's a bit odd that it can reliably do a certain number of >>>> frames before falling over. >>> >>> Others than those which Laurent already pointed out, one which crosses my >>> mind is the vsync polarity. The Documentation/video4linux/omap3isp.txt does >>> mention it. It _may_ have the effect that one line of input is missed by >>> the VD* counters. Thus the VD* counters might never reach the expected >>> value --- the last line of the frame. >> >> I would first try to increase vertical blanking to see if it helps. > Have done. No luck as yet. This sensor mt9v034 annoyingly starts live. > Right now this means I get two frames with very short vblank (10% ratio, at 60fps, > so sub 2 microseonds.) Whilst the failure seems to be at a later time, I'd > obviously like to get rid of these. Hmm. Via a bit of reordering of writes and a temporary disable, it now does one frame, then about a 100ms pause, then continues with 50ms blanking periods, vs, about 18ms of data transfer. Still running into what looks like the same issue with the ccdc getting wedged... Having introduced some debugging into the isr I get: 55.123840] power on called [ 55.135528] interrupt 2147483648 [ 55.139038] interrupt 2147483648 [ 55.142578] interrupt 2147483648 [ 55.145965] interrupt 2147483648 [ 55.149383] interrupt 2147483648 [ 55.152770] interrupt 2147483648 [ 55.156188] interrupt 2147483648 [ 55.159576] interrupt 2147483648 [ 55.162994] interrupt 2147483648 [ 55.181854] end of set power [ 55.241821] get format called [ 55.245025] get pad format [ 55.248138] in [ 55.249877] get format called [ 55.252990] get pad format [ 55.256195] on [ 55.257904] s_stream called [ 55.260833] set params called [ 55.267944] stream enable attempted [ 55.282257] interrupt 2147483648 [ 55.302429] interrupt 512 [ 55.312408] interrupt 256 [ 55.385864] interrupt 2147483648 [ 55.406005] interrupt 512 [ 55.415985] interrupt 256 [ 55.492401] interrupt 2147483648 [ 55.512603] interrupt 512 [ 55.522583] interrupt 256 [ 55.599029] interrupt 2147483648 [ 55.619201] interrupt 512 [ 55.629180] interrupt 256 [ 55.705627] interrupt 2147483648 [ 55.725738] interrupt 512 [ 55.735687] interrupt 256 [ 55.740417] omap3isp omap3isp: CCDC won't become idle! [ 55.811645] interrupt 2147483648 [ 55.832000] interrupt 512 [ 55.842010] interrupt 256 Repeat last 4 lines ad infinitum or if lucky till my program gives up and closes everything. Sometimes that hangs the machine as well. So nothing obviously changing. Waveform of the vsync signal looks right to me. The other fun wedge that sometimes happens is both vd0 and vd1 occur together. Not sure what can be done about that one. It tends to occur after a are occasion where I actually get as far as closing the dev in a previous run. (i.e. something is wrong in my shutdown of the device). Jonathan ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: omap3isp: known causes of "CCDC won't become idle! 2011-07-05 16:35 ` Jonathan Cameron @ 2011-07-06 16:30 ` Jonathan Cameron 0 siblings, 0 replies; 10+ messages in thread From: Jonathan Cameron @ 2011-07-06 16:30 UTC (permalink / raw) To: Laurent Pinchart; +Cc: Sakari Ailus, Linux Media Mailing List On 07/05/11 17:35, Jonathan Cameron wrote: > On 07/05/11 16:22, Jonathan Cameron wrote: >> On 07/05/11 16:02, Laurent Pinchart wrote: >>> On Tuesday 05 July 2011 16:38:07 Sakari Ailus wrote: >>>> On Tue, Jul 05, 2011 at 02:48:57PM +0100, Jonathan Cameron wrote: >>>>> On 07/05/11 13:19, Sakari Ailus wrote: >>>>>> On Tue, Jul 05, 2011 at 12:22:06PM +0100, Jonathan Cameron wrote: >>>>>>> Hi Laurent, >>>>>>> >>>>>>> I'm just trying to get an mt9v034 sensor working on a beagle xm. >>>>>>> Everything more or less works, except that after a random number >>>>>>> of frames of capture, I tend to get won't become idle messages >>>>>>> and the vd0 and vd1 interrupts tend to turn up at same time. >>>>>>> >>>>>>> I was just wondering if there are any known issues with the ccdc >>>>>>> driver / silicon that might explain this? >>>>>>> >>>>>>> I also note that it appears to be impossible to disable >>>>>>> HS_VS_IRQarch/arm/mach-s3c2410/Kconfig:# cpu frequency scaling >>>>>>> support >>>>>>> >>>>>>> despite the datasheet claiming this can be done. Is this a known >>>>>>> issue? >>>>>> >>>>>> The same interrupt may be used to produce an interrupt per horizontal >>>>>> sync but the driver doesn't use that. I remember of a case where the >>>>>> two sync signals had enough crosstalk to cause vertical sync interrupt >>>>>> per every horizontal sync. (It's been discussed on this list.) This >>>>>> might not be the case here, though: you should be flooded with HS_VS >>>>>> interrupts. >>>>> >>>>> As far as I can tell, the driver doesn't use either interrupt (except to >>>>> pass it up as an event). Hence I was trying to mask it purely to cut >>>>> down on the interrupt load. >>>> >>>> It does. This is the only way to detect the CCDC has finished processing a >>>> frame. >>> >>> We actually use the VD0 and VD1 interrupts for that, not the HS_VS interrupt. > On that note, the interrupt was being disabled, just not it's value in the > register. What I was actually seeing was it combined with one of the others. > >>> >>>>>> The VD* counters are counting and interrupts are produced (AFAIR) even >>>>>> if the CCDC is disabled. >>>>> >>>>> Oh goody... >>>>> >>>>>> Once the CCDC starts receiving a frame, it becomes busy, and becomes >>>>>> idle only when it has received the full frame. For this reason it's >>>>>> important that the full frame is actually received by the CCDC, >>>>>> otherwise this is due to happen when the CCDC is being stopped at the >>>>>> end of the stream. >>>>> >>>>> Fair enough. Is there any software reason why it might think it hasn't >>>>> received the whole frame? Obviously it could in theory be a hardware >>>>> issue, but it's a bit odd that it can reliably do a certain number of >>>>> frames before falling over. >>>> >>>> Others than those which Laurent already pointed out, one which crosses my >>>> mind is the vsync polarity. The Documentation/video4linux/omap3isp.txt does >>>> mention it. It _may_ have the effect that one line of input is missed by >>>> the VD* counters. Thus the VD* counters might never reach the expected >>>> value --- the last line of the frame. >>> >>> I would first try to increase vertical blanking to see if it helps. >> Have done. No luck as yet. This sensor mt9v034 annoyingly starts live. >> Right now this means I get two frames with very short vblank (10% ratio, at 60fps, >> so sub 2 microseonds.) Whilst the failure seems to be at a later time, I'd >> obviously like to get rid of these. > Hmm. Via a bit of reordering of writes and a temporary disable, it now does one frame, > then about a 100ms pause, then continues with 50ms blanking periods, vs, about 18ms of > data transfer. Still running into what looks like the same issue with the ccdc getting > wedged... > > Having introduced some debugging into the isr I get: > > 55.123840] power on called > [ 55.135528] interrupt 2147483648 > [ 55.139038] interrupt 2147483648 > [ 55.142578] interrupt 2147483648 > [ 55.145965] interrupt 2147483648 > [ 55.149383] interrupt 2147483648 > [ 55.152770] interrupt 2147483648 > [ 55.156188] interrupt 2147483648 > [ 55.159576] interrupt 2147483648 > [ 55.162994] interrupt 2147483648 > [ 55.181854] end of set power > [ 55.241821] get format called > [ 55.245025] get pad format > [ 55.248138] in > [ 55.249877] get format called > [ 55.252990] get pad format > [ 55.256195] on > [ 55.257904] s_stream called > [ 55.260833] set params called > [ 55.267944] stream enable attempted > [ 55.282257] interrupt 2147483648 > [ 55.302429] interrupt 512 > [ 55.312408] interrupt 256 > [ 55.385864] interrupt 2147483648 > [ 55.406005] interrupt 512 > [ 55.415985] interrupt 256 > [ 55.492401] interrupt 2147483648 > [ 55.512603] interrupt 512 > [ 55.522583] interrupt 256 > [ 55.599029] interrupt 2147483648 > [ 55.619201] interrupt 512 > [ 55.629180] interrupt 256 > [ 55.705627] interrupt 2147483648 > [ 55.725738] interrupt 512 > [ 55.735687] interrupt 256 > [ 55.740417] omap3isp omap3isp: CCDC won't become idle! > [ 55.811645] interrupt 2147483648 > [ 55.832000] interrupt 512 > [ 55.842010] interrupt 256 > Repeat last 4 lines ad infinitum or if lucky till my program gives up > and closes everything. Sometimes that hangs the machine as well. > > So nothing obviously changing. Waveform of the vsync signal looks right to > me. > > The other fun wedge that sometimes happens is both vd0 and vd1 occur together. > Not sure what can be done about that one. It tends to occur after a are occasion > where I actually get as far as closing the dev in a previous run. (i.e. something > is wrong in my shutdown of the device). Having fiddle a lot more, it looks like I'm actually never getting some pixels (not exactly a good sign!) My suspicion is that it's due to a slow rise time of the clock input to the camera (and equally poor on the output). They both rise and fall very slowly given that I'm not running it very slowly. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: omap3isp: known causes of "CCDC won't become idle! 2011-07-05 15:02 ` Laurent Pinchart 2011-07-05 15:22 ` Jonathan Cameron @ 2011-07-05 16:16 ` Sakari Ailus 1 sibling, 0 replies; 10+ messages in thread From: Sakari Ailus @ 2011-07-05 16:16 UTC (permalink / raw) To: Laurent Pinchart; +Cc: Jonathan Cameron, Linux Media Mailing List On Tue, Jul 05, 2011 at 05:02:52PM +0200, Laurent Pinchart wrote: > On Tuesday 05 July 2011 16:38:07 Sakari Ailus wrote: > > On Tue, Jul 05, 2011 at 02:48:57PM +0100, Jonathan Cameron wrote: > > > On 07/05/11 13:19, Sakari Ailus wrote: > > > > On Tue, Jul 05, 2011 at 12:22:06PM +0100, Jonathan Cameron wrote: > > > >> Hi Laurent, > > > >> > > > >> I'm just trying to get an mt9v034 sensor working on a beagle xm. > > > >> Everything more or less works, except that after a random number > > > >> of frames of capture, I tend to get won't become idle messages > > > >> and the vd0 and vd1 interrupts tend to turn up at same time. > > > >> > > > >> I was just wondering if there are any known issues with the ccdc > > > >> driver / silicon that might explain this? > > > >> > > > >> I also note that it appears to be impossible to disable > > > >> HS_VS_IRQarch/arm/mach-s3c2410/Kconfig:# cpu frequency scaling > > > >> support > > > >> > > > >> despite the datasheet claiming this can be done. Is this a known > > > >> issue? > > > > > > > > The same interrupt may be used to produce an interrupt per horizontal > > > > sync but the driver doesn't use that. I remember of a case where the > > > > two sync signals had enough crosstalk to cause vertical sync interrupt > > > > per every horizontal sync. (It's been discussed on this list.) This > > > > might not be the case here, though: you should be flooded with HS_VS > > > > interrupts. > > > > > > As far as I can tell, the driver doesn't use either interrupt (except to > > > pass it up as an event). Hence I was trying to mask it purely to cut > > > down on the interrupt load. > > > > It does. This is the only way to detect the CCDC has finished processing a > > frame. > > We actually use the VD0 and VD1 interrupts for that, not the HS_VS interrupt. Right; I confused the two for a moment. Cheers, -- Sakari Ailus sakari.ailus@iki.fi ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-07-06 16:22 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-07-05 11:22 omap3isp: known causes of "CCDC won't become idle! Jonathan Cameron 2011-07-05 12:19 ` Sakari Ailus 2011-07-05 12:25 ` Laurent Pinchart 2011-07-05 13:48 ` Jonathan Cameron 2011-07-05 14:38 ` Sakari Ailus 2011-07-05 15:02 ` Laurent Pinchart 2011-07-05 15:22 ` Jonathan Cameron 2011-07-05 16:35 ` Jonathan Cameron 2011-07-06 16:30 ` Jonathan Cameron 2011-07-05 16:16 ` Sakari Ailus
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.