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 09/12] OMAPDSS: hide dss_select_dispc_clk_source()
Date: Wed, 31 Oct 2012 06:54:34 +0000 [thread overview]
Message-ID: <5090CB17.4070400@ti.com> (raw)
In-Reply-To: <1351613409-21186-10-git-send-email-tomi.valkeinen@ti.com>
On Tuesday 30 October 2012 09:40 PM, Tomi Valkeinen wrote:
> dss.c currently exposes functions to configure the dispc source clock
> and lcd source clock. There are configured separately from the output
> drivers.
>
> However, there is no safe way for the output drivers to handle dispc
> clock, as it's shared between the outputs. Thus, if, say, the DSI driver
> sets up DSI PLL and configures both the dispc and lcd clock sources to
> that DSI PLL, the resulting dispc clock could be too low for, say, HDMI.
>
> Thus the output drivers should really only be concerned about the lcd
> clock, which is what the output drivers actually use. There's lot to do
> to clean up the dss clock handling, but this patch takes one step
> forward and removes the use of dss_select_dispc_clk_source() from the
> output drivers.
>
> After this patch, the output drivers only configure the lcd source
> clock. On omap4+ the dispc src clock is never changed from the default
> PRCM source. On omap3, where the dispc and lcd clocks are actually the
> same, setting the lcd clock source sets the dispc clock source.
Maybe we could have one call to dss_select_dispc_clk_source() in
omap_dsshw_porbe(). This is not necessary now, but if we support a
splash screen on bootloader, and skip the hwmod resets, we might want to
switch back our dispc clock source to PRCM if the output drivers don't
to it. This is just a point though, we don't necessarily need it right now.
Archit
WARNING: multiple messages have this Message-ID (diff)
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 09/12] OMAPDSS: hide dss_select_dispc_clk_source()
Date: Wed, 31 Oct 2012 12:24:15 +0530 [thread overview]
Message-ID: <5090CB17.4070400@ti.com> (raw)
In-Reply-To: <1351613409-21186-10-git-send-email-tomi.valkeinen@ti.com>
On Tuesday 30 October 2012 09:40 PM, Tomi Valkeinen wrote:
> dss.c currently exposes functions to configure the dispc source clock
> and lcd source clock. There are configured separately from the output
> drivers.
>
> However, there is no safe way for the output drivers to handle dispc
> clock, as it's shared between the outputs. Thus, if, say, the DSI driver
> sets up DSI PLL and configures both the dispc and lcd clock sources to
> that DSI PLL, the resulting dispc clock could be too low for, say, HDMI.
>
> Thus the output drivers should really only be concerned about the lcd
> clock, which is what the output drivers actually use. There's lot to do
> to clean up the dss clock handling, but this patch takes one step
> forward and removes the use of dss_select_dispc_clk_source() from the
> output drivers.
>
> After this patch, the output drivers only configure the lcd source
> clock. On omap4+ the dispc src clock is never changed from the default
> PRCM source. On omap3, where the dispc and lcd clocks are actually the
> same, setting the lcd clock source sets the dispc clock source.
Maybe we could have one call to dss_select_dispc_clk_source() in
omap_dsshw_porbe(). This is not necessary now, but if we support a
splash screen on bootloader, and skip the hwmod resets, we might want to
switch back our dispc clock source to PRCM if the output drivers don't
to it. This is just a point though, we don't necessarily need it right now.
Archit
next prev parent reply other threads:[~2012-10-31 6:54 UTC|newest]
Thread overview: 76+ 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 ` Tomi Valkeinen
2012-10-30 16:09 ` [PATCH 01/12] OMAPFB: remove use of extended edid block Tomi Valkeinen
2012-10-30 16:09 ` Tomi Valkeinen
2012-10-31 6:10 ` Archit Taneja
2012-10-31 6:22 ` Archit Taneja
2012-10-31 6:23 ` Tomi Valkeinen
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:09 ` Tomi Valkeinen
2012-10-30 16:10 ` [PATCH 03/12] OMAPDSS: fix DPI & DSI init order Tomi Valkeinen
2012-10-30 16:10 ` Tomi Valkeinen
2012-10-30 16:10 ` [PATCH 04/12] OMAPDSS: fix DSI2 PLL clk names Tomi Valkeinen
2012-10-30 16:10 ` Tomi Valkeinen
2012-10-30 16:10 ` [PATCH 05/12] OMAPDSS: DSI: skip odd dividers when pck >= 100MHz Tomi Valkeinen
2012-10-30 16:10 ` Tomi Valkeinen
2012-10-31 6:45 ` Archit Taneja
2012-10-31 6:57 ` Archit Taneja
2012-10-31 7:26 ` Tomi Valkeinen
2012-10-31 7:26 ` Tomi Valkeinen
2012-10-31 7:32 ` Archit Taneja
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 ` Tomi Valkeinen
2012-10-30 16:10 ` [PATCH 07/12] OMAPDSS: add dss_calc_clock_rates() back Tomi Valkeinen
2012-10-30 16:10 ` Tomi Valkeinen
2012-10-30 16:10 ` [PATCH 08/12] OMAPDSS: setup default dss fck Tomi Valkeinen
2012-10-30 16:10 ` Tomi Valkeinen
2012-10-31 6:31 ` Archit Taneja
2012-10-31 6:43 ` Archit Taneja
2012-10-31 7:32 ` Tomi Valkeinen
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-30 16:10 ` Tomi Valkeinen
2012-10-31 6:54 ` Archit Taneja [this message]
2012-10-31 6:54 ` Archit Taneja
2012-10-31 7:17 ` Tomi Valkeinen
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 ` 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 ` Tomi Valkeinen
2012-10-30 16:10 ` [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available Tomi Valkeinen
2012-10-30 16:10 ` Tomi Valkeinen
2012-10-31 7:26 ` Archit Taneja
2012-10-31 7:38 ` Archit Taneja
2012-11-02 10:08 ` Tomi Valkeinen
2012-11-02 10:08 ` Tomi Valkeinen
2012-11-02 10:44 ` Archit Taneja
2012-11-02 10:56 ` Archit Taneja
2012-11-02 10:49 ` Tomi Valkeinen
2012-11-02 10:49 ` Tomi Valkeinen
2012-11-02 11:09 ` Archit Taneja
2012-11-02 11:21 ` Archit Taneja
2012-11-02 11:28 ` Tomi Valkeinen
2012-11-02 11:28 ` Tomi Valkeinen
2012-11-02 11:56 ` Archit Taneja
2012-11-02 11:56 ` Archit Taneja
2012-11-05 8:55 ` Tomi Valkeinen
2012-11-05 8:55 ` Tomi Valkeinen
2012-11-05 14:21 ` Rob Clark
2012-11-05 14:21 ` Rob Clark
2012-11-06 13:41 ` Tomi Valkeinen
2012-11-06 13:41 ` Tomi Valkeinen
2012-11-06 14:40 ` Rob Clark
2012-11-06 14:40 ` Rob Clark
2012-11-07 10:01 ` Tomi Valkeinen
2012-11-07 10:01 ` Tomi Valkeinen
2012-11-07 14:32 ` Rob Clark
2012-11-07 14:32 ` Rob Clark
2012-11-07 15:13 ` Tomi Valkeinen
2012-11-07 15:13 ` Tomi Valkeinen
2012-11-07 19:18 ` Rob Clark
2012-11-07 19:18 ` Rob Clark
2012-11-08 7:39 ` Tomi Valkeinen
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=5090CB17.4070400@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.