RE: i.MX53 using imx-media to capture analog video through ADV7180

2018-02-19 Thread Matthew Starr
On 02/16/2018 07:03 PM, Steve Longerbeam wrote:
> On 02/14/2018 07:44 AM, Fabio Estevam wrote:
> > [Adding Steve and Philipp in case they could provide some suggestions]
> >
> > On Wed, Feb 14, 2018 at 1:21 PM, Matthew Starr <mst...@hedonline.com>
> wrote:
> >> I have successfully modified device tree files in the mainline 4.15.1 
> >> kernel
> to get a display product using the i.MX53 processor to initialize the 
> imx-media
> drivers.  I think up to this point they have only been tested on i.MX6
> processors.
> 
> Yes that's correct. I have not tested imx-media driver on any i.MX5 targets.
> There are likely issues with i.MX5 support.
> 
> >>I am using two ADV7180 analog capture chips, one per CSI port, on this
> display product.
> >>
> >> I have everything initialize successfully at boot, but I am unable to get 
> >> the
> media-ctl command to link the ADV7180 devices to the CSI ports.  I used the
> following website as guidance of how to setup the links between media
> devices:
> >> https://linuxtv.org/downloads/v4l-dvb-apis/v4l-drivers/imx.html
> >>
> >> When trying to link the ADV7180 chip to a CSI port, I use the following
> command and get the result below:
> >>
> >>  media-ctl -v -l "'adv7180 1-0021':0->'ipu1_csi0':0[1]"
> >>
> >>  No link between "adv7180 1-0021":0 and "ipu1_csi0":0
> >>  media_parse_setup_link: Unable to parse link
> >>  Unable to parse link: Invalid argument (22)
> >>
> >> How do I get the ADV7180 and CSI port on the i.MX53 processor to link?
> >>
> >> The difference for the i.MX53 compared to the i.MX6 processor is that
> there is only one IPU and no mipi support, so my device tree does not use
> any video-mux or mux devices.  Could this have something to do with why I
> can't link the ADV7180 to the CSI port?
> 
> It probably does. Clearly there was no media link defined from the adv7180
> to any of the CSI ports, which can also be seen from the media topology you
> printed below.
> 
> As long as the OF graph is correct, I don't see why this would have happened.
> Please send two things:
> 
> 1. Your patches to DT files
> 2. dmesg output.
> 
> There could be more issues with i.MX5 support in imx-media, but it should be
> figured out why the media links from adv7180 to the CSI ports were not
> established first.
> 
> 
> Steve
> 

Steve,

I figured out the linking issue with modifying the imx-media-of.c file in an 
attached patch (imx-media-of-support-imx53-sensor-links.patch). This change 
allowed the linking directly from the ADV7180 to the CSI port.

I also had to make some changes to the imx53.dtsi file to get the imx-capture 
driver to initially work and those changes are also in another attached patch 
(imx53-add-imx-capture-support.patch).  This included adding an alias for ipu0, 
adding the imx-capture-subsystem device, and creating CSI port endpoints.

Additionally I attached my device's shared .dtsi file (pm-041.dtsi) and .dts 
file (cl-711.dts).  In these files you can see I attached CSI0 to ADV7180_0 and 
CSI1 to ADV7180_1.  I am not sure if the imx53 can support two simultaneous 
parallel sensors on both CSI ports at the same time (although this is what I 
would really like), but at this time I would like to get at least one capture 
stream working to start with.

I attached the dmesg output as an attachment after applying my patches 
(dmesg.txt).

I am used to an old 2.6.35 Freescale kernel that supports imx53 video capture 
and I am not familiar with the updated V4L2 media linking and capture of the 
4.15 kernel.  I setup all the links with media-ctl commands and printed the 
topology in the media-ctl_imx53_adv7180.txt file that is attached 
(media-ctl_imx53_adv7180.txt).

I can't seem to get the capture to work, as I always get errors of some sort.  
There are never any errors in dmesg though so the drivers are not throwing 
errors.  Here is the output from gstreamer:
# gst-launch-1.0 -v v4l2src device=/dev/video7 ! autovideosink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Internal data 
stream error.
Additional debug info:
gstbasesrc.c(2939): gst_base_src_loop (): 
/GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
streaming stopped, reason not-negotiated (-4)
Execution ended after 0:00:00.007445670
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

Any idea what could be wrong with the capture stream?

Regards,
Matt


imx53-add-imx-capture-support.patch
Description: imx53-add-imx-c

i.MX53 using imx-media to capture analog video through ADV7180

2018-02-14 Thread Matthew Starr
   -> "ipu1_ic_prpvf":0 [ENABLED]

- entity 29: ipu1_vdic (3 pads, 3 links)
 type V4L2 subdev subtype Unknown flags 0
 device node name /dev/v4l-subdev5
pad0: Sink
[fmt:AYUV8_1X32/640x480 field:none]
<- "ipu1_csi1":1 []
<- "ipu1_csi0":1 [ENABLED]
pad1: Sink
[fmt:UYVY8_2X8/640x480 field:none]
pad2: Source
[fmt:AYUV8_1X32/640x480 field:none]
-> "ipu1_ic_prp":0 [ENABLED]

- entity 33: ipu2_vdic (3 pads, 1 link)
 type V4L2 subdev subtype Unknown flags 0
 device node name /dev/v4l-subdev6
pad0: Sink
[fmt:AYUV8_1X32/640x480 field:none]
pad1: Sink
[fmt:UYVY8_2X8/640x480 field:none]
pad2: Source
[fmt:AYUV8_1X32/640x480 field:none]
-> "ipu2_ic_prp":0 []

- entity 37: ipu1_ic_prpenc (2 pads, 2 links)
 type V4L2 subdev subtype Unknown flags 0
 device node name /dev/v4l-subdev7
pad0: Sink
[fmt:AYUV8_1X32/640x480 field:none]
<- "ipu1_ic_prp":1 []
pad1: Source
[fmt:AYUV8_1X32/640x480 field:none]
-> "ipu1_ic_prpenc capture":0 []

- entity 40: ipu1_ic_prpenc capture (1 pad, 1 link)
 type Node subtype V4L flags 0
 device node name /dev/video6
pad0: Sink
<- "ipu1_ic_prpenc":1 []

- entity 46: ipu1_ic_prpvf (2 pads, 2 links)
 type V4L2 subdev subtype Unknown flags 0
 device node name /dev/v4l-subdev8
pad0: Sink
[fmt:AYUV8_1X32/640x480 field:none]
<- "ipu1_ic_prp":2 [ENABLED]
pad1: Source
[fmt:AYUV8_1X32/640x480 field:none]
-> "ipu1_ic_prpvf capture":0 [ENABLED]

- entity 49: ipu1_ic_prpvf capture (1 pad, 1 link)
 type Node subtype V4L flags 0
 device node name /dev/video7
pad0: Sink
<- "ipu1_ic_prpvf":1 [ENABLED]

- entity 55: ipu2_ic_prp (3 pads, 3 links)
 type V4L2 subdev subtype Unknown flags 0
 device node name /dev/v4l-subdev9
pad0: Sink
[fmt:AYUV8_1X32/640x480 field:none]
<- "ipu2_vdic":2 []
pad1: Source
[fmt:AYUV8_1X32/640x480 field:none]
-> "ipu2_ic_prpenc":0 []
pad2: Source
[fmt:AYUV8_1X32/640x480 field:none]
-> "ipu2_ic_prpvf":0 []

- entity 59: ipu2_ic_prpenc (2 pads, 2 links)
 type V4L2 subdev subtype Unknown flags 0
 device node name /dev/v4l-subdev10
pad0: Sink
[fmt:AYUV8_1X32/640x480 field:none]
<- "ipu2_ic_prp":1 []
pad1: Source
[fmt:AYUV8_1X32/640x480 field:none]
-> "ipu2_ic_prpenc capture":0 []

- entity 62: ipu2_ic_prpenc capture (1 pad, 1 link)
 type Node subtype V4L flags 0
 device node name /dev/video8
pad0: Sink
<- "ipu2_ic_prpenc":1 []

- entity 68: ipu2_ic_prpvf (2 pads, 2 links)
 type V4L2 subdev subtype Unknown flags 0
 device node name /dev/v4l-subdev11
pad0: Sink
        [fmt:AYUV8_1X32/640x480 field:none]
<- "ipu2_ic_prp":2 []
pad1: Source
[fmt:AYUV8_1X32/640x480 field:none]
-> "ipu2_ic_prpvf capture":0 []

- entity 71: ipu2_ic_prpvf capture (1 pad, 1 link)
 type Node subtype V4L flags 0
 device node name /dev/video9
pad0: Sink
<- "ipu2_ic_prpvf":1 []


Best regards,
 
Matthew Starr