Problems with the omap3isp

Problems with the omap3isp

[Stefan Herbrechtsmeier]

Hi Laurent,

I have some problems with the omap3isp driver. At the moment I use a 
linux-stable 3.14.5 with your fixes for omap3xxx-clocks.dtsi.

1. If I change the clock rate to 24 MHz in my camera driver the whole 
system freeze at the clk_prepare_enable. The first enable and disable 
works without any problem. The system freeze during a systemd / udev 
call of media-ctl.

2. If I enable the streaming I get a  "omap3isp omap3isp: CCDC won't 
become idle!" and if I disable streaming I get a "omap3isp omap3isp: 
Unable to stop OMAP3 ISP CCDC". I think the problem is, that I can't 
disable the camera output. Do you change the order of the stream enable 
/ disable after Linux 3.4?

Kind regards,
   Stefan

Re: Problems with the omap3isp

[Laurent Pinchart]

Hi Stefan,

Sorry for the late reply.

On Tuesday 15 July 2014 12:04:09 Stefan Herbrechtsmeier wrote:
> Hi Laurent,
> 
> I have some problems with the omap3isp driver. At the moment I use a
> linux-stable 3.14.5 with your fixes for omap3xxx-clocks.dtsi.
> 
> 1. If I change the clock rate to 24 MHz in my camera driver the whole
> system freeze at the clk_prepare_enable. The first enable and disable
> works without any problem. The system freeze during a systemd / udev
> call of media-ctl.

I've never seen that before. Where does your sensor get its clock from ? Is it 
connected to the ISP XCLKA or XCLKB output ? What happens if you don't change 
the clock rate to 24 MHz ? What rate is it set to in that case ?

> 2. If I enable the streaming I get a  "omap3isp omap3isp: CCDC won't
> become idle!" and if I disable streaming I get a "omap3isp omap3isp:
> Unable to stop OMAP3 ISP CCDC". I think the problem is, that I can't
> disable the camera output. Do you change the order of the stream enable
> / disable after Linux 3.4?

Not that I know of.

The two problems might be related, maybe we could concentrate on the first one 
first.

-- 
Regards,

Laurent Pinchart

Re: Problems with the omap3isp

[Stefan Herbrechtsmeier]

Am 31.07.2014 01:10, schrieb Laurent Pinchart:
> On Tuesday 15 July 2014 12:04:09 Stefan Herbrechtsmeier wrote:
>> Hi Laurent,
>>
>> I have some problems with the omap3isp driver. At the moment I use a
>> linux-stable 3.14.5 with your fixes for omap3xxx-clocks.dtsi.
>>
>> 1. If I change the clock rate to 24 MHz in my camera driver the whole
>> system freeze at the clk_prepare_enable. The first enable and disable
>> works without any problem. The system freeze during a systemd / udev
>> call of media-ctl.
> I've never seen that before. Where does your sensor get its clock from ? Is it
> connected to the ISP XCLKA or XCLKB output ?
XCLKA

>   What happens if you don't change
> the clock rate to 24 MHz ? What rate is it set to in that case ?
It works if I use a clock rate of 12 MHz or 36 MHz.

I use the following lines during power enable in the driver:
     clk_set_rate(ov5647->clk, 24000000);
     clk_prepare_enable(ov5647->clk);

This works during probe, but the second time I try to power up the 
device the system stall after clk_prepare_enable.

I see the following dump:

[  392.148620] INFO: rcu_preempt self-detected stall on CPU { 0} (t=2100 
jiffies g=1819 c=1818 q=16)
[  392.158142] CPU: 0 PID: 1853 Comm: v4l2-ctl Tainted: G W    
3.14.5-yocto-standard #131
[  392.167144] [<c001518c>] (unwind_backtrace) from [<c00125a0>] 
(show_stack+0x20/0x24)
[  392.175323] [<c00125a0>] (show_stack) from [<c069bdcc>] 
(dump_stack+0x20/0x28)
[  392.182922] [<c069bdcc>] (dump_stack) from [<c0086974>] 
(rcu_check_callbacks+0x210/0x694)
[  392.191558] [<c0086974>] (rcu_check_callbacks) from [<c0045684>] 
(update_process_times+0x4c/0x6c)
[  392.200897] [<c0045684>] (update_process_times) from [<c00906b0>] 
(tick_sched_handle.isra.14+0x58/0x64)
[  392.210784] [<c00906b0>] (tick_sched_handle.isra.14) from 
[<c009070c>] (tick_sched_timer+0x50/0x80)
[  392.220306] [<c009070c>] (tick_sched_timer) from [<c005b8b0>] 
(__run_hrtimer+0x190/0x2d0)
[  392.228912] [<c005b8b0>] (__run_hrtimer) from [<c005c20c>] 
(hrtimer_interrupt+0x118/0x260)
[  392.237640] [<c005c20c>] (hrtimer_interrupt) from [<c0022e34>] 
(omap2_gp_timer_interrupt+0x30/0x40)
[  392.247161] [<c0022e34>] (omap2_gp_timer_interrupt) from [<c007db60>] 
(handle_irq_event_percpu+0xb4/0x2d0)
[  392.257324] [<c007db60>] (handle_irq_event_percpu) from [<c007ddc8>] 
(handle_irq_event+0x4c/0x6c)
[  392.266662] [<c007ddc8>] (handle_irq_event) from [<c0080668>] 
(handle_level_irq+0xe0/0xf8)
[  392.275360] [<c0080668>] (handle_level_irq) from [<c007d314>] 
(generic_handle_irq+0x30/0x40)
[  392.284271] [<c007d314>] (generic_handle_irq) from [<c000f32c>] 
(handle_IRQ+0x70/0x90)
[  392.292602] [<c000f32c>] (handle_IRQ) from [<c00085f4>] 
(omap3_intc_handle_irq+0x68/0x90)
[  392.301208] [<c00085f4>] (omap3_intc_handle_irq) from [<c06a2f44>] 
(__irq_svc+0x44/0x78)
[  392.309722] Exception stack(0xdda299f8 to 0xdda29a40)
[  392.315032] 
99e0:                                                       00000001 
00000110
[  392.323638] 9a00: 00000000 de604600 dda28000 00000202 dda28000 
c0a73800 de554cc0 de554cc8
[  392.332244] 9a20: 0000000a dda29a8c dda299d8 dda29a40 c00724fc 
c003d1b8 60070113 ffffffff
[  392.340881] [<c06a2f44>] (__irq_svc) from [<c003d1b8>] 
(__do_softirq+0xd0/0x370)
[  392.348663] [<c003d1b8>] (__do_softirq) from [<c003d758>] 
(irq_exit+0x94/0x104)
[  392.356353] [<c003d758>] (irq_exit) from [<c000f330>] 
(handle_IRQ+0x74/0x90)
[  392.363769] [<c000f330>] (handle_IRQ) from [<c00085f4>] 
(omap3_intc_handle_irq+0x68/0x90)
[  392.372406] [<c00085f4>] (omap3_intc_handle_irq) from [<c06a2f44>] 
(__irq_svc+0x44/0x78)
[  392.380889] Exception stack(0xdda29ae8 to 0xdda29b30)
[  392.386230] 9ae0:                   00000001 00000110 00000000 
de604600 60070013 c0a5eb08
[  392.394836] 9b00: 60070013 fffffdfd de554cc0 de554cc8 de62b400 
dda29b44 dda29ac8 dda29b30
[  392.403442] 9b20: c00724fc c06a21b8 20070013 ffffffff
[  392.408752] [<c06a2f44>] (__irq_svc) from [<c06a21b8>] 
(_raw_spin_unlock_irqrestore+0x50/0x84)
[  392.417846] [<c06a21b8>] (_raw_spin_unlock_irqrestore) from 
[<c056750c>] (clk_enable_unlock+0xb4/0xc8)
[  392.427642] [<c056750c>] (clk_enable_unlock) from [<c0567bdc>] 
(clk_enable+0x34/0x3c)
[  392.435913] [<c0567bdc>] (clk_enable) from [<bf255f50>] 
(ov5647_set_power.part.2+0x68/0xc4 [ov5647])
[  392.445800] [<bf255f50>] (ov5647_set_power.part.2 [ov5647]) from 
[<bf255568>] (ov5647_set_power+0x24/0x58 [ov5647])
[  392.456787] [<bf255568>] (ov5647_set_power [ov5647]) from 
[<bf255604>] (ov5647_s_power+0x68/0xb4 [ov5647])
[  392.467041] [<bf255604>] (ov5647_s_power [ov5647]) from [<bf18812c>] 
(isp_pipeline_pm_power_one+0x98/0x118 [omap3_isp])
[  392.478454] [<bf18812c>] (isp_pipeline_pm_power_one [omap3_isp]) from 
[<bf188c84>] (isp_pipeline_pm_power.part.2+0x54/0xb4 [omap3_isp])
[  392.491333] [<bf188c84>] (isp_pipeline_pm_power.part.2 [omap3_isp]) 
from [<bf188d04>] (isp_pipeline_pm_power+0x20/0x2c [omap3_isp])
[  392.503845] [<bf188d04>] (isp_pipeline_pm_power [omap3_isp]) from 
[<bf189630>] (omap3isp_pipeline_pm_use+0x60/0x88 [omap3_isp])
[  392.515991] [<bf189630>] (omap3isp_pipeline_pm_use [omap3_isp]) from 
[<bf18c85c>] (isp_video_open+0x74/0x1a8 [omap3_isp])
[  392.527648] [<bf18c85c>] (isp_video_open [omap3_isp]) from 
[<bf1564f8>] (v4l2_open+0x8c/0xd4 [videodev])
[  392.537689] [<bf1564f8>] (v4l2_open [videodev]) from [<c0133064>] 
(chrdev_open+0x14c/0x178)
[  392.546478] [<c0133064>] (chrdev_open) from [<c012d418>] 
(do_dentry_open+0x284/0x298)
[  392.554748] [<c012d418>] (do_dentry_open) from [<c012d854>] 
(finish_open+0x48/0x5c)
[  392.562805] [<c012d854>] (finish_open) from [<c013c170>] 
(do_last.isra.31+0x860/0xac0)
[  392.571136] [<c013c170>] (do_last.isra.31) from [<c013c5f0>] 
(path_openat+0x220/0x5c8)
[  392.579467] [<c013c5f0>] (path_openat) from [<c013d79c>] 
(do_filp_open+0x3c/0x88)
[  392.587371] [<c013d79c>] (do_filp_open) from [<c012e538>] 
(do_sys_open+0x130/0x1d0)
[  392.595428] [<c012e538>] (do_sys_open) from [<c012e608>] 
(SyS_open+0x30/0x34)
[  392.602935] [<c012e608>] (SyS_open) from [<c000e2c0>] 
(ret_fast_syscall+0x0/0x48)

Re: Problems with the omap3isp

[Laurent Pinchart]

Hi Stefan,

On Thursday 31 July 2014 10:29:37 Stefan Herbrechtsmeier wrote:
> Am 31.07.2014 01:10, schrieb Laurent Pinchart:
> > On Tuesday 15 July 2014 12:04:09 Stefan Herbrechtsmeier wrote:
> >> Hi Laurent,
> >> 
> >> I have some problems with the omap3isp driver. At the moment I use a
> >> linux-stable 3.14.5 with your fixes for omap3xxx-clocks.dtsi.
> >> 
> >> 1. If I change the clock rate to 24 MHz in my camera driver the whole
> >> system freeze at the clk_prepare_enable. The first enable and disable
> >> works without any problem. The system freeze during a systemd / udev
> >> call of media-ctl.
> > 
> > I've never seen that before. Where does your sensor get its clock from ?
> > Is it connected to the ISP XCLKA or XCLKB output ?
> 
> XCLKA
> 
> > What happens if you don't change the clock rate to 24 MHz ? What rate is
> > it set to in that case ?
> 
> It works if I use a clock rate of 12 MHz or 36 MHz.
> 
> I use the following lines during power enable in the driver:
>      clk_set_rate(ov5647->clk, 24000000);
>      clk_prepare_enable(ov5647->clk);
> 
> This works during probe, but the second time I try to power up the
> device the system stall after clk_prepare_enable.

Just to make sure I understand properly, if you change the above frequency
value to 12000000 or 36000000 without modifying anything else, the problem
doesn't occur ?

Do you start streaming at all at any point ?

> I see the following dump:

[snip]

Looks like the CPU spends all its time processing interrupts. Could you
please try the following patch ? It should disable the ISP interrupt after
100000 occurrences, and create an isr_account property in sysfs that will
report the number of interrupts generated for each source. If my guess is
correct, you will hit the 100000 interrupts limit very quickly and the system
will unfreeze. If so, please report the content of /proc/interrupts and of
the isr_account property (if I remember correctly it should be located in
/sys/class/video4linux/video0/device/media0/ but you might need to search for
it).

diff --git a/drivers/media/platform/omap3isp/isp.c b/drivers/media/platform/omap3isp/isp.c
index de2dec5..c4e6455 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -400,6 +400,38 @@ static inline void isp_isr_dbg(struct isp_device *isp, u32 irqstatus)
 	printk(KERN_CONT "\n");
 }
 
+static unsigned int isp_isr_count[32];
+
+static inline void isp_isr_account(struct isp_device *isp, u32 irqstatus)
+{
+	unsigned int i;
+
+	spin_lock(&isp->isr_account_lock);
+	for (i = 0; i < 32; i++) {
+		if (irqstatus & (1 << i))
+			isp_isr_count[i]++;
+	}
+	spin_unlock(&isp->isr_account_lock);
+}
+
+static ssize_t isp_isr_account_show(struct device *dev,
+	struct device_attribute *attr, char *buf)
+{
+	struct isp_device *isp = container_of(to_media_device(to_media_devnode(dev)), struct isp_device, media_dev);
+	unsigned long flags;
+	unsigned int i;
+	int ret = 0;
+
+	spin_lock_irqsave(&isp->isr_account_lock, flags);
+	for (i = 0; i < 32; i++)
+		ret += sprintf(buf + ret, "%u\t%u\n", i, isp_isr_count[i]);
+	spin_unlock_irqrestore(&isp->isr_account_lock, flags);
+
+	return ret;
+}
+
+static DEVICE_ATTR(isr_account, S_IRUGO, isp_isr_account_show, NULL);
+
 static void isp_isr_sbl(struct isp_device *isp)
 {
 	struct device *dev = isp->dev;
@@ -462,6 +494,7 @@ static irqreturn_t isp_isr(int irq, void *_isp)
 				       IRQ0STATUS_CCDC_VD0_IRQ |
 				       IRQ0STATUS_CCDC_VD1_IRQ |
 				       IRQ0STATUS_HS_VS_IRQ;
+	static unsigned int count = 0;
 	struct isp_device *isp = _isp;
 	u32 irqstatus;
 	int ret;
@@ -469,6 +502,10 @@ static irqreturn_t isp_isr(int irq, void *_isp)
 	irqstatus = isp_reg_readl(isp, OMAP3_ISP_IOMEM_MAIN, ISP_IRQ0STATUS);
 	isp_reg_writel(isp, irqstatus, OMAP3_ISP_IOMEM_MAIN, ISP_IRQ0STATUS);
 
+	isp_isr_account(isp, irqstatus);
+	if (count++ >= 100000)
+		isp_disable_interrupts(isp);
+
 	isp_isr_sbl(isp);
 
 	if (irqstatus & IRQ0STATUS_CSIA_IRQ) {
@@ -1971,6 +2008,7 @@ static int isp_remove(struct platform_device *pdev)
 	struct isp_device *isp = platform_get_drvdata(pdev);
 	int i;
 
+	device_remove_file(&isp->media_dev.devnode.dev, &dev_attr_isr_account);
 	isp_unregister_entities(isp);
 	isp_cleanup_modules(isp);
 
@@ -2067,6 +2105,7 @@ static int isp_probe(struct platform_device *pdev)
 
 	mutex_init(&isp->isp_mutex);
 	spin_lock_init(&isp->stat_lock);
+	spin_lock_init(&isp->isr_account_lock);
 
 	isp->dev = &pdev->dev;
 	isp->pdata = pdata;
@@ -2156,6 +2195,8 @@ static int isp_probe(struct platform_device *pdev)
 	isp_power_settings(isp, 1);
 	omap3isp_put(isp);
 
+	ret = device_create_file(&isp->media_dev.devnode.dev, &dev_attr_isr_account);
+
 	return 0;
 
 error_modules:
diff --git a/drivers/media/platform/omap3isp/isp.h b/drivers/media/platform/omap3isp/isp.h
index 2620c40..b3f8448 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -259,6 +259,7 @@ struct isp_device {
 
 	/* ISP Obj */
 	spinlock_t stat_lock;	/* common lock for statistic drivers */
+	spinlock_t isr_account_lock;
 	struct mutex isp_mutex;	/* For handling ref_count field */
 	bool needs_reset;
 	int has_context;


-- 
Regards,

Laurent Pinchart

Re: Problems with the omap3isp

[Stefan Herbrechtsmeier]

Hi Laurent,

thank you very much for your help.

The problem is cross talk on the camera flex cable of the Gumstix Overo. 
The XCLKA signal is beside PCLK and VS. Additionally the OV5647 camera 
tristate all outputs by default. This leads to HS_VS_IRQ interrupts.  I 
wasn't aware of the interrupts enable during the isp_xclk_prepare.

Am 01.08.2014 15:57, schrieb Laurent Pinchart:
> On Thursday 31 July 2014 10:29:37 Stefan Herbrechtsmeier wrote:
>> Am 31.07.2014 01:10, schrieb Laurent Pinchart:
>>> On Tuesday 15 July 2014 12:04:09 Stefan Herbrechtsmeier wrote:
>>>> Hi Laurent,
>>>>
>>>> I have some problems with the omap3isp driver. At the moment I use a
>>>> linux-stable 3.14.5 with your fixes for omap3xxx-clocks.dtsi.
>>>>
>>>> 1. If I change the clock rate to 24 MHz in my camera driver the whole
>>>> system freeze at the clk_prepare_enable. The first enable and disable
>>>> works without any problem. The system freeze during a systemd / udev
>>>> call of media-ctl.
>>> I've never seen that before. Where does your sensor get its clock from ?
>>> Is it connected to the ISP XCLKA or XCLKB output ?
>> XCLKA
>>
>>> What happens if you don't change the clock rate to 24 MHz ? What rate is
>>> it set to in that case ?
>> It works if I use a clock rate of 12 MHz or 36 MHz.
>>
>> I use the following lines during power enable in the driver:
>>       clk_set_rate(ov5647->clk, 24000000);
>>       clk_prepare_enable(ov5647->clk);
>>
>> This works during probe, but the second time I try to power up the
>> device the system stall after clk_prepare_enable.
> Just to make sure I understand properly, if you change the above frequency
> value to 12000000 or 36000000 without modifying anything else, the problem
> doesn't occur ?
Yes.

> Do you start streaming at all at any point ?
No, it stops in s_power.

>> I see the following dump:
> [snip]
>
> Looks like the CPU spends all its time processing interrupts. Could you
> please try the following patch ? It should disable the ISP interrupt after
> 100000 occurrences, and create an isr_account property in sysfs that will
> report the number of interrupts generated for each source. If my guess is
> correct, you will hit the 100000 interrupts limit very quickly and the system
> will unfreeze. If so, please report the content of /proc/interrupts
...
  40:     100001      INTC  24  omap-iommu.0, OMAP3 ISP
...

>   and of
> the isr_account property (if I remember correctly it should be located in
> /sys/class/video4linux/video0/device/media0/ but you might need to search for
> it).
0       0
...
30      0
31      100001

Re: Problems with the omap3isp

[Laurent Pinchart]

Hi Stefan,

On Monday 04 August 2014 11:24:13 Stefan Herbrechtsmeier wrote:
> Hi Laurent,
> 
> thank you very much for your help.
> 
> The problem is cross talk on the camera flex cable of the Gumstix Overo.
> The XCLKA signal is beside PCLK and VS.

Right, I should have mentioned that. It's a know issue, and there's not much 
that can be done about it without a hardware redesign. A ground (or power 
supply) signal should really have been inserted on each side of the XCLKA and 
PCLK signals.

> Additionally the OV5647 camera tristate all outputs by default. This leads
> to HS_VS_IRQ interrupts.

This should be taken care of by pull-up or pull-down resistors on the camera 
signals. I've disabled them with the Caspa camera given the low drive strength 
of the buffer on the camera board, but you could enable them on your system.

> I wasn't aware of the interrupts enable during the isp_xclk_prepare.
> 
> Am 01.08.2014 15:57, schrieb Laurent Pinchart:
> > On Thursday 31 July 2014 10:29:37 Stefan Herbrechtsmeier wrote:
> >> Am 31.07.2014 01:10, schrieb Laurent Pinchart:
> >>> On Tuesday 15 July 2014 12:04:09 Stefan Herbrechtsmeier wrote:
> >>>> Hi Laurent,
> >>>> 
> >>>> I have some problems with the omap3isp driver. At the moment I use a
> >>>> linux-stable 3.14.5 with your fixes for omap3xxx-clocks.dtsi.
> >>>> 
> >>>> 1. If I change the clock rate to 24 MHz in my camera driver the whole
> >>>> system freeze at the clk_prepare_enable. The first enable and disable
> >>>> works without any problem. The system freeze during a systemd / udev
> >>>> call of media-ctl.
> >>> 
> >>> I've never seen that before. Where does your sensor get its clock from ?
> >>> Is it connected to the ISP XCLKA or XCLKB output ?
> >> 
> >> XCLKA
> >> 
> >>> What happens if you don't change the clock rate to 24 MHz ? What rate is
> >>> it set to in that case ?
> >> 
> >> It works if I use a clock rate of 12 MHz or 36 MHz.
> >> 
> >> I use the following lines during power enable in the driver:
> >>       clk_set_rate(ov5647->clk, 24000000);
> >>       clk_prepare_enable(ov5647->clk);
> >> 
> >> This works during probe, but the second time I try to power up the
> >> device the system stall after clk_prepare_enable.
> > 
> > Just to make sure I understand properly, if you change the above frequency
> > value to 12000000 or 36000000 without modifying anything else, the problem
> > doesn't occur ?
> 
> Yes.
> 
> > Do you start streaming at all at any point ?
> 
> No, it stops in s_power.
> 
> >> I see the following dump:
> > [snip]
> > 
> > Looks like the CPU spends all its time processing interrupts. Could you
> > please try the following patch ? It should disable the ISP interrupt after
> > 100000 occurrences, and create an isr_account property in sysfs that will
> > report the number of interrupts generated for each source. If my guess is
> > correct, you will hit the 100000 interrupts limit very quickly and the
> > system will unfreeze. If so, please report the content of
> > /proc/interrupts
> ...
>   40:     100001      INTC  24  omap-iommu.0, OMAP3 ISP
> ...
> 
> >   and of
> > 
> > the isr_account property (if I remember correctly it should be located in
> > /sys/class/video4linux/video0/device/media0/ but you might need to search
> > for it).
> 
> 0       0
> ...
> 30      0
> 31      100001

-- 
Regards,

Laurent Pinchart

Re: Problems with the omap3isp

[Stefan Herbrechtsmeier]

Hi Laurent,

Am 04.08.2014 um 17:25 schrieb Laurent Pinchart:
> On Monday 04 August 2014 11:24:13 Stefan Herbrechtsmeier wrote:
>> Hi Laurent,
>>
>> thank you very much for your help.
>>
>> The problem is cross talk on the camera flex cable of the Gumstix Overo.
>> The XCLKA signal is beside PCLK and VS.
> Right, I should have mentioned that. It's a know issue, and there's not much
> that can be done about it without a hardware redesign. A ground (or power
> supply) signal should really have been inserted on each side of the XCLKA and
> PCLK signals.
Exists a list about knowing issues with the Gumstix Overo? Because I 
have some problems with the MMC3 too.

>> Additionally the OV5647 camera tristate all outputs by default. This leads
>> to HS_VS_IRQ interrupts.
> This should be taken care of by pull-up or pull-down resistors on the camera
> signals. I've disabled them with the Caspa camera given the low drive strength
> of the buffer on the camera board, but you could enable them on your system.
I have manually rework my camera adapter and change the camera clock 
from XCLKA to XCLKB. Additionally I have enable the pull-ups in my 
device tree. Now the camera sensor from the Raspberry Pi camera module 
works together with the Gumstix Overo.

Thank you for your help,
   Stefan

Re: Problems with the omap3isp

[Laurent Pinchart]

Hi Stefan,

On Wednesday 27 August 2014 12:24:46 Stefan Herbrechtsmeier wrote:
> Am 04.08.2014 um 17:25 schrieb Laurent Pinchart:
> > On Monday 04 August 2014 11:24:13 Stefan Herbrechtsmeier wrote:
> >> Hi Laurent,
> >> 
> >> thank you very much for your help.
> >> 
> >> The problem is cross talk on the camera flex cable of the Gumstix Overo.
> >> The XCLKA signal is beside PCLK and VS.
> > 
> > Right, I should have mentioned that. It's a know issue, and there's not
> > much that can be done about it without a hardware redesign. A ground (or
> > power supply) signal should really have been inserted on each side of the
> > XCLKA and PCLK signals.
> 
> Exists a list about knowing issues with the Gumstix Overo? Because I
> have some problems with the MMC3 too.

Not to my knowledge. This crosstalk issue is something I've discovered and 
reported to Gumstix a couple of years ago.

> >> Additionally the OV5647 camera tristate all outputs by default. This
> >> leads to HS_VS_IRQ interrupts.
> > 
> > This should be taken care of by pull-up or pull-down resistors on the
> > camera signals. I've disabled them with the Caspa camera given the low
> > drive strength of the buffer on the camera board, but you could enable
> > them on your system.
>
> I have manually rework my camera adapter and change the camera clock
> from XCLKA to XCLKB. Additionally I have enable the pull-ups in my
> device tree. Now the camera sensor from the Raspberry Pi camera module
> works together with the Gumstix Overo.

Great. Any chance to see a driver for the ov5647 being submitted to the linux-
media mailing list ? :-)

-- 
Regards,

Laurent Pinchart