Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH v1 1/3] clk: tegra: Convert CCLKG mux to mux + clock
 divider on Tegra30
To:     Jon Hunter <jonathanh@nvidia.com>,
        Thierry Reding <thierry.reding@gmail.com>,
        Peter De Schrijver <pdeschrijver@nvidia.com>,
        Prashant Gaikwad <pgaikwad@nvidia.com>,
        Michael Turquette <mturquette@baylibre.com>,
        Stephen Boyd <sboyd@kernel.org>
Cc:     linux-clk@vger.kernel.org, linux-tegra@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <20180830192045.11017-1-digetx@gmail.com>
 <20180830192045.11017-2-digetx@gmail.com>
 <19523f37-eb78-067c-cc62-b6ceaad985a9@nvidia.com>
From:   Dmitry Osipenko <digetx@gmail.com>
Message-ID: <b1265595-f01d-5ab2-aaf9-6c4d674f9f3a@gmail.com>
Date:   Wed, 17 Oct 2018 15:27:24 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <19523f37-eb78-067c-cc62-b6ceaad985a9@nvidia.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 10/17/18 11:53 AM, Jon Hunter wrote:
> 
> On 30/08/2018 20:20, Dmitry Osipenko wrote:
>> Some of the CCLKG parents aren't accessible via device tree because they
>> are created as non-DT clocks. Apparently there is no reason to define
>> these clocks in that manner, hence convert CCLKG mux to mux + clock
>> divider to remove the non-DT parent clocks. Now it is possible to request
>> all of CCLKG parents from device tree, which is necessary for the CPUFreq
>> driver.
> 
> Is it likely that all of these clock parents will be used by the CPUFreq
> driver for these devices? If the clocks you currently need are available
> then my preference would be to stick with what we have for now.

You could use them all if you want, that's what HW allow. The current clock description doesn't fully describe the HW, though it should be enough at least for the CPUFreq driver if we are going to use clk_get_sys() and stick to the "default" parent. Peter?