* Unable to capture adv7280-m on i.MX6Q @ 2021-05-17 20:58 Fabio Estevam 2021-05-17 23:48 ` Fabio Estevam 0 siblings, 1 reply; 14+ messages in thread From: Fabio Estevam @ 2021-05-17 20:58 UTC (permalink / raw) To: Schrempf Frieder, Steve Longerbeam, Tim Harvey, Philipp Zabel Cc: Lars-Peter Clausen, linux-media, Nicolas Dufresne Hi, I am trying to capture from an adv7280-m (via MIPI-CSI2 interface) on an imx6q board. Here is the configuration: media-ctl -e "adv7180 2-0020" /dev/v4l-subdev13 media-ctl -e "ipu1_ic_prpvf capture" /dev/video2 v4l2-ctl --device /dev/v4l-subdev13 --set-standard PAL media-ctl -l "'adv7180 2-0020':0 -> 'imx6-mipi-csi2':0[1]" media-ctl -l "'imx6-mipi-csi2':2 -> 'ipu1_csi1':0[1]" media-ctl -l "'ipu1_csi1':1 -> 'ipu1_vdic':0[1]"; media-ctl -l "'ipu1_vdic':2 -> 'ipu1_ic_prp':0[1]" media-ctl -l "'ipu1_ic_prp':2 -> 'ipu1_ic_prpvf':0[1]" media-ctl -l "'ipu1_ic_prpvf':1 -> 'ipu1_ic_prpvf capture':0[1]" media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480 field:seq-tb]" media-ctl -V "'imx6-mipi-csi2':2 [fmt:UYVY2X8/720x480]" media-ctl -V "'ipu1_csi1':1 [fmt:AYUV32/800x480]"; media-ctl -V "'ipu1_vdic':2 [fmt:AYUV32/800x480 field:none]" media-ctl -V "'ipu1_ic_prp':2 [fmt:AYUV32/800x480 field:none]" media-ctl -V "'ipu1_ic_prpvf':1 [fmt:AYUV32/800x480 field:none]" v4l2-ctl -d2 --set-fmt-video=field=none Then when I try to launch Gstreamer: gst-launch-1.0 v4l2src device=/dev/video2 ! kmssink Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock [ 124.519578] ipu1_ic_prpvf: pipeline start failed with -32 ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed to allocate required memory. Additional debug info: ../sys/v4l2/gstv4l2src.c(659): gst_v4l2src_decide_allocation (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Buffer pool activation failed Execution ended after 0:00:00.032104334 Setting pipeline to NULL ... ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Internal data stream error. Additional debug info: ../libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: streaming stopped, reason not-negotiated (-4) Does anyone have any ideas as to why the pipeline fails? Thanks, Fabio Estevam ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Unable to capture adv7280-m on i.MX6Q 2021-05-17 20:58 Unable to capture adv7280-m on i.MX6Q Fabio Estevam @ 2021-05-17 23:48 ` Fabio Estevam 2021-06-08 3:13 ` Fabio Estevam 0 siblings, 1 reply; 14+ messages in thread From: Fabio Estevam @ 2021-05-17 23:48 UTC (permalink / raw) To: Schrempf Frieder, Steve Longerbeam, Tim Harvey, Philipp Zabel Cc: Lars-Peter Clausen, linux-media, Nicolas Dufresne On Mon, May 17, 2021 at 5:58 PM Fabio Estevam <festevam@gmail.com> wrote: > > Hi, > > I am trying to capture from an adv7280-m (via MIPI-CSI2 interface) on > an imx6q board. > > Here is the configuration: Decided to try to transmit to the ipu1_csi0 (virtual channel 0) instead: media-ctl -l "'adv7180 2-0020':0 -> 'imx6-mipi-csi2':0[1]" media-ctl -l "'imx6-mipi-csi2':1 -> 'ipu1_csi0_mux':0[1]" media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]" media-ctl -l "'ipu1_csi0':1 -> 'ipu1_vdic':0[1]" media-ctl -l "'ipu1_vdic':2 -> 'ipu1_ic_prp':0[1]" media-ctl -l "'ipu1_ic_prp':2 -> 'ipu1_ic_prpvf':0[1]" media-ctl -l "'ipu1_ic_prpvf':1 -> 'ipu1_ic_prpvf capture':0[1]" media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x576 field:seq-tb]" media-ctl -V "'imx6-mipi-csi2':1 [fmt:UYVY2X8/720x576]" media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x576]" media-ctl -V "'ipu1_csi0':1 [fmt:AYUV32/720x576]" media-ctl -V "'ipu1_vdic':2 [fmt:AYUV32/720x576 field:none]" media-ctl -V "'ipu1_ic_prp':2 [fmt:AYUV32/720x576 field:none]" media-ctl -V "'ipu1_ic_prpvf':1 [fmt:AYUV32/720x576 field:none]" # Configure "ipu1_ic_prpvf capture" interface (assumed at /dev/video2) v4l2-ctl -d2 --set-fmt-video=field=none gst-launch-1.0 v4l2src device=/dev/video2 ! kmssink Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock [ 11.745511] imx6-mipi-csi2: LP-11 wait timeout, likely a sensor driver bug, expect capture failures. [ 11.754956] imx6-mipi-csi2: phy_state = 0x00000200 [ 12.259957] imx6-mipi-csi2: clock lane timeout, phy_state = 0x00000200 [ 12.266630] ipu1_ic_prpvf: upstream stream on failed: -110 [ 12.274082] ipu1_ic_prpvf: pipeline start failed with -110 ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed to allocate required memory. Additional debug info: ../sys/v4l2/gstv4l2src.c(659): gst_v4l2src_decide_allocation (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Buffer pool activation failed Execution ended after 0:00:01.072478334 Setting pipeline to NULL ... Freeing pipeline ... Not sure why I am getting LP-11 and clock lane timeouts though. Thanks ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Unable to capture adv7280-m on i.MX6Q 2021-05-17 23:48 ` Fabio Estevam @ 2021-06-08 3:13 ` Fabio Estevam 2021-06-08 7:09 ` Philipp Zabel 0 siblings, 1 reply; 14+ messages in thread From: Fabio Estevam @ 2021-06-08 3:13 UTC (permalink / raw) To: Schrempf Frieder, Steve Longerbeam, Tim Harvey, Philipp Zabel Cc: Lars-Peter Clausen, linux-media, Nicolas Dufresne On Mon, May 17, 2021 at 8:48 PM Fabio Estevam <festevam@gmail.com> wrote: > Setting pipeline to PAUSED ... > Pipeline is live and does not need PREROLL ... > Pipeline is PREROLLED ... > Setting pipeline to PLAYING ... > New clock: GstSystemClock > [ 11.745511] imx6-mipi-csi2: LP-11 wait timeout, likely a sensor > driver bug, expect capture failures. > [ 11.754956] imx6-mipi-csi2: phy_state = 0x00000200 > [ 12.259957] imx6-mipi-csi2: clock lane timeout, phy_state = 0x00000200 > [ 12.266630] ipu1_ic_prpvf: upstream stream on failed: -110 > [ 12.274082] ipu1_ic_prpvf: pipeline start failed with -110 > ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed > to allocate required memory. > Additional debug info: > ../sys/v4l2/gstv4l2src.c(659): gst_v4l2src_decide_allocation (): > /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: > Buffer pool activation failed > Execution ended after 0:00:01.072478334 > Setting pipeline to NULL ... > Freeing pipeline ... > > Not sure why I am getting LP-11 and clock lane timeouts though. I saw this post: https://ez.analog.com/linux-software-drivers/f/q-a/535279/adv7282-m-dts-how-to-connect-adv-to-ipu1_csi0 and Frieder's patch: https://git.kontron-electronics.de/linux/linux/-/commit/0d90331a44d0f718b7327a94fc72612ddcb4ac0f.patch I applied Frieder's patch, but still getting the same errors below upon launching Gstreamer.: New clock: GstSystemClock [ 11.745511] imx6-mipi-csi2: LP-11 wait timeout, likely a sensor driver bug, expect capture failures. [ 11.754956] imx6-mipi-csi2: phy_state = 0x00000200 [ 12.259957] imx6-mipi-csi2: clock lane timeout, phy_state = 0x00000200 [ 12.266630] ipu1_ic_prpvf: upstream stream on failed: -110 [ 12.274082] ipu1_ic_prpvf: pipeline start failed with -110 Does anyone know what needs to be done to avoid the LP-11 timeout error? Thanks ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Unable to capture adv7280-m on i.MX6Q 2021-06-08 3:13 ` Fabio Estevam @ 2021-06-08 7:09 ` Philipp Zabel 2021-06-08 7:54 ` Ian Arkver 2021-06-09 2:34 ` Fabio Estevam 0 siblings, 2 replies; 14+ messages in thread From: Philipp Zabel @ 2021-06-08 7:09 UTC (permalink / raw) To: Fabio Estevam, Schrempf Frieder, Steve Longerbeam, Tim Harvey Cc: Lars-Peter Clausen, linux-media, Nicolas Dufresne Hi Fabio, On Tue, 2021-06-08 at 00:13 -0300, Fabio Estevam wrote: > On Mon, May 17, 2021 at 8:48 PM Fabio Estevam <festevam@gmail.com> wrote: > > > Setting pipeline to PAUSED ... > > Pipeline is live and does not need PREROLL ... > > Pipeline is PREROLLED ... > > Setting pipeline to PLAYING ... > > New clock: GstSystemClock > > [ 11.745511] imx6-mipi-csi2: LP-11 wait timeout, likely a sensor > > driver bug, expect capture failures. > > [ 11.754956] imx6-mipi-csi2: phy_state = 0x00000200 > > [ 12.259957] imx6-mipi-csi2: clock lane timeout, phy_state = 0x00000200 > > [ 12.266630] ipu1_ic_prpvf: upstream stream on failed: -110 > > [ 12.274082] ipu1_ic_prpvf: pipeline start failed with -110 > > ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed > > to allocate required memory. > > Additional debug info: > > ../sys/v4l2/gstv4l2src.c(659): gst_v4l2src_decide_allocation (): > > /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: > > Buffer pool activation failed > > Execution ended after 0:00:01.072478334 > > Setting pipeline to NULL ... > > Freeing pipeline ... > > > > Not sure why I am getting LP-11 and clock lane timeouts though. > > I saw this post: > https://ez.analog.com/linux-software-drivers/f/q-a/535279/adv7282-m-dts-how-to-connect-adv-to-ipu1_csi0 > > and Frieder's patch: > https://git.kontron-electronics.de/linux/linux/-/commit/0d90331a44d0f718b7327a94fc72612ddcb4ac0f.patch > > I applied Frieder's patch, but still getting the same errors below > upon launching Gstreamer.: > > New clock: GstSystemClock > [ 11.745511] imx6-mipi-csi2: LP-11 wait timeout, likely a sensor > driver bug, expect capture failures. > [ 11.754956] imx6-mipi-csi2: phy_state = 0x00000200 > [ 12.259957] imx6-mipi-csi2: clock lane timeout, phy_state = 0x00000200 > [ 12.266630] ipu1_ic_prpvf: upstream stream on failed: -110 > [ 12.274082] ipu1_ic_prpvf: pipeline start failed with -110 > > Does anyone know what needs to be done to avoid the LP-11 timeout error? The i.MX6 CSI-2 RX needs to see the LP-11 low power state on the lanes during streamon (before it calls the ADV7280-M s_stream(1)). That's where the LP-11 timeout error occurs. According to the ADV7280(-M) datasheet, "after the ADV7280-M is programmed, the clock lanes exit low power mode and remain in high speed mode until the part is reset or powered down." So it appears the ADV7280-M has to be freshly powered on in s_power(1) for this to work. Is the ADV7280-M powerdown GPIO connected properly on your board? Moving the CSI-2 configuration from s_power to s_stream was exactly the right thing to do in my mind. Just as a test, if you remove the CSI-2 register writes from either s_power and s_stream from the adv7180 driver completely, do you still run into the LP-11 timeout? If the CSI-2 TX never leaves the low power state, I would expect seeing the clock lane timeout instead regards Philipp ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Unable to capture adv7280-m on i.MX6Q 2021-06-08 7:09 ` Philipp Zabel @ 2021-06-08 7:54 ` Ian Arkver 2021-06-08 10:55 ` Frieder Schrempf 2021-06-09 2:34 ` Fabio Estevam 1 sibling, 1 reply; 14+ messages in thread From: Ian Arkver @ 2021-06-08 7:54 UTC (permalink / raw) To: Philipp Zabel, Fabio Estevam, Schrempf Frieder, Steve Longerbeam, Tim Harvey Cc: Lars-Peter Clausen, linux-media, Nicolas Dufresne Hi, On 08/06/2021 08:09, Philipp Zabel wrote: > Hi Fabio, > > On Tue, 2021-06-08 at 00:13 -0300, Fabio Estevam wrote: >> On Mon, May 17, 2021 at 8:48 PM Fabio Estevam <festevam@gmail.com> wrote: >> >>> Setting pipeline to PAUSED ... >>> Pipeline is live and does not need PREROLL ... >>> Pipeline is PREROLLED ... >>> Setting pipeline to PLAYING ... >>> New clock: GstSystemClock >>> [ 11.745511] imx6-mipi-csi2: LP-11 wait timeout, likely a sensor >>> driver bug, expect capture failures. >>> [ 11.754956] imx6-mipi-csi2: phy_state = 0x00000200 >>> [ 12.259957] imx6-mipi-csi2: clock lane timeout, phy_state = 0x00000200 >>> [ 12.266630] ipu1_ic_prpvf: upstream stream on failed: -110 >>> [ 12.274082] ipu1_ic_prpvf: pipeline start failed with -110 >>> ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed >>> to allocate required memory. >>> Additional debug info: >>> ../sys/v4l2/gstv4l2src.c(659): gst_v4l2src_decide_allocation (): >>> /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: >>> Buffer pool activation failed >>> Execution ended after 0:00:01.072478334 >>> Setting pipeline to NULL ... >>> Freeing pipeline ... >>> >>> Not sure why I am getting LP-11 and clock lane timeouts though. >> >> I saw this post: >> https://ez.analog.com/linux-software-drivers/f/q-a/535279/adv7282-m-dts-how-to-connect-adv-to-ipu1_csi0 >> >> and Frieder's patch: >> https://git.kontron-electronics.de/linux/linux/-/commit/0d90331a44d0f718b7327a94fc72612ddcb4ac0f.patch Frieder's moved adv writes should maybe be inside if (enable) though, with the else write-to-clear as well. Maybe gst sends a stream off? Regards, Ian >> >> I applied Frieder's patch, but still getting the same errors below >> upon launching Gstreamer.: >> >> New clock: GstSystemClock >> [ 11.745511] imx6-mipi-csi2: LP-11 wait timeout, likely a sensor >> driver bug, expect capture failures. >> [ 11.754956] imx6-mipi-csi2: phy_state = 0x00000200 >> [ 12.259957] imx6-mipi-csi2: clock lane timeout, phy_state = 0x00000200 >> [ 12.266630] ipu1_ic_prpvf: upstream stream on failed: -110 >> [ 12.274082] ipu1_ic_prpvf: pipeline start failed with -110 >> >> Does anyone know what needs to be done to avoid the LP-11 timeout error? > > The i.MX6 CSI-2 RX needs to see the LP-11 low power state on the lanes > during streamon (before it calls the ADV7280-M s_stream(1)). That's > where the LP-11 timeout error occurs. > > According to the ADV7280(-M) datasheet, "after the ADV7280-M is > programmed, the clock lanes exit low power mode and remain in high speed > mode until the part is reset or powered down." > So it appears the ADV7280-M has to be freshly powered on in s_power(1) > for this to work. Is the ADV7280-M powerdown GPIO connected properly on > your board? Moving the CSI-2 configuration from s_power to s_stream was > exactly the right thing to do in my mind. > > Just as a test, if you remove the CSI-2 register writes from either > s_power and s_stream from the adv7180 driver completely, do you still > run into the LP-11 timeout? If the CSI-2 TX never leaves the low power > state, I would expect seeing the clock lane timeout instead > > regards > Philipp > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Unable to capture adv7280-m on i.MX6Q 2021-06-08 7:54 ` Ian Arkver @ 2021-06-08 10:55 ` Frieder Schrempf 2021-06-08 11:20 ` Ian Arkver 2021-06-08 11:21 ` Fabio Estevam 0 siblings, 2 replies; 14+ messages in thread From: Frieder Schrempf @ 2021-06-08 10:55 UTC (permalink / raw) To: Ian Arkver, Philipp Zabel, Fabio Estevam, Steve Longerbeam, Tim Harvey Cc: Lars-Peter Clausen, linux-media, Nicolas Dufresne On 08.06.21 09:54, Ian Arkver wrote: > Hi, > > On 08/06/2021 08:09, Philipp Zabel wrote: >> Hi Fabio, >> >> On Tue, 2021-06-08 at 00:13 -0300, Fabio Estevam wrote: >>> On Mon, May 17, 2021 at 8:48 PM Fabio Estevam <festevam@gmail.com> wrote: >>> >>>> Setting pipeline to PAUSED ... >>>> Pipeline is live and does not need PREROLL ... >>>> Pipeline is PREROLLED ... >>>> Setting pipeline to PLAYING ... >>>> New clock: GstSystemClock >>>> [ 11.745511] imx6-mipi-csi2: LP-11 wait timeout, likely a sensor >>>> driver bug, expect capture failures. >>>> [ 11.754956] imx6-mipi-csi2: phy_state = 0x00000200 >>>> [ 12.259957] imx6-mipi-csi2: clock lane timeout, phy_state = 0x00000200 >>>> [ 12.266630] ipu1_ic_prpvf: upstream stream on failed: -110 >>>> [ 12.274082] ipu1_ic_prpvf: pipeline start failed with -110 >>>> ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed >>>> to allocate required memory. >>>> Additional debug info: >>>> ../sys/v4l2/gstv4l2src.c(659): gst_v4l2src_decide_allocation (): >>>> /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: >>>> Buffer pool activation failed >>>> Execution ended after 0:00:01.072478334 >>>> Setting pipeline to NULL ... >>>> Freeing pipeline ... >>>> >>>> Not sure why I am getting LP-11 and clock lane timeouts though. >>> >>> I saw this post: >>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fez.analog.com%2Flinux-software-drivers%2Ff%2Fq-a%2F535279%2Fadv7282-m-dts-how-to-connect-adv-to-ipu1_csi0&data=04%7C01%7Cfrieder.schrempf%40kontron.de%7C81057e8e187d4f2bf61908d92a52b30a%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637587357508272332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tb3C%2FU20jo5tp58olvCo%2BRWREFNZEJaZop1hHGMksBE%3D&reserved=0 >>> >>> and Frieder's patch: >>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kontron-electronics.de%2Flinux%2Flinux%2F-%2Fcommit%2F0d90331a44d0f718b7327a94fc72612ddcb4ac0f.patch&data=04%7C01%7Cfrieder.schrempf%40kontron.de%7C81057e8e187d4f2bf61908d92a52b30a%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637587357508272332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hsuRqyEYAh1PtGiwZRKcmENkVbJuRN85DBmuXHOZhBs%3D&reserved=0 > > Frieder's moved adv writes should maybe be inside if (enable) though, with the else write-to-clear as well. Maybe gst sends a stream off? There's an "if(!enable)" before that and it has "return 0". So it should be fine without "if(enable)". > >>> >>> I applied Frieder's patch, but still getting the same errors below >>> upon launching Gstreamer.: >>> >>> New clock: GstSystemClock >>> [ 11.745511] imx6-mipi-csi2: LP-11 wait timeout, likely a sensor >>> driver bug, expect capture failures. >>> [ 11.754956] imx6-mipi-csi2: phy_state = 0x00000200 >>> [ 12.259957] imx6-mipi-csi2: clock lane timeout, phy_state = 0x00000200 >>> [ 12.266630] ipu1_ic_prpvf: upstream stream on failed: -110 >>> [ 12.274082] ipu1_ic_prpvf: pipeline start failed with -110 >>> >>> Does anyone know what needs to be done to avoid the LP-11 timeout error? >> >> The i.MX6 CSI-2 RX needs to see the LP-11 low power state on the lanes >> during streamon (before it calls the ADV7280-M s_stream(1)). That's >> where the LP-11 timeout error occurs. >> >> According to the ADV7280(-M) datasheet, "after the ADV7280-M is >> programmed, the clock lanes exit low power mode and remain in high speed >> mode until the part is reset or powered down." >> So it appears the ADV7280-M has to be freshly powered on in s_power(1) >> for this to work. Is the ADV7280-M powerdown GPIO connected properly on >> your board? Moving the CSI-2 configuration from s_power to s_stream was >> exactly the right thing to do in my mind. >> >> Just as a test, if you remove the CSI-2 register writes from either >> s_power and s_stream from the adv7180 driver completely, do you still >> run into the LP-11 timeout? If the CSI-2 TX never leaves the low power >> state, I would expect seeing the clock lane timeout instead >> >> regards >> Philipp >> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Unable to capture adv7280-m on i.MX6Q 2021-06-08 10:55 ` Frieder Schrempf @ 2021-06-08 11:20 ` Ian Arkver 2021-06-08 11:21 ` Fabio Estevam 1 sibling, 0 replies; 14+ messages in thread From: Ian Arkver @ 2021-06-08 11:20 UTC (permalink / raw) To: Frieder Schrempf, Philipp Zabel, Fabio Estevam, Steve Longerbeam, Tim Harvey Cc: Lars-Peter Clausen, linux-media, Nicolas Dufresne On 08/06/2021 11:55, Frieder Schrempf wrote: > On 08.06.21 09:54, Ian Arkver wrote: >> Hi, >> >> On 08/06/2021 08:09, Philipp Zabel wrote: >>> Hi Fabio, >>> >>> On Tue, 2021-06-08 at 00:13 -0300, Fabio Estevam wrote: >>>> On Mon, May 17, 2021 at 8:48 PM Fabio Estevam <festevam@gmail.com> wrote: >>>> >>>>> Setting pipeline to PAUSED ... >>>>> Pipeline is live and does not need PREROLL ... >>>>> Pipeline is PREROLLED ... >>>>> Setting pipeline to PLAYING ... >>>>> New clock: GstSystemClock >>>>> [ 11.745511] imx6-mipi-csi2: LP-11 wait timeout, likely a sensor >>>>> driver bug, expect capture failures. >>>>> [ 11.754956] imx6-mipi-csi2: phy_state = 0x00000200 >>>>> [ 12.259957] imx6-mipi-csi2: clock lane timeout, phy_state = 0x00000200 >>>>> [ 12.266630] ipu1_ic_prpvf: upstream stream on failed: -110 >>>>> [ 12.274082] ipu1_ic_prpvf: pipeline start failed with -110 >>>>> ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed >>>>> to allocate required memory. >>>>> Additional debug info: >>>>> ../sys/v4l2/gstv4l2src.c(659): gst_v4l2src_decide_allocation (): >>>>> /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: >>>>> Buffer pool activation failed >>>>> Execution ended after 0:00:01.072478334 >>>>> Setting pipeline to NULL ... >>>>> Freeing pipeline ... >>>>> >>>>> Not sure why I am getting LP-11 and clock lane timeouts though. >>>> >>>> I saw this post: >>>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fez.analog.com%2Flinux-software-drivers%2Ff%2Fq-a%2F535279%2Fadv7282-m-dts-how-to-connect-adv-to-ipu1_csi0&data=04%7C01%7Cfrieder.schrempf%40kontron.de%7C81057e8e187d4f2bf61908d92a52b30a%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637587357508272332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tb3C%2FU20jo5tp58olvCo%2BRWREFNZEJaZop1hHGMksBE%3D&reserved=0 >>>> >>>> and Frieder's patch: >>>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kontron-electronics.de%2Flinux%2Flinux%2F-%2Fcommit%2F0d90331a44d0f718b7327a94fc72612ddcb4ac0f.patch&data=04%7C01%7Cfrieder.schrempf%40kontron.de%7C81057e8e187d4f2bf61908d92a52b30a%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637587357508272332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hsuRqyEYAh1PtGiwZRKcmENkVbJuRN85DBmuXHOZhBs%3D&reserved=0 >> >> Frieder's moved adv writes should maybe be inside if (enable) though, with the else write-to-clear as well. Maybe gst sends a stream off? > > There's an "if(!enable)" before that and it has "return 0". So it should be fine without "if(enable)". Doh, so there is. I really should read the whole patch before posting. Sorry. > >> >>>> >>>> I applied Frieder's patch, but still getting the same errors below >>>> upon launching Gstreamer.: >>>> >>>> New clock: GstSystemClock >>>> [ 11.745511] imx6-mipi-csi2: LP-11 wait timeout, likely a sensor >>>> driver bug, expect capture failures. >>>> [ 11.754956] imx6-mipi-csi2: phy_state = 0x00000200 >>>> [ 12.259957] imx6-mipi-csi2: clock lane timeout, phy_state = 0x00000200 >>>> [ 12.266630] ipu1_ic_prpvf: upstream stream on failed: -110 >>>> [ 12.274082] ipu1_ic_prpvf: pipeline start failed with -110 >>>> >>>> Does anyone know what needs to be done to avoid the LP-11 timeout error? >>> >>> The i.MX6 CSI-2 RX needs to see the LP-11 low power state on the lanes >>> during streamon (before it calls the ADV7280-M s_stream(1)). That's >>> where the LP-11 timeout error occurs. >>> >>> According to the ADV7280(-M) datasheet, "after the ADV7280-M is >>> programmed, the clock lanes exit low power mode and remain in high speed >>> mode until the part is reset or powered down." >>> So it appears the ADV7280-M has to be freshly powered on in s_power(1) >>> for this to work. Is the ADV7280-M powerdown GPIO connected properly on >>> your board? Moving the CSI-2 configuration from s_power to s_stream was >>> exactly the right thing to do in my mind. >>> >>> Just as a test, if you remove the CSI-2 register writes from either >>> s_power and s_stream from the adv7180 driver completely, do you still >>> run into the LP-11 timeout? If the CSI-2 TX never leaves the low power >>> state, I would expect seeing the clock lane timeout instead >>> >>> regards >>> Philipp >>> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Unable to capture adv7280-m on i.MX6Q 2021-06-08 10:55 ` Frieder Schrempf 2021-06-08 11:20 ` Ian Arkver @ 2021-06-08 11:21 ` Fabio Estevam 1 sibling, 0 replies; 14+ messages in thread From: Fabio Estevam @ 2021-06-08 11:21 UTC (permalink / raw) To: Frieder Schrempf Cc: Ian Arkver, Philipp Zabel, Steve Longerbeam, Tim Harvey, Lars-Peter Clausen, linux-media, Nicolas Dufresne Hi Frieder, On Tue, Jun 8, 2021 at 7:55 AM Frieder Schrempf <frieder.schrempf@kontron.de> wrote: > > Frieder's moved adv writes should maybe be inside if (enable) though, with the else write-to-clear as well. Maybe gst sends a stream off? > > There's an "if(!enable)" before that and it has "return 0". So it should be fine without "if(enable)". There is a missing if (state->chip_info->flags & ADV7180_FLAG_MIPI_CSI2) though. to prevent the csi writes to happen on non-MIPI ADV7180 parts. I will fix it when submitting upstream (if I get this to work though :-) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Unable to capture adv7280-m on i.MX6Q 2021-06-08 7:09 ` Philipp Zabel 2021-06-08 7:54 ` Ian Arkver @ 2021-06-09 2:34 ` Fabio Estevam 2021-06-09 7:20 ` Philipp Zabel 1 sibling, 1 reply; 14+ messages in thread From: Fabio Estevam @ 2021-06-09 2:34 UTC (permalink / raw) To: Philipp Zabel Cc: Schrempf Frieder, Steve Longerbeam, Tim Harvey, Lars-Peter Clausen, linux-media, Nicolas Dufresne Hi Philipp, On Tue, Jun 8, 2021 at 4:09 AM Philipp Zabel <p.zabel@pengutronix.de> wrote: > The i.MX6 CSI-2 RX needs to see the LP-11 low power state on the lanes > during streamon (before it calls the ADV7280-M s_stream(1)). That's > where the LP-11 timeout error occurs. > > According to the ADV7280(-M) datasheet, "after the ADV7280-M is > programmed, the clock lanes exit low power mode and remain in high speed > mode until the part is reset or powered down." > So it appears the ADV7280-M has to be freshly powered on in s_power(1) What do you mean by freshly powered on? > for this to work. Is the ADV7280-M powerdown GPIO connected properly on > your board? Moving the CSI-2 configuration from s_power to s_stream was > exactly the right thing to do in my mind. > > Just as a test, if you remove the CSI-2 register writes from either > s_power and s_stream from the adv7180 driver completely, do you still > run into the LP-11 timeout? If the CSI-2 TX never leaves the low power > state, I would expect seeing the clock lane timeout instead If I do this test, the first time I run the pipeline I get LP-11, the second time I get clock lane timeout. Thanks, Fabio Estevam ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Unable to capture adv7280-m on i.MX6Q 2021-06-09 2:34 ` Fabio Estevam @ 2021-06-09 7:20 ` Philipp Zabel 2021-06-09 12:27 ` Fabio Estevam 2021-06-09 17:28 ` Ian Arkver 0 siblings, 2 replies; 14+ messages in thread From: Philipp Zabel @ 2021-06-09 7:20 UTC (permalink / raw) To: Fabio Estevam Cc: Schrempf Frieder, Steve Longerbeam, Tim Harvey, Lars-Peter Clausen, linux-media, Nicolas Dufresne Hi Fabio, On Tue, 2021-06-08 at 23:34 -0300, Fabio Estevam wrote: > Hi Philipp, > > On Tue, Jun 8, 2021 at 4:09 AM Philipp Zabel <p.zabel@pengutronix.de> wrote: > > > The i.MX6 CSI-2 RX needs to see the LP-11 low power state on the lanes > > during streamon (before it calls the ADV7280-M s_stream(1)). That's > > where the LP-11 timeout error occurs. > > > > According to the ADV7280(-M) datasheet, "after the ADV7280-M is > > programmed, the clock lanes exit low power mode and remain in high speed > > mode until the part is reset or powered down." > > So it appears the ADV7280-M has to be freshly powered on in s_power(1) > > What do you mean by freshly powered on? That the ADV7280-M is in the state before "the clock lanes exit low power mode" due to being "programmed". Basically I was hoping that after the initial reset sequence, and after power on, before the CSI-2 registers are written, the clock lanes are in LP-11 state (and stay there until then). Unfortunately that doesn't appear to be the case below ... > > for this to work. Is the ADV7280-M powerdown GPIO connected properly on > > your board? Moving the CSI-2 configuration from s_power to s_stream was > > exactly the right thing to do in my mind. > > > > Just as a test, if you remove the CSI-2 register writes from either > > s_power and s_stream from the adv7180 driver completely, do you still > > run into the LP-11 timeout? If the CSI-2 TX never leaves the low power > > state, I would expect seeing the clock lane timeout instead > > If I do this test, the first time I run the pipeline I get LP-11, the > second time I get clock lane timeout. ... at least the first time. So now I wonder what happens between the first and second time (in s_stream? in s_power(0)?) that does put the lanes into LP-11 from whatever state they were in before. When you get the clock lane timeout, is phy_state = 0x610? Does it stay there when you repeat this again? regards Philipp ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Unable to capture adv7280-m on i.MX6Q 2021-06-09 7:20 ` Philipp Zabel @ 2021-06-09 12:27 ` Fabio Estevam 2021-06-09 17:28 ` Ian Arkver 1 sibling, 0 replies; 14+ messages in thread From: Fabio Estevam @ 2021-06-09 12:27 UTC (permalink / raw) To: Philipp Zabel Cc: Schrempf Frieder, Steve Longerbeam, Tim Harvey, Lars-Peter Clausen, linux-media, Nicolas Dufresne Hi Philipp, On Wed, Jun 9, 2021 at 4:20 AM Philipp Zabel <p.zabel@pengutronix.de> wrote: > So now I wonder what happens between the first and second time (in > s_stream? in s_power(0)?) that does put the lanes into LP-11 from > whatever state they were in before. When you get the clock lane timeout, > is phy_state = 0x610? Does it stay there when you repeat this again? Yes, correct. I do see phy_state = 0x610 in the second time I run the Gstreamer pipeline: New clock: GstSystemClock [ 24.190274] imx6-mipi-csi2: clock lane timeout, phy_state = 0x00000610 [ 24.197737] ipu1_ic_prpvf: upstream stream on failed: -110 [ 24.204359] ipu1_ic_prpvf: pipeline start failed with -110 It stays there if I repeat it again. Thanks, Fabio Estevam ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Unable to capture adv7280-m on i.MX6Q 2021-06-09 7:20 ` Philipp Zabel 2021-06-09 12:27 ` Fabio Estevam @ 2021-06-09 17:28 ` Ian Arkver 2021-06-25 1:20 ` Fabio Estevam 1 sibling, 1 reply; 14+ messages in thread From: Ian Arkver @ 2021-06-09 17:28 UTC (permalink / raw) To: Philipp Zabel, Fabio Estevam Cc: Schrempf Frieder, Steve Longerbeam, Tim Harvey, Lars-Peter Clausen, linux-media, Nicolas Dufresne Hi, On 09/06/2021 08:20, Philipp Zabel wrote: > Hi Fabio, > > On Tue, 2021-06-08 at 23:34 -0300, Fabio Estevam wrote: >> Hi Philipp, >> >> On Tue, Jun 8, 2021 at 4:09 AM Philipp Zabel <p.zabel@pengutronix.de> wrote: >> >>> The i.MX6 CSI-2 RX needs to see the LP-11 low power state on the lanes >>> during streamon (before it calls the ADV7280-M s_stream(1)). That's >>> where the LP-11 timeout error occurs. >>> >>> According to the ADV7280(-M) datasheet, "after the ADV7280-M is >>> programmed, the clock lanes exit low power mode and remain in high speed >>> mode until the part is reset or powered down." >>> So it appears the ADV7280-M has to be freshly powered on in s_power(1) Page 55 of the ADV7280-M HW Ref Manual shows how the CLK and DATA lanes can be (separately) forced into Ultra Low Power State. It mentions that when exiting ULPS it transmits the ULPS exit sequence, though it doesn't define what that sequence is. Perhaps this sequence includes transitioning through LP-11 enough to keep the CSI-2 RX happy? Just a thought. Regards, Ian >> >> What do you mean by freshly powered on? > > That the ADV7280-M is in the state before "the clock lanes exit low > power mode" due to being "programmed". Basically I was hoping that after > the initial reset sequence, and after power on, before the CSI-2 > registers are written, the clock lanes are in LP-11 state (and stay > there until then). > Unfortunately that doesn't appear to be the case below ... > >>> for this to work. Is the ADV7280-M powerdown GPIO connected properly on >>> your board? Moving the CSI-2 configuration from s_power to s_stream was >>> exactly the right thing to do in my mind. >>> >>> Just as a test, if you remove the CSI-2 register writes from either >>> s_power and s_stream from the adv7180 driver completely, do you still >>> run into the LP-11 timeout? If the CSI-2 TX never leaves the low power >>> state, I would expect seeing the clock lane timeout instead >> >> If I do this test, the first time I run the pipeline I get LP-11, the >> second time I get clock lane timeout. > > ... at least the first time. > > So now I wonder what happens between the first and second time (in > s_stream? in s_power(0)?) that does put the lanes into LP-11 from > whatever state they were in before. When you get the clock lane timeout, > is phy_state = 0x610? Does it stay there when you repeat this again? > > regards > Philipp > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Unable to capture adv7280-m on i.MX6Q 2021-06-09 17:28 ` Ian Arkver @ 2021-06-25 1:20 ` Fabio Estevam 2021-06-25 9:22 ` Ian Arkver 0 siblings, 1 reply; 14+ messages in thread From: Fabio Estevam @ 2021-06-25 1:20 UTC (permalink / raw) To: Ian Arkver Cc: Philipp Zabel, Schrempf Frieder, Steve Longerbeam, Tim Harvey, Lars-Peter Clausen, linux-media, Nicolas Dufresne Hi Ian, On Wed, Jun 9, 2021 at 2:28 PM Ian Arkver <ian.arkver.dev@gmail.com> wrote: > Page 55 of the ADV7280-M HW Ref Manual shows how the CLK and DATA lanes > can be (separately) forced into Ultra Low Power State. It mentions that > when exiting ULPS it transmits the ULPS exit sequence, though it doesn't > define what that sequence is. Perhaps this sequence includes > transitioning through LP-11 enough to keep the CSI-2 RX happy? I measured the CLK and DATA lines and they are stuck at 0. LP-11 means CLK and DATA at 1, right? So this is what I tried as per your suggestion: --- a/drivers/media/i2c/adv7180.c +++ b/drivers/media/i2c/adv7180.c @@ -505,6 +505,8 @@ static int adv7180_s_power(struct v4l2_subdev *sd, int on) struct adv7180_state *state = to_state(sd); int ret; ret = mutex_lock_interruptible(&state->mutex); if (ret) return ret; @@ -512,6 +514,20 @@ static int adv7180_s_power(struct v4l2_subdev *sd, int on) ret = adv7180_set_power(state, on); if (ret == 0) state->powered = on; + + if (state->chip_info->flags & ADV7180_FLAG_MIPI_CSI2) { + pr_err("**** Put MIPI CSI in LP-11\n"); + adv7180_csi_write(state, 0x26, 0x00); + msleep(100); + adv7180_csi_write(state, 0x26, 0x80); + msleep(100); + adv7180_csi_write(state, 0x26, 0xc0); + msleep(100); + adv7180_csi_write(state, 0x26, 0xe0); + msleep(100); + adv7180_csi_write(state, 0x26, 0xf0); + msleep(100); + } mutex_unlock(&state->mutex); return ret; but still see CLK and DATA at 0. Any ideas? Thanks, Fabio Estevam ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Unable to capture adv7280-m on i.MX6Q 2021-06-25 1:20 ` Fabio Estevam @ 2021-06-25 9:22 ` Ian Arkver 0 siblings, 0 replies; 14+ messages in thread From: Ian Arkver @ 2021-06-25 9:22 UTC (permalink / raw) To: Fabio Estevam Cc: Philipp Zabel, Schrempf Frieder, Steve Longerbeam, Tim Harvey, Lars-Peter Clausen, linux-media, Nicolas Dufresne Hi Fabio, On 25/06/2021 02:20, Fabio Estevam wrote: > Hi Ian, > > On Wed, Jun 9, 2021 at 2:28 PM Ian Arkver <ian.arkver.dev@gmail.com> wrote: > >> Page 55 of the ADV7280-M HW Ref Manual shows how the CLK and DATA lanes >> can be (separately) forced into Ultra Low Power State. It mentions that >> when exiting ULPS it transmits the ULPS exit sequence, though it doesn't >> define what that sequence is. Perhaps this sequence includes >> transitioning through LP-11 enough to keep the CSI-2 RX happy? > > I measured the CLK and DATA lines and they are stuck at 0. > > LP-11 means CLK and DATA at 1, right? > > So this is what I tried as per your suggestion: > > --- a/drivers/media/i2c/adv7180.c > +++ b/drivers/media/i2c/adv7180.c > @@ -505,6 +505,8 @@ static int adv7180_s_power(struct v4l2_subdev *sd, int on) > struct adv7180_state *state = to_state(sd); > int ret; > > ret = mutex_lock_interruptible(&state->mutex); > if (ret) > return ret; > @@ -512,6 +514,20 @@ static int adv7180_s_power(struct v4l2_subdev *sd, int on) > ret = adv7180_set_power(state, on); > if (ret == 0) > state->powered = on; > + > + if (state->chip_info->flags & ADV7180_FLAG_MIPI_CSI2) { > + pr_err("**** Put MIPI CSI in LP-11\n"); > + adv7180_csi_write(state, 0x26, 0x00); > + msleep(100); > + adv7180_csi_write(state, 0x26, 0x80); > + msleep(100); > + adv7180_csi_write(state, 0x26, 0xc0); > + msleep(100); > + adv7180_csi_write(state, 0x26, 0xe0); > + msleep(100); > + adv7180_csi_write(state, 0x26, 0xf0); > + msleep(100); > + } It looks like you're putting the clock and data into ULPS, but I don't see you clearing that mode again. It's the transition *out* of ULPS that I think would go through LP-11 and hopefully awaken the i.MX6 CSI. However, I'm only guessing from the ref manual. Unfortunately I don't have an ADV7280-M to try it with. I've only got the BT656 versions. Good luck! Ian > > mutex_unlock(&state->mutex); > return ret; > > but still see CLK and DATA at 0. > > Any ideas? > > Thanks, > > Fabio Estevam > ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2021-06-25 9:22 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-05-17 20:58 Unable to capture adv7280-m on i.MX6Q Fabio Estevam 2021-05-17 23:48 ` Fabio Estevam 2021-06-08 3:13 ` Fabio Estevam 2021-06-08 7:09 ` Philipp Zabel 2021-06-08 7:54 ` Ian Arkver 2021-06-08 10:55 ` Frieder Schrempf 2021-06-08 11:20 ` Ian Arkver 2021-06-08 11:21 ` Fabio Estevam 2021-06-09 2:34 ` Fabio Estevam 2021-06-09 7:20 ` Philipp Zabel 2021-06-09 12:27 ` Fabio Estevam 2021-06-09 17:28 ` Ian Arkver 2021-06-25 1:20 ` Fabio Estevam 2021-06-25 9:22 ` Ian Arkver
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.