Hi Kobayashi-san,

On Thu, Apr 16, 2015 at 7:35 PM, Keita Kobayashi
<[email protected]> wrote:
> This patch add the ARM CPUs Device Tree binding to document a new
> enable method of Renesas cpuidle.
>
> Signed-off-by: Keita Kobayashi <[email protected]>
> ---
>  Documentation/devicetree/bindings/arm/cpus.txt | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt 
> b/Documentation/devicetree/bindings/arm/cpus.txt
> index 8b9e0a9..663ee11 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -196,6 +196,7 @@ nodes to be present and contain the properties described 
> below.
>                             "qcom,gcc-msm8660"
>                             "qcom,kpss-acc-v1"
>                             "qcom,kpss-acc-v2"
> +                           "renesas,rcar-idle"
>                             "rockchip,rk3066-smp"
>
>         - cpu-release-addr

I don't mind this portion so much and I can see other vendors are
using this format. And with risk of upsetting the DT police I have to
mention my doubts about why we need this particular piece of binding.

The proposed string by this patch does not seem to describe any
hardware but it is aligned to other existing stings referring to
software such as "spin-table" and "psci". From a C code implementation
point of view we would get enough information to make a good decision
by just checking SoC compatible string. At the same time, this seems
to be the standard way of doing things and standard is good.

So if we should turn this into something that describes actual
hardware, how about pointing out the APMU hardware that is actually
managing the Core Standby mode that this CPUIdle implementation is
invoking? May I suggest using "renesas,rcar-apmu"? Or perhaps to be
safe we should do per-SoC string like in other cases like
"renesas,r8a7791-apmu"? Or is there some way we can make this work
without adding a new binding?

Thanks,

/ magnus
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to