Re: [PATCH 0/3] [media] tvp5150: Migrate to media-controller framework and add video format detection
On 2011-10-01 10:39, Enrico wrote: On Sat, Oct 1, 2011 at 5:55 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: We hack a few bits of the ISP CCDC driver to support ITU-R BT656 interlaced data with embedded syncs video format and ported the tvp5150 driver to the MCF so it can be detected as a sub-device and be part of the OMAP ISP image processing pipeline (as a source pad). That was already posted on the list [1], there was some discussion but i don't know what's the status/plan to get it into mainline. And, as you can see in [2], don't expect many comments :D [1]: http://www.spinics.net/lists/linux-media/msg37710.html [2]: http://www.spinics.net/lists/linux-media/msg37116.html Even if it does detect the signal shape (NTSC, PAL), doesn't one still need to [externally] configure the pads for this shape? Yes, that is why I wanted to do the auto-detection for the tvp5151, so we only have to manually configure the ISP components (or any other hardware video processing pipeline entities, sorry for my OMAP-specific comments). Laurent was not very happy [3] about changing video formats out of the driver control, so this should be discussed more. [3]: http://www.spinics.net/lists/linux-omap/msg56983.html I didn't know that the physical connection affected the video output format, I thought that it was only a physical medium to carry the same information, sorry if my comments are silly but I'm really newbie with video in general. I think you got it right, i haven't tested it but the output format shouldn't be affected by the video source( if it stays pal/ntsc of course). Maybe you will get only a different active video area so only cropping will be affected. It's not so much the video output [shape], rather that the input source can be selected and there does not seem to be a way to do that currently using the MC framework. I was thinking perhaps to have the driver have 3 different output pads and depending on which one you choose to link up tells the driver how to configure the input. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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/3] [media] tvp5150: Migrate to media-controller framework and add video format detection
On 2011-09-30 18:33, Javier Martinez Canillas wrote: Hello, The tvp5150 video decoder is usually used on a video pipeline with several video processing integrated circuits. So the driver has to be migrated to the new media device API to reflect this at the software level. Also the tvp5150 is able to detect what is the video standard at which the device is currently operating, so it makes sense to add video format detection in the driver as well as. This patch-set migrates the tvp5150 driver to the MCF and adds video format detection. What is this patchset relative to? Does it still handle the case of overscan? e.g. I typically capture from an NTSC source using this device at 720x524. Even if it does detect the signal shape (NTSC, PAL), doesn't one still need to [externally] configure the pads for this shape? Have you given any thought as to how the input (composite-A, composite-B or S-Video) could be configured using the MCF? Note: CC list trimmed to only the linux-media list. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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/3] [media] tvp5150: Migrate to media-controller framework and add video format detection
On Sat, Oct 1, 2011 at 3:34 PM, Gary Thomas g...@mlbassoc.com wrote: On 2011-09-30 18:33, Javier Martinez Canillas wrote: Hello, The tvp5150 video decoder is usually used on a video pipeline with several video processing integrated circuits. So the driver has to be migrated to the new media device API to reflect this at the software level. Also the tvp5150 is able to detect what is the video standard at which the device is currently operating, so it makes sense to add video format detection in the driver as well as. This patch-set migrates the tvp5150 driver to the MCF and adds video format detection. What is this patchset relative to? Hello Gary, Thank you, I'm a newbie with v4l2 in general and media controller framework in particular so your comments and suggestions are highly appreciated. I'm working to have proper support for the tvp5151 video capture connected through its parallel interface with our custom TI DM3730 ARM OMAP board. I think it's better to show the code as early as possible so I can have feedback from the community an see if I'm in the right path or completely lost, that is this patch-set about :) We hack a few bits of the ISP CCDC driver to support ITU-R BT656 interlaced data with embedded syncs video format and ported the tvp5150 driver to the MCF so it can be detected as a sub-device and be part of the OMAP ISP image processing pipeline (as a source pad). We are configuring the graph like this: ./media-ctl -r -l 'tvp5150 2-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' I thought (probably wrong for your comments) that since the tvp5150 can sense which signal shape is being transfer to it (NTSC/PAL/etc) we can configure automatically the tvp5150 source pad frame format to capture all the lines (not only the visible ones). And if user space wants a different frame format we can process the image latter. So we only have to configure the ISP CCDC input pad format to be coherent with the tvp5150 output pad. ./media-ctl --set-format 'OMAP3 ISP CCDC:0 [UYVY 720x625]' Does it still handle the case of overscan? e.g. I typically capture from an NTSC source using this device at 720x524. For the case of the overscan of if you want to crop the image I thought to use either the CCDC (to copy less lines on the memory output buffer) or the ISP resizer. But in that case one has to manually configure a different pipeline including the resizer and set the frame formats for each input and output pad (probably I'm wrong with this approach too). Even if it does detect the signal shape (NTSC, PAL), doesn't one still need to [externally] configure the pads for this shape? Yes, that is why I wanted to do the auto-detection for the tvp5151, so we only have to manually configure the ISP components (or any other hardware video processing pipeline entities, sorry for my OMAP-specific comments). Have you given any thought as to how the input (composite-A, composite-B or S-Video) could be configured using the MCF? I didn't know that the physical connection affected the video output format, I thought that it was only a physical medium to carry the same information, sorry if my comments are silly but I'm really newbie with video in general. Note: CC list trimmed to only the linux-media list. Thanks a lot, I just followed get_maintainer script suggestions. Best regards, -- Javier MartÃnez Canillas (+34) 682 39 81 69 Barcelona, Spain -- 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/3] [media] tvp5150: Migrate to media-controller framework and add video format detection
On Sat, Oct 1, 2011 at 5:55 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: We hack a few bits of the ISP CCDC driver to support ITU-R BT656 interlaced data with embedded syncs video format and ported the tvp5150 driver to the MCF so it can be detected as a sub-device and be part of the OMAP ISP image processing pipeline (as a source pad). That was already posted on the list [1], there was some discussion but i don't know what's the status/plan to get it into mainline. And, as you can see in [2], don't expect many comments :D [1]: http://www.spinics.net/lists/linux-media/msg37710.html [2]: http://www.spinics.net/lists/linux-media/msg37116.html Even if it does detect the signal shape (NTSC, PAL), doesn't one still need to [externally] configure the pads for this shape? Yes, that is why I wanted to do the auto-detection for the tvp5151, so we only have to manually configure the ISP components (or any other hardware video processing pipeline entities, sorry for my OMAP-specific comments). Laurent was not very happy [3] about changing video formats out of the driver control, so this should be discussed more. [3]: http://www.spinics.net/lists/linux-omap/msg56983.html I didn't know that the physical connection affected the video output format, I thought that it was only a physical medium to carry the same information, sorry if my comments are silly but I'm really newbie with video in general. I think you got it right, i haven't tested it but the output format shouldn't be affected by the video source( if it stays pal/ntsc of course). Maybe you will get only a different active video area so only cropping will be affected. 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: [PATCH 0/3] [media] tvp5150: Migrate to media-controller framework and add video format detection
On Sat, Oct 1, 2011 at 6:39 PM, Enrico ebut...@users.berlios.de wrote: On Sat, Oct 1, 2011 at 5:55 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: We hack a few bits of the ISP CCDC driver to support ITU-R BT656 interlaced data with embedded syncs video format and ported the tvp5150 driver to the MCF so it can be detected as a sub-device and be part of the OMAP ISP image processing pipeline (as a source pad). That was already posted on the list [1], there was some discussion but i don't know what's the status/plan to get it into mainline. Hello Enrico, Yes, I saw it. That is why I didn't post our modifications to the ISP CCDC driver. Our approach is very similar to the one followed by TI (changing the CCDC output buffer every two VD0 interrupts) but we did different a few things: - decouple next buffer obtaining from last buffer releasing - maintain two buffers (struct isp_buffer), current and last - move move most of the logic to the VD1 interrupt since the ISP is already busy while execution VD0 handler. And, as you can see in [2], don't expect many comments :D Yes, now I saw that you already posted this, sorry for not doing a correct mail archive browsing before posting the patch. [1]: http://www.spinics.net/lists/linux-media/msg37710.html [2]: http://www.spinics.net/lists/linux-media/msg37116.html Even if it does detect the signal shape (NTSC, PAL), doesn't one still need to [externally] configure the pads for this shape? Yes, that is why I wanted to do the auto-detection for the tvp5151, so we only have to manually configure the ISP components (or any other hardware video processing pipeline entities, sorry for my OMAP-specific comments). Laurent was not very happy [3] about changing video formats out of the driver control, so this should be discussed more. [3]: http://www.spinics.net/lists/linux-omap/msg56983.html Ok, I thought it was the right thing to do, my bad. Lets do it from user-space then using the MCF. I didn't know that the physical connection affected the video output format, I thought that it was only a physical medium to carry the same information, sorry if my comments are silly but I'm really newbie with video in general. I think you got it right, i haven't tested it but the output format shouldn't be affected by the video source( if it stays pal/ntsc of course). Maybe you will get only a different active video area so only cropping will be affected. Enrico Thanks and best regards, -- Javier MartÃnez Canillas (+34) 682 39 81 69 Barcelona, Spain -- 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/3] [media] tvp5150: Migrate to media-controller framework and add video format detection
On Sat, Oct 1, 2011 at 7:27 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: Yes, I saw it. That is why I didn't post our modifications to the ISP CCDC driver. Our approach is very similar to the one followed by TI (changing the CCDC output buffer every two VD0 interrupts) but we did different a few things: - decouple next buffer obtaining from last buffer releasing - maintain two buffers (struct isp_buffer), current and last - move move most of the logic to the VD1 interrupt since the ISP is already busy while execution VD0 handler. If you think it is a better approach you can submit it for review, right now there is no clean version supporting bt656 so yours can be the one. Even if it does detect the signal shape (NTSC, PAL), doesn't one still need to [externally] configure the pads for this shape? Yes, that is why I wanted to do the auto-detection for the tvp5151, so we only have to manually configure the ISP components (or any other hardware video processing pipeline entities, sorry for my OMAP-specific comments). Laurent was not very happy [3] about changing video formats out of the driver control, so this should be discussed more. [3]: http://www.spinics.net/lists/linux-omap/msg56983.html Ok, I thought it was the right thing to do, my bad. Lets do it from user-space then using the MCF. I see there is some ongoing discussion about a similar topic, so just follow it and see how it turns out. 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
