[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20181025161711.13727-1-TheSven73@googlemail.com>
Date: Thu, 25 Oct 2018 12:17:10 -0400
From: thesven73@...il.com
To: svendev@...x.com, p.zabel@...gutronix.de, denis@...rea.com,
rmk+kernel@....linux.org.uk
Cc: linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: [RFC v1 0/1] imx-drm: match ipu_di_signal_cfg's clk_pol with its observed behaviour.
From: Sven Van Asbroeck <svendev@...x.com>
Request For Comments
We believe that the ipuv3 DI's pixel clock polarity is possibly being
misconfigured by the imx-drm driver.
We used an oscilloscope the observe the actual behaviour on our hardware,
and it is the opposite of what the driver is supposed to configure.
Some confusion could arise because the Freescale documentation does not
speak about data stable on rising or falling edge, but only of clock active
high / active low:
i.MX 6Dual/6Quad Applications Processor Reference Manual, Rev. 3, 07/2015,
page 3298)
bit 17 DI0 Output Clock's polarity
This bits define the polarity of the DI0's clock.
1 The output clock is active high
0 The output clock is active low
However, the supposedly wrong behaviour has been in place since April 2014,
and no-one has complained so far.
See commit 85de9d17c485c4196f74d45de2206d4802f8a3be
What are we missing ?
Sven Van Asbroeck (1):
imx-drm: match ipu_di_signal_cfg's clk_pol with its observed
behaviour.
drivers/gpu/ipu-v3/ipu-di.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.17.1
Powered by blists - more mailing lists