[RFC] media: sun6i-csi: V3S parallel HREF/VREF polarity mismatch with GC0308

Yixiang Xu m992364136 at gmail.com
Sun May 10 18:44:37 PDT 2026


Hi,

I am debugging a parallel DVP GC0308 camera on an Allwinner V3S board
with Linux 6.8.12 and the mainline sun6i-csi driver.

The sensor probes correctly and the media graph is created, but the
captured frames are invalid unless the HREF/VREF polarity bits in
SUN6I_CSI_IF_CFG_REG are forced to 1.

Hardware / software setup:

SoC: Allwinner V3S
Kernel: Linux 6.8.12
Driver: drivers/media/platform/sunxi/sun6i-csi/
Sensor: GalaxyCore GC0308, parallel DVP, UYVY8_2X8
MCLK: 24 MHz
Bus: 8-bit parallel

Relevant device-tree endpoint properties:

bus-width = <8>;
data-shift = <0>;
hsync-active = <1>;
vsync-active = <1>;
data-active = <1>;
pclk-sample = <1>;

The GC0308 sensor side works:

I2C address 0x21 is occupied by the kernel driver

the sensor node appears as "gc0308 0-0021"

media-ctl shows:

gc0308 0-0021 -> sun6i-csi-bridge -> sun6i-csi-capture

the sensor source pad is set to:

UYVY8_2X8/640x480

With the unmodified sun6i-csi polarity mapping, the driver computes:

IF_CFG=0x00010000

That means:

bit16 PCLK = 1
bit17 HREF = 0
bit18 VREF = 0

The resulting captured buffers have the expected size, but the contents
are not valid image data. Typical UYVY/422P dumps look like repeated
single-byte patterns plus zero-filled tails, for example:

e8 e8 e8 e8 ...
d1 d1 d1 d1 ...
84 84 84 84 ...

As an A/B test, I forced the parallel CSI IF_CFG polarity bits to match
the old Allwinner BSP behaviour:

value |= SUN6I_CSI_IF_CFG_CLK_POL_RISING |
             SUN6I_CSI_IF_CFG_HREF_POL_NEGATIVE |
             SUN6I_CSI_IF_CFG_VREF_POL_NEGATIVE;

This changes the log to:

IF_CFG=0x00070000

After this change, the captured UYVY data starts looking like real
U/Y/V/Y data, for example:

80 16 80 16 80 15 7f 15 ...

and the frame displays correctly on the LCD.

I also compared against an old working Allwinner BSP for the same board
and sensor. The old GC0308 BSP driver uses:

VREF_POL = V4L2_MBUS_VSYNC_ACTIVE_HIGH
HREF_POL = V4L2_MBUS_HSYNC_ACTIVE_HIGH
CLK_POL = V4L2_MBUS_PCLK_SAMPLE_RISING

The old BSP path is known to display the GC0308 image correctly.
It effectively programs the CSI timing/polarity bits as 1 for
PCLK/HREF/VREF on this board.

This looks related to the existing comment in sun6i_csi_reg.h:

/* Note that Allwinner manuals and code invert positive/negative definitions. */

and also to the previous discussion:

[PATCH] media: sun6i-csi: Fix incorrect HSYNC/VSYNC/PCLK polarity configuration
https://www.spinics.net/lists/arm-kernel/msg771128.html

Parallel Camera Interface Timings, Signal Definitions and Polarity?
https://www.spinics.net/lists/arm-kernel/msg771862.html

Question:

What would be the preferred way to fix or represent this?

Change the sun6i-csi parallel HREF/VREF mapping so that
active-high hsync/vsync sets IF_CFG bit17/18 to 1?

Add a V3S-specific quirk for the parallel HREF/VREF mapping?

Use a device-tree workaround by writing:

hsync-active = <0>;
vsync-active = <0>;
pclk-sample = <1>;

so that the current driver computes IF_CFG=0x00070000,
even though this contradicts the GC0308 BSP/sensor active-high
description?

Is there a better way to distinguish HREF/VREF semantics from
HSYNC/VSYNC polarity in the binding or driver?

I am not proposing the hardcoded A/B-test patch as an upstream fix.
It was only used to isolate the issue. I can provide dmesg logs,
media-ctl output, raw frame dumps, and test additional variants if that
helps.

Thanks,
Andrew



More information about the linux-arm-kernel mailing list