Re: omap3isp Device Tree support status
Hi Sakari, Laurent, Wish You A Happy New Year!!! On Friday 10 October 2014 12:51 AM, Sakari Ailus wrote: Hi Alaganjar, On Fri, Oct 10, 2014 at 02:08:43AM +0530, Alaganraj Sandhanam wrote: Hi Sakari, On Wednesday 08 October 2014 05:03 PM, Sakari Ailus wrote: Hi Alaganjar, On Tue, Oct 07, 2014 at 02:37:37AM +0530, Alaganraj Sandhanam wrote: Hi Sakari, Thanks for the patches. On Monday 29 September 2014 03:43 AM, Sakari Ailus wrote: Hi, I managed to find some time for debugging my original omap3isp DT support patchset (which includes smiapp DT support as well), and found a few small but important bugs. The status is now that images can be captured using the Nokia N9 camera, in which the sensor is connected to the CSI-2 interface. Laurent confirmed that the parallel interface worked for him (Beagleboard, mt9p031 sensor on Leopard imaging's li-5m03 board). Good news! These patches (on top of the smiapp patches I recently sent for review which are in much better shape) are still experimental and not ready for review. I continue to clean them up and post them to the list when that is done. For now they can be found here: URL:http://git.linuxtv.org/cgit.cgi/sailus/media_tree.git/log/?h=rm696-043-dt I couldn't clone the repo, getting remote corrupt error. $ git remote -v media-sakari git://linuxtv.org/sailus/media_tree.git (fetch) media-sakari git://linuxtv.org/sailus/media_tree.git (push) origin git://linuxtv.org/media_tree.git (fetch) origin git://linuxtv.org/media_tree.git (push) sakari git://vihersipuli.retiisi.org.uk/~sailus/linux.git (fetch) sakari git://vihersipuli.retiisi.org.uk/~sailus/linux.git (push) $ git fetch media-sakari warning: cannot parse SRV response: Message too long remote: error: Could not read 5ea878796f0a1d9649fe43a6a09df53d3915c0ef remote: fatal: revision walk setup failed remote: aborting due to possible repository corruption on the remote side. fatal: protocol error: bad pack header I'm not sure what this could be related. Can you fetch from other trees, e.g. your origin remote? Do you get the same error from the remote on vihersipuli, and by using http instead? I'm able to fetch from origin and vihersipuli remotes. problem with only git://linuxtv.org/sailus/media_tree.git remote. Then you can get the same branch (or later) from vihersipuli. It's available there as well. Sorry for late response, because of some personal work I couldn't get time to test rm696-043-dt branch. I've beagleboard xM and MT9P031 Leopard imaging's LI-5M03 board. Compilation step: $ git checkout -b rm696-043-dt remotes/sakari/rm696-043-dt $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- omap2plus_defconfig $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig Enabled OMAP3ISP, MT9P031, Media controller support $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j4 Copy images to SD card $ sudo cp -f arch/arm/boot/zImage /media/alagan/BOOT/ $ sudo cp -f arch/arm/boot/dts/omap3-beagle-xm.dtb /media/alagan/BOOT/dtbs/ Kernel is booting but getting below error of_graph_get_next_endpoint(): no port node found in /ocp/omap3_isp@480bc000/ports Also device node /dev/media0 is missing and sensor not detected. Please find log below: U-Boot SPL 2014.07-rc3-dirty (Jun 16 2014 - 02:11:57) SPL: Please implement spl_start_uboot() for your board SPL: Direct Linux boot not active! reading u-boot.img reading u-boot.img U-Boot 2014.07-rc3-dirty (Jun 16 2014 - 02:11:57) OMAP36XX/37XX-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 Ghz OMAP3 Beagle board + LPDDR/NAND I2C: ready DRAM: 512 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0 *** Warning - readenv() failed, using default environment Beagle xM Rev C No EEPROM on expansion board No EEPROM on expansion board Die ID #327c00029ff8016849a904021023 Net: usb_ether Hit any key to stop autoboot: 0 mmc0 is current device gpio: pin 173 (gpio 173) value is 0 gpio: pin 4 (gpio 4) value is 0 SD/MMC found on device 0 reading uEnv.txt 153 bytes read in 3 ms (49.8 KiB/s) Loaded environment from uEnv.txt Importing environment from mmc ... Checking if lcdcmd is set ... Checking if uenvcmd is set ... Running default loadimage ... reading /zImage 4583568 bytes read in 293 ms (14.9 MiB/s) reading /dtbs/omap3-beagle-xm.dtb 62434 bytes read in 24 ms (2.5 MiB/s) Booting from mmc ... Kernel image @ 0x8030 [ 0x00 - 0x45f090 ] ## Flattened Device Tree blob at 815f Booting using the fdt blob at 0x815f Using Device Tree in place at 815f, end 816023e1 Starting kernel ... [0.498565] platform 48058000.ssi-controller: Cannot lookup hwmod 'ssi' [0.553863] edma-dma-engine edma-dma-engine.0: Can't allocate PaRAM dummy slot [1.358947] mtdoops: mtd device (mtddev=name/number) must be supplied [1.386444] twl4030_keypad 4807.i2c:twl@48:keypad: OF: linux,keymap property not defined in /ocp/i2c@4807/twl@48/keypad [1.398681] twl4030_keypad
Re: omap3isp Device Tree support status
Hi Alaganjar, On Fri, Oct 10, 2014 at 02:08:43AM +0530, Alaganraj Sandhanam wrote: Hi Sakari, On Wednesday 08 October 2014 05:03 PM, Sakari Ailus wrote: Hi Alaganjar, On Tue, Oct 07, 2014 at 02:37:37AM +0530, Alaganraj Sandhanam wrote: Hi Sakari, Thanks for the patches. On Monday 29 September 2014 03:43 AM, Sakari Ailus wrote: Hi, I managed to find some time for debugging my original omap3isp DT support patchset (which includes smiapp DT support as well), and found a few small but important bugs. The status is now that images can be captured using the Nokia N9 camera, in which the sensor is connected to the CSI-2 interface. Laurent confirmed that the parallel interface worked for him (Beagleboard, mt9p031 sensor on Leopard imaging's li-5m03 board). Good news! These patches (on top of the smiapp patches I recently sent for review which are in much better shape) are still experimental and not ready for review. I continue to clean them up and post them to the list when that is done. For now they can be found here: URL:http://git.linuxtv.org/cgit.cgi/sailus/media_tree.git/log/?h=rm696-043-dt I couldn't clone the repo, getting remote corrupt error. $ git remote -v media-sakari git://linuxtv.org/sailus/media_tree.git (fetch) media-sakari git://linuxtv.org/sailus/media_tree.git (push) origin git://linuxtv.org/media_tree.git (fetch) origin git://linuxtv.org/media_tree.git (push) sakari git://vihersipuli.retiisi.org.uk/~sailus/linux.git (fetch) sakari git://vihersipuli.retiisi.org.uk/~sailus/linux.git (push) $ git fetch media-sakari warning: cannot parse SRV response: Message too long remote: error: Could not read 5ea878796f0a1d9649fe43a6a09df53d3915c0ef remote: fatal: revision walk setup failed remote: aborting due to possible repository corruption on the remote side. fatal: protocol error: bad pack header I'm not sure what this could be related. Can you fetch from other trees, e.g. your origin remote? Do you get the same error from the remote on vihersipuli, and by using http instead? I'm able to fetch from origin and vihersipuli remotes. problem with only git://linuxtv.org/sailus/media_tree.git remote. Then you can get the same branch (or later) from vihersipuli. It's available there as well. -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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: omap3isp Device Tree support status
Hi Sakari, On Wednesday 08 October 2014 05:03 PM, Sakari Ailus wrote: Hi Alaganjar, On Tue, Oct 07, 2014 at 02:37:37AM +0530, Alaganraj Sandhanam wrote: Hi Sakari, Thanks for the patches. On Monday 29 September 2014 03:43 AM, Sakari Ailus wrote: Hi, I managed to find some time for debugging my original omap3isp DT support patchset (which includes smiapp DT support as well), and found a few small but important bugs. The status is now that images can be captured using the Nokia N9 camera, in which the sensor is connected to the CSI-2 interface. Laurent confirmed that the parallel interface worked for him (Beagleboard, mt9p031 sensor on Leopard imaging's li-5m03 board). Good news! These patches (on top of the smiapp patches I recently sent for review which are in much better shape) are still experimental and not ready for review. I continue to clean them up and post them to the list when that is done. For now they can be found here: URL:http://git.linuxtv.org/cgit.cgi/sailus/media_tree.git/log/?h=rm696-043-dt I couldn't clone the repo, getting remote corrupt error. $ git remote -v media-sakari git://linuxtv.org/sailus/media_tree.git (fetch) media-sakari git://linuxtv.org/sailus/media_tree.git (push) origin git://linuxtv.org/media_tree.git (fetch) origin git://linuxtv.org/media_tree.git (push) sakari git://vihersipuli.retiisi.org.uk/~sailus/linux.git (fetch) sakari git://vihersipuli.retiisi.org.uk/~sailus/linux.git (push) $ git fetch media-sakari warning: cannot parse SRV response: Message too long remote: error: Could not read 5ea878796f0a1d9649fe43a6a09df53d3915c0ef remote: fatal: revision walk setup failed remote: aborting due to possible repository corruption on the remote side. fatal: protocol error: bad pack header I'm not sure what this could be related. Can you fetch from other trees, e.g. your origin remote? Do you get the same error from the remote on vihersipuli, and by using http instead? I'm able to fetch from origin and vihersipuli remotes. problem with only git://linuxtv.org/sailus/media_tree.git remote. ThanksRegards Alaganraj -- 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: omap3isp Device Tree support status
Hi Alaganjar, On Tue, Oct 07, 2014 at 02:37:37AM +0530, Alaganraj Sandhanam wrote: Hi Sakari, Thanks for the patches. On Monday 29 September 2014 03:43 AM, Sakari Ailus wrote: Hi, I managed to find some time for debugging my original omap3isp DT support patchset (which includes smiapp DT support as well), and found a few small but important bugs. The status is now that images can be captured using the Nokia N9 camera, in which the sensor is connected to the CSI-2 interface. Laurent confirmed that the parallel interface worked for him (Beagleboard, mt9p031 sensor on Leopard imaging's li-5m03 board). Good news! These patches (on top of the smiapp patches I recently sent for review which are in much better shape) are still experimental and not ready for review. I continue to clean them up and post them to the list when that is done. For now they can be found here: URL:http://git.linuxtv.org/cgit.cgi/sailus/media_tree.git/log/?h=rm696-043-dt I couldn't clone the repo, getting remote corrupt error. $ git remote -v media-sakari git://linuxtv.org/sailus/media_tree.git (fetch) media-sakari git://linuxtv.org/sailus/media_tree.git (push) origingit://linuxtv.org/media_tree.git (fetch) origingit://linuxtv.org/media_tree.git (push) sakarigit://vihersipuli.retiisi.org.uk/~sailus/linux.git (fetch) sakarigit://vihersipuli.retiisi.org.uk/~sailus/linux.git (push) $ git fetch media-sakari warning: cannot parse SRV response: Message too long remote: error: Could not read 5ea878796f0a1d9649fe43a6a09df53d3915c0ef remote: fatal: revision walk setup failed remote: aborting due to possible repository corruption on the remote side. fatal: protocol error: bad pack header I'm not sure what this could be related. Can you fetch from other trees, e.g. your origin remote? Do you get the same error from the remote on vihersipuli, and by using http instead? -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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: omap3isp Device Tree support status
Hi Sakari, Thanks for the patches. On Monday 29 September 2014 03:43 AM, Sakari Ailus wrote: Hi, I managed to find some time for debugging my original omap3isp DT support patchset (which includes smiapp DT support as well), and found a few small but important bugs. The status is now that images can be captured using the Nokia N9 camera, in which the sensor is connected to the CSI-2 interface. Laurent confirmed that the parallel interface worked for him (Beagleboard, mt9p031 sensor on Leopard imaging's li-5m03 board). Good news! These patches (on top of the smiapp patches I recently sent for review which are in much better shape) are still experimental and not ready for review. I continue to clean them up and post them to the list when that is done. For now they can be found here: URL:http://git.linuxtv.org/cgit.cgi/sailus/media_tree.git/log/?h=rm696-043-dt I couldn't clone the repo, getting remote corrupt error. $ git remote -v media-sakarigit://linuxtv.org/sailus/media_tree.git (fetch) media-sakarigit://linuxtv.org/sailus/media_tree.git (push) origin git://linuxtv.org/media_tree.git (fetch) origin git://linuxtv.org/media_tree.git (push) sakari git://vihersipuli.retiisi.org.uk/~sailus/linux.git (fetch) sakari git://vihersipuli.retiisi.org.uk/~sailus/linux.git (push) $ git fetch media-sakari warning: cannot parse SRV response: Message too long remote: error: Could not read 5ea878796f0a1d9649fe43a6a09df53d3915c0ef remote: fatal: revision walk setup failed remote: aborting due to possible repository corruption on the remote side. fatal: protocol error: bad pack header Can you please guide me? ThanksRegards, Alaganraj -- 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
omap3isp Device Tree support status
Hi, I managed to find some time for debugging my original omap3isp DT support patchset (which includes smiapp DT support as well), and found a few small but important bugs. The status is now that images can be captured using the Nokia N9 camera, in which the sensor is connected to the CSI-2 interface. Laurent confirmed that the parallel interface worked for him (Beagleboard, mt9p031 sensor on Leopard imaging's li-5m03 board). These patches (on top of the smiapp patches I recently sent for review which are in much better shape) are still experimental and not ready for review. I continue to clean them up and post them to the list when that is done. For now they can be found here: URL:http://git.linuxtv.org/cgit.cgi/sailus/media_tree.git/log/?h=rm696-043-dt -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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: omap3isp device tree support
Hi Sakari, Thanks for the patches. I'll try this... ThanksRegards, Alagan On Thu, Aug 7, 2014 at 5:48 AM, Sakari Ailus sakari.ai...@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.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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: omap3isp device tree support
Please send unsubscribe linux-media message with empty subject line to majord...@vger.kernel.org. --- To: majord...@vger.kernel.org Subject: unsubscribe linux-media --- Regards, Alagan On Wed, Aug 6, 2014 at 5:59 AM, Raymond Jender ray...@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.sandha...@gmail.com wrote: Thanks Laurent. Regards, Alagan On Wed, Aug 6, 2014 at 4:11 AM, Laurent Pinchart laurent.pinch...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: omap3isp device tree support
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.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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: omap3isp device tree support
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 -- 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: omap3isp device tree support
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp device tree support
Thanks Laurent. Regards, Alagan On Wed, Aug 6, 2014 at 4:11 AM, Laurent Pinchart laurent.pinch...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp device tree support
On Fri, Jan 10, 2014 at 10:02 AM, Julien BERAUD julien.ber...@parrot.com wrote: Le 09/01/2014 19:14, Enrico a écrit : On Wed, Jan 8, 2014 at 12:55 PM, Julien BERAUD julien.ber...@parrot.com wrote: Le 07/01/2014 11:12, Enrico a écrit : On Mon, Jan 6, 2014 at 11:11 AM, Julien BERAUD julien.ber...@parrot.com wrote: Le 03/01/2014 12:30, Enrico a écrit : On Wed, Dec 18, 2013 at 11:09 AM, Enrico ebut...@users.berlios.de wrote: On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard florian.vauss...@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
Re: omap3isp device tree support
Le 09/01/2014 19:14, Enrico a écrit : On Wed, Jan 8, 2014 at 12:55 PM, Julien BERAUD julien.ber...@parrot.com wrote: Le 07/01/2014 11:12, Enrico a écrit : On Mon, Jan 6, 2014 at 11:11 AM, Julien BERAUD julien.ber...@parrot.com wrote: Le 03/01/2014 12:30, Enrico a écrit : On Wed, Dec 18, 2013 at 11:09 AM, Enrico ebut...@users.berlios.de wrote: On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard florian.vauss...@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 -- 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: omap3isp device tree support
On Wed, Jan 8, 2014 at 12:55 PM, Julien BERAUD julien.ber...@parrot.com wrote: Le 07/01/2014 11:12, Enrico a écrit : On Mon, Jan 6, 2014 at 11:11 AM, Julien BERAUD julien.ber...@parrot.com wrote: Le 03/01/2014 12:30, Enrico a écrit : On Wed, Dec 18, 2013 at 11:09 AM, Enrico ebut...@users.berlios.de wrote: On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard florian.vauss...@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 -- 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: omap3isp device tree support
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 -- 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: omap3isp device tree support
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 -- 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: omap3isp device tree support
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 -- 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: omap3isp device tree support
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 signature.asc Description: Digital signature
Re: omap3isp device tree support
On Tue, Jan 7, 2014 at 5:59 PM, Laurent Pinchart laurent.pinch...@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 -- 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: omap3isp device tree support
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 -- 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: omap3isp device tree support
Le 07/01/2014 11:12, Enrico a écrit : On Mon, Jan 6, 2014 at 11:11 AM, Julien BERAUD julien.ber...@parrot.com wrote: Le 03/01/2014 12:30, Enrico a écrit : On Wed, Dec 18, 2013 at 11:09 AM, Enrico ebut...@users.berlios.de wrote: On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard florian.vauss...@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 -- 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: omap3isp device tree support
On Mon, Jan 6, 2014 at 11:11 AM, Julien BERAUD julien.ber...@parrot.com wrote: Le 03/01/2014 12:30, Enrico a écrit : On Wed, Dec 18, 2013 at 11:09 AM, Enrico ebut...@users.berlios.de wrote: On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard florian.vauss...@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 -- 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: omap3isp device tree support
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 -- 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: omap3isp device tree support
Le 03/01/2014 12:30, Enrico a écrit : On Wed, Dec 18, 2013 at 11:09 AM, Enrico ebut...@users.berlios.de wrote: On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard florian.vauss...@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 majord...@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 -- 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: omap3isp device tree support
On Wed, Dec 18, 2013 at 11:09 AM, Enrico ebut...@users.berlios.de wrote: On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard florian.vauss...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp device tree support
On Wed, Dec 18, 2013 at 11:09 AM, Enrico ebut...@users.berlios.de wrote: On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard florian.vauss...@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: GW3.13.0-rc3+ #2 [1.604461] task: de87 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: 2153 [1.620849] sp : de86de30 ip : c06f8784 fp : [1.632934] r10: r9 : dea931ad r8 : c0b7e144 [1.638397] r7 : dea75c50 r6 : de8e4c00 r5 : de8e4c10 r4 : dea93010 [1.645263] r3 : fb042000 r2 : fb042050 r1 : 0014 r0 : [1.652130] Flags: nzCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel [1.659912] Control: 10c5387d Table: 80004019 DAC: 0015 [1.665924] Process swapper (pid: 1, stack limit = 0xde86c240) [1.672058] Stack: (0xde86de30 to 0xde86e000) [1.676635] de20: c053bd40 dea931ad [1.685241] de40: de8e4c10 de8e4c10 c0636340 c0636340 006e [1.693847] de60: de86c030 c029414c c0294134 c0b7e618 de8e4c10 c0292c98 de8e4c10 c0636340 [1.702453] de80: de8e4c44 c05eb8ac c0292e90 c0636340 c0292dfc c02912a8 [1.711029] dea0: de803aa8 de8c8050 c0636340 de9e4900 c0636ec0 c029246c c0559bec c0636340 [1.719635] dec0: 0006 c0636340 0006 c064e500 c064e500 c0293254 c05fddf8 [1.728240] dee0: 0006 c05eb8cc c05fddf8 c00087e4 de87 c0620438 6153 c0068fcc [1.736816] df00: c064e500 1480 c0620434 c05f72e0 c05f72b8 c0439170 0002 de86c000 [1.745422] df20: c0f9e9f5 c04568d4 006e c004be2c c05ab990 0006 c0f9ea08 0006 [1.754028] df40: 6153 c05fddf8 0006 c064e500 c064e500 c05d1480 006e c05f72e0 [1.762634] df60: c05f72d4 c05d1c68 0006 0006 c05d1480 c00550a0 052d1144 [1.771209] df80: 08010820 c04310f4 [1.779815] dfa0: c04310fc c000e048 [1.788421] dfc0: [1.796997] dfe0: 0013 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 -- 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: omap3isp device tree support
On Mon, Dec 23, 2013 at 6:45 PM, Enrico ebut...@users.berlios.de wrote: On Wed, Dec 18, 2013 at 11:09 AM, Enrico ebut...@users.berlios.de wrote: On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard florian.vauss...@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 -- 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: omap3isp device tree support
On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard florian.vauss...@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 -- 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: omap3isp device tree support
Hello Enrico, On 12/06/2013 11:54 AM, Enrico wrote: On Fri, Dec 6, 2013 at 11:31 AM, Florian Vaussard florian.vauss...@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 -- 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: omap3isp device tree support
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.pinch...@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.pinch...@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 000..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[] = {
+ 1300,
+ 2660,
+ 2700,
+ 0,
+};
+
+static struct mt9v032_platform_data beagle_mt9v034_platform_data = {
+ .clk_pol= 0,
+ .link_freqs = mt9v034_link_freqs,
+ .link_def_freq = 2660,
+};
+
+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
--
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
omap3isp device tree support
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 -- 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: omap3isp device tree support
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 -- 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: omap3isp device tree support
On Fri, Dec 6, 2013 at 11:31 AM, Florian Vaussard florian.vauss...@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 -- 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
