On 01/02/18 10:15, Peter De Schrijver wrote:
> On Thu, Feb 01, 2018 at 09:53:43AM +0000, Jon Hunter wrote:
>>
>> On 01/02/18 09:25, Peter De Schrijver wrote:
>>> On Wed, Jan 31, 2018 at 11:06:36AM +0000, Jon Hunter wrote:
>>>>
>>>> On 24/01/18 12:45, Peter De Schrijver wrote:
>>>>> Tegra210 has a very similar CPU clocking scheme than Tegra124. So add
>>>>> support in this driver. Also allow for the case where the CPU voltage is
>>>>> controlled directly by the DFLL rather than by a separate regulator object.
>>>>>
>>>>> Signed-off-by: Peter De Schrijver <pdeschrijver@xxxxxxxxxx>
>>>>> ---
>>>>> drivers/cpufreq/tegra124-cpufreq.c | 13 ++++++-------
>>>>> 1 file changed, 6 insertions(+), 7 deletions(-)
>>>>>
>>>>> diff --git a/drivers/cpufreq/tegra124-cpufreq.c b/drivers/cpufreq/tegra124-cpufreq.c
>>>>> index 4353025..d631dc4 100644
>>>>> --- a/drivers/cpufreq/tegra124-cpufreq.c
>>>>> +++ b/drivers/cpufreq/tegra124-cpufreq.c
>>>>> @@ -64,7 +64,8 @@ static void tegra124_cpu_switch_to_pllx(struct tegra124_cpufreq_priv *priv)
>>>>> {
>>>>> clk_set_parent(priv->cpu_clk, priv->pllp_clk);
>>>>> clk_disable_unprepare(priv->dfll_clk);
>>>>> - regulator_sync_voltage(priv->vdd_cpu_reg);
>>>>> + if (priv->vdd_cpu_reg)
>>>>> + regulator_sync_voltage(priv->vdd_cpu_reg);
>>>>> clk_set_parent(priv->cpu_clk, priv->pllx_clk);
>>>>> }
>>>>>
>>>>> @@ -89,10 +90,8 @@ static int tegra124_cpufreq_probe(struct platform_device *pdev)
>>>>> return -ENODEV;
>>>>>
>>>>> priv->vdd_cpu_reg = regulator_get(cpu_dev, "vdd-cpu");
>>>>> - if (IS_ERR(priv->vdd_cpu_reg)) {
>>>>> - ret = PTR_ERR(priv->vdd_cpu_reg);
>>>>> - goto out_put_np;
>>>>> - }
>>>>> + if (IS_ERR(priv->vdd_cpu_reg))
>>>>> + priv->vdd_cpu_reg = NULL;
>>>>>
>>>>
>>>> For Tegra124, don't we still want to return an error here?
>>>
>>> Not necessarily. Also on Tegra124 the DFLL can use PWM and I think jetson TK1
>>> can be reworked to use this.
>>
>> Seems to me that we should use DT or soc-data to specify which is being
>> used and then do the appropriate thing. I don't think that we should
>> assume that because the regulator is not present we are using PWM.
>
> I think we should rather move the sync logic into the DFLL driver in some
> future series. The DFLL driver does know about PWM vs I2C regulator.
Not sure I following what you mean by 'sync logic'. Also did you mean
the DFLL driver does NOT know about PWM vs I2C? However, we still know
at probe time what is used right?
Cheers
Jon
--
nvpublic
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
