>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@xxxxxxxxx> [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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
