About to tag v2.6.28-omap1 on Friday

About to tag v2.6.28-omap1 on Friday

[Tony Lindgren]

Hi all,

I'm planning to tag v2.6.28-omap1 on Friday. I'll be going through
my omap inbox and applying some obvious fixes, but if anybody has
new fixes that should go in, please post them ASAP.

Regards,

Tony

Re: About to tag v2.6.28-omap1 on Friday

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [090107 21:04]:
> Hi all,
> 
> I'm planning to tag v2.6.28-omap1 on Friday. I'll be going through
> my omap inbox and applying some obvious fixes, but if anybody has
> new fixes that should go in, please post them ASAP.

I've also pushed the recent 23 patch clock series from Paul,
and merged in Kevin's omap-pm-upstream branch. So please give
the current l-o head some testing on your favorite boards.

Looks like we now have some McBSP clock issue probably related
to the custom clock:

WARNING: at arch/arm/mach-omap2/clock.c:1092 omap2_clk_register+0x24/0x3c()     
Modules linked in:       
[<c00317f4>] (dump_stack+0x0/0x14) from [<c004c96c>]
 (warn_on_slowpath+0x4c/0x68
[<c004c920>] (warn_on_slowpath+0x0/0x68) from [<c0036450>]
 (omap2_clk_register+0
 r6:c0427bd0 r5:c0421e94 r4:c0421e30       
 [<c003642c>] (omap2_clk_register+0x0/0x3c) from [<c0039ce4>]
(clk_register+0x44/
[<c0039ca0>] (clk_register+0x0/0xc8) from [<c0011208>]
(omap2_mcbsp_init+0xc4/0x
 r7:c03bcc31 r6:00000008 r5:c0421e94 r4:c0421e30       
 [<c0011144>] (omap2_mcbsp_init+0x0/0x12c) from [<c002d2d4>]
(do_one_initcall+0x6
[<c002d270>] (do_one_initcall+0x0/0x198) from [<c0008718>]
(kernel_init+0x70/0xd
[<c00086a8>] (kernel_init+0x0/0xdc) from [<c004f324>]
(do_exit+0x0/0x6b4)       
 r5:00000000 r4:00000000 
...

Similar warnings for other McBSP clocks

...

omap-mcbsp omap-mcbsp.1: Invalid clock configuration for McBSP1.       
omap-mcbsp: probe of omap-mcbsp.1 failed with error -2       
omap-mcbsp omap-mcbsp.2: Invalid clock configuration for McBSP2.       
omap-mcbsp: probe of omap-mcbsp.2 failed with error -2       
omap-mcbsp omap-mcbsp.3: Invalid clock configuration for McBSP3.       
omap-mcbsp: probe of omap-mcbsp.3 failed with error -2       
omap-mcbsp omap-mcbsp.4: Invalid clock configuration for McBSP4.       
omap-mcbsp: probe of omap-mcbsp.4 failed with error -2       
omap-mcbsp omap-mcbsp.5: Invalid clock configuration for McBSP5.       
omap-mcbsp: probe of omap-mcbsp.5 failed with error -2         

Regards,

Tony

Re: About to tag v2.6.28-omap1 on Friday

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [090108 12:07]:
> * Tony Lindgren <tony@atomide.com> [090107 21:04]:
> > Hi all,
> > 
> > I'm planning to tag v2.6.28-omap1 on Friday. I'll be going through
> > my omap inbox and applying some obvious fixes, but if anybody has
> > new fixes that should go in, please post them ASAP.
> 
> I've also pushed the recent 23 patch clock series from Paul,
> and merged in Kevin's omap-pm-upstream branch. So please give
> the current l-o head some testing on your favorite boards.

OK, I think this is pretty much it for applying patches for now,
or at least I don't seem to have any more fixes in my omap inbox.

Let's give it few days of testing and tag v2.6.28-omap1 on Sunday
if no issues pop up.

I'm wondering if we should apply "[PATCH 3/3] usb: musb: fix null
pointer check in musb_platform_init" as otherwise the system may not
boot.. Felipe, any comments on that?

Regards,

Tony

Re: About to tag v2.6.28-omap1 on Friday

[Eero Nurkkala]

> Looks like we now have some McBSP clock issue probably related
> to the custom clock:

Could you please try:
http://marc.info/?l=linux-omap&m=122597514326263&w=2

And possibly ack the patch?

McBSP has a known spin-lock deadlock, why carry it around?

- Eero

Re: About to tag v2.6.28-omap1 on Friday

[Tony Lindgren]

* Eero Nurkkala <ext-eero.nurkkala@nokia.com> [090108 12:25]:
> > Looks like we now have some McBSP clock issue probably related
> > to the custom clock:
> 
> Could you please try:
> http://marc.info/?l=linux-omap&m=122597514326263&w=2
> 
> And possibly ack the patch?

Well this has been on hold as we don't know yet if we should
use or not use custom clocks.

Custom clocks allow combining multiple clocks into a single clock,
which makes it easy to use in the drivers. However, custom clocks
have some problems that Paul has pointed out, like not knowing
the parent.

At this point I'd say that if Paul does not like custom clocks,
we should stop using them. Up to Paul to decide me thinks unless
somebody has better ideas.

> McBSP has a known spin-lock deadlock, why carry it around?

Would be nice to get rid of the spin-lock issue.. But this patch
still does not help with the McBSP clocks failing because the
parent is not known.

Regards,

Tony

Re: About to tag v2.6.28-omap1 on Friday

[Eero Nurkkala]

>From clock34xx.h I find them having parents:
(but of course I'm possibly talking about something else
 you're meaning =)


static struct clk mcbsp2_ick = {
	.name		= "mcbsp_ick",
	.id		= 2,
	.parent		= &per_l4_ick,
	.prcm_mod	= OMAP3430_PER_MOD,
	.enable_reg	= CM_ICLKEN,
	.enable_bit	= OMAP3430_EN_MCBSP2_SHIFT,
	.idlest_bit	= OMAP3430_ST_MCBSP2_SHIFT,
	.flags		= CLOCK_IN_OMAP343X | WAIT_READY,
	.clkdm		= { .name = "per_clkdm" },
	.recalc		= &followparent_recalc,
};

static const struct clksel mcbsp_234_clksel[] = {
	{ .parent = &core_96m_fck, .rates = common_mcbsp_96m_rates },
	{ .parent = &mcbsp_clks,   .rates = common_mcbsp_mcbsp_rates },
	{ .parent = NULL }
};

static struct clk mcbsp2_src_fck = {
	.name		= "mcbsp_src_fck",
	.id		= 2,
	.prcm_mod	= CLK_REG_IN_SCM,
	.init		= &omap2_init_clksel_parent,
	.clksel_reg	= OMAP2_CONTROL_DEVCONF0,
	.clksel_mask	= OMAP2_MCBSP2_CLKS_MASK,
	.clksel		= mcbsp_234_clksel,
	.flags		= CLOCK_IN_OMAP343X,
	.clkdm		= { .name = "per_clkdm" },
	.recalc		= &omap2_clksel_recalc,
};

static struct clk mcbsp2_fck = {
	.name		= "mcbsp_fck",
	.id		= 2,
	.parent		= &mcbsp2_src_fck,
	.prcm_mod	= OMAP3430_PER_MOD,
	.enable_reg	= CM_FCLKEN,
	.enable_bit	= OMAP3430_EN_MCBSP2_SHIFT,
	.idlest_bit	= OMAP3430_ST_MCBSP2_SHIFT,
	.flags		= CLOCK_IN_OMAP343X | WAIT_READY,
	.clkdm		= { .name = "per_clkdm" },
	.recalc		= &omap2_clksel_recalc,
};

On Thu, 2009-01-08 at 13:12 +0200, ext Tony Lindgren wrote:
> * Eero Nurkkala <ext-eero.nurkkala@nokia.com> [090108 12:25]:
> > > Looks like we now have some McBSP clock issue probably related
> > > to the custom clock:
> > 
> > Could you please try:
> > http://marc.info/?l=linux-omap&m=122597514326263&w=2
> > 
> > And possibly ack the patch?
> 
> Well this has been on hold as we don't know yet if we should
> use or not use custom clocks.
> 
> Custom clocks allow combining multiple clocks into a single clock,
> which makes it easy to use in the drivers. However, custom clocks
> have some problems that Paul has pointed out, like not knowing
> the parent.
> 
> At this point I'd say that if Paul does not like custom clocks,
> we should stop using them. Up to Paul to decide me thinks unless
> somebody has better ideas.
> 
> > McBSP has a known spin-lock deadlock, why carry it around?
> 
> Would be nice to get rid of the spin-lock issue.. But this patch
> still does not help with the McBSP clocks failing because the
> parent is not known.
> 
> Regards,
> 
> Tony

Re: About to tag v2.6.28-omap1 on Friday

[Tony Lindgren]

* Eero Nurkkala <ext-eero.nurkkala@nokia.com> [090108 14:14]:
> >From clock34xx.h I find them having parents:
> (but of course I'm possibly talking about something else
>  you're meaning =)

Yeah, the problem is caused by arch/arm/mach-omap2/mcbsp.c
registering custom clocks that have no parent.

Tony

> 
> 
> static struct clk mcbsp2_ick = {
> 	.name		= "mcbsp_ick",
> 	.id		= 2,
> 	.parent		= &per_l4_ick,
> 	.prcm_mod	= OMAP3430_PER_MOD,
> 	.enable_reg	= CM_ICLKEN,
> 	.enable_bit	= OMAP3430_EN_MCBSP2_SHIFT,
> 	.idlest_bit	= OMAP3430_ST_MCBSP2_SHIFT,
> 	.flags		= CLOCK_IN_OMAP343X | WAIT_READY,
> 	.clkdm		= { .name = "per_clkdm" },
> 	.recalc		= &followparent_recalc,
> };
> 
> static const struct clksel mcbsp_234_clksel[] = {
> 	{ .parent = &core_96m_fck, .rates = common_mcbsp_96m_rates },
> 	{ .parent = &mcbsp_clks,   .rates = common_mcbsp_mcbsp_rates },
> 	{ .parent = NULL }
> };
> 
> static struct clk mcbsp2_src_fck = {
> 	.name		= "mcbsp_src_fck",
> 	.id		= 2,
> 	.prcm_mod	= CLK_REG_IN_SCM,
> 	.init		= &omap2_init_clksel_parent,
> 	.clksel_reg	= OMAP2_CONTROL_DEVCONF0,
> 	.clksel_mask	= OMAP2_MCBSP2_CLKS_MASK,
> 	.clksel		= mcbsp_234_clksel,
> 	.flags		= CLOCK_IN_OMAP343X,
> 	.clkdm		= { .name = "per_clkdm" },
> 	.recalc		= &omap2_clksel_recalc,
> };
> 
> static struct clk mcbsp2_fck = {
> 	.name		= "mcbsp_fck",
> 	.id		= 2,
> 	.parent		= &mcbsp2_src_fck,
> 	.prcm_mod	= OMAP3430_PER_MOD,
> 	.enable_reg	= CM_FCLKEN,
> 	.enable_bit	= OMAP3430_EN_MCBSP2_SHIFT,
> 	.idlest_bit	= OMAP3430_ST_MCBSP2_SHIFT,
> 	.flags		= CLOCK_IN_OMAP343X | WAIT_READY,
> 	.clkdm		= { .name = "per_clkdm" },
> 	.recalc		= &omap2_clksel_recalc,
> };
> 
> On Thu, 2009-01-08 at 13:12 +0200, ext Tony Lindgren wrote:
> > * Eero Nurkkala <ext-eero.nurkkala@nokia.com> [090108 12:25]:
> > > > Looks like we now have some McBSP clock issue probably related
> > > > to the custom clock:
> > > 
> > > Could you please try:
> > > http://marc.info/?l=linux-omap&m=122597514326263&w=2
> > > 
> > > And possibly ack the patch?
> > 
> > Well this has been on hold as we don't know yet if we should
> > use or not use custom clocks.
> > 
> > Custom clocks allow combining multiple clocks into a single clock,
> > which makes it easy to use in the drivers. However, custom clocks
> > have some problems that Paul has pointed out, like not knowing
> > the parent.
> > 
> > At this point I'd say that if Paul does not like custom clocks,
> > we should stop using them. Up to Paul to decide me thinks unless
> > somebody has better ideas.
> > 
> > > McBSP has a known spin-lock deadlock, why carry it around?
> > 
> > Would be nice to get rid of the spin-lock issue.. But this patch
> > still does not help with the McBSP clocks failing because the
> > parent is not known.
> > 
> > Regards,
> > 
> > Tony
>