Unable to capture adv7280-m on i.MX6Q

Unable to capture adv7280-m on i.MX6Q

[Fabio Estevam]

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

Re: Unable to capture adv7280-m on i.MX6Q

[Fabio Estevam]

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

Re: Unable to capture adv7280-m on i.MX6Q

[Fabio Estevam]

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

Re: Unable to capture adv7280-m on i.MX6Q

[Philipp Zabel]

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

Re: Unable to capture adv7280-m on i.MX6Q

[Ian Arkver]

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
> 

Re: Unable to capture adv7280-m on i.MX6Q

[Frieder Schrempf]

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&amp;data=04%7C01%7Cfrieder.schrempf%40kontron.de%7C81057e8e187d4f2bf61908d92a52b30a%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637587357508272332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=tb3C%2FU20jo5tp58olvCo%2BRWREFNZEJaZop1hHGMksBE%3D&amp;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&amp;data=04%7C01%7Cfrieder.schrempf%40kontron.de%7C81057e8e187d4f2bf61908d92a52b30a%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637587357508272332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=hsuRqyEYAh1PtGiwZRKcmENkVbJuRN85DBmuXHOZhBs%3D&amp;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
>>

Re: Unable to capture adv7280-m on i.MX6Q

[Ian Arkver]

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&amp;data=04%7C01%7Cfrieder.schrempf%40kontron.de%7C81057e8e187d4f2bf61908d92a52b30a%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637587357508272332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=tb3C%2FU20jo5tp58olvCo%2BRWREFNZEJaZop1hHGMksBE%3D&amp;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&amp;data=04%7C01%7Cfrieder.schrempf%40kontron.de%7C81057e8e187d4f2bf61908d92a52b30a%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637587357508272332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=hsuRqyEYAh1PtGiwZRKcmENkVbJuRN85DBmuXHOZhBs%3D&amp;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
>>>

Re: Unable to capture adv7280-m on i.MX6Q

[Fabio Estevam]

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 :-)

Re: Unable to capture adv7280-m on i.MX6Q

[Fabio Estevam]

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

Re: Unable to capture adv7280-m on i.MX6Q

[Philipp Zabel]

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

Re: Unable to capture adv7280-m on i.MX6Q

[Fabio Estevam]

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

Re: Unable to capture adv7280-m on i.MX6Q

[Ian Arkver]

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
> 

Re: Unable to capture adv7280-m on i.MX6Q

[Fabio Estevam]

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

Re: Unable to capture adv7280-m on i.MX6Q

[Ian Arkver]

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
>