Hi Uli,
On Mon, Feb 26, 2018 at 11:18 AM, Geert Uytterhoeven
<geert@xxxxxxxxxxxxxx> wrote:
> On Mon, Feb 26, 2018 at 10:21 AM, Geert Uytterhoeven
> <geert@xxxxxxxxxxxxxx> wrote:
>> On Mon, Feb 26, 2018 at 10:02 AM, Ulrich Hecht
>> <ulrich.hecht+renesas@xxxxxxxxx> wrote:
>>> On Tue, Feb 20, 2018 at 2:58 PM, Geert Uytterhoeven
>>> <geert@xxxxxxxxxxxxxx> wrote:
>>>> Would there be a use case for vin4_data4 and vin5_data4, or is that
>>>> mode only supported on R-Car H2?
>>>
>>> The docs don't mention it, so I would assume it's not supported.
>>
>> Thank you, queuing (also for r8a7795 and r8a77995) in sh-pfc-for-v4.17.
>
> Please send follow-up patches to reduce vin_data duplication.
Due to Sergei's submission for r8a77980, my attention was drawn to
Tables 26.8.x, which describes which pins are used for each video input
format.
The newly added tables for data18 are not correct, as they use the
VI4_DATA0-17 pins, while data18/rgb666 uses the same pins as data24/rgb888
mode, minus the 2 LSB pins for each channel. The BSP does it right, just
like the R-Car Gen2 PFC drivers.
As in the mean time this is in pinctrl/for-next, can you please send
follow-up patches fixing this bug for R-Car H3, M3-W, and D3?
Thanks!
P.S. Apparently R-Car Gen2 and Gen3 also support 8-bit YCbCr input data
on the DATA8-15 pins, for which we don't have pin groups yet.
Niklas: is this mode supported by the VIN driver?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
