From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5223EC433EF for ; Sun, 24 Apr 2022 14:40:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235675AbiDXOm6 (ORCPT ); Sun, 24 Apr 2022 10:42:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58620 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239172AbiDXOml (ORCPT ); Sun, 24 Apr 2022 10:42:41 -0400 Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4A46C38199 for ; Sun, 24 Apr 2022 07:39:40 -0700 (PDT) Received: by mail-ej1-x62b.google.com with SMTP id k23so25077470ejd.3 for ; Sun, 24 Apr 2022 07:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=sGIGnRcORiyz6ALQ2u4/pZkSv1Oidm+ZI/regT6wqA0=; b=MQS6HpnygwWQ+v5+kClKwPDQHTPm64pwU9XSQQ3KS6db3seA1YQXaxQ4o/uT2C75zo uMDjJpNo0TX0chwCXWdtiboO14vckMdPSvzWKVfUQOQk+uv40sZ3So6PIHJYHPiiBUoB R4EY2KHxl4hlJKBqCDGasw4XNF0tioJO2pM77PRwFHZRPihzDmByf9hSVgqM8YLM4WT4 XY4QkGeVblat4vTJ3voaSh/hhF7G2hVvKHwt0z8fi2ohQy6lZNo9l6NKVC0ZGn5m/ERp IWqeGh+ncW6v8sYCwAEMT/Ro4ZIMJ0QrDqfSDll5Qr9VdiegtHzFw9cqbZwjf2DMoDih rLGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=sGIGnRcORiyz6ALQ2u4/pZkSv1Oidm+ZI/regT6wqA0=; b=yoyQplkFIO5Sdiy9BGjuJQf8YRhvHhmrfQQRo2gtSdNxoay91s/u7YxZuZGgAkCO8U o4lUoJp+FHtMvywWRQswTaI5ktj4xrvjICxDYnfimJrlZQipdPtWhUodKHm8lodkLwY2 XSfp4KEz1hhl+MyMq/7rITT0TURyqcw7feSgwLV+XfytrmDqwUl4PUacaV3Su4AMci7U mjUDRKbdGR6wJ6+fjdDDzvLTruFv7t+DSe97S0NFfoON+lX1x3r0tWm2tdcTalqL8L3w BXE+tuMMvM9I/edCs6+j8pbgCoDeshiZSvDV1tBWsbbMOioFu1zD07P/bxc31vskYfWa 1IkQ== X-Gm-Message-State: AOAM533ACl5rvMHFTXTNAQyq1v+8okoxWzgHRjOt4twDXW91fkbFKO9T mUVwoLJG/lpwt//bpIA4goi3xBnp5ITBrg== X-Google-Smtp-Source: ABdhPJz72ENByBRkGeBbYwsJp+HUH6S8fiVg+HyFSfdr1+pHiyApAc3ejCoh3y/jBuCAJdnW+69Iqw== X-Received: by 2002:a17:906:974c:b0:6ef:f428:d527 with SMTP id o12-20020a170906974c00b006eff428d527mr11974862ejy.166.1650811178771; Sun, 24 Apr 2022 07:39:38 -0700 (PDT) Received: from [192.168.0.235] (xdsl-188-155-176-92.adslplus.ch. [188.155.176.92]) by smtp.gmail.com with ESMTPSA id a19-20020a50c313000000b0041fb0f2e155sm3419768edb.20.2022.04.24.07.39.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 24 Apr 2022 07:39:38 -0700 (PDT) Message-ID: Date: Sun, 24 Apr 2022 16:39:37 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH 1/2] arm64: dts: renesas: r9a07g044: Fix external clk node names Content-Language: en-US To: Biju Das , Rob Herring , Krzysztof Kozlowski Cc: Geert Uytterhoeven , Magnus Damm , "linux-renesas-soc@vger.kernel.org" , "devicetree@vger.kernel.org" , Chris Paterson , Biju Das , Prabhakar Mahadev Lad References: <20220423140658.145000-1-biju.das.jz@bp.renesas.com> <7bd2ae6d-c55f-4ab7-0c98-72da0d5d4050@linaro.org> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 24/04/2022 12:22, Biju Das wrote: > Hi Krzysztof Kozlowski, > > Thanks for the feedback. > >> Subject: Re: [PATCH 1/2] arm64: dts: renesas: r9a07g044: Fix external clk >> node names >> >> On 24/04/2022 09:50, Biju Das wrote: >>>> Subject: RE: [PATCH 1/2] arm64: dts: renesas: r9a07g044: Fix external >>>> clk node names >>>> >>>> Hi Krzysztof Kozlowski, >>>> >>>> Thanks for the feedback. >>>> >>>>> Subject: Re: [PATCH 1/2] arm64: dts: renesas: r9a07g044: Fix >>>>> external clk node names >>>>> >>>>> On 23/04/2022 16:06, Biju Das wrote: >>>>>> Fix audio clk node names with "_" -> "-" and add suffix '-clk' for >>>>>> can and extal clks. >>>>>> >>>>>> Signed-off-by: Biju Das >>>>>> --- >>>>>> arch/arm64/boot/dts/renesas/r9a07g044.dtsi | 8 ++++---- >>>>>> 1 file changed, 4 insertions(+), 4 deletions(-) >>>>>> >>>>>> diff --git a/arch/arm64/boot/dts/renesas/r9a07g044.dtsi >>>>>> b/arch/arm64/boot/dts/renesas/r9a07g044.dtsi >>>>>> index 19287cccb1f0..4f9a84d7af08 100644 >>>>>> --- a/arch/arm64/boot/dts/renesas/r9a07g044.dtsi >>>>>> +++ b/arch/arm64/boot/dts/renesas/r9a07g044.dtsi >>>>>> @@ -13,14 +13,14 @@ / { >>>>>> #address-cells = <2>; >>>>>> #size-cells = <2>; >>>>>> >>>>>> - audio_clk1: audio_clk1 { >>>>>> + audio_clk1: audio-clk1 { >>>>> >>>>> How about in such case keeping suffix "clk" everywhere and moving >>>>> the index >>>>> (1/2) to the first part? This way one day maybe schema will match >>>>> the clocks. >>>> >>>> Just a question, >>>> >>>> Your suggestion is "audio_clk1: audio-clk1" -> "audio_clk1: audio-clk" >>>> >>>> In that case, If you plan to drop the label in future, how will you >>>> differentiate between >>>> audio-clk1 and audio-clk2 with just node names? >>> >>> Or >>> >>> Do you want me to do the change like this? >>> >>> "audio_clk1: audio-clk1" -> "audio_clk_1: audio-clk-1" >>> >>> And fix the phandle reference in other dtsi files?? >> >> My suggestion was to move the [12] part into the first part, so the suffix >> "clk" stays consistent: >> audio1-clk >> audio2-clk > > From HW perspective, there are 2 audio clocks, audio clock1(multiple and sub multiple of 44.1 Khz) > and audio clk 2(Multiple and submultiple of 48Khz) connected to a single audio Codec. > > Based on the sampling rate, through clock generator driver we can switch the clock source for > audio mclock along with audio clock for SSI and we can support both these rates > > Since there is a single audio codec, I am not sure, audio1-clk and audio2-clk is a good choise. The name of the clock is not "audio clock" but "audio", because you do not call a car "Ford Mustang car", but just "Ford Mustang". Therefore "clock" is not part of the name, but just description of a type. > > What about like > > audio_clk1: audio-clk-1 ? > audio_clk2: audio-clk-2 ? > > Which is consistent with naming used for cpu and opp-tables? It's not consistent with clk naming. Nodes should have generic names, so the generic part is "clk". You add specific audio/audio-X prefix or suffix - it's fine, but not both. This is exactly the trouble when you start using specific names and Devicetree spec explicitly asks for generic names. So maybe go with the spec and call of these "clk-[0-9]" and problem is gone. Best regards, Krzysztof