Re: [PATCH v2 1/3] dt-bindings: display: display-timing: Add property to configure sync drive edge
From: Tomi Valkeinen <hidden>
Date: 2016-09-29 10:54:15
Also in:
dri-devel, linux-fbdev, lkml
On 22/09/16 13:35, Peter Ujfalusi wrote:
quoted hunk ↗ jump to hunk
There are display panels which demands that the sync signal is driven on different edge than the pixel data. With the syncclk-active property we can specify the clk edge to be used to drive the sync signal. When the property is missing it indicates that the sync is driven on the same edge as the pixel data. Signed-off-by: Peter Ujfalusi <redacted> CC: Rob Herring <robh+dt@kernel.org> CC: Mark Rutland <mark.rutland@arm.com> CC: devicetree@vger.kernel.org --- .../devicetree/bindings/display/panel/display-timing.txt | 8 ++++++++ 1 file changed, 8 insertions(+)diff --git a/Documentation/devicetree/bindings/display/panel/display-timing.txt b/Documentation/devicetree/bindings/display/panel/display-timing.txt index e1d4a0b59612..81a75893d1b8 100644 --- a/Documentation/devicetree/bindings/display/panel/display-timing.txt +++ b/Documentation/devicetree/bindings/display/panel/display-timing.txt@@ -32,6 +32,14 @@ optional properties: - active low = drive pixel data on falling edge/ sample data on rising edge - ignored = ignored + - syncclk-active: with + - active high = drive sync on rising edge/ + sample sync on falling edge of pixel + clock + - active low = drive sync on falling edge/ + sample sync on rising edge of pixel + clock + - omitted = same configuration as pixelclk-active
I wonder if the "sample sync on..." should be left out here. It makes sense for the pixel data, but for sync... Do the panels "sample" it, or do they trigger on rising/falling edge? Well, maybe that's a bit on the nitpick side, so: Reviewed-by: Tomi Valkeinen <redacted> Tomi