I've not been following these McBSP issues, but this
comment suggests to me that the clock API is just not
being used "correctly" here:
On Tuesday 15 April 2008, Chandra shekhar wrote:
> 1>
> Clock structure can be moved to header file and create a structure.
> So that instead of calling each clock by its name,( big problem for 2430 and 34xx
> Which has 5 mcbsp instances) it can be called by Using mcbsp id.
>
> Something like this can be done...
>
> static char omap_mcbsp_ick[][12] = {"mcbsp1_ick\0",
> "mcbsp2_ick\0",.........
>
> };
>
> static char omap_mcbsp_fck[][12] = {"mcbsp1_fck\0",
> "mcbsp2_fck\0",.........
> };
>
> static struct omap_mcbsp_clocks {
> struct clk *ick;
> struct clk *fck;
> } omap_mcbsp_clk[OMAP_MAX_MCBSP_COUNT];
>
> clk_enable(omap_mcbsp_clk[id].ick);
>
> Clk_get or clk_enable/disable will be much simplified.
The "correct" way to use the clock ACPI would be like:
struct device *mcbsp = ... something ... ;
struct clk *ick, *mck;
ick = clk_get(mcbsp, "ick");
fck = clk_get(mcbsp, "fck");
That is, don't expect clients to use names like "mcbsp2_fck" and
know which McBSP they're using ... just expect them to know
they have *some* module, and that its clock has generic names
such as "ick" and "fck".
Of course, working that way may involve a bunch of other changes...
- Dave
--
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
