[U-Boot] [U-Boot, v2, 16/18] clk: rockchip: Add rk322x gamc clock support

Dr. Philipp Tomsich philipp.tomsich at theobroma-systems.com
Mon Jan 8 15:12:30 UTC 2018


David,

As discussed last week (off-list), I implemented infrastructure-support for the
'assigned-clocks', 'assigned-clock-parents' and 'assigned-clock-rates’ properties
in the DTS … and validated on the RK3399.

For my work-in-progress tree, see the ‘assigned-clocks-wip’ branch at:
	https://github.com/ptomsich/u-boot-rockchip/tree/assigned-clocks-wip

If this is sufficient to solve our clocking-issue on GMAC let me know. I plan to
have some additional time to finish this up for submission around the end of
the week.

@Jakob: This is the change I mentioned this morning that provides infrastructure
to allow setting PLLs via the DTS.  These changes are also on our internal GIT
in the ‘assigned-clocks-wip’ branch (which I manually mirror onto GitHub, so I
can test via Travis-CI).

Comments are welcome,
Phil.

> On 4 Jan 2018, at 14:22, David.Wu <david.wu at rock-chips.com> wrote:
> 
> Hi Philipp,
> 
> Could i just make the clock-driver respond to the requested frequency? I.e. 50MHz will most likely always come from the internal sources
> so when 50Mhz for rmii gets requested you just assume that we will use the internal source. And the 125MHz, we assume that we will use the externalsource.
> 
> 在 2017/12/21 19:21, David.Wu 写道:
>> Hi Philipp,
>> 在 2017/11/26 22:50, Philipp Tomsich 写道:
>>> 
>>> On Thu, 9 Nov 2017, David Wu wrote:
>>> 
>>>> Assuming mac_clk is fed by an external clock, set clk_rmii_src
>>>> clock select control register from IO for rgmii interface.
>>>> 
>>>> Signed-off-by: David Wu <david.wu at rock-chips.com>
>>>> Acked-by: Philipp Tomsich <philipp.tomsich at theobroma-systems.com>
>>> 
>>> Reviewed-by: Philipp Tomsich <philipp.tomsich at theobroma-systems.com>
>>> 
>>> See below for requested changes.
>>> 
>>>> ---
>>>> 
>>>> Changes in v2:
>>>> - New patch
>>>> 
>>>> drivers/clk/rockchip/clk_rk322x.c | 13 +++++++++++++
>>>> 1 file changed, 13 insertions(+)
>>>> 
>>>> diff --git a/drivers/clk/rockchip/clk_rk322x.c b/drivers/clk/rockchip/clk_rk322x.c
>>>> index e87267d..5fd27cd 100644
>>>> --- a/drivers/clk/rockchip/clk_rk322x.c
>>>> +++ b/drivers/clk/rockchip/clk_rk322x.c
>>>> @@ -239,6 +239,16 @@ static ulong rockchip_mmc_get_clk(struct rk322x_cru *cru, uint clk_general_rate,
>>>>     return DIV_TO_RATE(src_rate, div) / 2;
>>>> }
>>>> 
>>>> +static int rk322x_mac_set_clk(struct rk322x_cru *cru,
>>>> +                  int periph, uint freq)
>>>> +{
>>>> +    /* Assuming mac_clk is fed by an external clock */
>>>> +    rk_clrsetreg(&cru->cru_clksel_con[5], BIT(5),
>>>> +             BIT(5));
>>> 
>>> Please use a symbolic constant for BIT(5).
>>> 
>>> If this is the input/output selection for the MAC clk and covered by 'clock_in_out = "input";' in the DTS, then the DTS should be consulted before assuming a specific setting here.
>>> 
>> Yes, I think so, but not do it now;
>> If it is "input", then actually do not need to set clk rate, as long as the direction of setting clk, clk rate rely on external clock input may originate from PHY.
>> If it is "output", then also need to set clk rate.
>> There has been the interface of setting clock rate currently, but not set the direction. Can we in the GMAC driver directly set cru registers of mac_clk direction through the dts property of "clk_in_out", otherwise need clk framework to provide a set of directional interface like setting the parent of mac_clk.
>>>> +
>>>> +    return 0;
>>>> +}
>>>> +
>>>> static ulong rockchip_mmc_set_clk(struct rk322x_cru *cru, uint clk_general_rate,
>>>>                   int periph, uint freq)
>>>> {
>>>> @@ -352,6 +362,9 @@ static ulong rk322x_clk_set_rate(struct clk *clk, ulong rate)
>>>>     case CLK_DDR:
>>>>         new_rate = rk322x_ddr_set_clk(priv->cru, rate);
>>>>         break;
>>>> +    case SCLK_MAC:
>>>> +        new_rate = rk322x_mac_set_clk(priv->cru, clk->id, rate);
>>>> +        break;
>>>>     default:
>>>>         return -ENOENT;
>>>>     }
>>>> 
>>> 
>>> 
>>> 
> 



More information about the U-Boot mailing list