OMAP3530 ISP irqs disabled

OMAP3530 ISP irqs disabled

[Bastian Hecht]

Hello ISP team,

I succeeded to stream the first images from the sensor to userspace
using Laurent's media-ctl and yafta. Unfortunately all images are
black (10MB of zeros).
Once by chance I streamed some images (1 of 20 about) with content.
All values were < 0x400, so that I assume the values were correctly
transferred for my 10-bit pixels.

I shortly describe my setup:
As I need xclk_a activated for my sensor to work (I2C), I activate the
xclk in the isp_probe function. Early hack that I want to remove
later.
While I placed my activation in mid of the probe function, I had
somehow the interrupts disabled when trying to stream using yafta. So
I hacked in the reenabling of the interrupts somewhere else in probe()
too.
As I dug through the isp code I saw that it is better to place the
clock activation after the final isp_put in probe() then the
interrupts keep working, but this way I never got a valid picture so
far. It's all a mess, I know. I try to transfer the activation to my
sensor code and board-setup code like in the et8ek8 code.

However... please help me get rid of these zeros! I keep reading
through the ISP and the mt9p031 docs to find some settings that could
have influence on the data sampling. The sensor is working fine now,
so the solution should be somewhere within the isp.

Thank you all,

 Bastian

Re: OMAP3530 ISP irqs disabled

[Bastian Hecht]

2010/11/3 Bastian Hecht <hechtb@googlemail.com>:
> Hello ISP team,
>
> I succeeded to stream the first images from the sensor to userspace
> using Laurent's media-ctl and yafta. Unfortunately all images are
> black (10MB of zeros).
> Once by chance I streamed some images (1 of 20 about) with content.
> All values were < 0x400, so that I assume the values were correctly
> transferred for my 10-bit pixels.
>
> I shortly describe my setup:
> As I need xclk_a activated for my sensor to work (I2C), I activate the
> xclk in the isp_probe function. Early hack that I want to remove
> later.
> While I placed my activation in mid of the probe function, I had
> somehow the interrupts disabled when trying to stream using yafta. So
> I hacked in the reenabling of the interrupts somewhere else in probe()
> too.
> As I dug through the isp code I saw that it is better to place the
> clock activation after the final isp_put in probe() then the
> interrupts keep working, but this way I never got a valid picture so
> far. It's all a mess, I know. I try to transfer the activation to my
> sensor code and board-setup code like in the et8ek8 code.

I enabled isr debugging (#define ISP_ISR_DEBUG) and see that only 1
HS_VS_event is generated per second. 1fps corresponds to my clocking,
so 1 vs per second is fine. But shouldn't I see about 2000 hs
interrupts there too? HS_VS_IRQ is described as "HS or VS synchro
event".

> However... please help me get rid of these zeros! I keep reading
> through the ISP and the mt9p031 docs to find some settings that could
> have influence on the data sampling. The sensor is working fine now,
> so the solution should be somewhere within the isp.
>
> Thank you all,
>
>  Bastian
>

Re: OMAP3530 ISP irqs disabled

[Michael Jones]

Bastian Hecht wrote:
> 
> I enabled isr debugging (#define ISP_ISR_DEBUG) and see that only 1
> HS_VS_event is generated per second. 1fps corresponds to my clocking,
> so 1 vs per second is fine. But shouldn't I see about 2000 hs
> interrupts there too? HS_VS_IRQ is described as "HS or VS synchro
> event".

HS_VS_IRQ is _either_ VS _or_ HS interrupts, but not both.  The SYNC_DETECT bits in ISP_CTRL determines which.  For writing into memory, the ISP only needs to react per frame, not per line, so it is set up to trigger on VS.

-- 
Michael Jones

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Re: OMAP3530 ISP irqs disabled

[Sakari Ailus]

Hi Bastian,

Bastian Hecht wrote:
> 2010/11/3 Bastian Hecht <hechtb@googlemail.com>:
>> Hello ISP team,
>>
>> I succeeded to stream the first images from the sensor to userspace
>> using Laurent's media-ctl and yafta. Unfortunately all images are
>> black (10MB of zeros).
>> Once by chance I streamed some images (1 of 20 about) with content.
>> All values were < 0x400, so that I assume the values were correctly
>> transferred for my 10-bit pixels.
>>
>> I shortly describe my setup:
>> As I need xclk_a activated for my sensor to work (I2C), I activate the
>> xclk in the isp_probe function. Early hack that I want to remove
>> later.

It _might_ be better to have this in isp_get().

>> While I placed my activation in mid of the probe function, I had
>> somehow the interrupts disabled when trying to stream using yafta. So
>> I hacked in the reenabling of the interrupts somewhere else in probe()
>> too.

That should definitely not be necessary. The interrupts are enabled in
isp_get().

>> As I dug through the isp code I saw that it is better to place the
>> clock activation after the final isp_put in probe() then the
>> interrupts keep working, but this way I never got a valid picture so
>> far. It's all a mess, I know. I try to transfer the activation to my
>> sensor code and board-setup code like in the et8ek8 code.
> 
> I enabled isr debugging (#define ISP_ISR_DEBUG) and see that only 1
> HS_VS_event is generated per second. 1fps corresponds to my clocking,
> so 1 vs per second is fine. But shouldn't I see about 2000 hs
> interrupts there too? HS_VS_IRQ is described as "HS or VS synchro
> event".

Are you getting any other interrupts? Basically every ISP block which is
on the pipe will produce interrupts. Which ISP block is writing the
images to memory for you?

>> However... please help me get rid of these zeros! I keep reading
>> through the ISP and the mt9p031 docs to find some settings that could
>> have influence on the data sampling. The sensor is working fine now,
>> so the solution should be somewhere within the isp.

Maybe a stupid question, but have you set exposure and gain to a
reasonable value? :-)

Regards,

-- 
Sakari Ailus
sakari.ailus@maxwell.research.nokia.com

Re: OMAP3530 ISP irqs disabled

[Bastian Hecht]

2010/11/3 Michael Jones <michael.jones@matrix-vision.de>:
> Bastian Hecht wrote:
>>
>> I enabled isr debugging (#define ISP_ISR_DEBUG) and see that only 1
>> HS_VS_event is generated per second. 1fps corresponds to my clocking,
>> so 1 vs per second is fine. But shouldn't I see about 2000 hs
>> interrupts there too? HS_VS_IRQ is described as "HS or VS synchro
>> event".
>
> HS_VS_IRQ is _either_ VS _or_ HS interrupts, but not both.  The SYNC_DETECT bits in ISP_CTRL determines which.  For writing into memory, the ISP only needs to react per frame, not per line, so it is set up to trigger on VS.

OK, I see, thank you. Is there a point in the ccdc code where I can
directly look up what is read from the camera pins cam_d*? All the
signals seem to be fine from the camera, I want to check if this is
true and the problem is in the dma part.

- Bastian

> --
> Michael Jones
> MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
> Registergericht: Amtsgericht Stuttgart, HRB 271090
> Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
>

Re: OMAP3530 ISP irqs disabled

[Bastian Hecht]

2010/11/3 Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>:
> Hi Bastian,
>
> Bastian Hecht wrote:
>> 2010/11/3 Bastian Hecht <hechtb@googlemail.com>:
>>> Hello ISP team,
>>>
>>> I succeeded to stream the first images from the sensor to userspace
>>> using Laurent's media-ctl and yafta. Unfortunately all images are
>>> black (10MB of zeros).
>>> Once by chance I streamed some images (1 of 20 about) with content.
>>> All values were < 0x400, so that I assume the values were correctly
>>> transferred for my 10-bit pixels.
>>>
>>> I shortly describe my setup:
>>> As I need xclk_a activated for my sensor to work (I2C), I activate the
>>> xclk in the isp_probe function. Early hack that I want to remove
>>> later.
>
> It _might_ be better to have this in isp_get().
>
>>> While I placed my activation in mid of the probe function, I had
>>> somehow the interrupts disabled when trying to stream using yafta. So
>>> I hacked in the reenabling of the interrupts somewhere else in probe()
>>> too.
>
> That should definitely not be necessary. The interrupts are enabled in
> isp_get().
>
>>> As I dug through the isp code I saw that it is better to place the
>>> clock activation after the final isp_put in probe() then the
>>> interrupts keep working, but this way I never got a valid picture so
>>> far. It's all a mess, I know. I try to transfer the activation to my
>>> sensor code and board-setup code like in the et8ek8 code.
>>
>> I enabled isr debugging (#define ISP_ISR_DEBUG) and see that only 1
>> HS_VS_event is generated per second. 1fps corresponds to my clocking,
>> so 1 vs per second is fine. But shouldn't I see about 2000 hs
>> interrupts there too? HS_VS_IRQ is described as "HS or VS synchro
>> event".
>
> Are you getting any other interrupts? Basically every ISP block which is
> on the pipe will produce interrupts. Which ISP block is writing the
> images to memory for you?

I read out the CCDC with this pipeline:
./media-ctl -r -l '"mt9p031 2-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3
ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]'
./media-ctl -f '"mt9p031 2-005d":0[SGRBG10 2592x1944], "OMAP3 ISP
CCDC":1[SGRBG10 2592x1944]'
./yavta -f SGRBG10 -s 2592x1944 -n 4 --capture=4 --skip 3 -F /dev/video2

I get these interrupts while reading 4 frames:

[ 3962.689483] s_stream is it! enable: 1
[ 3962.783843] omap3isp omap3isp: CCDC_VD0_IRQ
[ 3962.799530] omap3isp omap3isp: HS_VS_IRQ
[ 3963.532958] omap3isp omap3isp: CCDC_VD1_IRQ
[ 3963.899505] omap3isp omap3isp: CCDC_VD0_IRQ
[ 3963.914184] omap3isp omap3isp: HS_VS_IRQ
[ 3964.647644] omap3isp omap3isp: CCDC_VD1_IRQ
[ 3965.013153] omap3isp omap3isp: CCDC_VD0_IRQ
[ 3965.028839] omap3isp omap3isp: HS_VS_IRQ
[ 3965.762298] omap3isp omap3isp: CCDC_VD1_IRQ
[ 3966.127838] omap3isp omap3isp: CCDC_VD0_IRQ
[ 3966.143585] omap3isp omap3isp: HS_VS_IRQ
[ 3966.370788] omap3isp omap3isp: OMAP3 ISP AEWB: user wants to disable module.
[ 3966.370819] omap3isp omap3isp: OMAP3 ISP AEWB: module is being disabled
[ 3966.370849] omap3isp omap3isp: OMAP3 ISP AF: user wants to disable module.
[ 3966.370880] omap3isp omap3isp: OMAP3 ISP AF: module is being disabled
[ 3966.370880] omap3isp omap3isp: OMAP3 ISP histogram: user wants to
disable module.
[ 3966.370910] omap3isp omap3isp: OMAP3 ISP histogram: module is being disabled
[ 3966.876983] omap3isp omap3isp: CCDC_VD1_IRQ
[ 3967.242492] omap3isp omap3isp: CCDC_VD0_IRQ
[ 3967.242614] s_stream is it! enable: 0

> Maybe a stupid question, but have you set exposure and gain to a
> reasonable value? :-)

First reaction was - that must be it! But hmmm... the flanks on the
data lines of the camera are mostly high. When I press my finger on
the sensor they are mostly low. The other values seem to be good too:
xclk comes in with 6Mhz and pixelclk comes out with 6Mhz (all within
the limits of the datasheets - camera and omap isp). cam_vs raises for
about 1 sec goes shortly down and comes up again. cam_hs seems to fit
too.
Every 20th try I get data from an image sample the other times only zeros.

- Bastian


> Regards,
>
> --
> Sakari Ailus
> sakari.ailus@maxwell.research.nokia.com
>

Re: OMAP3530 ISP irqs disabled

[Laurent Pinchart]

Hi Bastian,

On Wednesday 03 November 2010 14:26:26 Bastian Hecht wrote:
> 2010/11/3 Michael Jones <michael.jones@matrix-vision.de>:
> > Bastian Hecht wrote:
> >> I enabled isr debugging (#define ISP_ISR_DEBUG) and see that only 1
> >> HS_VS_event is generated per second. 1fps corresponds to my clocking,
> >> so 1 vs per second is fine. But shouldn't I see about 2000 hs
> >> interrupts there too? HS_VS_IRQ is described as "HS or VS synchro
> >> event".
> > 
> > HS_VS_IRQ is _either_ VS _or_ HS interrupts, but not both.  The
> > SYNC_DETECT bits in ISP_CTRL determines which.  For writing into memory,
> > the ISP only needs to react per frame, not per line, so it is set up to
> > trigger on VS.
> 
> OK, I see, thank you. Is there a point in the ccdc code where I can
> directly look up what is read from the camera pins cam_d*? All the
> signals seem to be fine from the camera, I want to check if this is
> true and the problem is in the dma part.

No, the signals are not accessible directly in the ISP. What you could do, 
however, is read them as GPIOs.

-- 
Regards,

Laurent Pinchart

Re: OMAP3530 ISP irqs disabled

[Laurent Pinchart]

Hi Bastian,

On Wednesday 03 November 2010 14:38:25 Bastian Hecht wrote:
> 2010/11/3 Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>:
> > Bastian Hecht wrote:
> >> 2010/11/3 Bastian Hecht <hechtb@googlemail.com>:
> >>> Hello ISP team,
> >>> 
> >>> I succeeded to stream the first images from the sensor to userspace
> >>> using Laurent's media-ctl and yafta. Unfortunately all images are
> >>> black (10MB of zeros).
> >>> Once by chance I streamed some images (1 of 20 about) with content.
> >>> All values were < 0x400, so that I assume the values were correctly
> >>> transferred for my 10-bit pixels.
> >>> 
> >>> I shortly describe my setup:
> >>> As I need xclk_a activated for my sensor to work (I2C), I activate the
> >>> xclk in the isp_probe function. Early hack that I want to remove
> >>> later.
> > 
> > It _might_ be better to have this in isp_get().
> > 
> >>> While I placed my activation in mid of the probe function, I had
> >>> somehow the interrupts disabled when trying to stream using yafta. So
> >>> I hacked in the reenabling of the interrupts somewhere else in probe()
> >>> too.
> > 
> > That should definitely not be necessary. The interrupts are enabled in
> > isp_get().
> > 
> >>> As I dug through the isp code I saw that it is better to place the
> >>> clock activation after the final isp_put in probe() then the
> >>> interrupts keep working, but this way I never got a valid picture so
> >>> far. It's all a mess, I know. I try to transfer the activation to my
> >>> sensor code and board-setup code like in the et8ek8 code.
> >> 
> >> I enabled isr debugging (#define ISP_ISR_DEBUG) and see that only 1
> >> HS_VS_event is generated per second. 1fps corresponds to my clocking,
> >> so 1 vs per second is fine. But shouldn't I see about 2000 hs
> >> interrupts there too? HS_VS_IRQ is described as "HS or VS synchro
> >> event".
> > 
> > Are you getting any other interrupts? Basically every ISP block which is
> > on the pipe will produce interrupts. Which ISP block is writing the
> > images to memory for you?
> 
> I read out the CCDC with this pipeline:
> ./media-ctl -r -l '"mt9p031 2-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3
> ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]'
> ./media-ctl -f '"mt9p031 2-005d":0[SGRBG10 2592x1944], "OMAP3 ISP
> CCDC":1[SGRBG10 2592x1944]'
> ./yavta -f SGRBG10 -s 2592x1944 -n 4 --capture=4 --skip 3 -F /dev/video2
> 
> I get these interrupts while reading 4 frames:
> 
> [ 3962.689483] s_stream is it! enable: 1
> [ 3962.783843] omap3isp omap3isp: CCDC_VD0_IRQ
> [ 3962.799530] omap3isp omap3isp: HS_VS_IRQ
> [ 3963.532958] omap3isp omap3isp: CCDC_VD1_IRQ
> [ 3963.899505] omap3isp omap3isp: CCDC_VD0_IRQ
> [ 3963.914184] omap3isp omap3isp: HS_VS_IRQ
> [ 3964.647644] omap3isp omap3isp: CCDC_VD1_IRQ
> [ 3965.013153] omap3isp omap3isp: CCDC_VD0_IRQ
> [ 3965.028839] omap3isp omap3isp: HS_VS_IRQ
> [ 3965.762298] omap3isp omap3isp: CCDC_VD1_IRQ
> [ 3966.127838] omap3isp omap3isp: CCDC_VD0_IRQ
> [ 3966.143585] omap3isp omap3isp: HS_VS_IRQ
> [ 3966.370788] omap3isp omap3isp: OMAP3 ISP AEWB: user wants to disable
> module. [ 3966.370819] omap3isp omap3isp: OMAP3 ISP AEWB: module is being
> disabled [ 3966.370849] omap3isp omap3isp: OMAP3 ISP AF: user wants to
> disable module. [ 3966.370880] omap3isp omap3isp: OMAP3 ISP AF: module is
> being disabled [ 3966.370880] omap3isp omap3isp: OMAP3 ISP histogram: user
> wants to disable module.
> [ 3966.370910] omap3isp omap3isp: OMAP3 ISP histogram: module is being
> disabled [ 3966.876983] omap3isp omap3isp: CCDC_VD1_IRQ
> [ 3967.242492] omap3isp omap3isp: CCDC_VD0_IRQ
> [ 3967.242614] s_stream is it! enable: 0
> 
> > Maybe a stupid question, but have you set exposure and gain to a
> > reasonable value? :-)
> 
> First reaction was - that must be it! But hmmm... the flanks on the
> data lines of the camera are mostly high. When I press my finger on
> the sensor they are mostly low. The other values seem to be good too:
> xclk comes in with 6Mhz and pixelclk comes out with 6Mhz (all within
> the limits of the datasheets - camera and omap isp). cam_vs raises for
> about 1 sec goes shortly down and comes up again. cam_hs seems to fit
> too.
> Every 20th try I get data from an image sample the other times only zeros.

The CCDC is configured with a DC subtract value of 64 by default, so it 
subtract 64 from every pixel. If your pixel values are lower than or equal to 
64 you will get a black image. As a quick hack you can replace

ccdc->clamp.dcsubval = 64;

with

ccdc->clamp.dcsubval = 0;

in isp_ccdc_init(). The correct solution is to use the 
VIDIOC_PRIVATE_ISP_CCDC_CFG ioctl to configure the DC subtraction value to 0.

-- 
Regards,

Laurent Pinchart

Re: OMAP3530 ISP irqs disabled

[Bastian Hecht]

2010/11/4 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> Hi Bastian,
>
> On Wednesday 03 November 2010 14:38:25 Bastian Hecht wrote:
>> 2010/11/3 Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>:
>> > Bastian Hecht wrote:
>> >> 2010/11/3 Bastian Hecht <hechtb@googlemail.com>:
>> >>> Hello ISP team,
>> >>>
>> >>> I succeeded to stream the first images from the sensor to userspace
>> >>> using Laurent's media-ctl and yafta. Unfortunately all images are
>> >>> black (10MB of zeros).
>> >>> Once by chance I streamed some images (1 of 20 about) with content.
>> >>> All values were < 0x400, so that I assume the values were correctly
>> >>> transferred for my 10-bit pixels.
>> >>>
>> >>> I shortly describe my setup:
>> >>> As I need xclk_a activated for my sensor to work (I2C), I activate the
>> >>> xclk in the isp_probe function. Early hack that I want to remove
>> >>> later.
>> >
>> > It _might_ be better to have this in isp_get().
>> >
>> >>> While I placed my activation in mid of the probe function, I had
>> >>> somehow the interrupts disabled when trying to stream using yafta. So
>> >>> I hacked in the reenabling of the interrupts somewhere else in probe()
>> >>> too.
>> >
>> > That should definitely not be necessary. The interrupts are enabled in
>> > isp_get().
>> >
>> >>> As I dug through the isp code I saw that it is better to place the
>> >>> clock activation after the final isp_put in probe() then the
>> >>> interrupts keep working, but this way I never got a valid picture so
>> >>> far. It's all a mess, I know. I try to transfer the activation to my
>> >>> sensor code and board-setup code like in the et8ek8 code.
>> >>
>> >> I enabled isr debugging (#define ISP_ISR_DEBUG) and see that only 1
>> >> HS_VS_event is generated per second. 1fps corresponds to my clocking,
>> >> so 1 vs per second is fine. But shouldn't I see about 2000 hs
>> >> interrupts there too? HS_VS_IRQ is described as "HS or VS synchro
>> >> event".
>> >
>> > Are you getting any other interrupts? Basically every ISP block which is
>> > on the pipe will produce interrupts. Which ISP block is writing the
>> > images to memory for you?
>>
>> I read out the CCDC with this pipeline:
>> ./media-ctl -r -l '"mt9p031 2-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3
>> ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]'
>> ./media-ctl -f '"mt9p031 2-005d":0[SGRBG10 2592x1944], "OMAP3 ISP
>> CCDC":1[SGRBG10 2592x1944]'
>> ./yavta -f SGRBG10 -s 2592x1944 -n 4 --capture=4 --skip 3 -F /dev/video2
>>
>> I get these interrupts while reading 4 frames:
>>
>> [ 3962.689483] s_stream is it! enable: 1
>> [ 3962.783843] omap3isp omap3isp: CCDC_VD0_IRQ
>> [ 3962.799530] omap3isp omap3isp: HS_VS_IRQ
>> [ 3963.532958] omap3isp omap3isp: CCDC_VD1_IRQ
>> [ 3963.899505] omap3isp omap3isp: CCDC_VD0_IRQ
>> [ 3963.914184] omap3isp omap3isp: HS_VS_IRQ
>> [ 3964.647644] omap3isp omap3isp: CCDC_VD1_IRQ
>> [ 3965.013153] omap3isp omap3isp: CCDC_VD0_IRQ
>> [ 3965.028839] omap3isp omap3isp: HS_VS_IRQ
>> [ 3965.762298] omap3isp omap3isp: CCDC_VD1_IRQ
>> [ 3966.127838] omap3isp omap3isp: CCDC_VD0_IRQ
>> [ 3966.143585] omap3isp omap3isp: HS_VS_IRQ
>> [ 3966.370788] omap3isp omap3isp: OMAP3 ISP AEWB: user wants to disable
>> module. [ 3966.370819] omap3isp omap3isp: OMAP3 ISP AEWB: module is being
>> disabled [ 3966.370849] omap3isp omap3isp: OMAP3 ISP AF: user wants to
>> disable module. [ 3966.370880] omap3isp omap3isp: OMAP3 ISP AF: module is
>> being disabled [ 3966.370880] omap3isp omap3isp: OMAP3 ISP histogram: user
>> wants to disable module.
>> [ 3966.370910] omap3isp omap3isp: OMAP3 ISP histogram: module is being
>> disabled [ 3966.876983] omap3isp omap3isp: CCDC_VD1_IRQ
>> [ 3967.242492] omap3isp omap3isp: CCDC_VD0_IRQ
>> [ 3967.242614] s_stream is it! enable: 0
>>
>> > Maybe a stupid question, but have you set exposure and gain to a
>> > reasonable value? :-)
>>
>> First reaction was - that must be it! But hmmm... the flanks on the
>> data lines of the camera are mostly high. When I press my finger on
>> the sensor they are mostly low. The other values seem to be good too:
>> xclk comes in with 6Mhz and pixelclk comes out with 6Mhz (all within
>> the limits of the datasheets - camera and omap isp). cam_vs raises for
>> about 1 sec goes shortly down and comes up again. cam_hs seems to fit
>> too.
>> Every 20th try I get data from an image sample the other times only zeros.
>
> The CCDC is configured with a DC subtract value of 64 by default, so it
> subtract 64 from every pixel. If your pixel values are lower than or equal to
> 64 you will get a black image. As a quick hack you can replace
>
> ccdc->clamp.dcsubval = 64;
>
> with
>
> ccdc->clamp.dcsubval = 0;
>
> in isp_ccdc_init(). The correct solution is to use the
> VIDIOC_PRIVATE_ISP_CCDC_CFG ioctl to configure the DC subtraction value to 0.

This is not the problem. The 64 reduction is a nice hint as I was
wondering why I get 0x3BF when the sensor is full in light and I was
lucky and a frame was read. I wondered why it is not 0x3FF - all 10
bits high. When I slightly press my finger on it I get about
0x045-0x1bf. So the sensor values seem to be ok. The values fill the
whole 10MB image.

Can you give me an other media-ctl setup, so that I can read jpegs
from the preview unit, please?

I want to follow 3 leads now:

- replace my igep with another one
- check if the isp (code) works better with preview data
- I want to check yafta

Thank you,

 Bastian

Re: OMAP3530 ISP irqs disabled

[Bastian Hecht]

2010/11/4 Bastian Hecht <hechtb@googlemail.com>:
> 2010/11/4 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
>> Hi Bastian,
>>
>> On Wednesday 03 November 2010 14:38:25 Bastian Hecht wrote:
>>> 2010/11/3 Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>:
>>> > Bastian Hecht wrote:
>>> >> 2010/11/3 Bastian Hecht <hechtb@googlemail.com>:
>>> >>> Hello ISP team,
>>> >>>
>>> >>> I succeeded to stream the first images from the sensor to userspace
>>> >>> using Laurent's media-ctl and yafta. Unfortunately all images are
>>> >>> black (10MB of zeros).
>>> >>> Once by chance I streamed some images (1 of 20 about) with content.
>>> >>> All values were < 0x400, so that I assume the values were correctly
>>> >>> transferred for my 10-bit pixels.
>>> >>>
>>> >>> I shortly describe my setup:
>>> >>> As I need xclk_a activated for my sensor to work (I2C), I activate the
>>> >>> xclk in the isp_probe function. Early hack that I want to remove
>>> >>> later.
>>> >
>>> > It _might_ be better to have this in isp_get().
>>> >
>>> >>> While I placed my activation in mid of the probe function, I had
>>> >>> somehow the interrupts disabled when trying to stream using yafta. So
>>> >>> I hacked in the reenabling of the interrupts somewhere else in probe()
>>> >>> too.
>>> >
>>> > That should definitely not be necessary. The interrupts are enabled in
>>> > isp_get().
>>> >
>>> >>> As I dug through the isp code I saw that it is better to place the
>>> >>> clock activation after the final isp_put in probe() then the
>>> >>> interrupts keep working, but this way I never got a valid picture so
>>> >>> far. It's all a mess, I know. I try to transfer the activation to my
>>> >>> sensor code and board-setup code like in the et8ek8 code.
>>> >>
>>> >> I enabled isr debugging (#define ISP_ISR_DEBUG) and see that only 1
>>> >> HS_VS_event is generated per second. 1fps corresponds to my clocking,
>>> >> so 1 vs per second is fine. But shouldn't I see about 2000 hs
>>> >> interrupts there too? HS_VS_IRQ is described as "HS or VS synchro
>>> >> event".
>>> >
>>> > Are you getting any other interrupts? Basically every ISP block which is
>>> > on the pipe will produce interrupts. Which ISP block is writing the
>>> > images to memory for you?
>>>
>>> I read out the CCDC with this pipeline:
>>> ./media-ctl -r -l '"mt9p031 2-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3
>>> ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]'
>>> ./media-ctl -f '"mt9p031 2-005d":0[SGRBG10 2592x1944], "OMAP3 ISP
>>> CCDC":1[SGRBG10 2592x1944]'
>>> ./yavta -f SGRBG10 -s 2592x1944 -n 4 --capture=4 --skip 3 -F /dev/video2
>>>
>>> I get these interrupts while reading 4 frames:
>>>
>>> [ 3962.689483] s_stream is it! enable: 1
>>> [ 3962.783843] omap3isp omap3isp: CCDC_VD0_IRQ
>>> [ 3962.799530] omap3isp omap3isp: HS_VS_IRQ
>>> [ 3963.532958] omap3isp omap3isp: CCDC_VD1_IRQ
>>> [ 3963.899505] omap3isp omap3isp: CCDC_VD0_IRQ
>>> [ 3963.914184] omap3isp omap3isp: HS_VS_IRQ
>>> [ 3964.647644] omap3isp omap3isp: CCDC_VD1_IRQ
>>> [ 3965.013153] omap3isp omap3isp: CCDC_VD0_IRQ
>>> [ 3965.028839] omap3isp omap3isp: HS_VS_IRQ
>>> [ 3965.762298] omap3isp omap3isp: CCDC_VD1_IRQ
>>> [ 3966.127838] omap3isp omap3isp: CCDC_VD0_IRQ
>>> [ 3966.143585] omap3isp omap3isp: HS_VS_IRQ
>>> [ 3966.370788] omap3isp omap3isp: OMAP3 ISP AEWB: user wants to disable
>>> module. [ 3966.370819] omap3isp omap3isp: OMAP3 ISP AEWB: module is being
>>> disabled [ 3966.370849] omap3isp omap3isp: OMAP3 ISP AF: user wants to
>>> disable module. [ 3966.370880] omap3isp omap3isp: OMAP3 ISP AF: module is
>>> being disabled [ 3966.370880] omap3isp omap3isp: OMAP3 ISP histogram: user
>>> wants to disable module.
>>> [ 3966.370910] omap3isp omap3isp: OMAP3 ISP histogram: module is being
>>> disabled [ 3966.876983] omap3isp omap3isp: CCDC_VD1_IRQ
>>> [ 3967.242492] omap3isp omap3isp: CCDC_VD0_IRQ
>>> [ 3967.242614] s_stream is it! enable: 0
>>>
>>> > Maybe a stupid question, but have you set exposure and gain to a
>>> > reasonable value? :-)
>>>
>>> First reaction was - that must be it! But hmmm... the flanks on the
>>> data lines of the camera are mostly high. When I press my finger on
>>> the sensor they are mostly low. The other values seem to be good too:
>>> xclk comes in with 6Mhz and pixelclk comes out with 6Mhz (all within
>>> the limits of the datasheets - camera and omap isp). cam_vs raises for
>>> about 1 sec goes shortly down and comes up again. cam_hs seems to fit
>>> too.
>>> Every 20th try I get data from an image sample the other times only zeros.
>>
>> The CCDC is configured with a DC subtract value of 64 by default, so it
>> subtract 64 from every pixel. If your pixel values are lower than or equal to
>> 64 you will get a black image. As a quick hack you can replace
>>
>> ccdc->clamp.dcsubval = 64;
>>
>> with
>>
>> ccdc->clamp.dcsubval = 0;
>>
>> in isp_ccdc_init(). The correct solution is to use the
>> VIDIOC_PRIVATE_ISP_CCDC_CFG ioctl to configure the DC subtraction value to 0.
>
> This is not the problem. The 64 reduction is a nice hint as I was
> wondering why I get 0x3BF when the sensor is full in light and I was
> lucky and a frame was read. I wondered why it is not 0x3FF - all 10
> bits high. When I slightly press my finger on it I get about
> 0x045-0x1bf. So the sensor values seem to be ok. The values fill the
> whole 10MB image.

I want to clarify this:

I try to read images with yafta.
I read in 4 images with 5MP size (no skipping). All 4 images contain only zeros.
I repeat the process some times and keep checking the data. After -
let's say the 6th time - the images contain exactly the data I expect.
WHEN they are read they are good. I just don't want to read 20 black
images before 1 image is transferred right.

-Bastian


> Can you give me an other media-ctl setup, so that I can read jpegs
> from the preview unit, please?
>
> I want to follow 3 leads now:
>
> - replace my igep with another one
> - check if the isp (code) works better with preview data
> - I want to check yafta
>
> Thank you,
>
>  Bastian
>

Re: OMAP3530 ISP irqs disabled

[Bastian Hecht]

Hello all,

I got it now!!!
After adding debugfs support and observing my isp like a lynx I found
out that magically the ISP_CTRL register changes from
[  316.903900] omap3isp omap3isp: ###ISP CTRL=0x00200000  to
0x0020c040  after an successful image read :-)

This is the shift configuration that should never be touched and the
syn_detect register that changes from "trigger interrupts on HS
falling edge" to "VS rising edge".
I saw that the these registers get written in the ccdc_configure ->
isp_configure_bridge -> write_regs.

Let's see if I can find out the concrete bug location.

cheers,

 Bastian


2010/11/4 Bastian Hecht <hechtb@googlemail.com>:
> 2010/11/4 Bastian Hecht <hechtb@googlemail.com>:
>> 2010/11/4 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
>>> Hi Bastian,
>>>
>>> On Wednesday 03 November 2010 14:38:25 Bastian Hecht wrote:
>>>> 2010/11/3 Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>:
>>>> > Bastian Hecht wrote:
>>>> >> 2010/11/3 Bastian Hecht <hechtb@googlemail.com>:
>>>> >>> Hello ISP team,
>>>> >>>
>>>> >>> I succeeded to stream the first images from the sensor to userspace
>>>> >>> using Laurent's media-ctl and yafta. Unfortunately all images are
>>>> >>> black (10MB of zeros).
>>>> >>> Once by chance I streamed some images (1 of 20 about) with content.
>>>> >>> All values were < 0x400, so that I assume the values were correctly
>>>> >>> transferred for my 10-bit pixels.
>>>> >>>
>>>> >>> I shortly describe my setup:
>>>> >>> As I need xclk_a activated for my sensor to work (I2C), I activate the
>>>> >>> xclk in the isp_probe function. Early hack that I want to remove
>>>> >>> later.
>>>> >
>>>> > It _might_ be better to have this in isp_get().
>>>> >
>>>> >>> While I placed my activation in mid of the probe function, I had
>>>> >>> somehow the interrupts disabled when trying to stream using yafta. So
>>>> >>> I hacked in the reenabling of the interrupts somewhere else in probe()
>>>> >>> too.
>>>> >
>>>> > That should definitely not be necessary. The interrupts are enabled in
>>>> > isp_get().
>>>> >
>>>> >>> As I dug through the isp code I saw that it is better to place the
>>>> >>> clock activation after the final isp_put in probe() then the
>>>> >>> interrupts keep working, but this way I never got a valid picture so
>>>> >>> far. It's all a mess, I know. I try to transfer the activation to my
>>>> >>> sensor code and board-setup code like in the et8ek8 code.
>>>> >>
>>>> >> I enabled isr debugging (#define ISP_ISR_DEBUG) and see that only 1
>>>> >> HS_VS_event is generated per second. 1fps corresponds to my clocking,
>>>> >> so 1 vs per second is fine. But shouldn't I see about 2000 hs
>>>> >> interrupts there too? HS_VS_IRQ is described as "HS or VS synchro
>>>> >> event".
>>>> >
>>>> > Are you getting any other interrupts? Basically every ISP block which is
>>>> > on the pipe will produce interrupts. Which ISP block is writing the
>>>> > images to memory for you?
>>>>
>>>> I read out the CCDC with this pipeline:
>>>> ./media-ctl -r -l '"mt9p031 2-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3
>>>> ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]'
>>>> ./media-ctl -f '"mt9p031 2-005d":0[SGRBG10 2592x1944], "OMAP3 ISP
>>>> CCDC":1[SGRBG10 2592x1944]'
>>>> ./yavta -f SGRBG10 -s 2592x1944 -n 4 --capture=4 --skip 3 -F /dev/video2
>>>>
>>>> I get these interrupts while reading 4 frames:
>>>>
>>>> [ 3962.689483] s_stream is it! enable: 1
>>>> [ 3962.783843] omap3isp omap3isp: CCDC_VD0_IRQ
>>>> [ 3962.799530] omap3isp omap3isp: HS_VS_IRQ
>>>> [ 3963.532958] omap3isp omap3isp: CCDC_VD1_IRQ
>>>> [ 3963.899505] omap3isp omap3isp: CCDC_VD0_IRQ
>>>> [ 3963.914184] omap3isp omap3isp: HS_VS_IRQ
>>>> [ 3964.647644] omap3isp omap3isp: CCDC_VD1_IRQ
>>>> [ 3965.013153] omap3isp omap3isp: CCDC_VD0_IRQ
>>>> [ 3965.028839] omap3isp omap3isp: HS_VS_IRQ
>>>> [ 3965.762298] omap3isp omap3isp: CCDC_VD1_IRQ
>>>> [ 3966.127838] omap3isp omap3isp: CCDC_VD0_IRQ
>>>> [ 3966.143585] omap3isp omap3isp: HS_VS_IRQ
>>>> [ 3966.370788] omap3isp omap3isp: OMAP3 ISP AEWB: user wants to disable
>>>> module. [ 3966.370819] omap3isp omap3isp: OMAP3 ISP AEWB: module is being
>>>> disabled [ 3966.370849] omap3isp omap3isp: OMAP3 ISP AF: user wants to
>>>> disable module. [ 3966.370880] omap3isp omap3isp: OMAP3 ISP AF: module is
>>>> being disabled [ 3966.370880] omap3isp omap3isp: OMAP3 ISP histogram: user
>>>> wants to disable module.
>>>> [ 3966.370910] omap3isp omap3isp: OMAP3 ISP histogram: module is being
>>>> disabled [ 3966.876983] omap3isp omap3isp: CCDC_VD1_IRQ
>>>> [ 3967.242492] omap3isp omap3isp: CCDC_VD0_IRQ
>>>> [ 3967.242614] s_stream is it! enable: 0
>>>>
>>>> > Maybe a stupid question, but have you set exposure and gain to a
>>>> > reasonable value? :-)
>>>>
>>>> First reaction was - that must be it! But hmmm... the flanks on the
>>>> data lines of the camera are mostly high. When I press my finger on
>>>> the sensor they are mostly low. The other values seem to be good too:
>>>> xclk comes in with 6Mhz and pixelclk comes out with 6Mhz (all within
>>>> the limits of the datasheets - camera and omap isp). cam_vs raises for
>>>> about 1 sec goes shortly down and comes up again. cam_hs seems to fit
>>>> too.
>>>> Every 20th try I get data from an image sample the other times only zeros.
>>>
>>> The CCDC is configured with a DC subtract value of 64 by default, so it
>>> subtract 64 from every pixel. If your pixel values are lower than or equal to
>>> 64 you will get a black image. As a quick hack you can replace
>>>
>>> ccdc->clamp.dcsubval = 64;
>>>
>>> with
>>>
>>> ccdc->clamp.dcsubval = 0;
>>>
>>> in isp_ccdc_init(). The correct solution is to use the
>>> VIDIOC_PRIVATE_ISP_CCDC_CFG ioctl to configure the DC subtraction value to 0.
>>
>> This is not the problem. The 64 reduction is a nice hint as I was
>> wondering why I get 0x3BF when the sensor is full in light and I was
>> lucky and a frame was read. I wondered why it is not 0x3FF - all 10
>> bits high. When I slightly press my finger on it I get about
>> 0x045-0x1bf. So the sensor values seem to be ok. The values fill the
>> whole 10MB image.
>
> I want to clarify this:
>
> I try to read images with yafta.
> I read in 4 images with 5MP size (no skipping). All 4 images contain only zeros.
> I repeat the process some times and keep checking the data. After -
> let's say the 6th time - the images contain exactly the data I expect.
> WHEN they are read they are good. I just don't want to read 20 black
> images before 1 image is transferred right.
>
> -Bastian
>
>
>> Can you give me an other media-ctl setup, so that I can read jpegs
>> from the preview unit, please?
>>
>> I want to follow 3 leads now:
>>
>> - replace my igep with another one
>> - check if the isp (code) works better with preview data
>> - I want to check yafta
>>
>> Thank you,
>>
>>  Bastian
>>
>

Re: OMAP3530 ISP irqs disabled

[Bastian Hecht]

2010/11/5 Bastian Hecht <hechtb@googlemail.com>:
> Hello all,
>
> I got it now!!!
> After adding debugfs support and observing my isp like a lynx I found
> out that magically the ISP_CTRL register changes from
> [  316.903900] omap3isp omap3isp: ###ISP CTRL=0x00200000  to
> 0x0020c040  after an successful image read :-)

Sorry false alarm... the bridge gets configured correctly for my 12-
to 10-bit shift and the isp listens for VS for frame starts. It just
was 0x00200000 after reset and had to be set correctly.

> This is the shift configuration that should never be touched and the
> syn_detect register that changes from "trigger interrupts on HS
> falling edge" to "VS rising edge".
> I saw that the these registers get written in the ccdc_configure ->
> isp_configure_bridge -> write_regs.
>
> Let's see if I can find out the concrete bug location.
>
> cheers,
>
>  Bastian
>
>
> 2010/11/4 Bastian Hecht <hechtb@googlemail.com>:
>> 2010/11/4 Bastian Hecht <hechtb@googlemail.com>:
>>> 2010/11/4 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
>>>> Hi Bastian,
>>>>
>>>> On Wednesday 03 November 2010 14:38:25 Bastian Hecht wrote:
>>>>> 2010/11/3 Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>:
>>>>> > Bastian Hecht wrote:
>>>>> >> 2010/11/3 Bastian Hecht <hechtb@googlemail.com>:
>>>>> >>> Hello ISP team,
>>>>> >>>
>>>>> >>> I succeeded to stream the first images from the sensor to userspace
>>>>> >>> using Laurent's media-ctl and yafta. Unfortunately all images are
>>>>> >>> black (10MB of zeros).
>>>>> >>> Once by chance I streamed some images (1 of 20 about) with content.
>>>>> >>> All values were < 0x400, so that I assume the values were correctly
>>>>> >>> transferred for my 10-bit pixels.
>>>>> >>>
>>>>> >>> I shortly describe my setup:
>>>>> >>> As I need xclk_a activated for my sensor to work (I2C), I activate the
>>>>> >>> xclk in the isp_probe function. Early hack that I want to remove
>>>>> >>> later.
>>>>> >
>>>>> > It _might_ be better to have this in isp_get().
>>>>> >
>>>>> >>> While I placed my activation in mid of the probe function, I had
>>>>> >>> somehow the interrupts disabled when trying to stream using yafta. So
>>>>> >>> I hacked in the reenabling of the interrupts somewhere else in probe()
>>>>> >>> too.
>>>>> >
>>>>> > That should definitely not be necessary. The interrupts are enabled in
>>>>> > isp_get().
>>>>> >
>>>>> >>> As I dug through the isp code I saw that it is better to place the
>>>>> >>> clock activation after the final isp_put in probe() then the
>>>>> >>> interrupts keep working, but this way I never got a valid picture so
>>>>> >>> far. It's all a mess, I know. I try to transfer the activation to my
>>>>> >>> sensor code and board-setup code like in the et8ek8 code.
>>>>> >>
>>>>> >> I enabled isr debugging (#define ISP_ISR_DEBUG) and see that only 1
>>>>> >> HS_VS_event is generated per second. 1fps corresponds to my clocking,
>>>>> >> so 1 vs per second is fine. But shouldn't I see about 2000 hs
>>>>> >> interrupts there too? HS_VS_IRQ is described as "HS or VS synchro
>>>>> >> event".
>>>>> >
>>>>> > Are you getting any other interrupts? Basically every ISP block which is
>>>>> > on the pipe will produce interrupts. Which ISP block is writing the
>>>>> > images to memory for you?
>>>>>
>>>>> I read out the CCDC with this pipeline:
>>>>> ./media-ctl -r -l '"mt9p031 2-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3
>>>>> ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]'
>>>>> ./media-ctl -f '"mt9p031 2-005d":0[SGRBG10 2592x1944], "OMAP3 ISP
>>>>> CCDC":1[SGRBG10 2592x1944]'
>>>>> ./yavta -f SGRBG10 -s 2592x1944 -n 4 --capture=4 --skip 3 -F /dev/video2
>>>>>
>>>>> I get these interrupts while reading 4 frames:
>>>>>
>>>>> [ 3962.689483] s_stream is it! enable: 1
>>>>> [ 3962.783843] omap3isp omap3isp: CCDC_VD0_IRQ
>>>>> [ 3962.799530] omap3isp omap3isp: HS_VS_IRQ
>>>>> [ 3963.532958] omap3isp omap3isp: CCDC_VD1_IRQ
>>>>> [ 3963.899505] omap3isp omap3isp: CCDC_VD0_IRQ
>>>>> [ 3963.914184] omap3isp omap3isp: HS_VS_IRQ
>>>>> [ 3964.647644] omap3isp omap3isp: CCDC_VD1_IRQ
>>>>> [ 3965.013153] omap3isp omap3isp: CCDC_VD0_IRQ
>>>>> [ 3965.028839] omap3isp omap3isp: HS_VS_IRQ
>>>>> [ 3965.762298] omap3isp omap3isp: CCDC_VD1_IRQ
>>>>> [ 3966.127838] omap3isp omap3isp: CCDC_VD0_IRQ
>>>>> [ 3966.143585] omap3isp omap3isp: HS_VS_IRQ
>>>>> [ 3966.370788] omap3isp omap3isp: OMAP3 ISP AEWB: user wants to disable
>>>>> module. [ 3966.370819] omap3isp omap3isp: OMAP3 ISP AEWB: module is being
>>>>> disabled [ 3966.370849] omap3isp omap3isp: OMAP3 ISP AF: user wants to
>>>>> disable module. [ 3966.370880] omap3isp omap3isp: OMAP3 ISP AF: module is
>>>>> being disabled [ 3966.370880] omap3isp omap3isp: OMAP3 ISP histogram: user
>>>>> wants to disable module.
>>>>> [ 3966.370910] omap3isp omap3isp: OMAP3 ISP histogram: module is being
>>>>> disabled [ 3966.876983] omap3isp omap3isp: CCDC_VD1_IRQ
>>>>> [ 3967.242492] omap3isp omap3isp: CCDC_VD0_IRQ
>>>>> [ 3967.242614] s_stream is it! enable: 0
>>>>>
>>>>> > Maybe a stupid question, but have you set exposure and gain to a
>>>>> > reasonable value? :-)
>>>>>
>>>>> First reaction was - that must be it! But hmmm... the flanks on the
>>>>> data lines of the camera are mostly high. When I press my finger on
>>>>> the sensor they are mostly low. The other values seem to be good too:
>>>>> xclk comes in with 6Mhz and pixelclk comes out with 6Mhz (all within
>>>>> the limits of the datasheets - camera and omap isp). cam_vs raises for
>>>>> about 1 sec goes shortly down and comes up again. cam_hs seems to fit
>>>>> too.
>>>>> Every 20th try I get data from an image sample the other times only zeros.
>>>>
>>>> The CCDC is configured with a DC subtract value of 64 by default, so it
>>>> subtract 64 from every pixel. If your pixel values are lower than or equal to
>>>> 64 you will get a black image. As a quick hack you can replace
>>>>
>>>> ccdc->clamp.dcsubval = 64;
>>>>
>>>> with
>>>>
>>>> ccdc->clamp.dcsubval = 0;
>>>>
>>>> in isp_ccdc_init(). The correct solution is to use the
>>>> VIDIOC_PRIVATE_ISP_CCDC_CFG ioctl to configure the DC subtraction value to 0.
>>>
>>> This is not the problem. The 64 reduction is a nice hint as I was
>>> wondering why I get 0x3BF when the sensor is full in light and I was
>>> lucky and a frame was read. I wondered why it is not 0x3FF - all 10
>>> bits high. When I slightly press my finger on it I get about
>>> 0x045-0x1bf. So the sensor values seem to be ok. The values fill the
>>> whole 10MB image.
>>
>> I want to clarify this:
>>
>> I try to read images with yafta.
>> I read in 4 images with 5MP size (no skipping). All 4 images contain only zeros.
>> I repeat the process some times and keep checking the data. After -
>> let's say the 6th time - the images contain exactly the data I expect.
>> WHEN they are read they are good. I just don't want to read 20 black
>> images before 1 image is transferred right.
>>
>> -Bastian
>>
>>
>>> Can you give me an other media-ctl setup, so that I can read jpegs
>>> from the preview unit, please?
>>>
>>> I want to follow 3 leads now:
>>>
>>> - replace my igep with another one
>>> - check if the isp (code) works better with preview data
>>> - I want to check yafta
>>>
>>> Thank you,
>>>
>>>  Bastian
>>>
>>
>

Re: OMAP3530 ISP irqs disabled

[Michael Jones]

Hi Bastian (Laurent, and Sakari),
> 
> I want to clarify this:
> 
> I try to read images with yafta.
> I read in 4 images with 5MP size (no skipping). All 4 images contain only zeros.
> I repeat the process some times and keep checking the data. After -
> let's say the 6th time - the images contain exactly the data I expect.
> WHEN they are read they are good. I just don't want to read 20 black
> images before 1 image is transferred right.
> 
> -Bastian
> 

I'm on to your problem, having reproduced it myself.  I suspect that you're actually only getting one frame: your very first buffer.  You don't touch it, and neither does the CCDC after you requeue it, and after you've cycled through all your other buffers, you get back the non-zero frame.  If you clear the "good" frame in your application once, you won't get any more non-zero frames afterwards.  Or if you request more buffers, you'll have fewer non-zero frames.  That's the behavior I observe.

The CCDC is getting disabled by the VD1 interrupt:
ispccdc_vd1_isr()->__ispccdc_handle_stopping()->__ispccdc_enable(ccdc, 0)

To test this theory I tried disabling the VD1 interrupt, but it didn't solve the problem.  In fact, I was still getting VD1 interrupts even though I had disabled them.  Has anybody else observed that VD1 cannot be disabled?

I also found it strange that the CCDC seemed to continue to generate interrupts when it's disabled.

Here's my suggestion for a fix, hopefully Laurent or Sakari can comment on it:

--- a/drivers/media/video/isp/ispccdc.c
+++ b/drivers/media/video/isp/ispccdc.c
@@ -1477,7 +1477,7 @@ static void ispccdc_vd1_isr(struct isp_ccdc_device *ccdc)
        spin_lock_irqsave(&ccdc->lsc.req_lock, flags);

        /* We are about to stop CCDC and/without LSC */
-       if ((ccdc->output & CCDC_OUTPUT_MEMORY) ||
+       if ((ccdc->output & CCDC_OUTPUT_MEMORY) &&
            (ccdc->state == ISP_PIPELINE_STREAM_SINGLESHOT))
                ccdc->stopping = CCDC_STOP_REQUEST;


-- 
Michael Jones

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Re: OMAP3530 ISP irqs disabled

[Bastian Hecht]

2010/11/5 Michael Jones <michael.jones@matrix-vision.de>:
> Hi Bastian (Laurent, and Sakari),
>>
>> I want to clarify this:
>>
>> I try to read images with yafta.
>> I read in 4 images with 5MP size (no skipping). All 4 images contain only zeros.
>> I repeat the process some times and keep checking the data. After -
>> let's say the 6th time - the images contain exactly the data I expect.
>> WHEN they are read they are good. I just don't want to read 20 black
>> images before 1 image is transferred right.
>>
>> -Bastian
>>
>
> I'm on to your problem, having reproduced it myself.  I suspect that you're actually only getting one frame: your very first buffer.  You don't touch it, and neither does the CCDC after you requeue it, and after you've cycled through all your other buffers, you get back the non-zero frame.  If you clear the "good" frame in your application once, you won't get any more non-zero frames afterwards.  Or if you request more buffers, you'll have fewer non-zero frames.  That's the behavior I observe.

I can confirm the very first buffer theorem. I indeed get 1 valid
frame after each reboot. First I didn'notice it because I used
Laurent's yafta .... --skip 3 ... command line. I read 4 frames and
only saved the last.

Btw, heaven sent you... I keep working on this problem 1 week now and
am pretty desperate. I started reading about the linux memory
management system to understand all the buffer dma streaming. (well
that is probably not the worst thing to sacrifice time...)

Tell me if I can do something for you to help.

cheers,

 Bastian


> The CCDC is getting disabled by the VD1 interrupt:
> ispccdc_vd1_isr()->__ispccdc_handle_stopping()->__ispccdc_enable(ccdc, 0)
>
> To test this theory I tried disabling the VD1 interrupt, but it didn't solve the problem.  In fact, I was still getting VD1 interrupts even though I had disabled them.  Has anybody else observed that VD1 cannot be disabled?
>
> I also found it strange that the CCDC seemed to continue to generate interrupts when it's disabled.
>
> Here's my suggestion for a fix, hopefully Laurent or Sakari can comment on it:
>
> --- a/drivers/media/video/isp/ispccdc.c
> +++ b/drivers/media/video/isp/ispccdc.c
> @@ -1477,7 +1477,7 @@ static void ispccdc_vd1_isr(struct isp_ccdc_device *ccdc)
>        spin_lock_irqsave(&ccdc->lsc.req_lock, flags);
>
>        /* We are about to stop CCDC and/without LSC */
> -       if ((ccdc->output & CCDC_OUTPUT_MEMORY) ||
> +       if ((ccdc->output & CCDC_OUTPUT_MEMORY) &&
>            (ccdc->state == ISP_PIPELINE_STREAM_SINGLESHOT))
>                ccdc->stopping = CCDC_STOP_REQUEST;
>
>
> --
> Michael Jones
>
> MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
> Registergericht: Amtsgericht Stuttgart, HRB 271090
> Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
>

Re: OMAP3530 ISP irqs disabled

[Sakari Ailus]

[-- Attachment #1: Type: text/plain, Size: 3014 bytes --]

Hi all!

Michael Jones wrote:
> Hi Bastian (Laurent, and Sakari),
>>
>> I want to clarify this:
>>
>> I try to read images with yafta.
>> I read in 4 images with 5MP size (no skipping). All 4 images contain only zeros.
>> I repeat the process some times and keep checking the data. After -
>> let's say the 6th time - the images contain exactly the data I expect.
>> WHEN they are read they are good. I just don't want to read 20 black
>> images before 1 image is transferred right.
>>
>> -Bastian
>>
> 
> I'm on to your problem, having reproduced it myself. I suspect that
you're actually only getting one frame: your very first buffer. You
don't touch it, and neither does the CCDC after you requeue it, and
after you've cycled through all your other buffers, you get back the
non-zero frame. If you clear the "good" frame in your application once,
you won't get any more non-zero frames afterwards. Or if you request
more buffers, you'll have fewer non-zero frames. That's the behavior I
observe.

(FYI: your lines are quite long, well over 80 characters.)

Have you checked the ISP writes data to the buffers? It's good to try
with a known pattern that you can't get from a sensor.

> 
> The CCDC is getting disabled by the VD1 interrupt: 
> ispccdc_vd1_isr()->__ispccdc_handle_stopping()->__ispccdc_enable(ccdc,
> 0)
> 
> To test this theory I tried disabling the VD1 interrupt, but it
> didn't
solve the problem. In fact, I was still getting VD1 interrupts even
though I had disabled them. Has anybody else observed that VD1 cannot be
disabled?
> 
> I also found it strange that the CCDC seemed to continue to generate interrupts when it's disabled.

Yes, the CCDC VD0 and VD1 counters keep counting even if the module is
disabled. That is a known problem.

The VD0 interrupts are ignored as long as there are no buffers queued.

How many buffers do you have btw.?

> Here's my suggestion for a fix, hopefully Laurent or Sakari can comment on it:
> 
> --- a/drivers/media/video/isp/ispccdc.c
> +++ b/drivers/media/video/isp/ispccdc.c
> @@ -1477,7 +1477,7 @@ static void ispccdc_vd1_isr(struct isp_ccdc_device *ccdc)
>         spin_lock_irqsave(&ccdc->lsc.req_lock, flags);
> 
>         /* We are about to stop CCDC and/without LSC */
> -       if ((ccdc->output & CCDC_OUTPUT_MEMORY) ||
> +       if ((ccdc->output & CCDC_OUTPUT_MEMORY) &&
>             (ccdc->state == ISP_PIPELINE_STREAM_SINGLESHOT))
>                 ccdc->stopping = CCDC_STOP_REQUEST;

Does this fix the problem? ISP_PIPELINE_STREAM_SINGLESHOT is there for
memory sources and I do not think this is a correct fix.

Is your VSYNC on falling or rising edge? This is defined for CCP2 and
this is what the driver was originally written for. If it's different
(rising??), you should apply the attached wildly opportunistic patch,
which I do not expect to fix this problem, however.

But I might be just pointing you to wrong direction, better wait for
Laurent's answer. :-)

Cheers,

-- 
Sakari Ailus
sakari.ailus@maxwell.research.nokia.com

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 519 bytes --]

--- drivers/media/video/isp/ispccdc.c~	2010-09-17 00:43:17.000000000 +0300
+++ drivers/media/video/isp/ispccdc.c	2010-11-07 06:42:46.000000000 +0200
@@ -1225,7 +1225,7 @@
 	/* Generate VD0 on the last line of the image and VD1 on the
 	 * 2/3 height line.
 	 */
-	isp_reg_writel(isp, ((format->height - 2) << ISPCCDC_VDINT_0_SHIFT) |
+	isp_reg_writel(isp, ((format->height - 1) << ISPCCDC_VDINT_0_SHIFT) |
 		       ((format->height * 2 / 3) << ISPCCDC_VDINT_1_SHIFT),
 		       OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VDINT);
 

Re: OMAP3530 ISP irqs disabled

[Bastian Hecht]

2010/11/7 Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>:
> Hi all!
>
> Michael Jones wrote:
>> Hi Bastian (Laurent, and Sakari),
>>>
>>> I want to clarify this:
>>>
>>> I try to read images with yafta.
>>> I read in 4 images with 5MP size (no skipping). All 4 images contain only zeros.
>>> I repeat the process some times and keep checking the data. After -
>>> let's say the 6th time - the images contain exactly the data I expect.
>>> WHEN they are read they are good. I just don't want to read 20 black
>>> images before 1 image is transferred right.
>>>
>>> -Bastian
>>>
>>
>> I'm on to your problem, having reproduced it myself. I suspect that
> you're actually only getting one frame: your very first buffer. You
> don't touch it, and neither does the CCDC after you requeue it, and
> after you've cycled through all your other buffers, you get back the
> non-zero frame. If you clear the "good" frame in your application once,
> you won't get any more non-zero frames afterwards. Or if you request
> more buffers, you'll have fewer non-zero frames. That's the behavior I
> observe.
>
> (FYI: your lines are quite long, well over 80 characters.)
>
> Have you checked the ISP writes data to the buffers? It's good to try
> with a known pattern that you can't get from a sensor.
>
>>
>> The CCDC is getting disabled by the VD1 interrupt:
>> ispccdc_vd1_isr()->__ispccdc_handle_stopping()->__ispccdc_enable(ccdc,
>> 0)
>>
>> To test this theory I tried disabling the VD1 interrupt, but it
>> didn't
> solve the problem. In fact, I was still getting VD1 interrupts even
> though I had disabled them. Has anybody else observed that VD1 cannot be
> disabled?
>>
>> I also found it strange that the CCDC seemed to continue to generate interrupts when it's disabled.
>
> Yes, the CCDC VD0 and VD1 counters keep counting even if the module is
> disabled. That is a known problem.
>
> The VD0 interrupts are ignored as long as there are no buffers queued.
>
> How many buffers do you have btw.?
>
>> Here's my suggestion for a fix, hopefully Laurent or Sakari can comment on it:
>>
>> --- a/drivers/media/video/isp/ispccdc.c
>> +++ b/drivers/media/video/isp/ispccdc.c
>> @@ -1477,7 +1477,7 @@ static void ispccdc_vd1_isr(struct isp_ccdc_device *ccdc)
>>         spin_lock_irqsave(&ccdc->lsc.req_lock, flags);
>>
>>         /* We are about to stop CCDC and/without LSC */
>> -       if ((ccdc->output & CCDC_OUTPUT_MEMORY) ||
>> +       if ((ccdc->output & CCDC_OUTPUT_MEMORY) &&
>>             (ccdc->state == ISP_PIPELINE_STREAM_SINGLESHOT))
>>                 ccdc->stopping = CCDC_STOP_REQUEST;
>
> Does this fix the problem? ISP_PIPELINE_STREAM_SINGLESHOT is there for
> memory sources and I do not think this is a correct fix.

It fixes the problem for me. I read 2 frames now, the first is half
full, but the second gets synchronized nicely then and I got my first
picture out of it. It works reliable now.

> Is your VSYNC on falling or rising edge? This is defined for CCP2 and
> this is what the driver was originally written for. If it's different
> (rising??), you should apply the attached wildly opportunistic patch,
> which I do not expect to fix this problem, however.

I got rising HSYNC and rising VSINC sampled at falling pixelclock.

- Bastian


> But I might be just pointing you to wrong direction, better wait for
> Laurent's answer. :-)
>
> Cheers,
>
> --
> Sakari Ailus
> sakari.ailus@maxwell.research.nokia.com
>

Re: OMAP3530 ISP irqs disabled

[Laurent Pinchart]

Hi,

On Sunday 07 November 2010 05:54:02 Sakari Ailus wrote:
> Michael Jones wrote:
> > Hi Bastian (Laurent, and Sakari),
> > 
> >> I want to clarify this:
> >> 
> >> I try to read images with yafta.
> >> I read in 4 images with 5MP size (no skipping). All 4 images contain
> >> only zeros. I repeat the process some times and keep checking the data.
> >> After - let's say the 6th time - the images contain exactly the data I
> >> expect. WHEN they are read they are good. I just don't want to read 20
> >> black images before 1 image is transferred right.
> >> 
> >> -Bastian
> > 
> > I'm on to your problem, having reproduced it myself. I suspect that
> 
> you're actually only getting one frame: your very first buffer. You
> don't touch it, and neither does the CCDC after you requeue it, and
> after you've cycled through all your other buffers, you get back the
> non-zero frame. If you clear the "good" frame in your application once,
> you won't get any more non-zero frames afterwards. Or if you request
> more buffers, you'll have fewer non-zero frames. That's the behavior I
> observe.
> 
> (FYI: your lines are quite long, well over 80 characters.)
> 
> Have you checked the ISP writes data to the buffers? It's good to try
> with a known pattern that you can't get from a sensor.
> 
> > The CCDC is getting disabled by the VD1 interrupt:
> > ispccdc_vd1_isr()->__ispccdc_handle_stopping()->__ispccdc_enable(ccdc,
> > 0)
> > 
> > To test this theory I tried disabling the VD1 interrupt, but it
> > didn't
> 
> solve the problem. In fact, I was still getting VD1 interrupts even
> though I had disabled them. Has anybody else observed that VD1 cannot be
> disabled?
> 
> > I also found it strange that the CCDC seemed to continue to generate
> > interrupts when it's disabled.
> 
> Yes, the CCDC VD0 and VD1 counters keep counting even if the module is
> disabled. That is a known problem.
> 
> The VD0 interrupts are ignored as long as there are no buffers queued.
> 
> How many buffers do you have btw.?
> 
> > Here's my suggestion for a fix, hopefully Laurent or Sakari can comment
> > on it:
> > 
> > --- a/drivers/media/video/isp/ispccdc.c
> > +++ b/drivers/media/video/isp/ispccdc.c
> > @@ -1477,7 +1477,7 @@ static void ispccdc_vd1_isr(struct isp_ccdc_device
> > *ccdc)
> > 
> >         spin_lock_irqsave(&ccdc->lsc.req_lock, flags);
> >         
> >         /* We are about to stop CCDC and/without LSC */
> > 
> > -       if ((ccdc->output & CCDC_OUTPUT_MEMORY) ||
> > +       if ((ccdc->output & CCDC_OUTPUT_MEMORY) &&
> > 
> >             (ccdc->state == ISP_PIPELINE_STREAM_SINGLESHOT))
> >             
> >                 ccdc->stopping = CCDC_STOP_REQUEST;
> 
> Does this fix the problem? ISP_PIPELINE_STREAM_SINGLESHOT is there for
> memory sources and I do not think this is a correct fix.
> 
> Is your VSYNC on falling or rising edge? This is defined for CCP2 and
> this is what the driver was originally written for. If it's different
> (rising??), you should apply the attached wildly opportunistic patch,
> which I do not expect to fix this problem, however.
> 
> But I might be just pointing you to wrong direction, better wait for
> Laurent's answer. :-)

Sorry for the late reply, I've been travelling for the past two weeks and had 
no hardware to test this on. I will try the latest code on a board with a 
parallel sensor and I'll let you know if I can reproduce the problem.

-- 
Regards,

Laurent Pinchart

Re: OMAP3530 ISP irqs disabled

[Michael Jones]

Sakari Ailus wrote:

<snip>

> (FYI: your lines are quite long, well over 80 characters.)
Should be better now, thanks.

<snip>
> 
>> Here's my suggestion for a fix, hopefully Laurent or Sakari can comment on it:
>>
>> --- a/drivers/media/video/isp/ispccdc.c
>> +++ b/drivers/media/video/isp/ispccdc.c
>> @@ -1477,7 +1477,7 @@ static void ispccdc_vd1_isr(struct isp_ccdc_device *ccdc)
>>         spin_lock_irqsave(&ccdc->lsc.req_lock, flags);
>>
>>         /* We are about to stop CCDC and/without LSC */
>> -       if ((ccdc->output & CCDC_OUTPUT_MEMORY) ||
>> +       if ((ccdc->output & CCDC_OUTPUT_MEMORY) &&
>>             (ccdc->state == ISP_PIPELINE_STREAM_SINGLESHOT))
>>                 ccdc->stopping = CCDC_STOP_REQUEST;
> 
> Does this fix the problem? ISP_PIPELINE_STREAM_SINGLESHOT is there for
> memory sources and I do not think this is a correct fix.

I was also able to reproduce Bastian's problem and this fixed it for me.
 With the condition as it is, it says on VD1, if the output is memory,
CCDC will be disabled.  This is obviously not what I want just because
I'm writing from CCDC to memory.  So something needs to be changed in
this condition for Bastian.  But I'm not  clear on what cases the CCDC
_does_ need to be disabled here, which is why I'm unsure about the fix.

> 
> Is your VSYNC on falling or rising edge? This is defined for CCP2 and
> this is what the driver was originally written for. If it's different
> (rising??), you should apply the attached wildly opportunistic patch,
> which I do not expect to fix this problem, however.
> 
> But I might be just pointing you to wrong direction, better wait for
> Laurent's answer. :-)
> 
> Cheers,
> 


-- 
Michael Jones

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Re: OMAP3530 ISP irqs disabled

[Michael Jones]

Laurent Pinchart wrote:

> 
> Sorry for the late reply, I've been travelling for the past two weeks and had 
> no hardware to test this on. I will try the latest code on a board with a 
> parallel sensor and I'll let you know if I can reproduce the problem.
> 

If I'm correct about the problem, it's not about the parallel sensor,
it's about writing the data from the CCDC to memory.  I expect the
problem to occur with a serial sensor too if the CCDC writes to memory.

-- 
Michael Jones

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Re: OMAP3530 ISP irqs disabled

[Laurent Pinchart]

Hi Michael,

On Monday 08 November 2010 13:26:52 Michael Jones wrote:
> Laurent Pinchart wrote:
> > Sorry for the late reply, I've been travelling for the past two weeks and
> > had no hardware to test this on. I will try the latest code on a board
> > with a parallel sensor and I'll let you know if I can reproduce the
> > problem.
> 
> If I'm correct about the problem, it's not about the parallel sensor,
> it's about writing the data from the CCDC to memory.  I expect the
> problem to occur with a serial sensor too if the CCDC writes to memory.

You're 100% right, I've been able to reproduce the problem with both a 
parallel and a serial sensor. I wonder how this bug got introduced, it's time 
to tighten the QA process. I'll work on a fix ASAP.

-- 
Regards,

Laurent Pinchart