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

[Yong]

Hi,

On Wed, 22 Nov 2017 10:45:26 +0100
Maxime Ripard <maxime.ripard at free-electrons.com> wrote:

> Hi,
> 
> 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 at 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.
> 
> > > 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?
I haven't tested it with MEDIA_BUS_FMT_YUYV8_2X8.

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.

Thanks,
Yong
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sun6i_csi_fix_writing_to_incorrect_buffer.patch
Type: application/octet-stream
Size: 10429 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171123/59977f67/attachment.obj>