linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [RFC v1 0/1] imx-drm: match ipu_di_signal_cfg's clk_pol with its observed behaviour.
@ 2018-10-25 18:15 thesven73
  0 siblings, 0 replies; 2+ messages in thread
From: thesven73 @ 2018-10-25 18:15 UTC (permalink / raw)
  To: svendev, p.zabel, denis, rmk+kernel; +Cc: linux-kernel, dri-devel

Hi Russell, thanks for looking at the RFC !

> Given what's in the documentation, I'd opt for it describing the
> edge that the output data changes, not the latch edge.  With that
> interpretation, the existing code is correct.

The clock polarity is reversed in Freescale's non-mainline fbdev code,
which we were using previously, contributing to the confusion.

Yes, I think your interpretation is the correct one. Let's double-check.

Suppose we set this bus flag in the panel/mode definition:

drm/drm_connector.h:
/* drive data on pos. edge */
#define DRM_BUS_FLAG_PIXDATA_POSEDGE	(1<<2)

According to your interpretation, this means we're asking the data to change
on the positive edge, and be stable on the negative edge. Correct?

then clk_pol == 1:
drivers/gpu/drm/imx/ipuv3-crtc.c:
	sig_cfg.clk_pol = !!(imx_crtc_state->bus_flags &
			     DRM_BUS_FLAG_PIXDATA_POSEDGE);

then DI_GENERAL bit 17 is set:
drivers/gpu/ipu-v3/ipu-di.c:
	if (sig->clk_pol)
		di_gen |= DI_GEN_POLARITY_DISP_CLK;

and data is stable on the pixel clock's falling edge, as we observed on
the oscilloscope.

All good. Thank you !

^ permalink raw reply	[flat|nested] 2+ messages in thread
* [RFC v1 0/1] imx-drm: match ipu_di_signal_cfg's clk_pol with its observed behaviour.
@ 2018-10-25 16:17 thesven73
  0 siblings, 0 replies; 2+ messages in thread
From: thesven73 @ 2018-10-25 16:17 UTC (permalink / raw)
  To: svendev, p.zabel, denis, rmk+kernel; +Cc: linux-kernel, dri-devel

From: Sven Van Asbroeck <svendev@arcx.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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2018-10-25 18:15 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-25 18:15 [RFC v1 0/1] imx-drm: match ipu_di_signal_cfg's clk_pol with its observed behaviour thesven73
  -- strict thread matches above, loose matches on Subject: below --
2018-10-25 16:17 thesven73

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).