On 12/18/2014 06:06 PM, Tony Lindgren wrote:
> * Ezequiel Garcia <ezequiel@xxxxxxxxxxxxxxxxxxxx> [141218 12:49]:
>> Tony, Roger:
>>
>> As far as I can see, the GPMC interface clock (GPMC_FCLK) is not
>> properly modeled in the devicetree. Instead, hwmod magic seems to be used.
>
> I guess you mean the functional clock not interface clock?
>
>> arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c:
>> struct omap_hwmod_ocp_if am33xx_l3_s__gpmc = {
>> .master = &am33xx_l3_s_hwmod,
>> .slave = &am33xx_gpmc_hwmod,
>> .clk = "l3s_gclk",
>> .addr = am33xx_gpmc_addr_space,
>> .user = OCP_USER_MPU,
>> };
>>
>> I'd like to know what would be the appropriate DT model for this clock.
>> Perhaps, as child of CORE_M4_CLK, divided by 2:
>>
>> gpmc_fclk: gpmc_fclk {
>> #clock-cells = <0>;
>> compatible = "fixed-factor-clock";
>> clocks = <&dpll_core_m4_ck>;
>> clock-mult = <1>;
>> clock-div = <2>;
>> };
>>
>> How does it look? Also, I'm wondering if this works OK when used with
>> the hwmod stuff.
>
> Hmm we do have clocks or aliases for l3s_gclk, so it's there as otherwise
> the GPMC would not work at all :) Sure with device tree only systems we
> should have the clock phandle directly available though.
>
Right.
> Note that the hwmod code takes care of runtime PM clock gating for the
> drivers.
Not entirely sure how that works, but I'll take a look.
> But the clock entry for am33xx_l3_s__gpmc should be coming
> from .dts.
Right.
> Please also check out the hwmod dts related changes Felipe
> posted last week, that might allow populating .clk from .dts already.
>
Ah, nice. I'll take a look.
Thanks Tony!
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
--
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
