linux-kernel - Re: [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20171204174511.a5be3b521e9a7c7004d32d0d@magewell.com>
Date:   Mon, 4 Dec 2017 17:45:11 +0800
From:   Yong <yong.deng@...ewell.com>
To:     Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc:     Mauro Carvalho Chehab <mchehab@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Chen-Yu Tsai <wens@...e.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "David S. Miller" <davem@...emloft.net>,
        Hans Verkuil <hverkuil@...all.nl>,
        Arnd Bergmann <arnd@...db.de>,
        Hugues Fruchet <hugues.fruchet@...com>,
        Yannick Fertre <yannick.fertre@...com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Benoit Parrot <bparrot@...com>,
        Benjamin Gaignard <benjamin.gaignard@...aro.org>,
        Jean-Christophe Trotin <jean-christophe.trotin@...com>,
        Ramesh Shanmugasundaram <ramesh.shanmugasundaram@...renesas.com>,
        Minghsiu Tsai <minghsiu.tsai@...iatek.com>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Robert Jarzmik <robert.jarzmik@...e.fr>,
        linux-media@...r.kernel.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-sunxi@...glegroups.com
Subject: Re: [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.

Hi Maxime,

I just noticed that you are using the second iteration?
Have you received my third iteration?

On Sat, 25 Nov 2017 17:02:33 +0100
Maxime Ripard <maxime.ripard@...e-electrons.com> wrote:

> On Thu, Nov 23, 2017 at 09:14:44AM +0800, Yong wrote:
> > > On Wed, Nov 22, 2017 at 09:33:06AM +0800, Yong wrote:
> > > > > On Thu, Jul 27, 2017 at 01:01:35PM +0800, Yong Deng wrote:
> > > > > > Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> > > > > > and CSI1 is used for parallel interface. This is not documented in
> > > > > > datasheet but by testing and guess.
> > > > > > 
> > > > > > This patch implement a v4l2 framework driver for it.
> > > > > > 
> > > > > > Currently, the driver only support the parallel interface. MIPI-CSI2,
> > > > > > ISP's support are not included in this patch.
> > > > > > 
> > > > > > Signed-off-by: Yong Deng <yong.deng@...ewell.com>
> > > > > 
> > > > > Thanks again for this driver.
> > > > > 
> > > > > It seems like at least this iteration is behaving in a weird way with
> > > > > DMA transfers for at least YU12 and NV12 (and I would assume YV12).
> > > > > 
> > > > > Starting a transfer of multiple frames in either of these formats,
> > > > > using either ffmpeg (ffmpeg -f v4l2 -video_size 640x480 -framerate 30
> > > > > -i /dev/video0 output.mkv) or yavta (yavta -c80 -p -F --skip 0 -f NV12
> > > > > -s 640x480 $(media-c tl -e 'sun6i-csi')) will end up in a panic.
> > > > > 
> > > > > The panic seems to be generated with random data going into parts of
> > > > > the kernel memory, the pattern being in my case something like
> > > > > 0x8287868a which is very odd (always around 0x88)
> > > > > 
> > > > > It turns out that when you cover the sensor, the values change to
> > > > > around 0x28, so it really seems like it's pixels that have been copied
> > > > > there.
> > > > > 
> > > > > I've looked quickly at the DMA setup, and it seems reasonable to
> > > > > me. Do you have the same issue on your side? Have you been able to
> > > > > test those formats using your hardware?
> > > > 
> > > > I had tested the following formats with BT1120 input:
> > > > V4L2_PIX_FMT_NV12		-> NV12
> > > > V4L2_PIX_FMT_NV21		-> NV21
> > > > V4L2_PIX_FMT_NV16		-> NV16
> > > > V4L2_PIX_FMT_NV61		-> NV61
> > > > V4L2_PIX_FMT_YUV420		-> YU12
> > > > V4L2_PIX_FMT_YVU420		-> YV12
> > > > V4L2_PIX_FMT_YUV422P		-> 422P
> > > > And they all work fine.
> > > 
> > > Ok, that's good to know.
> > > 
> > > > > Given that they all are planar formats and YUYV and the likes work
> > > > > just fine, maybe we can leave them aside for now?
> > > > 
> > > > V4L2_PIX_FMT_YUV422P and V4L2_PIX_FMT_YUYV is OK, and V4L2_PIX_FMT_NV12
> > > > is bad? It's really weird.
> > > > 
> > > > What's your input bus code format, type and width?
> > > 
> > > The sensor is an ov5640, so the MBUS code for the bus is
> > > MEDIA_BUS_FMT_YUYV8_2X8.
> > 
> > Did you test on V3s?
> 
> No, this is on an H3, but that would be the first difference so far.
> 
> > I haven't tested it with MEDIA_BUS_FMT_YUYV8_2X8.
> 
> Ok, it's good to know that at least it works on your end, it's useful
> for us to debug things :)
> 
> > The Allwinner CSI's DMA is definitely weird. Ondřej Jirman thought
> > that CSI has an internal queue (Ondřej's commit has explained in detail).
> > I think CSI just pick up the buffer address before the frame done 
> > interrupt triggered. 
> > The patch in attachment can deal with this. You can see if it is
> > useful to solve your problem.
> 
> I'll test that on monday, thanks!
> 
> Maxime
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com


Thanks,
Yong