Re: [PATCH 0/1] S3C244X/S3C64XX SoC camera host interface driver
Hi Tomasz, On 08/12/2012 12:22 AM, Tomasz Figa wrote: On Saturday 11 of August 2012 21:32:15 Sylwester Nawrocki wrote: On 08/11/2012 08:39 PM, Tomasz Figa wrote: Hi, On Saturday 11 of August 2012 20:06:13 Sylwester Nawrocki wrote: Hi all, This patch adds a driver for Samsung S3C244X/S3C64XX SoC series camera host interface. My intention was to create a V4L2 driver that would work with standard applications like Gstreamer or mplayer, and yet exposing possibly all features available in the hardware. It took me several weeks to do this work in my (limited) spare time. Finally I've got something that is functional and I think might be useful for others, so I'm publishing this initial version. It hopefully doesn't need much tweaking or corrections, at least as far as S3C244X is concerned. It has not been tested on S3C64XX SoCs, as I don't have the hardware. However, the driver has been designed with covering S3C64XX as well in mind, and I've already taken care of some differences between S3C2444X and S3C64XX. Mem-to-mem features are not yet supported, but these are quite separate issue and could be easily added as a next step. I will try to test it on S3C6410 in some reasonably near future and report any needed corrections. Sounds great, thanks. I have not tested the driver yet, but I am looking through the code and it seems like S3C6410 (at least according to the documentation) supports far more pixel formats than defined in the driver. Both preview and scaler paths are supposed to support 420/422 planar, 422 interleaved and 565/666/888 formats. Indeed, somehow I missed that s3c64xx supports most of the pixel formats on both: the preview and the codec data paths. I've updated the pixel format definitions to reflect that, but it still needs to be verified with proper tests. I just didn't add YUV422 packed format, I expect it to be done by someone who actually verifies that it works, after checking/updating camif-regs.c as well. Also two distinct planar 420 formats exist that simply differ by plane order YUV420 (currently supported in your driver) and YVU420 (with Cb and Cr planes swapped). It should be pretty straightforward to add support for the latter. Yeah, thanks for the suggestion. I've added support for YVU420 - it yields more options where setting up gstreamer pipelines, along with a few fixes for issues I've found after some more testing, including LKM build. It can be pulled from following git tree: git://linuxtv.org/snawrocki/media.git s3c-camif-devel It's based off of staging/for_v3.7 branch (3.6-rc3). I consider it more or less stable. The final branch for mainline is 's3c-camif', the difference is only that the fixes were squashed to a single commit adding the whole driver there. -- Thanks, Sylwester -- 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
[PATCH 0/1] S3C244X/S3C64XX SoC camera host interface driver
Hi all, This patch adds a driver for Samsung S3C244X/S3C64XX SoC series camera host interface. My intention was to create a V4L2 driver that would work with standard applications like Gstreamer or mplayer, and yet exposing possibly all features available in the hardware. It took me several weeks to do this work in my (limited) spare time. Finally I've got something that is functional and I think might be useful for others, so I'm publishing this initial version. It hopefully doesn't need much tweaking or corrections, at least as far as S3C244X is concerned. It has not been tested on S3C64XX SoCs, as I don't have the hardware. However, the driver has been designed with covering S3C64XX as well in mind, and I've already taken care of some differences between S3C2444X and S3C64XX. Mem-to-mem features are not yet supported, but these are quite separate issue and could be easily added as a next step. The patch to follow only adds the CAMIF driver, the other two required for the camera on Mini2440 board to work (OV9650 sensor driver and the board file patch) can be found in branch s3c-camif-v3.5 in git repository: git://github.com/snawrocki/linux.git Gitweb: https://github.com/snawrocki/linux/commits/s3c-camif-v3.5 These patches are based off of stable v3.5 kernel. The S3C-CAMIF driver exposes one v4l2 subdev and two capture video nodes - for the codec and preview data paths. For minimum functionality there is no need to touch the subdev device node in user space. However it is recommended for best results. For my tests I used nice Mini2440 BSP from Pengutronix, which already contains various applications, like Gstreamer, v4l2-ctl or even media-ctl. It's available at http://www.pengutronix.de/oselas/bsp/pengutronix/index_en.html. I've tested the driver with mplayer and Gstreamer, also simultaneous capture from the preview and codec video nodes. The codec path camera preview at framebuffer can be started, for example, with following command: # gst-launch v4l2src device=/dev/video0 ! video/x-raw-yuv,width=320,height= 240 ! ffmpegcolorspace ! fbdevsink In order to select the preview video node (which supports only RGB pixel formats) /dev/video0 need to be replaced with /dev/video1, e.g. # gst-launch v4l2src device=/dev/video1 ! video/x-raw-rgb,bpp=32,endianness= 4321,depth=32,width=320,height=240 ! ffmpegcolorspace ! fbdevsink In this case I'm getting slightly incorrect color representation, still need to figure out why this happens. The supported pixel formats are listed in the attached supported_pixel_formats.txt file. The camera test pattern is exposed through a private control at the subdev node, all supported controls are listed in attached supported_controls.txt file. The test pattern can be enabled e.g. with command: # v4l2-ctl -d /dev/v4l-subdev1 --set-ctrl=test_pattern=1 A note about the driver's internals The S3C-CAMIF driver sets at the camera input (catchcam) (default) pixel format as retrieved from the sensor subdev. This happens during driver's initialization, so there is no need to touch the subdev in user space to capture video from the camera. If pixel resolution selected at /dev/video? differs from the one set at camera input (S3C-CAMIF subdev pad 0), the image frames will be resized accordingly, taking into account the resizer's capabilities. To change pixel format at the sensor subdev and the camif input, so those better match our target capture resolution, following commands can be used: media-ctl --set-v4l2 'OV9650:0 [fmt: YUYV2X8/640x640]' media-ctl --set-v4l2 'S3C-CAMIF:0 [fmt: YUYV2X8/640x640]' The only requirement is that these formats are same, otherwise it won't be possible to start streaming and VIDIOC_STREAMON will fail wit -EPIPE errno. The video node numbering might be different, if there are other V4L2 drivers in the system. It can be easily checked with media-ctl utility (media-ctl -p), my configuration was as in attached camif_media_info.txt log. I've run v4l2-compliance on both video nodes, the results can be found in file v4l2_compliance_log.txt. A graph depicting device topology can be generated from attached camif_graph.dot file (which was created with 'media-ctl --print-dot'), with following command: # cat camif_graph.dot | dot -Tpdf camif_graph.pdf # evince camif_graph.pdf There is still some more work needed to make the OV9650 sensor driver ready for the mainline, I'm planning to take care of it in near future. As for the CAMIF driver, I might try to push it upstream if it doesn't take too much of my time and there is enough interest from the users side. Feature requests or bug reports are welcome. Regards, Sylwester --- Sylwester Nawrocki (1): V4L: Add driver for S3C244X/S3C64XX SoC series camera interface drivers/media/video/Kconfig | 12 + drivers/media/video/Makefile |1 + drivers/media/video/s3c-camif/Makefile|5 +
Re: [PATCH 0/1] S3C244X/S3C64XX SoC camera host interface driver
Hi, On Saturday 11 of August 2012 20:06:13 Sylwester Nawrocki wrote: Hi all, This patch adds a driver for Samsung S3C244X/S3C64XX SoC series camera host interface. My intention was to create a V4L2 driver that would work with standard applications like Gstreamer or mplayer, and yet exposing possibly all features available in the hardware. It took me several weeks to do this work in my (limited) spare time. Finally I've got something that is functional and I think might be useful for others, so I'm publishing this initial version. It hopefully doesn't need much tweaking or corrections, at least as far as S3C244X is concerned. It has not been tested on S3C64XX SoCs, as I don't have the hardware. However, the driver has been designed with covering S3C64XX as well in mind, and I've already taken care of some differences between S3C2444X and S3C64XX. Mem-to-mem features are not yet supported, but these are quite separate issue and could be easily added as a next step. I will try to test it on S3C6410 in some reasonably near future and report any needed corrections. Currently I am using a modified s5p-fimc driver in my project, but it supports only the codec path of S3C64xx and any needed stream duplication and rescaling is done in later processing, so it might be wise to migrate to yours. Best regards, Tomasz Figa The patch to follow only adds the CAMIF driver, the other two required for the camera on Mini2440 board to work (OV9650 sensor driver and the board file patch) can be found in branch s3c-camif-v3.5 in git repository: git://github.com/snawrocki/linux.git Gitweb: https://github.com/snawrocki/linux/commits/s3c-camif-v3.5 These patches are based off of stable v3.5 kernel. The S3C-CAMIF driver exposes one v4l2 subdev and two capture video nodes - for the codec and preview data paths. For minimum functionality there is no need to touch the subdev device node in user space. However it is recommended for best results. For my tests I used nice Mini2440 BSP from Pengutronix, which already contains various applications, like Gstreamer, v4l2-ctl or even media-ctl. It's available at http://www.pengutronix.de/oselas/bsp/pengutronix/index_en.html. I've tested the driver with mplayer and Gstreamer, also simultaneous capture from the preview and codec video nodes. The codec path camera preview at framebuffer can be started, for example, with following command: # gst-launch v4l2src device=/dev/video0 ! video/x-raw-yuv,width=320,height= 240 ! ffmpegcolorspace ! fbdevsink In order to select the preview video node (which supports only RGB pixel formats) /dev/video0 need to be replaced with /dev/video1, e.g. # gst-launch v4l2src device=/dev/video1 ! video/x-raw-rgb,bpp=32,endianness= 4321,depth=32,width=320,height=240 ! ffmpegcolorspace ! fbdevsink In this case I'm getting slightly incorrect color representation, still need to figure out why this happens. The supported pixel formats are listed in the attached supported_pixel_formats.txt file. The camera test pattern is exposed through a private control at the subdev node, all supported controls are listed in attached supported_controls.txt file. The test pattern can be enabled e.g. with command: # v4l2-ctl -d /dev/v4l-subdev1 --set-ctrl=test_pattern=1 A note about the driver's internals The S3C-CAMIF driver sets at the camera input (catchcam) (default) pixel format as retrieved from the sensor subdev. This happens during driver's initialization, so there is no need to touch the subdev in user space to capture video from the camera. If pixel resolution selected at /dev/video? differs from the one set at camera input (S3C-CAMIF subdev pad 0), the image frames will be resized accordingly, taking into account the resizer's capabilities. To change pixel format at the sensor subdev and the camif input, so those better match our target capture resolution, following commands can be used: media-ctl --set-v4l2 'OV9650:0 [fmt: YUYV2X8/640x640]' media-ctl --set-v4l2 'S3C-CAMIF:0 [fmt: YUYV2X8/640x640]' The only requirement is that these formats are same, otherwise it won't be possible to start streaming and VIDIOC_STREAMON will fail wit -EPIPE errno. The video node numbering might be different, if there are other V4L2 drivers in the system. It can be easily checked with media-ctl utility (media-ctl -p), my configuration was as in attached camif_media_info.txt log. I've run v4l2-compliance on both video nodes, the results can be found in file v4l2_compliance_log.txt. A graph depicting device topology can be generated from attached camif_graph.dot file (which was created with 'media-ctl --print-dot'), with following command: # cat camif_graph.dot | dot -Tpdf camif_graph.pdf # evince camif_graph.pdf There is still some more work needed to make the OV9650 sensor driver ready for the mainline, I'm planning to take care of it in near future. As for
Re: [PATCH 0/1] S3C244X/S3C64XX SoC camera host interface driver
On 08/11/2012 08:39 PM, Tomasz Figa wrote: Hi, On Saturday 11 of August 2012 20:06:13 Sylwester Nawrocki wrote: Hi all, This patch adds a driver for Samsung S3C244X/S3C64XX SoC series camera host interface. My intention was to create a V4L2 driver that would work with standard applications like Gstreamer or mplayer, and yet exposing possibly all features available in the hardware. It took me several weeks to do this work in my (limited) spare time. Finally I've got something that is functional and I think might be useful for others, so I'm publishing this initial version. It hopefully doesn't need much tweaking or corrections, at least as far as S3C244X is concerned. It has not been tested on S3C64XX SoCs, as I don't have the hardware. However, the driver has been designed with covering S3C64XX as well in mind, and I've already taken care of some differences between S3C2444X and S3C64XX. Mem-to-mem features are not yet supported, but these are quite separate issue and could be easily added as a next step. I will try to test it on S3C6410 in some reasonably near future and report any needed corrections. Sounds great, thanks. Currently I am using a modified s5p-fimc driver in my project, but it supports only the codec path of S3C64xx and any needed stream duplication and rescaling is done in later processing, so it might be wise to migrate to yours. Yeah, the s3c camif is quite different from the s5p one. Thus the s3c-camif driver might be a much better starting point for S3C6410. I could test any changes for s3c6410 back on s3c2440 and incorporate the verified ones into some common stable git branch. -- Regards, Sylwester -- 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: [PATCH 0/1] S3C244X/S3C64XX SoC camera host interface driver
On Saturday 11 of August 2012 21:32:15 Sylwester Nawrocki wrote: On 08/11/2012 08:39 PM, Tomasz Figa wrote: Hi, On Saturday 11 of August 2012 20:06:13 Sylwester Nawrocki wrote: Hi all, This patch adds a driver for Samsung S3C244X/S3C64XX SoC series camera host interface. My intention was to create a V4L2 driver that would work with standard applications like Gstreamer or mplayer, and yet exposing possibly all features available in the hardware. It took me several weeks to do this work in my (limited) spare time. Finally I've got something that is functional and I think might be useful for others, so I'm publishing this initial version. It hopefully doesn't need much tweaking or corrections, at least as far as S3C244X is concerned. It has not been tested on S3C64XX SoCs, as I don't have the hardware. However, the driver has been designed with covering S3C64XX as well in mind, and I've already taken care of some differences between S3C2444X and S3C64XX. Mem-to-mem features are not yet supported, but these are quite separate issue and could be easily added as a next step. I will try to test it on S3C6410 in some reasonably near future and report any needed corrections. Sounds great, thanks. I have not tested the driver yet, but I am looking through the code and it seems like S3C6410 (at least according to the documentation) supports far more pixel formats than defined in the driver. Both preview and scaler paths are supposed to support 420/422 planar, 422 interleaved and 565/666/888 formats. Also two distinct planar 420 formats exist that simply differ by plane order YUV420 (currently supported in your driver) and YVU420 (with Cb and Cr planes swapped). It should be pretty straightforward to add support for the latter. Best regards, Tomasz Figa Currently I am using a modified s5p-fimc driver in my project, but it supports only the codec path of S3C64xx and any needed stream duplication and rescaling is done in later processing, so it might be wise to migrate to yours. Yeah, the s3c camif is quite different from the s5p one. Thus the s3c-camif driver might be a much better starting point for S3C6410. I could test any changes for s3c6410 back on s3c2440 and incorporate the verified ones into some common stable git branch. -- Regards, Sylwester -- 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
