Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752668AbdLDJpd (ORCPT ); Mon, 4 Dec 2017 04:45:33 -0500 Received: from out20-74.mail.aliyun.com ([115.124.20.74]:53694 "EHLO out20-74.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751156AbdLDJpa (ORCPT ); Mon, 4 Dec 2017 04:45:30 -0500 X-Alimail-AntiSpam: AC=CONTINUE;BC=0.04459847|-1;CH=green;FP=0|0|0|0|0|-1|-1|-1;HT=e02c03275;MF=yong.deng@magewell.com;NM=1;PH=DS;RN=24;RT=24;SR=0;TI=SMTPD_---.9awMRQg_1512380712; Date: Mon, 4 Dec 2017 17:45:11 +0800 From: Yong To: Maxime Ripard Cc: Mauro Carvalho Chehab , Rob Herring , Mark Rutland , Chen-Yu Tsai , Greg Kroah-Hartman , "David S. Miller" , Hans Verkuil , Arnd Bergmann , Hugues Fruchet , Yannick Fertre , Philipp Zabel , Benoit Parrot , Benjamin Gaignard , Jean-Christophe Trotin , Ramesh Shanmugasundaram , Minghsiu Tsai , Krzysztof Kozlowski , Robert Jarzmik , linux-media@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com Subject: Re: [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI. Message-Id: <20171204174511.a5be3b521e9a7c7004d32d0d@magewell.com> In-Reply-To: <20171125160233.skefdpkjy4peh7et@flea.lan> References: <1501131697-1359-1-git-send-email-yong.deng@magewell.com> <1501131697-1359-2-git-send-email-yong.deng@magewell.com> <20171121154827.5a35xa6zlqrrvkxx@flea.lan> <20171122093306.d30fe641f269d62daa1f66b4@magewell.com> <20171122094526.nqxfy2e5jzxw7nl4@flea.lan> <20171123091444.4bed66dffeb36ecea8dfa706@magewell.com> <20171125160233.skefdpkjy4peh7et@flea.lan> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3688 Lines: 95 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 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 > > > > > > > > > > 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