Parallel Camera Interface Timings, Signal Definitions and Polarity?

[Chen-Yu Tsai <wens@kernel.org>]

Hi everyone,

Recently, Ondřej posted a patch fixing the polarity of VSYNC/HSYNC
signals in the sun6i-csi driver [1].

Allwinner documents use the terms VSYNC and HSYNC in their camera
sensor interface hardware description, but based on the timing diagrams
included, they actually mean VREF (or inverted VSYNC) and HREF instead:
the polarity is reversed, and HSYNC is active only when valid data is
being sent over the parallel bus.

Based on my limited experience, it seems camera sensors mostly use VSYNC
and HREF, where VSYNC is defined to be a pulse that is sent after a full
frame or field has been transmitted, and HREF is a level signal which is
active when there is valid data during a horizontal line.

I'm guessing we (sunxi / Allwinner) are not the only platform to get it
wrong. Is there a concrete definition of what VSYNC and HSYNC mean, and
what active high vs active low correspond to?

For SYNC signals, I would assume the pulse portion is the active part,
so a signal such as the following would be considered active low.

    ________      ____________
            |    |
            |    |
            |____|  <- active low SYNC pulse


Also, if HSYNC is used instead of HREF, there doesn't seem to be a way
to specify how long the horizontal back porch is, i.e. how many clock
cycles should the hardware skip before capturing data. Same goes for
VSYNC instead of VREF.

Does the hardware work because we got lucky that sensors use HREF,
which means no horizontal back porch when HREF is considered an inverted
HSYNC, and no vertical back porch because HREF is only asserted starting
with the first valid line, instead of having preceding blanking lines?

The device tree bindings only have hsync-active and vsync-active. VREF
and HREF are only mentioned in passing in the header file [2], without
describing the differences or how to specify which type of signal is
used. I believe this deserves some clarification and improvement. This
would help authors of new hardware drivers immensely.

Any thoughts or comments on the matter?


Regards
ChenYu

[1] https://lkml.org/lkml/2019/11/27/1816
[2] https://elixir.bootlin.com/linux/latest/source/include/media/v4l2-mediabus.h#L27

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel