Re: [PATCH v2 0/2] media: i2c: ov5640: Re-work MIPI startup sequence
Hi Jacopo, Pardon the late reply, see below. On 07/11/2018 12:21 AM, jacopo mondi wrote: Hi Steve, On Tue, Jul 10, 2018 at 02:10:54PM -0700, Steve Longerbeam wrote: Hi Jacopo, Sorry to report my testing on SabreSD has same result as last time. This series fixes the LP-11 timeout at stream on but captured images are still blank. I tried the 640x480 mode with UYVY2X8. Here is the pad config: This saddens me :( I'm capturing with the same format and sizes... this shouldn't be the issue Could you confirm this matches what you have in your tree? 5dc2c80 media: ov5640: Fix timings setup code b35e757 media: i2c: ov5640: Re-work MIPI startup sequence 3c4a737 media: ov5640: fix frame interval enumeration 41cb1c7 media: ov5640: adjust xclk_max c3f3ba3 media: ov5640: add support of module orientation ce85705 media: ov5640: add HFLIP/VFLIP controls support 8663341 media: ov5640: Program the visible resolution 476dec0 media: ov5640: Add horizontal and vertical totals dba13a0 media: ov5640: Change horizontal and vertical resolutions name 8f57c2f media: ov5640: Init properly the SCLK dividers Yes, I have that commit sequence. FWIW, I can verify what Jagan Teki reported earlier, that the driver still works on the SabreSD platform at: dba13a0 media: ov5640: Change horizontal and vertical resolutions name and is broken at: 476dec0 media: ov5640: Add horizontal and vertical totals with LP-11 timeout at the mipi csi-2 receiver: [ 80.763189] imx6-mipi-csi2: LP-11 timeout, phy_state = 0x0230 [ 80.769599] ipu1_csi1: pipeline start failed with -110 Steve # media-ctl --get-v4l2 "'ov5640 1-003c':0" [fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range] Steve On 07/10/2018 11:36 AM, Jacopo Mondi wrote: Hello, this series fixes capture operations on i.MX6Q platforms (and possible other platforms reported not working) using MIPI CSI-2 interface. This iteration expands the v1 version with an additional fix, initially submitted by Maxime in his series: [PATCH v3 00/12] media: ov5640: Misc cleanup and improvements https://www.spinics.net/lists/linux-media/msg134436.html The original patch has been reported not fully fixing the issues by Daniel Mack in his comment here below (on a Qualcomm platform if I'm not wrong): https://www.spinics.net/lists/linux-media/msg134524.html On my i.MX6Q testing platform that patch alone does not fix MIPI capture neither. The version I'm sending here re-introduces some of the timings parameters in the initial configuration blob (not in the single mode ones), which apparently has to be at least initially programmed to allow the driver to later program them singularly in the 'set_timings()' function. Unfortunately I do not have a real rationale behind this which explains why it has to be done this way :( For the MIPI startup sequence re-work patch, no changes compared to v1. Steve reported he has verified the LP-11 timout issue is solved on his testing platform too. For more details, please refer to the v1 cover letter: https://www.mail-archive.com/linux-media@vger.kernel.org/msg133352.html Thanks j Jacopo Mondi (1): media: i2c: ov5640: Re-work MIPI startup sequence Samuel Bobrowicz (1): media: ov5640: Fix timings setup code drivers/media/i2c/ov5640.c | 107 ++--- 1 file changed, 82 insertions(+), 25 deletions(-) -- 2.7.4
Re: [PATCH v2 0/2] media: i2c: ov5640: Re-work MIPI startup sequence
Hi Jacopo, On 07/14/2018 11:57 AM, Steve Longerbeam wrote: Hi Jacopo, Pardon the late reply, see below. On 07/11/2018 12:21 AM, jacopo mondi wrote: Hi Steve, On Tue, Jul 10, 2018 at 02:10:54PM -0700, Steve Longerbeam wrote: Hi Jacopo, Sorry to report my testing on SabreSD has same result as last time. This series fixes the LP-11 timeout at stream on but captured images are still blank. I tried the 640x480 mode with UYVY2X8. Here is the pad config: This saddens me :( I'm capturing with the same format and sizes... this shouldn't be the issue Could you confirm this matches what you have in your tree? 5dc2c80 media: ov5640: Fix timings setup code b35e757 media: i2c: ov5640: Re-work MIPI startup sequence 3c4a737 media: ov5640: fix frame interval enumeration 41cb1c7 media: ov5640: adjust xclk_max c3f3ba3 media: ov5640: add support of module orientation ce85705 media: ov5640: add HFLIP/VFLIP controls support 8663341 media: ov5640: Program the visible resolution 476dec0 media: ov5640: Add horizontal and vertical totals dba13a0 media: ov5640: Change horizontal and vertical resolutions name 8f57c2f media: ov5640: Init properly the SCLK dividers Yes, I have that commit sequence. FWIW, I can verify what Jagan Teki reported earlier, that the driver still works on the SabreSD platform at: dba13a0 media: ov5640: Change horizontal and vertical resolutions name and is broken at: 476dec0 media: ov5640: Add horizontal and vertical totals with LP-11 timeout at the mipi csi-2 receiver: [ 80.763189] imx6-mipi-csi2: LP-11 timeout, phy_state = 0x0230 [ 80.769599] ipu1_csi1: pipeline start failed with -110 And I discovered the bug in 476dec0 "media: ov5640: Add horizontal and vertical totals". The call to ov5640_set_timings() needs to be moved before the calls to ov5640_get_vts() and ov5640_get_hts(). But I see you have discovered that as well, and fixed in the second patch in your series. Steve # media-ctl --get-v4l2 "'ov5640 1-003c':0" [fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range] Steve On 07/10/2018 11:36 AM, Jacopo Mondi wrote: Hello, this series fixes capture operations on i.MX6Q platforms (and possible other platforms reported not working) using MIPI CSI-2 interface. This iteration expands the v1 version with an additional fix, initially submitted by Maxime in his series: [PATCH v3 00/12] media: ov5640: Misc cleanup and improvements https://www.spinics.net/lists/linux-media/msg134436.html The original patch has been reported not fully fixing the issues by Daniel Mack in his comment here below (on a Qualcomm platform if I'm not wrong): https://www.spinics.net/lists/linux-media/msg134524.html On my i.MX6Q testing platform that patch alone does not fix MIPI capture neither. The version I'm sending here re-introduces some of the timings parameters in the initial configuration blob (not in the single mode ones), which apparently has to be at least initially programmed to allow the driver to later program them singularly in the 'set_timings()' function. Unfortunately I do not have a real rationale behind this which explains why it has to be done this way :( For the MIPI startup sequence re-work patch, no changes compared to v1. Steve reported he has verified the LP-11 timout issue is solved on his testing platform too. For more details, please refer to the v1 cover letter: https://www.mail-archive.com/linux-media@vger.kernel.org/msg133352.html Thanks j Jacopo Mondi (1): media: i2c: ov5640: Re-work MIPI startup sequence Samuel Bobrowicz (1): media: ov5640: Fix timings setup code drivers/media/i2c/ov5640.c | 107 ++--- 1 file changed, 82 insertions(+), 25 deletions(-) -- 2.7.4
Re: [PATCH v2 0/2] media: i2c: ov5640: Re-work MIPI startup sequence
On 07/14/2018 12:41 PM, Steve Longerbeam wrote: Hi Jacopo, On 07/14/2018 11:57 AM, Steve Longerbeam wrote: Hi Jacopo, Pardon the late reply, see below. On 07/11/2018 12:21 AM, jacopo mondi wrote: Hi Steve, On Tue, Jul 10, 2018 at 02:10:54PM -0700, Steve Longerbeam wrote: Hi Jacopo, Sorry to report my testing on SabreSD has same result as last time. This series fixes the LP-11 timeout at stream on but captured images are still blank. I tried the 640x480 mode with UYVY2X8. Here is the pad config: This saddens me :( I'm capturing with the same format and sizes... this shouldn't be the issue Could you confirm this matches what you have in your tree? 5dc2c80 media: ov5640: Fix timings setup code b35e757 media: i2c: ov5640: Re-work MIPI startup sequence 3c4a737 media: ov5640: fix frame interval enumeration 41cb1c7 media: ov5640: adjust xclk_max c3f3ba3 media: ov5640: add support of module orientation ce85705 media: ov5640: add HFLIP/VFLIP controls support 8663341 media: ov5640: Program the visible resolution 476dec0 media: ov5640: Add horizontal and vertical totals dba13a0 media: ov5640: Change horizontal and vertical resolutions name 8f57c2f media: ov5640: Init properly the SCLK dividers Yes, I have that commit sequence. FWIW, I can verify what Jagan Teki reported earlier, that the driver still works on the SabreSD platform at: dba13a0 media: ov5640: Change horizontal and vertical resolutions name and is broken at: 476dec0 media: ov5640: Add horizontal and vertical totals with LP-11 timeout at the mipi csi-2 receiver: [ 80.763189] imx6-mipi-csi2: LP-11 timeout, phy_state = 0x0230 [ 80.769599] ipu1_csi1: pipeline start failed with -110 And I discovered the bug in 476dec0 "media: ov5640: Add horizontal and vertical totals". The call to ov5640_set_timings() needs to be moved before the calls to ov5640_get_vts() and ov5640_get_hts(). But I see you have discovered that as well, and fixed in the second patch in your series. But strangely, if I revert to 476dec0, and then move the call to ov5640_set_timings() to just after ov5640_load_regs() in ov5640_set_mode_exposure_calc() and ov5640_set_mode_direct(), the LP-11 timeouts are still present. So I can confirm this strangeness which you already pointed out below [1]. The version I'm sending here re-introduces some of the timings parameters in the initial configuration blob (not in the single mode ones), which apparently has to be at least initially programmed to allow the driver to later program them singularly in the 'set_timings()' function. Unfortunately I do not have a real rationale behind this which explains why it has to be done this way :( [1] here :) Steve
cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sun Jul 15 05:00:11 CEST 2018 media-tree git hash:39fbb88165b2bbbc77ea7acab5f10632a31526e6 media_build git hash: f3b64e45d2f2ef45cd4ae5b90a8f2a4fb284e43c v4l-utils git hash: e4df0e3cd3a84570714defe279d13eae894cb1fa edid-decode git hash: ab18befbcacd6cd4dff63faa82e32700369d6f25 gcc version:i686-linux-gcc (GCC) 8.1.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.16.0-1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-arm64: OK linux-git-i686: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK Check COMPILE_TEST: OK linux-2.6.36.4-i686: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-i686: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-i686: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-i686: OK linux-2.6.39.4-x86_64: OK linux-3.0.101-i686: OK linux-3.0.101-x86_64: OK linux-3.1.10-i686: OK linux-3.1.10-x86_64: OK linux-3.2.102-i686: OK linux-3.2.102-x86_64: OK linux-3.3.8-i686: OK linux-3.3.8-x86_64: OK linux-3.4.113-i686: OK linux-3.4.113-x86_64: OK linux-3.5.7-i686: OK linux-3.5.7-x86_64: OK linux-3.6.11-i686: OK linux-3.6.11-x86_64: OK linux-3.7.10-i686: OK linux-3.7.10-x86_64: OK linux-3.8.13-i686: OK linux-3.8.13-x86_64: OK linux-3.9.11-i686: OK linux-3.9.11-x86_64: OK linux-3.10.108-i686: OK linux-3.10.108-x86_64: OK linux-3.11.10-i686: OK linux-3.11.10-x86_64: OK linux-3.12.74-i686: OK linux-3.12.74-x86_64: OK linux-3.13.11-i686: OK linux-3.13.11-x86_64: OK linux-3.14.79-i686: OK linux-3.14.79-x86_64: OK linux-3.15.10-i686: OK linux-3.15.10-x86_64: OK linux-3.16.57-i686: OK linux-3.16.57-x86_64: OK linux-3.17.8-i686: OK linux-3.17.8-x86_64: OK linux-3.18.115-i686: OK linux-3.18.115-x86_64: OK linux-3.19.8-i686: OK linux-3.19.8-x86_64: OK linux-4.0.9-i686: OK linux-4.0.9-x86_64: OK linux-4.1.52-i686: OK linux-4.1.52-x86_64: OK linux-4.2.8-i686: OK linux-4.2.8-x86_64: OK linux-4.3.6-i686: OK linux-4.3.6-x86_64: OK linux-4.4.140-i686: OK linux-4.4.140-x86_64: OK linux-4.5.7-i686: OK linux-4.5.7-x86_64: OK linux-4.6.7-i686: OK linux-4.6.7-x86_64: OK linux-4.7.10-i686: OK linux-4.7.10-x86_64: OK linux-4.8.17-i686: OK linux-4.8.17-x86_64: OK linux-4.9.112-i686: OK linux-4.9.112-x86_64: OK linux-4.10.17-i686: OK linux-4.10.17-x86_64: OK linux-4.11.12-i686: OK linux-4.11.12-x86_64: OK linux-4.12.14-i686: OK linux-4.12.14-x86_64: OK linux-4.13.16-i686: OK linux-4.13.16-x86_64: OK linux-4.14.55-i686: OK linux-4.14.55-x86_64: OK linux-4.15.18-i686: OK linux-4.15.18-x86_64: OK linux-4.16.18-i686: OK linux-4.16.18-x86_64: OK linux-4.17.6-i686: OK linux-4.17.6-x86_64: OK linux-4.18-rc4-i686: OK linux-4.18-rc4-x86_64: OK apps: OK spec-git: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
