* omap3isp device tree support @ 2013-12-06 10:13 Enrico 2013-12-06 10:31 ` Florian Vaussard 2013-12-09 13:11 ` Laurent Pinchart 0 siblings, 2 replies; 28+ messages in thread From: Enrico @ 2013-12-06 10:13 UTC (permalink / raw) To: linux-media Hi, i know there is some work going on for omap3isp device tree support, but right now is it possible to enable it in some other way in a DT kernel? I've tried enabling it in board-generic.c (omap3_init_camera(...) with proper platform data) but it hangs early at boot, do someone know if it's possible and how to do it? Thanks, Enrico ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: omap3isp device tree support 2013-12-06 10:13 omap3isp device tree support Enrico @ 2013-12-06 10:31 ` Florian Vaussard 2013-12-06 10:54 ` Enrico 2013-12-09 13:11 ` Laurent Pinchart 1 sibling, 1 reply; 28+ messages in thread From: Florian Vaussard @ 2013-12-06 10:31 UTC (permalink / raw) To: Enrico, linux-media Hello, On 12/06/2013 11:13 AM, Enrico wrote: > Hi, > > i know there is some work going on for omap3isp device tree support, > but right now is it possible to enable it in some other way in a DT > kernel? > The DT support is not yet ready, but an RFC binding has been proposed. It won't be ready for 3.14. > I've tried enabling it in board-generic.c (omap3_init_camera(...) with > proper platform data) but it hangs early at boot, do someone know if > it's possible and how to do it? > I did the same a few days ago, and went through several problems (panics, half DT support,...). Now I am able to probe the ISP, I still have one kernel panic to fix. Hope to send the patches in 1 or 2 days. We are still in a transition period, but things should calm down in the coming releases. Cheers, Florian [1] http://www.spinics.net/lists/linux-media/msg69424.html ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: omap3isp device tree support 2013-12-06 10:31 ` Florian Vaussard @ 2013-12-06 10:54 ` Enrico 2013-12-17 13:11 ` Florian Vaussard 0 siblings, 1 reply; 28+ messages in thread From: Enrico @ 2013-12-06 10:54 UTC (permalink / raw) To: florian.vaussard; +Cc: linux-media On Fri, Dec 6, 2013 at 11:31 AM, Florian Vaussard <florian.vaussard@epfl.ch> wrote: > Hello, > > On 12/06/2013 11:13 AM, Enrico wrote: >> Hi, >> >> i know there is some work going on for omap3isp device tree support, >> but right now is it possible to enable it in some other way in a DT >> kernel? >> > > The DT support is not yet ready, but an RFC binding has been proposed. > It won't be ready for 3.14. > >> I've tried enabling it in board-generic.c (omap3_init_camera(...) with >> proper platform data) but it hangs early at boot, do someone know if >> it's possible and how to do it? >> > > I did the same a few days ago, and went through several problems > (panics, half DT support,...). Now I am able to probe the ISP, I still > have one kernel panic to fix. Hope to send the patches in 1 or 2 days. > We are still in a transition period, but things should calm down in the > coming releases. > > Cheers, > > Florian > > [1] http://www.spinics.net/lists/linux-media/msg69424.html Thanks Florian, i will gladly help in testing. Enrico ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: omap3isp device tree support 2013-12-06 10:54 ` Enrico @ 2013-12-17 13:11 ` Florian Vaussard 2013-12-18 10:09 ` Enrico 0 siblings, 1 reply; 28+ messages in thread From: Florian Vaussard @ 2013-12-17 13:11 UTC (permalink / raw) To: Enrico; +Cc: linux-media Hello Enrico, On 12/06/2013 11:54 AM, Enrico wrote: > On Fri, Dec 6, 2013 at 11:31 AM, Florian Vaussard > <florian.vaussard@epfl.ch> wrote: >> Hello, >> >> On 12/06/2013 11:13 AM, Enrico wrote: >>> Hi, >>> >>> i know there is some work going on for omap3isp device tree support, >>> but right now is it possible to enable it in some other way in a DT >>> kernel? >>> >> >> The DT support is not yet ready, but an RFC binding has been proposed. >> It won't be ready for 3.14. >> >>> I've tried enabling it in board-generic.c (omap3_init_camera(...) with >>> proper platform data) but it hangs early at boot, do someone know if >>> it's possible and how to do it? >>> >> >> I did the same a few days ago, and went through several problems >> (panics, half DT support,...). Now I am able to probe the ISP, I still >> have one kernel panic to fix. Hope to send the patches in 1 or 2 days. >> We are still in a transition period, but things should calm down in the >> coming releases. >> So I converted the iommu to DT (patches just sent), used pdata quirks for the isp / mtv9032 data, added a few patches from other people (mainly clk to fix a crash when deferring the omap3isp probe), and a few small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren) to boot on DT with a working MT9V032 camera. The missing part is the DT binding for the omap3isp, but I guess that we will have to wait a bit more for this. If you want to test, I have a development tree here [1]. Any feedback is welcome. Cheers, Florian [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: omap3isp device tree support 2013-12-17 13:11 ` Florian Vaussard @ 2013-12-18 10:09 ` Enrico 2013-12-23 17:45 ` Enrico 2014-01-03 11:30 ` Enrico 0 siblings, 2 replies; 28+ messages in thread From: Enrico @ 2013-12-18 10:09 UTC (permalink / raw) To: florian.vaussard; +Cc: linux-media On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard <florian.vaussard@epfl.ch> wrote: > So I converted the iommu to DT (patches just sent), used pdata quirks > for the isp / mtv9032 data, added a few patches from other people > (mainly clk to fix a crash when deferring the omap3isp probe), and a few > small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren) > to boot on DT with a working MT9V032 camera. The missing part is the DT > binding for the omap3isp, but I guess that we will have to wait a bit > more for this. > > If you want to test, I have a development tree here [1]. Any feedback is > welcome. > > Cheers, > > Florian > > [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt Thanks Florian, i will report what i get with my setup. Enrico ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: omap3isp device tree support 2013-12-18 10:09 ` Enrico @ 2013-12-23 17:45 ` Enrico 2013-12-23 18:33 ` Enrico 2014-01-03 11:30 ` Enrico 1 sibling, 1 reply; 28+ messages in thread From: Enrico @ 2013-12-23 17:45 UTC (permalink / raw) To: florian.vaussard; +Cc: linux-media On Wed, Dec 18, 2013 at 11:09 AM, Enrico <ebutera@users.berlios.de> wrote: > On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard > <florian.vaussard@epfl.ch> wrote: >> So I converted the iommu to DT (patches just sent), used pdata quirks >> for the isp / mtv9032 data, added a few patches from other people >> (mainly clk to fix a crash when deferring the omap3isp probe), and a few >> small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren) >> to boot on DT with a working MT9V032 camera. The missing part is the DT >> binding for the omap3isp, but I guess that we will have to wait a bit >> more for this. >> >> If you want to test, I have a development tree here [1]. Any feedback is >> welcome. >> >> Cheers, >> >> Florian >> >> [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt > > Thanks Florian, > > i will report what i get with my setup. Uhm it's unrelated to omap3isp but i get a kernel panic in serial_omap_probe: [ 1.575225] console [ttyO2] enabled [ 1.581268] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfb042050 [ 1.589324] Internal error: : 1028 [#1] ARM [ 1.593719] Modules linked in: [ 1.596954] CPU: 0 PID: 1 Comm: swapper Tainted: G W 3.13.0-rc3+ #2 [ 1.604461] task: de870000 ti: de86c000 task.ti: de86c000 [ 1.610137] PC is at serial_omap_probe+0x3a8/0x644 [ 1.615203] LR is at trace_hardirqs_on_caller+0x104/0x1dc [ 1.620849] pc : [<c028c0a4>] lr : [<c006411c>] psr: 20000153 [ 1.620849] sp : de86de30 ip : c06f8784 fp : 00000000 [ 1.632934] r10: 00000000 r9 : dea931ad r8 : c0b7e144 [ 1.638397] r7 : dea75c50 r6 : de8e4c00 r5 : de8e4c10 r4 : dea93010 [ 1.645263] r3 : fb042000 r2 : fb042050 r1 : 00000014 r0 : 00000000 [ 1.652130] Flags: nzCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel [ 1.659912] Control: 10c5387d Table: 80004019 DAC: 00000015 [ 1.665924] Process swapper (pid: 1, stack limit = 0xde86c240) [ 1.672058] Stack: (0xde86de30 to 0xde86e000) [ 1.676635] de20: c053bd40 dea931ad 00000000 00000000 [ 1.685241] de40: de8e4c10 00000000 de8e4c10 c0636340 00000000 00000000 c0636340 0000006e [ 1.693847] de60: de86c030 c029414c c0294134 c0b7e618 de8e4c10 c0292c98 de8e4c10 c0636340 [ 1.702453] de80: de8e4c44 00000000 c05eb8ac c0292e90 00000000 c0636340 c0292dfc c02912a8 [ 1.711029] dea0: de803aa8 de8c8050 c0636340 de9e4900 c0636ec0 c029246c c0559bec c0636340 [ 1.719635] dec0: 00000006 c0636340 00000006 c064e500 c064e500 c0293254 00000000 c05fddf8 [ 1.728240] dee0: 00000006 c05eb8cc c05fddf8 c00087e4 de870000 c0620438 60000153 c0068fcc [ 1.736816] df00: c064e500 00001480 c0620434 c05f72e0 c05f72b8 c0439170 00000002 de86c000 [ 1.745422] df20: c0f9e9f5 c04568d4 0000006e c004be2c c05ab990 00000006 c0f9ea08 00000006 [ 1.754028] df40: 60000153 c05fddf8 00000006 c064e500 c064e500 c05d1480 0000006e c05f72e0 [ 1.762634] df60: c05f72d4 c05d1c68 00000006 00000006 c05d1480 00000000 c00550a0 052d1144 [ 1.771209] df80: 08010820 00000000 c04310f4 00000000 00000000 00000000 00000000 00000000 [ 1.779815] dfa0: 00000000 c04310fc 00000000 c000e048 00000000 00000000 00000000 00000000 [ 1.788421] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 1.796997] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 41001412 44300082 [ 1.805633] [<c028c0a4>] (serial_omap_probe+0x3a8/0x644) from [<c029414c>] (platform_drv_probe+0x18/0x48) [ 1.815673] [<c029414c>] (platform_drv_probe+0x18/0x48) from [<c0292c98>] (driver_probe_device+0x114/0x234) [ 1.825927] [<c0292c98>] (driver_probe_device+0x114/0x234) from [<c0292e90>] (__driver_attach+0x94/0x98) [ 1.835906] [<c0292e90>] (__driver_attach+0x94/0x98) from [<c02912a8>] (bus_for_each_dev+0x60/0x94) [ 1.845428] [<c02912a8>] (bus_for_each_dev+0x60/0x94) from [<c029246c>] (bus_add_driver+0x148/0x1f0) [ 1.855010] [<c029246c>] (bus_add_driver+0x148/0x1f0) from [<c0293254>] (driver_register+0x78/0xf8) [ 1.864532] [<c0293254>] (driver_register+0x78/0xf8) from [<c05eb8cc>] (serial_omap_init+0x20/0x44) [ 1.874053] [<c05eb8cc>] (serial_omap_init+0x20/0x44) from [<c00087e4>] (do_one_initcall+0x100/0x150) [ 1.883758] [<c00087e4>] (do_one_initcall+0x100/0x150) from [<c05d1c68>] (kernel_init_freeable+0x1fc/0x29c) [ 1.894012] [<c05d1c68>] (kernel_init_freeable+0x1fc/0x29c) from [<c04310fc>] (kernel_init+0x8/0x120) [ 1.903717] [<c04310fc>] (kernel_init+0x8/0x120) from [<c000e048>] (ret_from_fork+0x14/0x2c) [ 1.912567] Code: e5d42051 e5943024 e3a01014 e0832211 (e5923000) is it a known bug? something i should check in my config/dts? Enrico ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: omap3isp device tree support 2013-12-23 17:45 ` Enrico @ 2013-12-23 18:33 ` Enrico 0 siblings, 0 replies; 28+ messages in thread From: Enrico @ 2013-12-23 18:33 UTC (permalink / raw) To: florian.vaussard; +Cc: linux-media On Mon, Dec 23, 2013 at 6:45 PM, Enrico <ebutera@users.berlios.de> wrote: > On Wed, Dec 18, 2013 at 11:09 AM, Enrico <ebutera@users.berlios.de> wrote: >> On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard >> <florian.vaussard@epfl.ch> wrote: >>> So I converted the iommu to DT (patches just sent), used pdata quirks >>> for the isp / mtv9032 data, added a few patches from other people >>> (mainly clk to fix a crash when deferring the omap3isp probe), and a few >>> small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren) >>> to boot on DT with a working MT9V032 camera. The missing part is the DT >>> binding for the omap3isp, but I guess that we will have to wait a bit >>> more for this. >>> >>> If you want to test, I have a development tree here [1]. Any feedback is >>> welcome. >>> >>> Cheers, >>> >>> Florian >>> >>> [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt >> >> Thanks Florian, >> >> i will report what i get with my setup. > > Uhm it's unrelated to omap3isp but i get a kernel panic in serial_omap_probe: Sorry for the noise, it was a stupid problem with DT. Enrico ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: omap3isp device tree support 2013-12-18 10:09 ` Enrico 2013-12-23 17:45 ` Enrico @ 2014-01-03 11:30 ` Enrico 2014-01-06 10:11 ` Julien BERAUD 2014-01-07 16:59 ` Laurent Pinchart 1 sibling, 2 replies; 28+ messages in thread From: Enrico @ 2014-01-03 11:30 UTC (permalink / raw) To: florian.vaussard; +Cc: linux-media, Laurent Pinchart On Wed, Dec 18, 2013 at 11:09 AM, Enrico <ebutera@users.berlios.de> wrote: > On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard > <florian.vaussard@epfl.ch> wrote: >> So I converted the iommu to DT (patches just sent), used pdata quirks >> for the isp / mtv9032 data, added a few patches from other people >> (mainly clk to fix a crash when deferring the omap3isp probe), and a few >> small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren) >> to boot on DT with a working MT9V032 camera. The missing part is the DT >> binding for the omap3isp, but I guess that we will have to wait a bit >> more for this. >> >> If you want to test, I have a development tree here [1]. Any feedback is >> welcome. >> >> Cheers, >> >> Florian >> >> [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt > > Thanks Florian, > > i will report what i get with my setup. And here i am. I can confirm it works, video source is tvp5150 (with platform data in pdata-quirks.c) in bt656 mode. Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so if you want to push it you can add a Tested-by me. There is only one problem, but it's unrelated to your DT work. It's an old problem (see for example [1] and [2]), seen by other people too and it seems it's still there. Basically if i capture with yavta while the system is idle then it just waits without getting any frame. If i add some cpu load (usually i do a "cat /dev/zero" in a ssh terminal) it starts capturing correctly. The strange thing is that i do get isp interrupts in the idle case, so i don't know why they don't "propagate" to yavta. Any hints on how to debug this? Enrico [1]: https://linuxtv.org/patch/7836/ [2]: https://www.mail-archive.com/linux-media@vger.kernel.org/msg44923.html ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: omap3isp device tree support 2014-01-03 11:30 ` Enrico @ 2014-01-06 10:11 ` Julien BERAUD 2014-01-07 10:12 ` Enrico 2014-01-07 16:59 ` Laurent Pinchart 1 sibling, 1 reply; 28+ messages in thread From: Julien BERAUD @ 2014-01-06 10:11 UTC (permalink / raw) To: Enrico, florian.vaussard; +Cc: linux-media, Laurent Pinchart Le 03/01/2014 12:30, Enrico a écrit : > On Wed, Dec 18, 2013 at 11:09 AM, Enrico <ebutera@users.berlios.de> wrote: >> On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard >> <florian.vaussard@epfl.ch> wrote: >>> So I converted the iommu to DT (patches just sent), used pdata quirks >>> for the isp / mtv9032 data, added a few patches from other people >>> (mainly clk to fix a crash when deferring the omap3isp probe), and a few >>> small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren) >>> to boot on DT with a working MT9V032 camera. The missing part is the DT >>> binding for the omap3isp, but I guess that we will have to wait a bit >>> more for this. >>> >>> If you want to test, I have a development tree here [1]. Any feedback is >>> welcome. >>> >>> Cheers, >>> >>> Florian >>> >>> [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt >> Thanks Florian, >> >> i will report what i get with my setup. > And here i am. > > I can confirm it works, video source is tvp5150 (with platform data in > pdata-quirks.c) in bt656 mode. > > Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so > if you want to push it you can add a Tested-by me. > > There is only one problem, but it's unrelated to your DT work. > > It's an old problem (see for example [1] and [2]), seen by other > people too and it seems it's still there. > Basically if i capture with yavta while the system is idle then it > just waits without getting any frame. > If i add some cpu load (usually i do a "cat /dev/zero" in a ssh > terminal) it starts capturing correctly. > > The strange thing is that i do get isp interrupts in the idle case, so > i don't know why they don't "propagate" to yavta. > > Any hints on how to debug this? > > Enrico > > [1]: https://linuxtv.org/patch/7836/ > [2]: https://www.mail-archive.com/linux-media@vger.kernel.org/msg44923.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html I have had what looked a lot like these problems before and it was due to a wrong configuration of the ccdc cropping regarding to the blanking. Could you send me the configuration of the pipeline that you apply with media-ctl, just in case this is the same problem. Regards, Julien BERAUD ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: omap3isp device tree support 2014-01-06 10:11 ` Julien BERAUD @ 2014-01-07 10:12 ` Enrico 2014-01-08 11:55 ` Julien BERAUD 0 siblings, 1 reply; 28+ messages in thread From: Enrico @ 2014-01-07 10:12 UTC (permalink / raw) To: Julien BERAUD; +Cc: florian.vaussard, linux-media, Laurent Pinchart On Mon, Jan 6, 2014 at 11:11 AM, Julien BERAUD <julien.beraud@parrot.com> wrote: > > Le 03/01/2014 12:30, Enrico a écrit : >> >> On Wed, Dec 18, 2013 at 11:09 AM, Enrico <ebutera@users.berlios.de> wrote: >>> >>> On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard >>> <florian.vaussard@epfl.ch> wrote: >>>> >>>> So I converted the iommu to DT (patches just sent), used pdata quirks >>>> for the isp / mtv9032 data, added a few patches from other people >>>> (mainly clk to fix a crash when deferring the omap3isp probe), and a few >>>> small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren) >>>> to boot on DT with a working MT9V032 camera. The missing part is the DT >>>> binding for the omap3isp, but I guess that we will have to wait a bit >>>> more for this. >>>> >>>> If you want to test, I have a development tree here [1]. Any feedback is >>>> welcome. >>>> >>>> Cheers, >>>> >>>> Florian >>>> >>>> [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt >>> >>> Thanks Florian, >>> >>> i will report what i get with my setup. >> >> And here i am. >> >> I can confirm it works, video source is tvp5150 (with platform data in >> pdata-quirks.c) in bt656 mode. >> >> Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so >> if you want to push it you can add a Tested-by me. >> >> There is only one problem, but it's unrelated to your DT work. >> >> It's an old problem (see for example [1] and [2]), seen by other >> people too and it seems it's still there. >> Basically if i capture with yavta while the system is idle then it >> just waits without getting any frame. >> If i add some cpu load (usually i do a "cat /dev/zero" in a ssh >> terminal) it starts capturing correctly. >> >> The strange thing is that i do get isp interrupts in the idle case, so >> i don't know why they don't "propagate" to yavta. >> >> Any hints on how to debug this? >> >> Enrico >> >> [1]: https://linuxtv.org/patch/7836/ >> [2]: >> https://www.mail-archive.com/linux-media@vger.kernel.org/msg44923.html > > I have had what looked a lot like these problems before and it was due to a > wrong configuration of the ccdc cropping regarding to the blanking. Could > you send me the configuration of the pipeline that you apply with media-ctl, > just in case this is the same problem. i'm using: media-ctl -r -l '"tvp5150 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' media-ctl --set-format '"tvp5150 2-005c":0 [UYVY 720x625]' And then capture with yavta -s 720x625 (or 720x576, can't remember right now). Thanks, Enrico ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: omap3isp device tree support 2014-01-07 10:12 ` Enrico @ 2014-01-08 11:55 ` Julien BERAUD 2014-01-09 18:14 ` Enrico 0 siblings, 1 reply; 28+ messages in thread From: Julien BERAUD @ 2014-01-08 11:55 UTC (permalink / raw) To: Enrico; +Cc: florian.vaussard, linux-media, Laurent Pinchart Le 07/01/2014 11:12, Enrico a écrit : > On Mon, Jan 6, 2014 at 11:11 AM, Julien BERAUD <julien.beraud@parrot.com> wrote: >> Le 03/01/2014 12:30, Enrico a écrit : >>> On Wed, Dec 18, 2013 at 11:09 AM, Enrico <ebutera@users.berlios.de> wrote: >>>> On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard >>>> <florian.vaussard@epfl.ch> wrote: >>>>> So I converted the iommu to DT (patches just sent), used pdata quirks >>>>> for the isp / mtv9032 data, added a few patches from other people >>>>> (mainly clk to fix a crash when deferring the omap3isp probe), and a few >>>>> small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren) >>>>> to boot on DT with a working MT9V032 camera. The missing part is the DT >>>>> binding for the omap3isp, but I guess that we will have to wait a bit >>>>> more for this. >>>>> >>>>> If you want to test, I have a development tree here [1]. Any feedback is >>>>> welcome. >>>>> >>>>> Cheers, >>>>> >>>>> Florian >>>>> >>>>> [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt >>>> Thanks Florian, >>>> >>>> i will report what i get with my setup. >>> And here i am. >>> >>> I can confirm it works, video source is tvp5150 (with platform data in >>> pdata-quirks.c) in bt656 mode. >>> >>> Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so >>> if you want to push it you can add a Tested-by me. >>> >>> There is only one problem, but it's unrelated to your DT work. >>> >>> It's an old problem (see for example [1] and [2]), seen by other >>> people too and it seems it's still there. >>> Basically if i capture with yavta while the system is idle then it >>> just waits without getting any frame. >>> If i add some cpu load (usually i do a "cat /dev/zero" in a ssh >>> terminal) it starts capturing correctly. >>> >>> The strange thing is that i do get isp interrupts in the idle case, so >>> i don't know why they don't "propagate" to yavta. >>> >>> Any hints on how to debug this? >>> >>> Enrico >>> >>> [1]: https://linuxtv.org/patch/7836/ >>> [2]: >>> https://www.mail-archive.com/linux-media@vger.kernel.org/msg44923.html >> I have had what looked a lot like these problems before and it was due to a >> wrong configuration of the ccdc cropping regarding to the blanking. Could >> you send me the configuration of the pipeline that you apply with media-ctl, >> just in case this is the same problem. > i'm using: > > media-ctl -r -l '"tvp5150 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP > CCDC":1->"OMAP3 ISP CCDC output":0[1]' > media-ctl --set-format '"tvp5150 2-005c":0 [UYVY 720x625]' > > And then capture with yavta -s 720x625 (or 720x576, can't remember right now). > > Thanks, > > Enrico I don't think this is sufficient, though I am no expert about omap3 isp, you should configure the format of the ccdc input and of the ccdc output too. When I had this problem, it was solved by adding cropping at the input of the CCDC, corresponding to the blanking period, which was : - media-ctl -v -f '"OMAP3 ISP CCDC":0 [UYVY2X8 720x576 (0,49/720x576)]' or - media-ctl -v -f '"OMAP3 ISP CCDC":0 [UYVY2X8 720x480 (0,45/720x480)]' respectively. I don't know if this can be of any help. Regards, Julien BERAUD ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: omap3isp device tree support 2014-01-08 11:55 ` Julien BERAUD @ 2014-01-09 18:14 ` Enrico 2014-01-10 9:02 ` Julien BERAUD 0 siblings, 1 reply; 28+ messages in thread From: Enrico @ 2014-01-09 18:14 UTC (permalink / raw) To: Julien BERAUD; +Cc: florian.vaussard, linux-media, Laurent Pinchart On Wed, Jan 8, 2014 at 12:55 PM, Julien BERAUD <julien.beraud@parrot.com> wrote: > > Le 07/01/2014 11:12, Enrico a écrit : > >> On Mon, Jan 6, 2014 at 11:11 AM, Julien BERAUD <julien.beraud@parrot.com> >> wrote: >>> >>> Le 03/01/2014 12:30, Enrico a écrit : >>>> >>>> On Wed, Dec 18, 2013 at 11:09 AM, Enrico <ebutera@users.berlios.de> >>>> wrote: >>>>> >>>>> On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard >>>>> <florian.vaussard@epfl.ch> wrote: >>>>>> >>>>>> So I converted the iommu to DT (patches just sent), used pdata quirks >>>>>> for the isp / mtv9032 data, added a few patches from other people >>>>>> (mainly clk to fix a crash when deferring the omap3isp probe), and a >>>>>> few >>>>>> small hacks. I get a 3.13-rc3 (+ board-removal part from Tony >>>>>> Lindgren) >>>>>> to boot on DT with a working MT9V032 camera. The missing part is the >>>>>> DT >>>>>> binding for the omap3isp, but I guess that we will have to wait a bit >>>>>> more for this. >>>>>> >>>>>> If you want to test, I have a development tree here [1]. Any feedback >>>>>> is >>>>>> welcome. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Florian >>>>>> >>>>>> [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt >>>>> >>>>> Thanks Florian, >>>>> >>>>> i will report what i get with my setup. >>>> >>>> And here i am. >>>> >>>> I can confirm it works, video source is tvp5150 (with platform data in >>>> pdata-quirks.c) in bt656 mode. >>>> >>>> Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so >>>> if you want to push it you can add a Tested-by me. >>>> >>>> There is only one problem, but it's unrelated to your DT work. >>>> >>>> It's an old problem (see for example [1] and [2]), seen by other >>>> people too and it seems it's still there. >>>> Basically if i capture with yavta while the system is idle then it >>>> just waits without getting any frame. >>>> If i add some cpu load (usually i do a "cat /dev/zero" in a ssh >>>> terminal) it starts capturing correctly. >>>> >>>> The strange thing is that i do get isp interrupts in the idle case, so >>>> i don't know why they don't "propagate" to yavta. >>>> >>>> Any hints on how to debug this? >>>> >>>> Enrico >>>> >>>> [1]: https://linuxtv.org/patch/7836/ >>>> [2]: >>>> https://www.mail-archive.com/linux-media@vger.kernel.org/msg44923.html >>> >>> I have had what looked a lot like these problems before and it was due to >>> a >>> wrong configuration of the ccdc cropping regarding to the blanking. Could >>> you send me the configuration of the pipeline that you apply with >>> media-ctl, >>> just in case this is the same problem. >> >> i'm using: >> >> media-ctl -r -l '"tvp5150 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP >> CCDC":1->"OMAP3 ISP CCDC output":0[1]' >> media-ctl --set-format '"tvp5150 2-005c":0 [UYVY 720x625]' >> >> And then capture with yavta -s 720x625 (or 720x576, can't remember right >> now). >> >> Thanks, >> >> Enrico > > I don't think this is sufficient, though I am no expert about omap3 isp, you > should configure the format of the ccdc input and of the ccdc output too. > When I had this problem, it was solved by adding cropping at the input of > the CCDC, corresponding to the blanking period, which was : > - media-ctl -v -f '"OMAP3 ISP CCDC":0 [UYVY2X8 720x576 (0,49/720x576)]' > or > - media-ctl -v -f '"OMAP3 ISP CCDC":0 [UYVY2X8 720x480 (0,45/720x480)]' > respectively. > > I don't know if this can be of any help. > > Regards, > Julien BERAUD It seems i can't set cropping at the CCDC input (sink), but i can on output (source): - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 pad0: Sink [fmt:UYVY2X8/720x625] <- "OMAP3 ISP CCP2":1 [] <- "OMAP3 ISP CSI2a":1 [] <- "tvp5150 1-005c":0 [ENABLED] pad1: Source [fmt:UYVY2X8/720x576 crop.bounds:(0,0)/720x624 crop:(0,48)/720x576] -> "OMAP3 ISP CCDC output":0 [ENABLED] -> "OMAP3 ISP resizer":0 [] pad2: Source [fmt:unknown/720x624] -> "OMAP3 ISP preview":0 [] -> "OMAP3 ISP AEWB":0 [ENABLED,IMMUTABLE] -> "OMAP3 ISP AF":0 [ENABLED,IMMUTABLE] -> "OMAP3 ISP histogram":0 [ENABLED,IMMUTABLE] The strange thing is that with these settings the situation is even worse, i don't get any frames in yavta (while i see interrupts on omap3isp) even with the "cat /dev/zero" trick. So you are right, playing with cropping can make it work or not, are you sure you could set cropping at the ccdc input? Enrico ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: omap3isp device tree support 2014-01-09 18:14 ` Enrico @ 2014-01-10 9:02 ` Julien BERAUD 2014-02-07 10:24 ` Enrico 0 siblings, 1 reply; 28+ messages in thread From: Julien BERAUD @ 2014-01-10 9:02 UTC (permalink / raw) To: Enrico; +Cc: florian.vaussard, linux-media, Laurent Pinchart Le 09/01/2014 19:14, Enrico a écrit : > On Wed, Jan 8, 2014 at 12:55 PM, Julien BERAUD <julien.beraud@parrot.com> wrote: >> Le 07/01/2014 11:12, Enrico a écrit : >> >>> On Mon, Jan 6, 2014 at 11:11 AM, Julien BERAUD <julien.beraud@parrot.com> >>> wrote: >>>> Le 03/01/2014 12:30, Enrico a écrit : >>>>> On Wed, Dec 18, 2013 at 11:09 AM, Enrico <ebutera@users.berlios.de> >>>>> wrote: >>>>>> On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard >>>>>> <florian.vaussard@epfl.ch> wrote: >>>>>>> So I converted the iommu to DT (patches just sent), used pdata quirks >>>>>>> for the isp / mtv9032 data, added a few patches from other people >>>>>>> (mainly clk to fix a crash when deferring the omap3isp probe), and a >>>>>>> few >>>>>>> small hacks. I get a 3.13-rc3 (+ board-removal part from Tony >>>>>>> Lindgren) >>>>>>> to boot on DT with a working MT9V032 camera. The missing part is the >>>>>>> DT >>>>>>> binding for the omap3isp, but I guess that we will have to wait a bit >>>>>>> more for this. >>>>>>> >>>>>>> If you want to test, I have a development tree here [1]. Any feedback >>>>>>> is >>>>>>> welcome. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Florian >>>>>>> >>>>>>> [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt >>>>>> Thanks Florian, >>>>>> >>>>>> i will report what i get with my setup. >>>>> And here i am. >>>>> >>>>> I can confirm it works, video source is tvp5150 (with platform data in >>>>> pdata-quirks.c) in bt656 mode. >>>>> >>>>> Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so >>>>> if you want to push it you can add a Tested-by me. >>>>> >>>>> There is only one problem, but it's unrelated to your DT work. >>>>> >>>>> It's an old problem (see for example [1] and [2]), seen by other >>>>> people too and it seems it's still there. >>>>> Basically if i capture with yavta while the system is idle then it >>>>> just waits without getting any frame. >>>>> If i add some cpu load (usually i do a "cat /dev/zero" in a ssh >>>>> terminal) it starts capturing correctly. >>>>> >>>>> The strange thing is that i do get isp interrupts in the idle case, so >>>>> i don't know why they don't "propagate" to yavta. >>>>> >>>>> Any hints on how to debug this? >>>>> >>>>> Enrico >>>>> >>>>> [1]: https://linuxtv.org/patch/7836/ >>>>> [2]: >>>>> https://www.mail-archive.com/linux-media@vger.kernel.org/msg44923.html >>>> I have had what looked a lot like these problems before and it was due to >>>> a >>>> wrong configuration of the ccdc cropping regarding to the blanking. Could >>>> you send me the configuration of the pipeline that you apply with >>>> media-ctl, >>>> just in case this is the same problem. >>> i'm using: >>> >>> media-ctl -r -l '"tvp5150 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP >>> CCDC":1->"OMAP3 ISP CCDC output":0[1]' >>> media-ctl --set-format '"tvp5150 2-005c":0 [UYVY 720x625]' >>> >>> And then capture with yavta -s 720x625 (or 720x576, can't remember right >>> now). >>> >>> Thanks, >>> >>> Enrico >> I don't think this is sufficient, though I am no expert about omap3 isp, you >> should configure the format of the ccdc input and of the ccdc output too. >> When I had this problem, it was solved by adding cropping at the input of >> the CCDC, corresponding to the blanking period, which was : >> - media-ctl -v -f '"OMAP3 ISP CCDC":0 [UYVY2X8 720x576 (0,49/720x576)]' >> or >> - media-ctl -v -f '"OMAP3 ISP CCDC":0 [UYVY2X8 720x480 (0,45/720x480)]' >> respectively. >> >> I don't know if this can be of any help. >> >> Regards, >> Julien BERAUD > It seems i can't set cropping at the CCDC input (sink), but i can on > output (source): > > - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) > type V4L2 subdev subtype Unknown flags 0 > device node name /dev/v4l-subdev2 > pad0: Sink > [fmt:UYVY2X8/720x625] > <- "OMAP3 ISP CCP2":1 [] > <- "OMAP3 ISP CSI2a":1 [] > <- "tvp5150 1-005c":0 [ENABLED] > pad1: Source > [fmt:UYVY2X8/720x576 > crop.bounds:(0,0)/720x624 > crop:(0,48)/720x576] > -> "OMAP3 ISP CCDC output":0 [ENABLED] > -> "OMAP3 ISP resizer":0 [] > pad2: Source > [fmt:unknown/720x624] > -> "OMAP3 ISP preview":0 [] > -> "OMAP3 ISP AEWB":0 [ENABLED,IMMUTABLE] > -> "OMAP3 ISP AF":0 [ENABLED,IMMUTABLE] > -> "OMAP3 ISP histogram":0 [ENABLED,IMMUTABLE] > > The strange thing is that with these settings the situation is even > worse, i don't get any frames in yavta (while i see interrupts on > omap3isp) even with the "cat /dev/zero" trick. > > So you are right, playing with cropping can make it work or not, are > you sure you could set cropping at the ccdc input? > > Enrico Enrico, Sorry it didn't work. I just wanted to give a hint of what could be going wrong. I am sorry I don't have time to investigate, I am sure I could set the cropping at the input of ccdc, and that the result was to write register ISPCCDC_VERT_START in order to skip the vertical blanking period correctly. The branch I was on was a bit different though. If you want to investigate this issue, you will at least need to see what is written in the registers of the ISP. Regards, Julien ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: omap3isp device tree support 2014-01-10 9:02 ` Julien BERAUD @ 2014-02-07 10:24 ` Enrico 0 siblings, 0 replies; 28+ messages in thread From: Enrico @ 2014-02-07 10:24 UTC (permalink / raw) To: Julien BERAUD, Laurent Pinchart; +Cc: florian.vaussard, linux-media On Fri, Jan 10, 2014 at 10:02 AM, Julien BERAUD <julien.beraud@parrot.com> wrote: > > Le 09/01/2014 19:14, Enrico a écrit : > >> On Wed, Jan 8, 2014 at 12:55 PM, Julien BERAUD <julien.beraud@parrot.com> >> wrote: >>> >>> Le 07/01/2014 11:12, Enrico a écrit : >>> >>>> On Mon, Jan 6, 2014 at 11:11 AM, Julien BERAUD >>>> <julien.beraud@parrot.com> >>>> wrote: >>>>> >>>>> Le 03/01/2014 12:30, Enrico a écrit : >>>>>> >>>>>> On Wed, Dec 18, 2013 at 11:09 AM, Enrico <ebutera@users.berlios.de> >>>>>> wrote: >>>>>>> >>>>>>> On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard >>>>>>> <florian.vaussard@epfl.ch> wrote: >>>>>>>> >>>>>>>> So I converted the iommu to DT (patches just sent), used pdata >>>>>>>> quirks >>>>>>>> for the isp / mtv9032 data, added a few patches from other people >>>>>>>> (mainly clk to fix a crash when deferring the omap3isp probe), and a >>>>>>>> few >>>>>>>> small hacks. I get a 3.13-rc3 (+ board-removal part from Tony >>>>>>>> Lindgren) >>>>>>>> to boot on DT with a working MT9V032 camera. The missing part is the >>>>>>>> DT >>>>>>>> binding for the omap3isp, but I guess that we will have to wait a >>>>>>>> bit >>>>>>>> more for this. >>>>>>>> >>>>>>>> If you want to test, I have a development tree here [1]. Any >>>>>>>> feedback >>>>>>>> is >>>>>>>> welcome. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Florian >>>>>>>> >>>>>>>> [1] >>>>>>>> https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt >>>>>>> >>>>>>> Thanks Florian, >>>>>>> >>>>>>> i will report what i get with my setup. >>>>>> >>>>>> And here i am. >>>>>> >>>>>> I can confirm it works, video source is tvp5150 (with platform data in >>>>>> pdata-quirks.c) in bt656 mode. >>>>>> >>>>>> Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so >>>>>> if you want to push it you can add a Tested-by me. >>>>>> >>>>>> There is only one problem, but it's unrelated to your DT work. >>>>>> >>>>>> It's an old problem (see for example [1] and [2]), seen by other >>>>>> people too and it seems it's still there. >>>>>> Basically if i capture with yavta while the system is idle then it >>>>>> just waits without getting any frame. >>>>>> If i add some cpu load (usually i do a "cat /dev/zero" in a ssh >>>>>> terminal) it starts capturing correctly. >>>>>> >>>>>> The strange thing is that i do get isp interrupts in the idle case, so >>>>>> i don't know why they don't "propagate" to yavta. >>>>>> >>>>>> Any hints on how to debug this? >>>>>> >>>>>> Enrico >>>>>> >>>>>> [1]: https://linuxtv.org/patch/7836/ >>>>>> [2]: >>>>>> a https://www.mail-archive.com/linux-media@vger.kernel.org/msg44923.html >>>>> >>>>> I have had what looked a lot like these problems before and it was due >>>>> to >>>>> a >>>>> wrong configuration of the ccdc cropping regarding to the blanking. >>>>> Could >>>>> you send me the configuration of the pipeline that you apply with >>>>> media-ctl, >>>>> just in case this is the same problem. >>>> >>>> i'm using: >>>> >>>> media-ctl -r -l '"tvp5150 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP >>>> CCDC":1->"OMAP3 ISP CCDC output":0[1]' >>>> media-ctl --set-format '"tvp5150 2-005c":0 [UYVY 720x625]' >>>> >>>> And then capture with yavta -s 720x625 (or 720x576, can't remember right >>>> now). >>>> >>>> Thanks, >>>> >>>> Enrico >>> >>> I don't think this is sufficient, though I am no expert about omap3 isp, >>> you >>> should configure the format of the ccdc input and of the ccdc output too. >>> When I had this problem, it was solved by adding cropping at the input of >>> the CCDC, corresponding to the blanking period, which was : >>> - media-ctl -v -f '"OMAP3 ISP CCDC":0 [UYVY2X8 720x576 (0,49/720x576)]' >>> or >>> - media-ctl -v -f '"OMAP3 ISP CCDC":0 [UYVY2X8 720x480 (0,45/720x480)]' >>> respectively. >>> >>> I don't know if this can be of any help. >>> >>> Regards, >>> Julien BERAUD >> >> It seems i can't set cropping at the CCDC input (sink), but i can on >> output (source): >> >> - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) >> type V4L2 subdev subtype Unknown flags 0 >> device node name /dev/v4l-subdev2 >> pad0: Sink >> [fmt:UYVY2X8/720x625] >> <- "OMAP3 ISP CCP2":1 [] >> <- "OMAP3 ISP CSI2a":1 [] >> <- "tvp5150 1-005c":0 [ENABLED] >> pad1: Source >> [fmt:UYVY2X8/720x576 >> crop.bounds:(0,0)/720x624 >> crop:(0,48)/720x576] >> -> "OMAP3 ISP CCDC output":0 [ENABLED] >> -> "OMAP3 ISP resizer":0 [] >> pad2: Source >> [fmt:unknown/720x624] >> -> "OMAP3 ISP preview":0 [] >> -> "OMAP3 ISP AEWB":0 [ENABLED,IMMUTABLE] >> -> "OMAP3 ISP AF":0 [ENABLED,IMMUTABLE] >> -> "OMAP3 ISP histogram":0 [ENABLED,IMMUTABLE] >> >> The strange thing is that with these settings the situation is even >> worse, i don't get any frames in yavta (while i see interrupts on >> omap3isp) even with the "cat /dev/zero" trick. >> >> So you are right, playing with cropping can make it work or not, are >> you sure you could set cropping at the ccdc input? >> >> Enrico > > Enrico, > > Sorry it didn't work. I just wanted to give a hint of what could be going > wrong. I am sorry I don't have time to investigate, I am sure I could set > the cropping at the input of ccdc, and that the result was to write register > ISPCCDC_VERT_START in order to skip the vertical blanking period correctly. > The branch I was on was a bit different though. If you want to investigate > this issue, you will at least need to see what is written in the registers > of the ISP. > > Regards, > Julien I think i nailed down the problem, the fix is really simple but a better solution should be implemented: i noticed that when the system is idle i was getting no frames with yavta because FLDSTAT was always 0 and ccdc_isr_buffer was never called. In bt656 mode the VD0 interrupt is setup with (format->height/2 - 2), probably when the system is idle it doesn't "react" and process the interrupt soon enough so it will always get the FLDSTAT of the same field (top or bottom). Using (format->height/2 - 3) fix the problem (FLDSTAT toggles) BUT now you have tons of "CCDC won't become idle.." because the default ccdc_sbl_wait_idle(ccdc, 1000) is not enough to get the end of field. Increasing it to 2ms helps but since we are in interrupt context i suppose i'm delaying ALL the system so this is really ugly. I think the real solution should be to use VD0 and VD1 interrupts, one to get the current FLDSTAT and the other for ccdc_sbl_wait_idle..... What do you think? Enrico ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: omap3isp device tree support 2014-01-03 11:30 ` Enrico 2014-01-06 10:11 ` Julien BERAUD @ 2014-01-07 16:59 ` Laurent Pinchart 2014-01-09 20:26 ` Florian Vaussard 2014-01-09 23:14 ` Enrico 1 sibling, 2 replies; 28+ messages in thread From: Laurent Pinchart @ 2014-01-07 16:59 UTC (permalink / raw) To: Enrico; +Cc: florian.vaussard, linux-media Hi Enrico, On Friday 03 January 2014 12:30:33 Enrico wrote: > On Wed, Dec 18, 2013 at 11:09 AM, Enrico wrote: > > On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard wrote: > >> So I converted the iommu to DT (patches just sent), Florian, I've used your patches as a base for OMAP3 ISP DT work and they seem pretty good (although patch 1/7 will need to be reworked, but that's not a blocker). I've just had to fix a problem with the OMAP3 IOMMU, please see http://git.linuxtv.org/pinchartl/media.git/commit/d3abafde0277f168df0b2912b5d84550590d80b2 I'd appreciate your comments on that. I can post the patch already if you think that would be helpful. You can find my work-in-progress branch at http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp/dt (the last three patches are definitely not complete yet). > >> used pdata quirks for the isp / mtv9032 data, added a few patches from > >> other people (mainly clk to fix a crash when deferring the omap3isp > >> probe), and a few small hacks. I get a 3.13-rc3 (+ board-removal part > >> from Tony Lindgren) to boot on DT with a working MT9V032 camera. The > >> missing part is the DT binding for the omap3isp, but I guess that we will > >> have to wait a bit more for this. > >> > >> If you want to test, I have a development tree here [1]. Any feedback is > >> welcome. > >> > >> Cheers, > >> > >> Florian > >> > >> [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt > > > > Thanks Florian, > > > > i will report what i get with my setup. > > And here i am. > > I can confirm it works, video source is tvp5150 (with platform data in > pdata-quirks.c) in bt656 mode. > > Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so > if you want to push it you can add a Tested-by me. The second patch is not clean enough in my opinion. I need to find time to work on it. I had set some time aside for OMAP3 ISP development last week but I've ended up working on DT support (not done yet, I've worked with Sakari and he might finish the job in the upcoming weeks) instead of BT.656. I'm afraid this will have to wait for around three weeks. > There is only one problem, but it's unrelated to your DT work. > > It's an old problem (see for example [1] and [2]), seen by other > people too and it seems it's still there. > Basically if i capture with yavta while the system is idle then it > just waits without getting any frame. > If i add some cpu load (usually i do a "cat /dev/zero" in a ssh > terminal) it starts capturing correctly. > > The strange thing is that i do get isp interrupts in the idle case, so > i don't know why they don't "propagate" to yavta. > > Any hints on how to debug this? > > Enrico > > [1]: https://linuxtv.org/patch/7836/ > [2]: https://www.mail-archive.com/linux-media@vger.kernel.org/msg44923.html -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: omap3isp device tree support 2014-01-07 16:59 ` Laurent Pinchart @ 2014-01-09 20:26 ` Florian Vaussard 2014-01-09 20:49 ` Laurent Pinchart 2014-01-09 23:14 ` Enrico 1 sibling, 1 reply; 28+ messages in thread From: Florian Vaussard @ 2014-01-09 20:26 UTC (permalink / raw) To: Laurent Pinchart, Enrico; +Cc: linux-media, Sebastian Reichel Hi Laurant, On 01/07/2014 05:59 PM, Laurent Pinchart wrote: > Hi Enrico, > > On Friday 03 January 2014 12:30:33 Enrico wrote: >> On Wed, Dec 18, 2013 at 11:09 AM, Enrico wrote: >>> On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard wrote: >>>> So I converted the iommu to DT (patches just sent), > > Florian, I've used your patches as a base for OMAP3 ISP DT work and they seem > pretty good (although patch 1/7 will need to be reworked, but that's not a > blocker). I've just had to fix a problem with the OMAP3 IOMMU, please see > > http://git.linuxtv.org/pinchartl/media.git/commit/d3abafde0277f168df0b2912b5d84550590d80b2 > According to the comments on the IOMMU/DT patches [1], some work is still needed to merge these patches, mainly to support other IOMMUs (OMAP4, OMAP5). So the current base is probably ok. I will resume my work on this soon. What are your comments on patch 1? I briefly looked at your fix, seems ok to me. I do not figure out how it worked for me. I will look at it closer next week. > I'd appreciate your comments on that. I can post the patch already if you > think that would be helpful. > It is probably better to wait for the v2 of the iommu series. I can include your patch in it. > You can find my work-in-progress branch at > > http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp/dt > > (the last three patches are definitely not complete yet). > Great news! A while ago, Sebastian Reichel (in CC) posted an RFC for the binding [2]. Are you working with him on this? Regards, Florian [1] https://lkml.org/lkml/2013/12/17/197 [2] http://thread.gmane.org/gmane.linux.drivers.devicetree/50580 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: omap3isp device tree support 2014-01-09 20:26 ` Florian Vaussard @ 2014-01-09 20:49 ` Laurent Pinchart 2014-01-09 20:54 ` Florian Vaussard 2014-01-09 21:30 ` Sebastian Reichel 0 siblings, 2 replies; 28+ messages in thread From: Laurent Pinchart @ 2014-01-09 20:49 UTC (permalink / raw) To: florian.vaussard; +Cc: Enrico, linux-media, Sebastian Reichel Hi Florian, On Thursday 09 January 2014 21:26:58 Florian Vaussard wrote: > On 01/07/2014 05:59 PM, Laurent Pinchart wrote: > > On Friday 03 January 2014 12:30:33 Enrico wrote: > >> On Wed, Dec 18, 2013 at 11:09 AM, Enrico wrote: > >>> On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard wrote: > >>>> So I converted the iommu to DT (patches just sent), > > > > Florian, I've used your patches as a base for OMAP3 ISP DT work and they > > seem pretty good (although patch 1/7 will need to be reworked, but that's > > not a blocker). I've just had to fix a problem with the OMAP3 IOMMU, > > please see > > > > http://git.linuxtv.org/pinchartl/media.git/commit/d3abafde0277f168df0b2912 > > b5d84550590d80b2 > > According to the comments on the IOMMU/DT patches [1], some work is still > needed to merge these patches, mainly to support other IOMMUs (OMAP4, > OMAP5). Sure, the code need to be reworked, but I believe it's going in the right direction and shouldn't be too complex to fix. > So the current base is probably ok. I will resume my work on this soon. Great, thanks. > What are your comments on patch 1? I just agree with Suman that there can be multiple IOMMUs and that the bus_set_iommu() call should thus be kept in the init function. The current infrastructure allows multiple IOMMUs to coexist as long as they're of the same type (I'm pretty sure we'll have to fix that at some point). I believe the problem that patch 1/7 tries to fix is actually the right behaviour. > I briefly looked at your fix, seems ok to me. I do not figure out how it > worked for me. I was puzzled by that as well :-) > I will look at it closer next week. > > > I'd appreciate your comments on that. I can post the patch already if you > > think that would be helpful. > > It is probably better to wait for the v2 of the iommu series. I can include > your patch in it. Please feel free to do so. > > You can find my work-in-progress branch at > > > > http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp/dt > > > > (the last three patches are definitely not complete yet). > > Great news! A while ago, Sebastian Reichel (in CC) posted an RFC for the > binding [2]. Are you working with him on this? No, I've replied to Sebastian's patch but haven't received any answer. My main concern is that the proposal didn't use the V4L2 DT bindings to describe the pipeline. > [1] https://lkml.org/lkml/2013/12/17/197 > [2] http://thread.gmane.org/gmane.linux.drivers.devicetree/50580 -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: omap3isp device tree support 2014-01-09 20:49 ` Laurent Pinchart @ 2014-01-09 20:54 ` Florian Vaussard 2014-01-09 21:30 ` Sebastian Reichel 1 sibling, 0 replies; 28+ messages in thread From: Florian Vaussard @ 2014-01-09 20:54 UTC (permalink / raw) To: Laurent Pinchart; +Cc: Enrico, linux-media, Sebastian Reichel Hi, On 01/09/2014 09:49 PM, Laurent Pinchart wrote: > Hi Florian, > > On Thursday 09 January 2014 21:26:58 Florian Vaussard wrote: >> On 01/07/2014 05:59 PM, Laurent Pinchart wrote: >>> On Friday 03 January 2014 12:30:33 Enrico wrote: >>>> On Wed, Dec 18, 2013 at 11:09 AM, Enrico wrote: >>>>> On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard wrote: >>>>>> So I converted the iommu to DT (patches just sent), >>> >>> Florian, I've used your patches as a base for OMAP3 ISP DT work and they >>> seem pretty good (although patch 1/7 will need to be reworked, but that's >>> not a blocker). I've just had to fix a problem with the OMAP3 IOMMU, >>> please see >>> >>> http://git.linuxtv.org/pinchartl/media.git/commit/d3abafde0277f168df0b2912 >>> b5d84550590d80b2 >> >> According to the comments on the IOMMU/DT patches [1], some work is still >> needed to merge these patches, mainly to support other IOMMUs (OMAP4, >> OMAP5). > > Sure, the code need to be reworked, but I believe it's going in the right > direction and shouldn't be too complex to fix. > >> So the current base is probably ok. I will resume my work on this soon. > > Great, thanks. > >> What are your comments on patch 1? > > I just agree with Suman that there can be multiple IOMMUs and that the > bus_set_iommu() call should thus be kept in the init function. The current > infrastructure allows multiple IOMMUs to coexist as long as they're of the > same type (I'm pretty sure we'll have to fix that at some point). I believe > the problem that patch 1/7 tries to fix is actually the right behaviour. > Yes I agree also with Suman, even if I do not really like the current "trick". With the move to DT, we can probably use something like <phandle> <-> consumer relations to improve this. >> I briefly looked at your fix, seems ok to me. I do not figure out how it >> worked for me. > > I was puzzled by that as well :-) > Will dig into this next week as well. Regards, Florian ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: omap3isp device tree support 2014-01-09 20:49 ` Laurent Pinchart 2014-01-09 20:54 ` Florian Vaussard @ 2014-01-09 21:30 ` Sebastian Reichel 1 sibling, 0 replies; 28+ messages in thread From: Sebastian Reichel @ 2014-01-09 21:30 UTC (permalink / raw) To: Laurent Pinchart; +Cc: florian.vaussard, Enrico, linux-media [-- Attachment #1: Type: text/plain, Size: 909 bytes --] Hi, On Thu, Jan 09, 2014 at 09:49:09PM +0100, Laurent Pinchart wrote: > > > You can find my work-in-progress branch at > > > > > > http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp/dt > > > > > > (the last three patches are definitely not complete yet). > > > > Great news! A while ago, Sebastian Reichel (in CC) posted an RFC for the > > binding [2]. Are you working with him on this? > > No, I've replied to Sebastian's patch but haven't received any answer. My main > concern is that the proposal didn't use the V4L2 DT bindings to describe the > pipeline. ah sorry I thought I replied to this mail. I acknowledge all concerns, which I received in the reply. I have not yet found time to continue on DT for omap3isp. P.S.: I will continue this when I find time, but I definitely don't feel offended if somebody else wants to continue ;) -- Sebastian [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: omap3isp device tree support 2014-01-07 16:59 ` Laurent Pinchart 2014-01-09 20:26 ` Florian Vaussard @ 2014-01-09 23:14 ` Enrico 2014-01-10 0:00 ` Laurent Pinchart 1 sibling, 1 reply; 28+ messages in thread From: Enrico @ 2014-01-09 23:14 UTC (permalink / raw) To: Laurent Pinchart; +Cc: linux-media On Tue, Jan 7, 2014 at 5:59 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Hi Enrico, > > On Friday 03 January 2014 12:30:33 Enrico wrote: >> On Wed, Dec 18, 2013 at 11:09 AM, Enrico wrote: >> > On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard wrote: >> >> So I converted the iommu to DT (patches just sent), > > Florian, I've used your patches as a base for OMAP3 ISP DT work and they seem > pretty good (although patch 1/7 will need to be reworked, but that's not a > blocker). I've just had to fix a problem with the OMAP3 IOMMU, please see > > http://git.linuxtv.org/pinchartl/media.git/commit/d3abafde0277f168df0b2912b5d84550590d80b2 > > I'd appreciate your comments on that. I can post the patch already if you > think that would be helpful. > > You can find my work-in-progress branch at > > http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp/dt > > (the last three patches are definitely not complete yet). > >> >> used pdata quirks for the isp / mtv9032 data, added a few patches from >> >> other people (mainly clk to fix a crash when deferring the omap3isp >> >> probe), and a few small hacks. I get a 3.13-rc3 (+ board-removal part >> >> from Tony Lindgren) to boot on DT with a working MT9V032 camera. The >> >> missing part is the DT binding for the omap3isp, but I guess that we will >> >> have to wait a bit more for this. >> >> >> >> If you want to test, I have a development tree here [1]. Any feedback is >> >> welcome. >> >> >> >> Cheers, >> >> >> >> Florian >> >> >> >> [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt >> > >> > Thanks Florian, >> > >> > i will report what i get with my setup. >> >> And here i am. >> >> I can confirm it works, video source is tvp5150 (with platform data in >> pdata-quirks.c) in bt656 mode. >> >> Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so >> if you want to push it you can add a Tested-by me. > > The second patch is not clean enough in my opinion. I need to find time to > work on it. I had set some time aside for OMAP3 ISP development last week but > I've ended up working on DT support (not done yet, I've worked with Sakari and > he might finish the job in the upcoming weeks) instead of BT.656. I'm afraid > this will have to wait for around three weeks. Yes i know the history of those patches, and if i'm not wrong you didn't have the hardware to test them so i just wanted to confirm that they work (apart from the other problem). Enrico ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: omap3isp device tree support 2014-01-09 23:14 ` Enrico @ 2014-01-10 0:00 ` Laurent Pinchart 0 siblings, 0 replies; 28+ messages in thread From: Laurent Pinchart @ 2014-01-10 0:00 UTC (permalink / raw) To: Enrico; +Cc: linux-media Hi Enrico, On Friday 10 January 2014 00:14:47 Enrico wrote: > On Tue, Jan 7, 2014 at 5:59 PM, Laurent Pinchart wrote: > > On Friday 03 January 2014 12:30:33 Enrico wrote: > >> On Wed, Dec 18, 2013 at 11:09 AM, Enrico wrote: > >> > On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard wrote: > >> >> So I converted the iommu to DT (patches just sent), > > > > Florian, I've used your patches as a base for OMAP3 ISP DT work and they > > seem pretty good (although patch 1/7 will need to be reworked, but that's > > not a blocker). I've just had to fix a problem with the OMAP3 IOMMU, > > please see > > > > http://git.linuxtv.org/pinchartl/media.git/commit/d3abafde0277f168df0b2912 > > b5d84550590d80b2 > > > > I'd appreciate your comments on that. I can post the patch already if you > > think that would be helpful. > > > > You can find my work-in-progress branch at > > > > http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp/dt > > > > (the last three patches are definitely not complete yet). > > > >> >> used pdata quirks for the isp / mtv9032 data, added a few patches from > >> >> other people (mainly clk to fix a crash when deferring the omap3isp > >> >> probe), and a few small hacks. I get a 3.13-rc3 (+ board-removal part > >> >> from Tony Lindgren) to boot on DT with a working MT9V032 camera. The > >> >> missing part is the DT binding for the omap3isp, but I guess that we > >> >> will have to wait a bit more for this. > >> >> > >> >> If you want to test, I have a development tree here [1]. Any feedback > >> >> is welcome. > >> >> > >> >> Cheers, > >> >> > >> >> Florian > >> >> > >> >> [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt > >> > > >> > Thanks Florian, > >> > > >> > i will report what i get with my setup. > >> > >> And here i am. > >> > >> I can confirm it works, video source is tvp5150 (with platform data in > >> pdata-quirks.c) in bt656 mode. > >> > >> Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so > >> if you want to push it you can add a Tested-by me. > > > > The second patch is not clean enough in my opinion. I need to find time to > > work on it. I had set some time aside for OMAP3 ISP development last week > > but I've ended up working on DT support (not done yet, I've worked with > > Sakari and he might finish the job in the upcoming weeks) instead of > > BT.656. I'm afraid this will have to wait for around three weeks. > > Yes i know the history of those patches, and if i'm not wrong you > didn't have the hardware to test them so i just wanted to confirm that > they work (apart from the other problem). That's correct, but thanks to a generous donator (who I'm not sure I can name) I now have the hardware, I just need to find time :-) -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: omap3isp device tree support 2013-12-06 10:13 omap3isp device tree support Enrico 2013-12-06 10:31 ` Florian Vaussard @ 2013-12-09 13:11 ` Laurent Pinchart 1 sibling, 0 replies; 28+ messages in thread From: Laurent Pinchart @ 2013-12-09 13:11 UTC (permalink / raw) To: Enrico; +Cc: linux-media Hi Enrico, On Friday 06 December 2013 11:13:50 Enrico wrote: > Hi, > > i know there is some work going on for omap3isp device tree support, > but right now is it possible to enable it in some other way in a DT > kernel? > > I've tried enabling it in board-generic.c (omap3_init_camera(...) with > proper platform data) but it hangs early at boot, do someone know if > it's possible and how to do it? Here's what I currently use to test the mt9v032 driver on my Beagleboard-xM with a mainline kernel. If you need proper regulators support it will get more complex. commit 9184392db932be81ea9d33080c1740c3a20f5132 Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Date: Mon Jun 20 13:21:17 2011 +0200 board-omap3beagle: Add support for the MT9V034 sensor module Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 1f25f3e..8bc8695 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -239,7 +239,8 @@ obj-$(CONFIG_SOC_OMAP2420) += msdi.o obj-$(CONFIG_MACH_OMAP_GENERIC) += board-generic.o pdata-quirks.o obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o obj-$(CONFIG_MACH_OMAP_2430SDP) += board-2430sdp.o -obj-$(CONFIG_MACH_OMAP3_BEAGLE) += board-omap3beagle.o +obj-$(CONFIG_MACH_OMAP3_BEAGLE) += board-omap3beagle.o \ + board-omap3beagle-camera.o obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o obj-$(CONFIG_MACH_OMAP_LDP) += board-ldp.o obj-$(CONFIG_MACH_OMAP3530_LV_SOM) += board-omap3logic.o diff --git a/arch/arm/mach-omap2/board-omap3beagle-camera.c b/arch/arm/mach-omap2/board-omap3beagle-camera.c new file mode 100644 index 0000000..c927c23 --- /dev/null +++ b/arch/arm/mach-omap2/board-omap3beagle-camera.c @@ -0,0 +1,93 @@ +/* + * arch/arm/mach-omap2/board-omap3beagle-camera.c + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include <asm/mach-types.h> +#include <linux/clk.h> +#include <linux/i2c.h> +#include <linux/regulator/fixed.h> +#include <linux/regulator/machine.h> +#include <plat/cpu.h> +#include <plat/i2c.h> + +#include <media/mt9v032.h> +#include <media/omap3isp.h> + +#include "devices.h" + +#define MT9V034_RESET_GPIO 98 + +static struct regulator_consumer_supply mt9v034_dummy_supplies[] = { + REGULATOR_SUPPLY("vaa", "3-0048"), + REGULATOR_SUPPLY("vdd", "3-0048"), + REGULATOR_SUPPLY("vdd_io", "3-0048"), +}; + +static const s64 mt9v034_link_freqs[] = { + 13000000, + 26600000, + 27000000, + 0, +}; + +static struct mt9v032_platform_data beagle_mt9v034_platform_data = { + .clk_pol = 0, + .link_freqs = mt9v034_link_freqs, + .link_def_freq = 26600000, +}; + +static struct i2c_board_info mt9v034_camera_i2c_device = { + I2C_BOARD_INFO("mt9v034", 0x48), + .platform_data = &beagle_mt9v034_platform_data, +}; + +static struct isp_subdev_i2c_board_info mt9v034_camera_subdevs[] = { + { + .board_info = &mt9v034_camera_i2c_device, + .i2c_adapter_id = 3, + }, + { NULL, 0, }, +}; + +static struct isp_v4l2_subdevs_group beagle_camera_subdevs[] = { + { + .subdevs = mt9v034_camera_subdevs, + .interface = ISP_INTERFACE_PARALLEL, + .bus = { + .parallel = { + .data_lane_shift = ISP_LANE_SHIFT_2, + .clk_pol = 0, + } + }, + }, + { }, +}; + +static struct isp_platform_data beagle_isp_platform_data = { + .xclks = { + [0] = { + .dev_id = "3-0048", + }, + }, + .subdevs = beagle_camera_subdevs, +}; + +static int __init beagle_camera_init(void) +{ + if (!of_machine_is_compatible("ti,omap3-beagle-xm")) + return 0; + + clk_add_alias(NULL, "3-0048", "cam_xclka", NULL); + + regulator_register_fixed(0, mt9v034_dummy_supplies, + ARRAY_SIZE(mt9v034_dummy_supplies)); + + omap3_init_camera(&beagle_isp_platform_data); + + return 0; +} +late_initcall(beagle_camera_init); -- Regards, Laurent Pinchart ^ permalink raw reply related [flat|nested] 28+ messages in thread
[parent not found: <CALFbYK1kEnB2_3VqpLFNtaJ7hj9UHuhrL0iO_rFHD2VFt8THFw@mail.gmail.com>]
* Re: omap3isp device tree support [not found] <CALFbYK1kEnB2_3VqpLFNtaJ7hj9UHuhrL0iO_rFHD2VFt8THFw@mail.gmail.com> @ 2014-08-05 22:19 ` Laurent Pinchart [not found] ` <CALFbYK3YtrDPGxc3UpASk7MgPTBGcd899Crvm1csY8g+j-fehg@mail.gmail.com> 0 siblings, 1 reply; 28+ messages in thread From: Laurent Pinchart @ 2014-08-05 22:19 UTC (permalink / raw) To: alaganraj sandhanam; +Cc: linux-media, sre, sakari.ailus Hi Alagan, On Wednesday 06 August 2014 03:36:19 alaganraj sandhanam wrote: > Hi Laurent, > > I want to test mt9p031 with beagleboard-xm on 3.16 kernel. > It seems device tree support for omap3isp is not upstreamed. > can you please guide me to validate the same? DT bindings for the OMAP3 ISP are unfortunately not available yet. Sakari is working on them, but I don't think he an commit to any date yet. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 28+ messages in thread
[parent not found: <CALFbYK3YtrDPGxc3UpASk7MgPTBGcd899Crvm1csY8g+j-fehg@mail.gmail.com>]
* Re: omap3isp device tree support [not found] ` <CALFbYK3YtrDPGxc3UpASk7MgPTBGcd899Crvm1csY8g+j-fehg@mail.gmail.com> @ 2014-08-05 22:41 ` Laurent Pinchart 2014-08-05 22:50 ` alaganraj sandhanam 2014-08-07 0:18 ` Sakari Ailus 1 sibling, 1 reply; 28+ messages in thread From: Laurent Pinchart @ 2014-08-05 22:41 UTC (permalink / raw) To: alaganraj sandhanam; +Cc: linux-media, sre, sakari.ailus Hi Alagan, On Wednesday 06 August 2014 04:07:58 alaganraj sandhanam wrote: > Hi Laurent, > > Thanks for the info. what about git://linuxtv.org/pinchartl/media.git > omap3isp/dt branch? > I took 3 patches from this branch, fixed > error: implicit declaration of function ‘v4l2_of_get_next_endpoint’ > by changing to "of_graph_get_next_endpoint". > > while booting i'm getting below msg > [ 1.558471] of_graph_get_next_endpoint(): no port node found in > /ocp/omap3_isp@480bc000 > [ 1.567169] omap3isp 480bc000.omap3_isp: no port node at > /ocp/omap3_isp@480bc000 > > omap3isp/dt is not working branch? The branch contains work in progress patches. If I'm not mistaken the code isn't complete and doesn't work yet. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: omap3isp device tree support 2014-08-05 22:41 ` Laurent Pinchart @ 2014-08-05 22:50 ` alaganraj sandhanam [not found] ` <1407284947.78794.YahooMailNeo@web162403.mail.bf1.yahoo.com> 0 siblings, 1 reply; 28+ messages in thread From: alaganraj sandhanam @ 2014-08-05 22:50 UTC (permalink / raw) To: Laurent Pinchart; +Cc: linux-media, sre, sakari.ailus Thanks Laurent. Regards, Alagan On Wed, Aug 6, 2014 at 4:11 AM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Hi Alagan, > > On Wednesday 06 August 2014 04:07:58 alaganraj sandhanam wrote: >> Hi Laurent, >> >> Thanks for the info. what about git://linuxtv.org/pinchartl/media.git >> omap3isp/dt branch? >> I took 3 patches from this branch, fixed >> error: implicit declaration of function ‘v4l2_of_get_next_endpoint’ >> by changing to "of_graph_get_next_endpoint". >> >> while booting i'm getting below msg >> [ 1.558471] of_graph_get_next_endpoint(): no port node found in >> /ocp/omap3_isp@480bc000 >> [ 1.567169] omap3isp 480bc000.omap3_isp: no port node at >> /ocp/omap3_isp@480bc000 >> >> omap3isp/dt is not working branch? > > The branch contains work in progress patches. If I'm not mistaken the code > isn't complete and doesn't work yet. > > -- > Regards, > > Laurent Pinchart > ^ permalink raw reply [flat|nested] 28+ messages in thread
[parent not found: <1407284947.78794.YahooMailNeo@web162403.mail.bf1.yahoo.com>]
* Re: omap3isp device tree support [not found] ` <1407284947.78794.YahooMailNeo@web162403.mail.bf1.yahoo.com> @ 2014-08-06 18:40 ` Alaganraj Sandhanam 0 siblings, 0 replies; 28+ messages in thread From: Alaganraj Sandhanam @ 2014-08-06 18:40 UTC (permalink / raw) To: Raymond Jender; +Cc: Laurent Pinchart, linux-media, sre, sakari.ailus Please send "unsubscribe linux-media" message with empty subject line to majordomo@vger.kernel.org. --------------------------------------------------------------------------------------- To: majordomo@vger.kernel.org Subject: unsubscribe linux-media --------------------------------------------------------------------------------------- Regards, Alagan On Wed, Aug 6, 2014 at 5:59 AM, Raymond Jender <rayj00@yahoo.com> wrote: > Why can't I get off this stinkin mail list? The unsubscribe email does not work! > > Get me the heII off this list! > > > > > > > On Tuesday, August 5, 2014 3:51 PM, alaganraj sandhanam <alaganraj.sandhanam@gmail.com> wrote: > > > > Thanks Laurent. > > Regards, > Alagan > > > On Wed, Aug 6, 2014 at 4:11 AM, Laurent Pinchart > <laurent.pinchart@ideasonboard.com> wrote: >> Hi Alagan, >> >> On Wednesday 06 August 2014 04:07:58 alaganraj sandhanam wrote: >>> Hi Laurent, >>> >>> Thanks for the info. what about git://linuxtv.org/pinchartl/media.git >>> omap3isp/dt branch? >>> I took 3 patches from this branch, fixed >>> error: implicit declaration of function ‘v4l2_of_get_next_endpoint’ >>> by changing to "of_graph_get_next_endpoint". >>> >>> while booting i'm getting below msg >>> [ 1.558471] of_graph_get_next_endpoint(): no port node found in >>> /ocp/omap3_isp@480bc000 >>> [ 1.567169] omap3isp 480bc000.omap3_isp: no port node at >>> /ocp/omap3_isp@480bc000 >>> >>> omap3isp/dt is not working branch? >> >> The branch contains work in progress patches. If I'm not mistaken the code >> isn't complete and doesn't work yet. >> >> -- >> Regards, >> >> Laurent Pinchart >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: omap3isp device tree support [not found] ` <CALFbYK3YtrDPGxc3UpASk7MgPTBGcd899Crvm1csY8g+j-fehg@mail.gmail.com> 2014-08-05 22:41 ` Laurent Pinchart @ 2014-08-07 0:18 ` Sakari Ailus 2014-08-07 14:39 ` Alaganraj Sandhanam 1 sibling, 1 reply; 28+ messages in thread From: Sakari Ailus @ 2014-08-07 0:18 UTC (permalink / raw) To: alaganraj sandhanam; +Cc: Laurent Pinchart, linux-media, sre Hi Alaganraj, On Wed, Aug 06, 2014 at 04:07:58AM +0530, alaganraj sandhanam wrote: > Hi Laurent, > > Thanks for the info. what about git://linuxtv.org/pinchartl/media.git > omap3isp/dt branch? > I took 3 patches from this branch, fixed > error: implicit declaration of function ‘v4l2_of_get_next_endpoint’ > by changing to "of_graph_get_next_endpoint". > > while booting i'm getting below msg > [ 1.558471] of_graph_get_next_endpoint(): no port node found in > /ocp/omap3_isp@480bc000 > [ 1.567169] omap3isp 480bc000.omap3_isp: no port node at > /ocp/omap3_isp@480bc000 > > omap3isp/dt is not working branch? My patches, while experimental, may be helpful for you. Perhaps. At the moment the issue is IOMMU; Hiroshi Doyu had some patches to get that attached to the ISP but for various reasons they didn't make it to the mainline kernel. You can find my patches here: <URL:http://vihersipuli.retiisi.org.uk/cgi-bin/gitweb.cgi?p=~sailus/linux.git;a=shortlog;h=refs/heads/rm696-041-dt> PLEASE do no clone the entire tree, but add that as a remote to an existing tree. The patches are on top of the linux-omap master branch. I think I've gotten through to sensor sub-device registration with these and the smiapp driver. I'll try to send some of the omap3isp and possibly also smiapp patches for review soon. It's unlikely to be a complete set, though. -- Kind regards, Sakari Ailus e-mail: sakari.ailus@iki.fi XMPP: sailus@retiisi.org.uk ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: omap3isp device tree support 2014-08-07 0:18 ` Sakari Ailus @ 2014-08-07 14:39 ` Alaganraj Sandhanam 0 siblings, 0 replies; 28+ messages in thread From: Alaganraj Sandhanam @ 2014-08-07 14:39 UTC (permalink / raw) To: Sakari Ailus; +Cc: Laurent Pinchart, linux-media, sre Hi Sakari, Thanks for the patches. I'll try this... Thanks&Regards, Alagan On Thu, Aug 7, 2014 at 5:48 AM, Sakari Ailus <sakari.ailus@iki.fi> wrote: > Hi Alaganraj, > > On Wed, Aug 06, 2014 at 04:07:58AM +0530, alaganraj sandhanam wrote: >> Hi Laurent, >> >> Thanks for the info. what about git://linuxtv.org/pinchartl/media.git >> omap3isp/dt branch? >> I took 3 patches from this branch, fixed >> error: implicit declaration of function ‘v4l2_of_get_next_endpoint’ >> by changing to "of_graph_get_next_endpoint". >> >> while booting i'm getting below msg >> [ 1.558471] of_graph_get_next_endpoint(): no port node found in >> /ocp/omap3_isp@480bc000 >> [ 1.567169] omap3isp 480bc000.omap3_isp: no port node at >> /ocp/omap3_isp@480bc000 >> >> omap3isp/dt is not working branch? > > My patches, while experimental, may be helpful for you. Perhaps. At the > moment the issue is IOMMU; Hiroshi Doyu had some patches to get that > attached to the ISP but for various reasons they didn't make it to the > mainline kernel. > > You can find my patches here: > > <URL:http://vihersipuli.retiisi.org.uk/cgi-bin/gitweb.cgi?p=~sailus/linux.git;a=shortlog;h=refs/heads/rm696-041-dt> > > PLEASE do no clone the entire tree, but add that as a remote to an existing > tree. The patches are on top of the linux-omap master branch. > > I think I've gotten through to sensor sub-device registration with these and > the smiapp driver. I'll try to send some of the omap3isp and possibly also > smiapp patches for review soon. It's unlikely to be a complete set, though. > > -- > Kind regards, > > Sakari Ailus > e-mail: sakari.ailus@iki.fi XMPP: sailus@retiisi.org.uk ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2014-08-07 14:39 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-06 10:13 omap3isp device tree support Enrico
2013-12-06 10:31 ` Florian Vaussard
2013-12-06 10:54 ` Enrico
2013-12-17 13:11 ` Florian Vaussard
2013-12-18 10:09 ` Enrico
2013-12-23 17:45 ` Enrico
2013-12-23 18:33 ` Enrico
2014-01-03 11:30 ` Enrico
2014-01-06 10:11 ` Julien BERAUD
2014-01-07 10:12 ` Enrico
2014-01-08 11:55 ` Julien BERAUD
2014-01-09 18:14 ` Enrico
2014-01-10 9:02 ` Julien BERAUD
2014-02-07 10:24 ` Enrico
2014-01-07 16:59 ` Laurent Pinchart
2014-01-09 20:26 ` Florian Vaussard
2014-01-09 20:49 ` Laurent Pinchart
2014-01-09 20:54 ` Florian Vaussard
2014-01-09 21:30 ` Sebastian Reichel
2014-01-09 23:14 ` Enrico
2014-01-10 0:00 ` Laurent Pinchart
2013-12-09 13:11 ` Laurent Pinchart
[not found] <CALFbYK1kEnB2_3VqpLFNtaJ7hj9UHuhrL0iO_rFHD2VFt8THFw@mail.gmail.com>
2014-08-05 22:19 ` Laurent Pinchart
[not found] ` <CALFbYK3YtrDPGxc3UpASk7MgPTBGcd899Crvm1csY8g+j-fehg@mail.gmail.com>
2014-08-05 22:41 ` Laurent Pinchart
2014-08-05 22:50 ` alaganraj sandhanam
[not found] ` <1407284947.78794.YahooMailNeo@web162403.mail.bf1.yahoo.com>
2014-08-06 18:40 ` Alaganraj Sandhanam
2014-08-07 0:18 ` Sakari Ailus
2014-08-07 14:39 ` Alaganraj Sandhanam
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.