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 [off-list ref] wrote:

On Thu, Nov 23, 2017 at 09:14:44AM +0800, Yong wrote:

quoted

quoted

On Wed, Nov 22, 2017 at 09:33:06AM +0800, Yong wrote:

quoted

quoted

On Thu, Jul 27, 2017 at 01:01:35PM +0800, Yong Deng wrote:

quoted

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@magewell.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.

quoted

quoted

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.

quoted

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

quoted

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