mbox series

[0/4] cpufreq: mediatek: introduce mtk cpufreq

Message ID 20220307122151.11666-1-jia-wei.chang@mediatek.com
Headers show
Series cpufreq: mediatek: introduce mtk cpufreq | expand

Message

Jia-Wei Chang March 7, 2022, 12:21 p.m. UTC
CPUFREQ is DVFS driver used for power saving by scaling clock frequency
and supply voltage of CPUs. This module cooperates with CCI DEVFREQ for
certain Mediatek SoCs.

Jia-Wei Chang (4):
  dt-bindings: cpufreq: mediatek: transform cpufreq-mediatek into yaml
  dt-bindings: cpufreq: mediatek: add mt8186 cpufreq dt-bindings
  cpufreq: mediatek: clean up cpufreq driver
  cpufreq: mediatek: add platform data and clean up voltage tracking
    logic

 .../bindings/cpufreq/cpufreq-mediatek.yaml    | 172 +++++
 drivers/cpufreq/mediatek-cpufreq.c            | 717 +++++++++---------
 2 files changed, 521 insertions(+), 368 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.yaml

Comments

Viresh Kumar March 8, 2022, 4:40 a.m. UTC | #1
On 07-03-22, 20:21, Tim Chang wrote:
> cleanup of naming, print log and comments.

As told by Krzysztof, this should be broken into several patches. One
patch for each rename, if you really need to do that.

You shouldn't just change "err" to "ret". It is fine if the driver
used "err" at some places and "ret" at others, but otherwise there is
no need of that change.

This should be easier for us to review, we aren't going to dig into
every minute change here, that you don't describe in the message, and
see if something is wrong. Please make this easier for us.

This patch alone may end up in 5-10 different patches.
Krzysztof Kozlowski April 1, 2022, 4:32 p.m. UTC | #2
On 01/04/2022 15:26, Jia-Wei Chang wrote:
> On Thu, 2022-03-24 at 11:33 +0100, Krzysztof Kozlowski wrote:
>> On 24/03/2022 10:38, Jia-Wei Chang wrote:
>>>>
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-
>>>>> mediatek.yaml
>>>>> b/Documentation/devicetree/bindings/cpufreq/cpufreq-
>>>>> mediatek.yaml
>>>>> new file mode 100644
>>>>> index 000000000000..584946eb3790
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-
>>>>> mediatek.yaml
>>>>> @@ -0,0 +1,131 @@
>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>> +%YAML 1.2
>>>>> +---
>>>>> +$id: 
>>>>>
> https://urldefense.com/v3/__http://devicetree.org/schemas/cpufreq/cpufreq-mediatek.yaml*__;Iw!!CTRNKA9wMg0ARbw!xbKG4TgD0MRpMLyGJVBZEGpZFrNOclrcxOCx_APKo5Nmg8nF2x5PcBdE0unvL2NdpChkMA$
>>>>>  
>>>>> +$schema: 
>>>>>
> https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!xbKG4TgD0MRpMLyGJVBZEGpZFrNOclrcxOCx_APKo5Nmg8nF2x5PcBdE0unvL2O8T_oxCQ$
>>>>>  
>>>>> +
>>>>> +title: Mediatek CPUFREQ driver Device Tree Bindings
>>>>
>>>> Please remove "driver Device Tree Bindings" because the title
>>>> should
>>>> describe the hardware. Therefore it could be something like
>>>> "Mediatek
>>>> SoC CPU frequency and voltage scaling".
>>>
>>> Thanks for your suggestion of title.
>>> Or should I use the origin title "Binding for MediaTek's CPUFreq
>>> driver"?
>>
>> Mediatek CPUFREQ
>> or
>> Mediatek CPU frequency scaling
> 
> Ok, I will choose one of it.
> 
>>
>>>
>>>>
>>>> How is it related to cpufreq-mediatek-hw.yaml? The names/title
>>>> look
>>>> unfortunately too similar.
>>>
>>> No, mediatek-cpufreq is performing in kernel driver rather than on
>>> hardware.
>>> On the other hand, mediatek-cpufreq-hw is performing on hardware.
>>> That's why "hw" is present in its name.
>>
>> Unfortunately, I do not get it. The bindings are only about hardware,
>> so
>> how bindings could be about CPU frequency scaling not in hardware?
> 
> Sorry, let me correct my statements.
> 
> For mediatek-cpufreq here, the required hardware are clock and
> regulator which have to be under control of mediatek-cpufreq. That's
> the reason why it needs bindings.
> 
> mediatek-cpufreq scales up and down voltage and frequency via kernel
> framework of clock and regulator, however, mediatek-cpufreq-hw delegate
> the voltage and frequency control to a hardware agent instead.

OK, that makes sense, thanks for explanation.

> 
>>
>>>
>>>>
>>>> In general this does not look like proper bindings (see also
>>>> below
>>>> lack
>>>> of compatible). Bindings describe the hardware, so what is
>>>> exactly
>>>> the
>>>> hardware here?
>>>
>>> Except for SoC, there's no requirement of hardware binding for
>>> mediatek-cpufreq.
>>> mediatek-cpufreq recognizes the compatible of Mediatek SoC while
>>> probing.
>>
>> What is the hardware here? If there is no requirement for bindings
>> for
>> mediate-cpufreq, why do we have this patch here?
> 
> Sorry, that's my mistake.
> Clock and regulator are required hardware for mediatek-cpufreq.
> 
>>
>>>
>>>>
>>>>> +
>>>>> +maintainers:
>>>>> +  - Jia-Wei Chang <jia-wei.chang@mediatek.com>
>>>>> +
>>>>> +description: |
>>>>> +  CPUFREQ is used for scaling clock frequency of CPUs.
>>>>> +  The module cooperates with CCI DEVFREQ to manage frequency
>>>>> for
>>>>> some Mediatek
>>>>> +  SoCs.
>>>>> +
>>>>> +properties:
>>>>
>>>> How is this schema going to be applied? I don't see here select
>>>> neither
>>>> compatible.
>>>
>>> As mentioned above, only compatible of SoC is required for
>>> mediatek-
>>> cpufreq.
>>
>> It does not answer my questions. How the schema is going to be
>> applied?
> 
> Currently, we do use compatible of SoC to probe mediatek-cpufreq.

Probing and binding to compatible is correct, but there is no compatible
here, so the schema is a no-op. Does nothing.

> If the better way is using clock and regulator opp, do you have a
> suggestion to approach that?
> I mean I can't find a good example from other vendors trying to do that
> way. Or maybe I miss something?

One other way (proper) is to use cpufreq-dt and existing bindings. I
understand that maybe you need some specific bindings here, but I fail
to see how they would work. IOW, you don't have the compatible, no
select, so nothing can use these bindings. Also bindings do not refer to
any specific hardware, like SoC model.

It's good that you try to convert existing bindings to DT schema, but
with that they should be probably fixed/updated to match proper bindings.

Best regards,
Krzysztof