From: Archit Taneja <archit@ti.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org, rob@ti.com
Subject: Re: [PATCH 05/12] OMAPDSS: DSI: skip odd dividers when pck >= 100MHz
Date: Wed, 31 Oct 2012 06:57:13 +0000 [thread overview]
Message-ID: <5090C8F9.4060103@ti.com> (raw)
In-Reply-To: <1351613409-21186-6-git-send-email-tomi.valkeinen@ti.com>
On Tuesday 30 October 2012 09:40 PM, Tomi Valkeinen wrote:
> The DSI PLL and HSDivider can be used to generate the pixel clock for
> LCD overlay manager, which then goes to DPI output. On the DPI output
> pin the voltage of the signal is shifted from the OMAP's internal
> minimal voltage to 1.8V range. The shifting is not instant, and the
> higher the clock frequency, the less time there is to shift the signal
> to nominal voltage.
>
> If the HSDivider's divider is greater than one and odd, the resulting
> pixel clock does not have 50% duty cycle. For example, with a divider of
> 3, the duty cycle is 33%.
>
> When combining high frequency (in the area of 140MHz+) and non-50% duty
> cycle, it has been observed the the shifter does not have enough time to
> shift the voltage enough, and this leads to bad signal which is rejected
> by monitors.
Is this something seen on OMAP3 also? I guess it must be since it's the
same DSI IP.
>
> As a workaround this patch makes the divider calculation skip all odd
> dividers when the required pixel clock is over 100MHz.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/dsi.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
> index 7d0db2b..d0e35da 100644
> --- a/drivers/video/omap2/dss/dsi.c
> +++ b/drivers/video/omap2/dss/dsi.c
> @@ -1386,6 +1386,11 @@ retry:
> cur.dsi_pll_hsdiv_dispc_clk > cur.clkin4ddr / cur.regm_dispc;
>
> + if (cur.regm_dispc > 1 &&
> + cur.regm_dispc % 2 != 0 &&
> + req_pck >= 1000000)
> + continue;
> +
Why do we do the req_pck check here? Can't we do it much earlier? We
could bail out right in the beginning of dsi_pll_calc_clock_div_pck() if
we see that req_pck is greater than 100 Mhz.
Also, we could maybe have a comment (or in the commit message) saying
that we chose the 100 Mhz to make it a safe bet.
Archit
next prev parent reply other threads:[~2012-10-31 6:57 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-30 16:09 [PATCH 00/12] OMAPDSS: use DSI PLL clk for DPI Tomi Valkeinen
2012-10-30 16:09 ` [PATCH 01/12] OMAPFB: remove use of extended edid block Tomi Valkeinen
2012-10-31 6:22 ` Archit Taneja
2012-10-31 6:23 ` Tomi Valkeinen
2012-10-30 16:09 ` [PATCH 02/12] OMAPFB: improve mode selection from EDID Tomi Valkeinen
2012-10-30 16:10 ` [PATCH 03/12] OMAPDSS: fix DPI & DSI init order Tomi Valkeinen
2012-10-30 16:10 ` [PATCH 04/12] OMAPDSS: fix DSI2 PLL clk names Tomi Valkeinen
2012-10-30 16:10 ` [PATCH 05/12] OMAPDSS: DSI: skip odd dividers when pck >= 100MHz Tomi Valkeinen
2012-10-31 6:57 ` Archit Taneja [this message]
2012-10-31 7:26 ` Tomi Valkeinen
2012-10-31 7:44 ` Archit Taneja
2012-10-30 16:10 ` [PATCH 06/12] OMAPDSS: DSI: workaround for HSDiv problem Tomi Valkeinen
2012-10-30 16:10 ` [PATCH 07/12] OMAPDSS: add dss_calc_clock_rates() back Tomi Valkeinen
2012-10-30 16:10 ` [PATCH 08/12] OMAPDSS: setup default dss fck Tomi Valkeinen
2012-10-31 6:43 ` Archit Taneja
2012-10-31 7:32 ` Tomi Valkeinen
2012-10-30 16:10 ` [PATCH 09/12] OMAPDSS: hide dss_select_dispc_clk_source() Tomi Valkeinen
2012-10-31 6:54 ` Archit Taneja
2012-10-31 7:17 ` Tomi Valkeinen
2012-10-30 16:10 ` [PATCH 10/12] OMAPDSS: DPI: use dpi.dsidev to see whether to use dsi pll Tomi Valkeinen
2012-10-30 16:10 ` [PATCH 11/12] OMAPDSS: DPI: verify if DSI PLL is operational Tomi Valkeinen
2012-10-30 16:10 ` [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available Tomi Valkeinen
2012-10-31 7:38 ` Archit Taneja
2012-11-02 10:08 ` Tomi Valkeinen
2012-11-02 10:56 ` Archit Taneja
2012-11-02 10:49 ` Tomi Valkeinen
2012-11-02 11:21 ` Archit Taneja
2012-11-02 11:28 ` Tomi Valkeinen
2012-11-02 11:56 ` Archit Taneja
2012-11-05 8:55 ` Tomi Valkeinen
2012-11-05 14:21 ` Rob Clark
2012-11-06 13:41 ` Tomi Valkeinen
2012-11-06 14:40 ` Rob Clark
2012-11-07 10:01 ` Tomi Valkeinen
2012-11-07 14:32 ` Rob Clark
2012-11-07 15:13 ` Tomi Valkeinen
2012-11-07 19:18 ` Rob Clark
2012-11-08 7:39 ` Tomi Valkeinen
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=5090C8F9.4060103@ti.com \
--to=archit@ti.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=rob@ti.com \
--cc=tomi.valkeinen@ti.com \
/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).