From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3] imx-drm: Add mx6 hdmi transmitter support
Date: Wed, 30 Oct 2013 19:36:22 +0000 [thread overview]
Message-ID: <20131030193622.GN16735@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <1382992009-19407-1-git-send-email-festevam@gmail.com>
On Mon, Oct 28, 2013 at 06:26:49PM -0200, Fabio Estevam wrote:
> + /*Wait for PHY PLL lock */
> + msec = 4;
> + val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
> + while (!val) {
> + udelay(1000);
> + if (msec-- == 0) {
> + dev_dbg(hdmi->dev, "PHY PLL not locked\n");
> + return -EINVAL;
> + }
> + val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
> + }
This loop is not always sufficient for the PLL to always lock. It's also
buggy because it behaves like this:
msec = 4
read register
check bit - still one?
yes - wait 1ms
msec == 0?
no - msec = 3
read register
... msec eventually msec = 0
read register
check bit - still one
yes - wait 1ms
msec == 0?
yes - print debug and exit
So the last wait for 1ms performs no real function other than to delay
the inevitable exit. If we really want to wait 5ms for the condition
we're testing to become true, then do it like this:
msec = 5;
do {
val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
if (!val)
break;
if (msec == 0) {
dev_err(hdmi->dev, "PHY PLL not locked\n");
return -EINVAL;
}
udelay(1000);
msec--;
} while (1);
This way, we check for the success condition immediately before checking
for the failure condition, and only waiting after that.
I'd also suggest making it a dev_err() so that it's obvious when it
doesn't lock - the current dev_dbg() remains hidden and causes
failures which don't seem to be visible to the user via the logs.
Hence why this issue has been overlooked...
> +static void hdmi_av_composer(struct imx_hdmi *hdmi,
> + const struct drm_display_mode *mode)
> +{
> + u8 inv_val;
> + struct hdmi_vmode *vmode = &hdmi->hdmi_data.video_mode;
> + int hblank, vblank, h_de_hs, v_de_vs, hsync_len, vsync_len;
> +
> + vmode->mhsyncpolarity = !!(mode->flags & DRM_MODE_FLAG_PHSYNC);
> + vmode->mvsyncpolarity = !!(mode->flags & DRM_MODE_FLAG_PVSYNC);
> + vmode->minterlaced = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
> + vmode->mpixelclock = mode->htotal * mode->vtotal *
> + drm_mode_vrefresh(mode);
We can do better here:
vmode->mpixelclock = mode->clock * 1000;
as the above is not quite correct when considering all the
possibilities. Since we're given the pixel clock in the mode structure,
we might as well make use it.
> + /* Set up VSYNC active edge delay (in pixel clks) */
> + vsync_len = mode->vsync_end - mode->vsync_start;
> + hdmi_writeb(hdmi, vsync_len, HDMI_FC_VSYNCINWIDTH);
Commentry - vsync len is in lines not pixel clocks.
Other than that, it seems to work here on the Carrier-1. Thanks.
next prev parent reply other threads:[~2013-10-30 19:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1382992009-19407-1-git-send-email-festevam@gmail.com>
2013-10-28 21:03 ` [PATCH v3] imx-drm: Add mx6 hdmi transmitter support Greg KH
2013-10-29 22:01 ` Fabio Estevam
2013-10-29 23:47 ` Russell King - ARM Linux
2013-10-30 1:00 ` Fabio Estevam
2013-10-28 21:19 ` Russell King - ARM Linux
2013-10-29 15:00 ` Fabio Estevam
2013-10-29 15:45 ` Fabio Estevam
2013-10-29 18:53 ` Russell King - ARM Linux
2013-10-30 19:36 ` Russell King - ARM Linux [this message]
2013-10-30 20:39 ` Russell King - ARM Linux
2013-10-30 20:39 ` [PATCH 1/6] imx-drm: hdmi: fix PLL lock wait Russell King
2013-10-30 20:41 ` [PATCH 2/6] imx-drm: hdmi: fix pixel clock Russell King
2013-10-30 20:42 ` [PATCH 3/6] imx-drm: hdmi: fix wrong comment Russell King
2013-10-30 20:43 ` [PATCH 4/6] imx-drm: hdmi: get rid of pointless fb_reg Russell King
2013-10-30 20:44 ` [PATCH 5/6] imx-drm: hdmi: get rid of clk manipulations in imx_hdmi_fb_registered() Russell King
2013-10-30 20:45 ` [PATCH 6/6] imx-drm: hdmi: minor cleanups Russell King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131030193622.GN16735@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).