[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