Setting dss1_alwon_fck

Setting dss1_alwon_fck

[Tomi Valkeinen]

Hi,

Mans Rullgard has the patches mentioned below in his kernel tree at
http://git.mansr.com/?p=linux-omap;a=summary . I currently have those
patches and use the following sequence to set the dss1_alwon_fck clock:

/* get the rate of the parent of dpll4_m4_ck, which is dpll4_ck */
prate = clk_get_rate(clk_get_parent(dispc.dpll4_m4_ck));

/* calculate divisor so that wanted dss1_alwon_fck is prate / div * 2.
 * x2 because dss1_alwon_fck comes from dpll4_m4x2_ck */
div = ...;

/* set the rate */
clk_set_rate(dispc.dpll4_m4_ck, prate / div);

Is this the correct way to set dss1_alwon_fck? Are the patches below
needed, or can dss1_alwon_fck be set some other way?

 Tomi


commit e2de5e5578fbaa9b4b75074796da0608fc93e6ae
Author: Mans Rullgard <mans@mansr.com>
Date:   Tue Jul 22 01:58:18 2008 +0100

    ARM: OMAP: add clk_get_parent() for OMAP2/3
    
    Signed-off-by: Mans Rullgard <mans@mansr.com>

:100644 100644 577be44... 28aec36... M  arch/arm/mach-omap2/clock.c
:100644 100644 49245f7... 4aa69d5... M  arch/arm/mach-omap2/clock.h
:100644 100644 54cc6e1... ed7af21... M  arch/arm/mach-omap2/clock24xx.c
:100644 100644 04dedec... 08c8c46... M  arch/arm/mach-omap2/clock34xx.c

commit 2b7b958dc79e51127d7a4ecf88ce12dbc6c31426
Author: Mans Rullgard <mans@mansr.com>
Date:   Tue Jul 22 01:31:11 2008 +0100

    ARM: OMAP: make dpll4_m4_ck programmable with clk_set_rate()
    
    Filling the set_rate and round_rate fields of dpll4_m4_ck makes
    this clock programmable through clk_set_rate().  This is needed
    to give omapfb control over the dss1_alwon_fck rate.

:100644 100644 161da12... 876eb13... M  arch/arm/mach-omap2/clock34xx.h

Re: Setting dss1_alwon_fck

[Måns Rullgård]

Tomi Valkeinen <tomi.valkeinen@nokia.com> writes:

> Hi,
>
> Mans Rullgard has the patches mentioned below in his kernel tree at
> http://git.mansr.com/?p=linux-omap;a=summary . I currently have those
> patches and use the following sequence to set the dss1_alwon_fck clock:
>
> /* get the rate of the parent of dpll4_m4_ck, which is dpll4_ck */
> prate = clk_get_rate(clk_get_parent(dispc.dpll4_m4_ck));
>
> /* calculate divisor so that wanted dss1_alwon_fck is prate / div * 2.
>  * x2 because dss1_alwon_fck comes from dpll4_m4x2_ck */
> div = ...;
>
> /* set the rate */
> clk_set_rate(dispc.dpll4_m4_ck, prate / div);
>
> Is this the correct way to set dss1_alwon_fck?

It's the only way I could find.  I'd prefer if the mucking about with
get_parent() could be avoided, but Paul (I think) told me there was no
other way, at least not then.  Maybe it has changed since.

I'd also prefer to not do those divisor calculations.  However, I
could think of no other way to get the desired result, since
clock_set_rate() isn't aware of the cascaded dividers.

> Are the patches below needed, or can dss1_alwon_fck be set some
> other way?

At the time I wrote them, they were necessary.  If later changes to
the clock subsystem have made them obsolete, all the better.  I don't
recall seeing anything like that going in, though.

> commit e2de5e5578fbaa9b4b75074796da0608fc93e6ae
> Author: Mans Rullgard <mans@mansr.com>
> Date:   Tue Jul 22 01:58:18 2008 +0100
>
>     ARM: OMAP: add clk_get_parent() for OMAP2/3
>
>     Signed-off-by: Mans Rullgard <mans@mansr.com>
>
> :100644 100644 577be44... 28aec36... M  arch/arm/mach-omap2/clock.c
> :100644 100644 49245f7... 4aa69d5... M  arch/arm/mach-omap2/clock.h
> :100644 100644 54cc6e1... ed7af21... M  arch/arm/mach-omap2/clock24xx.c
> :100644 100644 04dedec... 08c8c46... M  arch/arm/mach-omap2/clock34xx.c
>
> commit 2b7b958dc79e51127d7a4ecf88ce12dbc6c31426
> Author: Mans Rullgard <mans@mansr.com>
> Date:   Tue Jul 22 01:31:11 2008 +0100
>
>     ARM: OMAP: make dpll4_m4_ck programmable with clk_set_rate()
>
>     Filling the set_rate and round_rate fields of dpll4_m4_ck makes
>     this clock programmable through clk_set_rate().  This is needed
>     to give omapfb control over the dss1_alwon_fck rate.
>
> :100644 100644 161da12... 876eb13... M  arch/arm/mach-omap2/clock34xx.h

I'll send the patches as replies to this mail for easier reference.

-- 
Måns Rullgård
mans@mansr.com

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] OMAP: Make dpll4_m4_ck programmable with clk_set_rate()

[Mans Rullgard]

Filling the set_rate and round_rate fields of dpll4_m4_ck makes
this clock programmable through clk_set_rate().  This is needed
to give omapfb control over the dss1_alwon_fck rate.

Signed-off-by: Mans Rullgard <mans@mansr.com>
---
 arch/arm/mach-omap2/clock34xx.h |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 4adf78e..e51e182 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -875,6 +875,8 @@ static struct clk dpll4_m6_ck = {
 				PARENT_CONTROLS_CLOCK,
 	.clkdm		= { .name = "dpll4_clkdm" },
 	.recalc		= &omap2_clksel_recalc,
+	.set_rate	= &omap2_clksel_set_rate,
+	.round_rate	= &omap2_clksel_round_rate,
 };
 
 /* The PWRDN bit is apparently only available on 3430ES2 and above */
-- 
1.6.0.2

[PATCH 2/2] OMAP: Add clk_get_parent() for OMAP2/3

[Mans Rullgard]

This makes clk_get_parent() work on OMAP2/3.

Signed-off-by: Mans Rullgard <mans@mansr.com>
---
 arch/arm/mach-omap2/clock.c     |    5 +++++
 arch/arm/mach-omap2/clock.h     |    1 +
 arch/arm/mach-omap2/clock24xx.c |    1 +
 arch/arm/mach-omap2/clock34xx.c |    1 +
 4 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index c3af24e..9e502a0 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -817,6 +817,11 @@ int omap2_clk_set_parent(struct clk *clk, struct clk *new_parent)
 	return 0;
 }
 
+struct clk *omap2_clk_get_parent(struct clk *clk)
+{
+	return clk->parent;
+}
+
 /* DPLL rate rounding code */
 
 /**
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index bcb0c03..a5183d0 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -29,6 +29,7 @@ int omap2_clk_set_rate(struct clk *clk, unsigned long rate);
 int omap2_clk_set_parent(struct clk *clk, struct clk *new_parent);
 int omap2_dpll_set_rate_tolerance(struct clk *clk, unsigned int tolerance);
 long omap2_dpll_round_rate(struct clk *clk, unsigned long target_rate);
+struct clk *omap2_clk_get_parent(struct clk *clk);
 
 #ifdef CONFIG_OMAP_RESET_CLOCKS
 void omap2_clk_disable_unused(struct clk *clk);
diff --git a/arch/arm/mach-omap2/clock24xx.c b/arch/arm/mach-omap2/clock24xx.c
index a54f10f..4382e60 100644
--- a/arch/arm/mach-omap2/clock24xx.c
+++ b/arch/arm/mach-omap2/clock24xx.c
@@ -416,6 +416,7 @@ static struct clk_functions omap2_clk_functions = {
 	.clk_round_rate		= omap2_clk_round_rate,
 	.clk_set_rate		= omap2_clk_set_rate,
 	.clk_set_parent		= omap2_clk_set_parent,
+	.clk_get_parent		= omap2_clk_get_parent,
 	.clk_disable_unused	= omap2_clk_disable_unused,
 #ifdef	CONFIG_CPU_FREQ
 	.clk_init_cpufreq_table	= omap2_clk_init_cpufreq_table,
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index c89d6bc..5a6a2da 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -635,6 +635,7 @@ static struct clk_functions omap2_clk_functions = {
 	.clk_round_rate		= omap2_clk_round_rate,
 	.clk_set_rate		= omap2_clk_set_rate,
 	.clk_set_parent		= omap2_clk_set_parent,
+	.clk_get_parent		= omap2_clk_get_parent,
 	.clk_disable_unused	= omap2_clk_disable_unused,
 };
 
-- 
1.6.0.2

Re: [PATCH 1/2] OMAP: Make dpll4_m4_ck programmable with clk_set_rate()

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 429 bytes --]

On Tue, 21 Oct 2008, Mans Rullgard wrote:

> Filling the set_rate and round_rate fields of dpll4_m4_ck makes
> this clock programmable through clk_set_rate().  This is needed
> to give omapfb control over the dss1_alwon_fck rate.
> 
> Signed-off-by: Mans Rullgard <mans@mansr.com>

Acked-by: Paul Walmsley <paul@pwsan.com>

Måns, sorry this took so long, these two patches slipped through the 
cracks here.


- Paul

Re: [PATCH 2/2] OMAP: Add clk_get_parent() for OMAP2/3

[Paul Walmsley]

On Tue, 21 Oct 2008, Mans Rullgard wrote:

> This makes clk_get_parent() work on OMAP2/3.
> 
> Signed-off-by: Mans Rullgard <mans@mansr.com>

Acked-by: Paul Walmsley <paul@pwsan.com>


- Paul

Re: [PATCH 1/2] OMAP: Make dpll4_m4_ck programmable with clk_set_rate()

[Tony Lindgren]

* Paul Walmsley <paul@pwsan.com> [081205 15:52]:
> On Tue, 21 Oct 2008, Mans Rullgard wrote:
> 
> > Filling the set_rate and round_rate fields of dpll4_m4_ck makes
> > this clock programmable through clk_set_rate().  This is needed
> > to give omapfb control over the dss1_alwon_fck rate.
> > 
> > Signed-off-by: Mans Rullgard <mans@mansr.com>
> 
> Acked-by: Paul Walmsley <paul@pwsan.com>
> 
> Måns, sorry this took so long, these two patches slipped through the 
> cracks here.

Pushing both to l-o tree today. Paul, I take it you will queue these
up for mainline via your clock series?

Måns, I heard you have some display patches? How about queuing up
those on the fbdev list?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] OMAP: Make dpll4_m4_ck programmable with clk_set_rate()

[Paul Walmsley]

On Fri, 5 Dec 2008, Tony Lindgren wrote:

> Pushing both to l-o tree today. Paul, I take it you will queue these
> up for mainline via your clock series?

Yes, and that will go for any other clock patches that you push into l-o 
between now and the time that I send that series to Russell.

- Paul

Re: [PATCH 1/2] OMAP: Make dpll4_m4_ck programmable with clk_set_rate()

[Tony Lindgren]

* Paul Walmsley <paul@pwsan.com> [081205 17:04]:
> On Fri, 5 Dec 2008, Tony Lindgren wrote:
> 
> > Pushing both to l-o tree today. Paul, I take it you will queue these
> > up for mainline via your clock series?
> 
> Yes, and that will go for any other clock patches that you push into l-o 
> between now and the time that I send that series to Russell.

OK, so I'll push the clock patches from Kevin's queue posted on Monday
to l-o, and then at some point we'll switch to your clock queue for
l-o tree.

Regards,

Tony

Re: [PATCH 1/2] OMAP: Make dpll4_m4_ck programmable with clk_set_rate()

[Måns Rullgård]

Tony Lindgren <tony@atomide.com> writes:

> * Paul Walmsley <paul@pwsan.com> [081205 15:52]:
>> On Tue, 21 Oct 2008, Mans Rullgard wrote:
>> 
>> > Filling the set_rate and round_rate fields of dpll4_m4_ck makes
>> > this clock programmable through clk_set_rate().  This is needed
>> > to give omapfb control over the dss1_alwon_fck rate.
>> > 
>> > Signed-off-by: Mans Rullgard <mans@mansr.com>
>> 
>> Acked-by: Paul Walmsley <paul@pwsan.com>
>> 
>> Måns, sorry this took so long, these two patches slipped through the 
>> cracks here.
>
> Pushing both to l-o tree today. Paul, I take it you will queue these
> up for mainline via your clock series?
>
> Måns, I heard you have some display patches? How about queuing up
> those on the fbdev list?

It looks like Tomi's driver is shaping up nicely, so it's probably not
worthwhile spending any significant time on the current driver.  If
anyone is interested, everything I have is in my git tree.

-- 
Måns Rullgård
mans@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Branch for fbdriver (Re: [PATCH 1/2] OMAP: Make dpll4_m4_ck programmable with clk_set_rate())

[Tony Lindgren]

* Måns Rullgård <mans@mansr.com> [081205 17:40]:
> Tony Lindgren <tony@atomide.com> writes:
> 
> > * Paul Walmsley <paul@pwsan.com> [081205 15:52]:
> >> On Tue, 21 Oct 2008, Mans Rullgard wrote:
> >> 
> >> > Filling the set_rate and round_rate fields of dpll4_m4_ck makes
> >> > this clock programmable through clk_set_rate().  This is needed
> >> > to give omapfb control over the dss1_alwon_fck rate.
> >> > 
> >> > Signed-off-by: Mans Rullgard <mans@mansr.com>
> >> 
> >> Acked-by: Paul Walmsley <paul@pwsan.com>
> >> 
> >> Måns, sorry this took so long, these two patches slipped through the 
> >> cracks here.
> >
> > Pushing both to l-o tree today. Paul, I take it you will queue these
> > up for mainline via your clock series?
> >
> > Måns, I heard you have some display patches? How about queuing up
> > those on the fbdev list?
> 
> It looks like Tomi's driver is shaping up nicely, so it's probably not
> worthwhile spending any significant time on the current driver.  If
> anyone is interested, everything I have is in my git tree.

OK, good to know. Tomi, do you have a git branch against the
mainline kernel for your driver?

We could start mirroring it on linux-omap and then start automerging
it on daily basis to linux-omap for testing (Assuming it does not cause
problems with other stuff :)

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Branch for fbdriver (Re: [PATCH 1/2] OMAP: Make dpll4_m4_ck programmable with clk_set_rate())

[Tomi Valkeinen]

Hi,

On Fri, 2008-12-05 at 18:12 -0800, ext Tony Lindgren wrote:
> * Måns Rullgård <mans@mansr.com> [081205 17:40]:
> > Tony Lindgren <tony@atomide.com> writes:
> > 
> > > Måns, I heard you have some display patches? How about queuing up
> > > those on the fbdev list?
> > 
> > It looks like Tomi's driver is shaping up nicely, so it's probably not
> > worthwhile spending any significant time on the current driver.  If
> > anyone is interested, everything I have is in my git tree.
> 
> OK, good to know. Tomi, do you have a git branch against the
> mainline kernel for your driver?
> 
> We could start mirroring it on linux-omap and then start automerging
> it on daily basis to linux-omap for testing (Assuming it does not cause
> problems with other stuff :)

I have a git tree against current linux-omap tree at
http://www.bat.org/~tomba/git/linux-omap-dss.git

It is possible to have a branch based on Linus' tree also, but it's more
maintenance work as I need a bunch of omap patches that are not in
Linus' tree. (Actually, I have never tested DSS2 with Linus' tree, so
I'm not sure how much stuff there's missing).

I'd like to get the DSS2 working on OMAP2 also, but I'm (still) waiting
for my N810. Half a year ago the DSS2 did work on OMAP2, but I'm sure
it's since been broken, and needs some healing.

But after that I'm all for it. 

However, there is a small breakage because of the VRAM manager and
OMAP_TAG removal. That code is common for the old and new DSS. I have a
patch to fix the old DSS to use the VRAM manager, but I don't think it's
a good idea to break the old working code with new experimental code =).
So I think I'll see if I can easily separate the old and new boot time
memory allocation.

But what does it mean in practice? 

Mirroring means you (script?) will fetch a branch from my tree to dss2
branch on linux-omap tree?

What does automerging mean?

Does it mean I can still continue rebasing my tree to keep it clean?

 Tomi


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Branch for fbdriver (Re: [PATCH 1/2] OMAP: Make dpll4_m4_ck programmable with clk_set_rate())

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@nokia.com> [081208 06:55]:
> Hi,
> 
> On Fri, 2008-12-05 at 18:12 -0800, ext Tony Lindgren wrote:
> > * Måns Rullgård <mans@mansr.com> [081205 17:40]:
> > > Tony Lindgren <tony@atomide.com> writes:
> > > 
> > > > Måns, I heard you have some display patches? How about queuing up
> > > > those on the fbdev list?
> > > 
> > > It looks like Tomi's driver is shaping up nicely, so it's probably not
> > > worthwhile spending any significant time on the current driver.  If
> > > anyone is interested, everything I have is in my git tree.
> > 
> > OK, good to know. Tomi, do you have a git branch against the
> > mainline kernel for your driver?
> > 
> > We could start mirroring it on linux-omap and then start automerging
> > it on daily basis to linux-omap for testing (Assuming it does not cause
> > problems with other stuff :)
> 
> I have a git tree against current linux-omap tree at
> http://www.bat.org/~tomba/git/linux-omap-dss.git
> 
> It is possible to have a branch based on Linus' tree also, but it's more
> maintenance work as I need a bunch of omap patches that are not in
> Linus' tree. (Actually, I have never tested DSS2 with Linus' tree, so
> I'm not sure how much stuff there's missing).

Well let's see what needs to be patched outside drivers/video and get
it merged to mainline so you can maintain your patches against the
mainline tree.

If something is not in the mainline for drivers/video, we can try to
get those integrated to mainline, or add them to your queue for now.

> I'd like to get the DSS2 working on OMAP2 also, but I'm (still) waiting
> for my N810. Half a year ago the DSS2 did work on OMAP2, but I'm sure
> it's since been broken, and needs some healing.
> 
> But after that I'm all for it. 

OK

> However, there is a small breakage because of the VRAM manager and
> OMAP_TAG removal. That code is common for the old and new DSS. I have a
> patch to fix the old DSS to use the VRAM manager, but I don't think it's
> a good idea to break the old working code with new experimental code =).
> So I think I'll see if I can easily separate the old and new boot time
> memory allocation.

Well we need to get rid of the old OMAP_TAGs too.

> But what does it mean in practice? 
> 
> Mirroring means you (script?) will fetch a branch from my tree to dss2
> branch on linux-omap tree?

Yes, I'll git-fetch your branch automatically once a day.

> What does automerging mean?

I'll merge your branch into linux-omap master branch once a day
automatically.

> Does it mean I can still continue rebasing my tree to keep it clean?

Yes!

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html