Skip to contentSkip to conversation

Setting dss1_alwon_fck

PATCH In review Tomi Valkeinen 4 participants 13 messages Oct 20, 2008 – Dec 8, 2008

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

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 <[email protected]>
Date:   Tue Jul 22 01:58:18 2008 +0100

ARM: OMAP: add clk_get_parent() for OMAP2/3

: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 <[email protected]>
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

#1 lore raw
Quoted 9 lines · 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));

Quoted 8 lines

/* 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.

Quoted 2 lines

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.

Quoted 17 lines

commit e2de5e5578fbaa9b4b75074796da0608fc93e6ae

Author: Mans Rullgard <[email protected]>
Date:   Tue Jul 22 01:58:18 2008 +0100

ARM: OMAP: add clk_get_parent() for OMAP2/3

: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 <[email protected]>
Date:   Tue Jul 22 01:31:11 2008 +0100
Quoted 7 lines

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.

Signature · 7 lines
Måns Rullgård
[email protected]

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#2 lore raw

PATCH 1/2 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.

---
 arch/arm/mach-omap2/clock34xx.h |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/clock34xx.h +2 -0
index 4adf78e..e51e182 100644
@@ -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 */
Signature · 1 line
1.6.0.2
maintainer Acked-by on v1 1/2
#3 lore raw

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

Quoted 5 lines · 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.

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

- Paul

maintainer
#4 lore raw

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

Quoted 6 lines · Paul Walmsley
Quoted 4 lines · 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.

Quoted 6 lines
Quoted 1 line

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

maintainer
#5 lore raw

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

Quoted 2 lines · Tony Lindgren

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

maintainer
#6 lore raw

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

Quoted 7 lines · Paul Walmsley
Quoted 2 lines · Tony Lindgren

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

#7 lore raw

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

In reply to Tony Lindgren
Quoted 11 lines · Tony Lindgren
Quoted 10 lines · Paul Walmsley
Quoted 5 lines · 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.

Quoted 8 lines
Quoted 2 lines

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.

Signature · 6 lines
Måns Rullgård
[email protected]
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
maintainer
#8 lore raw

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

Quoted 19 lines · Måns Rullgård
Quoted 17 lines · Tony Lindgren
Quoted 6 lines · Paul Walmsley
Quoted 4 lines · 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.

Quoted 6 lines
Quoted 1 line

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?

Quoted 6 lines
Quoted 2 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#9 lore raw

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

Hi,

Quoted 10 lines · ext Tony Lindgren
Quoted 8 lines · Måns Rullgård
Quoted 2 lines · Tony Lindgren

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.

Quoted 6 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

maintainer
#10 lore raw

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

Quoted 20 lines · Tomi Valkeinen

Hi,

Quoted 10 lines · ext Tony Lindgren
Quoted 8 lines · Måns Rullgård
Quoted 2 lines · Tony Lindgren

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.

Quoted 6 lines

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 :)

Quoted 7 lines

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.

Quoted 5 lines

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

Quoted 6 lines

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.

Quoted 4 lines

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.

Quoted 1 line

What does automerging mean?

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

Quoted 1 line

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#11 lore raw

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

In reply to Måns Rullgård

This makes clk_get_parent() work on OMAP2/3.

---
 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(-)
arch/arm/mach-omap2/clock.c +5 -0
index c3af24e..9e502a0 100644
@@ -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 */
 
 /**
arch/arm/mach-omap2/clock.h +1 -0
index bcb0c03..a5183d0 100644
@@ -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);
arch/arm/mach-omap2/clock24xx.c +1 -0
index a54f10f..4382e60 100644
@@ -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,
arch/arm/mach-omap2/clock34xx.c +1 -0
index c89d6bc..5a6a2da 100644
@@ -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,
 };
 
Signature · 1 line
1.6.0.2