Re: [PATCH 4/5] drm/vc4: Add DPI driver

Eric Anholt
2016-03-25T00:02:34Z

[-- Attachment #1: Type: text/plain, Size: 3674 bytes --]

Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> writes:

> On Fri, Mar 18, 2016 at 07:42:45PM -0700, Eric Anholt wrote:
>> The DPI interface involves taking a ton of our GPIOs to be used as
>> outputs, and routing display signals over them in parallel.
>>
>> Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
>> ---
>> .../devicetree/bindings/display/brcm,bcm-vc4.txt | 67 +++
>> drivers/gpu/drm/vc4/Kconfig | 1 +
>> drivers/gpu/drm/vc4/Makefile | 1 +
>> drivers/gpu/drm/vc4/vc4_debugfs.c | 1 +
>> drivers/gpu/drm/vc4/vc4_dpi.c | 518 +++++++++++++++++++++
>> drivers/gpu/drm/vc4/vc4_drv.c | 1 +
>> drivers/gpu/drm/vc4/vc4_drv.h | 5 +
>> 7 files changed, 594 insertions(+)
>> create mode 100644 drivers/gpu/drm/vc4/vc4_dpi.c
>>
>> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
>> index 56a961a..1782c3f 100644
>> --- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
>> +++ b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
>> @@ -35,6 +35,44 @@ Optional properties for HDMI:
>> as an interrupt/status bit in the HDMI controller
>> itself). See bindings/pinctrl/brcm,bcm2835-gpio.txt
>>
>> +Required properties for DPI:
>> +- compatible: Should be "brcm,bcm2835-dpi"
>> +- reg: Physical base address and length of the registers
>> +- clocks: a) core: The core clock the unit runs on
>> + b) pixel: The pixel clock that feeds the pixelvalve
>> +- port: Port node with a single endpoint connecting to the
>> + panel device, as defined in [1]
>> +- brcm,output-format: Output data format, must be one of:
>> + 0) disabled
>> + 1) 00000000rrrrrggggggbbbbb
>> + 2) 000rrrrr00gggggg000bbbbb
>> + 3) 00rrrrr000gggggg00bbbbb0
>> + 4) 000000rrrrrrggggggbbbbbb
>> + 5) 00rrrrrr00gggggg00bbbbbb
>> + 6) rrrrrrrrggggggggbbbbbbbb
>> +
>> +Optional properties for DPI:
>> +- brcm,rgb-order: RGB reordering, must be one of:
>> + 0) RGB
>> + 1) BGR
>> + 2) GRB
>> + 3) BRG
>
>> +- brcm,hsync-disable: Disables the hsync signal
>> +- brcm,vsync-disable: Disables the vsync signal
>> +- brcm,output-enable-disable: Disables the output enable signal
>> +- brcm,hsync-falling: Outputs the hsync signal on the falling clk edge
>> +- brcm,vsync-falling: Outputs the vsync signal on the falling clk edge
>> +- brcm,output-enable-falling: Outputs the output enable signal on the
>> + falling clk edge
>> +- brcm,output-enable-invert: Inverts the polarity of the output enable
>> + signal
>> +- brcm,pixel-clk-invert: Inverts the polarity of the pixel clk signal
>> +- brcm,output-enable-mode: Sets output enable when (vsync | hsync)
>> + instead of (hactive & vactive)
>
> These are all really properties of what the panel requires and we
> already have video timings binding that would cover some of these.
>
> Also, do you have actual users? Some of these seem like they would be
> rare or never. I've not seen panels caring about which clock edge the
> sync signals are on.

I was using output-format, rgb_order, output-enable-mode to get my panel
to work. I'm suspicious that the !output_enable_mode is not useful,
though (Note: I had documented it backwards: false is hsync|vsync, true
is hactive&vactive). That just left me with output-format. I think
.bus_format in the panel_desc can cover that, so I've now dropped all of
these brcm properties.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]