Re: Problems with the omap3isp
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with the omap3isp
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with the omap3isp
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, 2400); 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 1200 or 3600 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 10 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 10 interrupts limit very quickly and the system will unfreeze. If so, please report the content of /proc/interrupts ... 40: 11 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 11 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with the omap3isp
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, 2400); 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 1200 or 3600 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 10 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 10 interrupts limit very quickly and the system will unfreeze. If so, please report the content of /proc/interrupts ... 40: 11 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 11 -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with the omap3isp
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, 2400);
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 1200 or 3600 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
10 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 10 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++ = 10)
+ 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);
+
Re: Problems with the omap3isp
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, 2400);
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.22] [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: 0001
0110
[ 392.323638] 9a00: de604600 dda28000 0202 dda28000
c0a73800 de554cc0 de554cc8
[ 392.332244] 9a20: 000a dda29a8c dda299d8 dda29a40 c00724fc
c003d1b8 60070113
[ 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: 0001 0110
de604600 60070013 c0a5eb08
[ 392.394836] 9b00: 60070013 fdfd de554cc0 de554cc8 de62b400
dda29b44 dda29ac8 dda29b30
[ 392.403442] 9b20: c00724fc c06a21b8 20070013
[ 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])
Re: Problems with the omap3isp
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
