From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
To: linux-fbdev@vger.kernel.org
Subject: Re: [PATCH 3/6] ARM: mach-shmobile: extend clock definitions on
Date: Fri, 02 Jul 2010 12:33:24 +0000 [thread overview]
Message-ID: <Pine.LNX.4.64.1007021402540.1237@axis700.grange> (raw)
In-Reply-To: <Pine.LNX.4.64.1006301137290.17489@axis700.grange>
On Fri, 2 Jul 2010, Magnus Damm wrote:
> On Wed, Jun 30, 2010 at 6:55 PM, Guennadi Liakhovetski
> <g.liakhovetski@gmx.de> wrote:
> > Add definitions for DV_CLKI and HDMI clocks, extend support for PLLC2 and some
> > other clocks.
> >
> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>
> Hi Guennadi,
>
> Thanks for your work on this.
>
> > diff --git a/arch/arm/mach-shmobile/clock-sh7372.c b/arch/arm/mach-shmobile/clock-sh7372.c
> > index 26521a7..21cb629 100644
> > --- a/arch/arm/mach-shmobile/clock-sh7372.c
> > +++ b/arch/arm/mach-shmobile/clock-sh7372.c
> > @@ -50,6 +50,12 @@
> > #define SMSTPCR3 0xe615013c
> > #define SMSTPCR4 0xe6150140
> >
> > +/* Fixed 27 MHz video clock from DV_CLKI pin */
> > +static struct clk dv_clki_clk = {
> > + .name = "dv_clki",
> > + .rate = 27000000,
> > +};
>
> Hm, 27MHz is a board property, not a cpu property.
Well, yes, but I think somewhere something suggested, that 27MHz is what
you're actually supposed to provide there. Otherwise your board can always
just call clk_set_rate(), right? Or what's the preferred way to let
platforms set up clocks?
> Also, you don't want to use "name" in struct clk. clkdev is used for
> lookup these days.
Right, it is not needed, thanks.
> > /* PLLC2 */
> > +
> > +/* Indices are important - they are the actual src selecting values */
> > +static struct clk *pllc2_parent[] = {
> > + [0] = &extal1_div2_clk,
> > + [1] = &extal2_div2_clk,
> > + [2] = &dv_clki_div2_clk,
> > + [3] = NULL, /* extal2_div4 not implemented yet*/
> > +};
>
> Why not implemented yet?
Because it's not used yet. Should I implement it anyway?
> > + /*
> > + * TODO: If the PLL is off, mult should be = 1, but the clock must be
> > + * stopped during re-parenting, a better solution to this conflict
> > + * should be found.
> > + */
> > + mult = (((__raw_readl(PLLC2CR) >> 24) & 0x3f) + 1) * 2;
>
> Yes, this needs to be fixed.
You mean now or in the future? If now - I don't see a reasonable fix so
far... Do you?
> > +enum { DIV6_HDMI, DIV6_REPARENT_NR };
> > +
> > +/* Indices are important - they are the actual src selecting values */
> > +static struct clk *hdmi_parent[] = {
> > + [0] = &pllc1_div2_clk,
> > + [1] = &pllc2_clk,
> > + [2] = &dv_clki_clk,
> > + [3] = NULL, /* pllc2_div4 not implemented yet */
> > +};
> > +
> > +static struct clk div6_reparent_clks[DIV6_REPARENT_NR] = {
> > + [DIV6_HDMI] = SH_CLK_DIV6_EXT(&pllc1_div2_clk, HDMICKCR, 0,
> > + hdmi_parent, ARRAY_SIZE(hdmi_parent), 6, 2),
> > +};
>
> This part looks nice and clean IMO. Thanks!
Thanks for the review!
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
next prev parent reply other threads:[~2010-07-02 12:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-30 9:55 [PATCH 3/6] ARM: mach-shmobile: extend clock definitions on sh7372 Guennadi Liakhovetski
2010-07-02 8:21 ` [PATCH 3/6] ARM: mach-shmobile: extend clock definitions on Magnus Damm
2010-07-02 12:33 ` Guennadi Liakhovetski [this message]
2010-07-05 4:20 ` Magnus Damm
2010-07-05 15:04 ` Guennadi Liakhovetski
2010-07-06 9:46 ` Magnus Damm
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=Pine.LNX.4.64.1007021402540.1237@axis700.grange \
--to=g.liakhovetski@gmx.de \
--cc=linux-fbdev@vger.kernel.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