On 4/25/20 3:54 AM, Pragnesh Patel wrote:
> Hi Sean,
> 
>> -----Original Message-----
>> From: U-Boot <u-boot-boun...@lists.denx.de> On Behalf Of Sean Anderson
>> Sent: 23 April 2020 08:03
>> To: u-boot@lists.denx.de
>> Cc: Rick Chen <rickche...@gmail.com>; Bin Meng <bmeng...@gmail.com>;
>> Sean Anderson <sean...@gmail.com>
>> Subject: [PATCH v9 18/21] riscv: Enable cpu clock if it is present
>>
>> [External Email] Do not click links or attachments unless you recognize the
>> sender and know the content is safe
>>
>> The cpu clock is probably already enabled if we are executing code (though we
>> could be executing from a different core). This patch prevents the cpu clock 
>> or
>> its parents from being disabled.
>>
>> Signed-off-by: Sean Anderson <sean...@gmail.com>
>> Reviewed-by: Bin Meng <bmeng...@gmail.com>
>> ---
>> This patch was previously submitted on its own as
>> https://patchwork.ozlabs.org/patch/1232420/
>>
>> Changes in v4:
>> - New
>>
>> drivers/cpu/riscv_cpu.c | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/drivers/cpu/riscv_cpu.c b/drivers/cpu/riscv_cpu.c index
>> c6ed060abc..9ce58695aa 100644
>> --- a/drivers/cpu/riscv_cpu.c
>> +++ b/drivers/cpu/riscv_cpu.c
>> @@ -1,6 +1,7 @@
>> // SPDX-License-Identifier: GPL-2.0+
>> /*
>>  * Copyright (C) 2018, Bin Meng <bmeng...@gmail.com>
>> + * Copyright (C) 2020, Sean Anderson <sean...@gmail.com>
>>  */
>>
>> #include <clk.h>
>> @@ -117,6 +118,24 @@ static int riscv_cpu_bind(struct udevice *dev)
>>        return 0;
>> }
>>
>> +static int riscv_cpu_probe(struct udevice *dev) {
>> +       int ret = 0;
>> +       struct clk clk;
>> +
>> +       /* Get a clock if it exists */
>> +       ret = clk_get_by_index(dev, 0, &clk);
>> +       if (ret)
>> +               return 0;
>> +
>> +       ret = clk_enable(&clk);
>> +       clk_free(&clk);
>> +       if (ret == -ENOSYS || ret == -ENOTSUPP)
>> +               return 0;
>> +       else
>> +               return ret;
>> +}
> 
> can we add clk_set_rate() if clock-frequency is present in cpus node of dts ?

I already commented on this in your patch series, but I want to have a
record of it here as well.

I think this is better done with assigned-clock-frequency. If just the
clock-frequency property is present (but not the clocks property), we
can't set the frequency, so we need to assume the CPU is already running
at that frequency. If we use the clock-frequency property to denote the
desired frequency when there is a clocks property present, that changes
the semantics when the clocks property is not present. If the clocks
property is present, we should use the existing apis to configure the
clock.

--Sean

Reply via email to