Message-ID: <CAMRc=McArNo1d_zvt1_5h9EgDaTKk3DgYf+UNxcwBW9Y+M-2=w@mail.gmail.com>
Date:   Wed, 25 Apr 2018 12:26:26 +0200
From:   Bartosz Golaszewski <brgl@...ev.pl>
To:     Sekhar Nori <nsekhar@...com>
Cc:     David Lechner <david@...hnology.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        linux-clk <linux-clk@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Kevin Hilman <khilman@...nel.org>,
        Adam Ford <aford173@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 12/44] clk: davinci: Add platform information for TI
 DA850 PSC

2018-04-25 12:09 GMT+02:00 Bartosz Golaszewski <brgl@...ev.pl>:
> 2018-04-25 8:07 GMT+02:00 Sekhar Nori <nsekhar@...com>:
>> On Tuesday 24 April 2018 09:41 PM, David Lechner wrote:
>>> On 04/24/2018 03:28 AM, Sekhar Nori wrote:
>>>> On Monday 23 April 2018 08:29 PM, David Lechner wrote:
>>>>> On 04/06/2018 11:46 AM, Stephen Boyd wrote:
>>>>>> Quoting Sekhar Nori (2018-04-06 02:37:03)
>>>>>>>
>>>>>>> Can you please check that and confirm there is no issue with genpd and
>>>>>>> using CLK_OF_DECLARE() to initialize clocks?
>>>>>>>
>>>>>>> Unless you report an issue back, or Mike and Stephen have ideas about
>>>>>>> how to handle the dependency between PSC/PLL derived timer clock
>>>>>>> initialization and and timer_probe(), I think we need to move back to
>>>>>>> using CLK_OF_DECLARE().
>>>>>>
>>>>>> In such a case, please use the hybrid approach where the clks required
>>>>>> for the clockevent and/or clocksource are registered in the early
>>>>>> CLK_OF_DECLARE path but the rest of the clks get registered with a
>>>>>> proper platform device and driver. There are examples of this approach
>>>>>> on other platforms already.
>>>>>>
>>>>>
>>>>> I looked at this a bit last week, but I didn't come up with any approach
>>>>> that I was happy with. It seems like it would be nice to just register
>>>>> the absolute minimum clocks needed. On DA8XX, that would just be the
>>>>> PLL0
>>>>> AUXCLK. On most of the other SoCs, it would be the PLL AUXCLK plus one
>>>>> LPSC clock. The AUXCLKs are easy because they are just a simple gate
>>>>> from the oscillator. The LPSC clocks are a bit more tricky because they
>>>>> have a complex sequence for turning on. Furthermore, on DM646X, we need
>>>>> the whole PLL up to SYSCLK3 plus one LPSC clock, so things get a bit
>>>>> messy there.
>>>>
>>>> Things might change in the context of work being done here by Bartosz
>>>> for converting clocks to early platform devices.
>>>>
>>>> But, keeping that development aside for a moment: I think this means the
>>>> PLLs and PSCs need to be CLK_OF_DECLARE(). What we can have as platform
>>>> devices are clocks that are not in the path to get timer clock working
>>>> (like CFGCHIP clocks).
>>>
>>> CLK_OF_DECLARE() only matters on DA850. None of the other SoCs use device
>>
>> Thats true today, but lets not make the assumption that none of the
>> other DaVinci SoCs will gain DT support ever. We don't want churn in CCF
>> support once someone tries to add DT support for other platforms.
>>
>> I already have people using DM365 in mainline, for example.
>>
>>> tree. And on DA850, the timer0 clock is just the PLL0 AUXCLK, so PSCs can> still be platform devices there. And in fact, one of the PSC clocks on
>>> DA850 depends on async3, which is a CFGCHIP clock, so if we made the PSCs
>>> CLK_OF_DECLARE(), then we also have to make at least the async3 CFGCHIP
>>> clock CLK_OF_DECLARE(). But, like I said, I think that can be avoided by
>>> leaving the PSC clocks as a platform device on DA850 (and DA830).
>>
>> Okay, I did not realize that there is a dependency between CFGCHIP clk
>> and PSC too.
>>
>>> For everything else, we need the legacy board file equivalent of
>>> CLK_OF_DECLARE(), which is basically what I had here in v5 of the
>>> series.
>>
>> Yeah. I did not realize the dependency with timer when platform devices
>> were suggested. Sorry.
>>
>>>
>>> So, if we want this to keep moving before the if/when of Bartosz's
>>> early platform device stuff, I'm thinking that I will make the PLL
>>
>> After looking at feedback to Bartosz's series, and the fact that
>> previous attempts at doing the same thing were rejected, I think there
>> is benefit in keeping CCF support moving independent Bartosz's work.
>> Otherwise, we have no chance of getting anything merged for v4.18.
>>
>
> It's true, that the feedback was not very positive, but I'm still
> thinking I can come up with something that would get accepted. Last
> time someone came up with the idea, the problem it was supposed to
> solve was different (dependencies between devices) and was eventually
> fixed with introduction of probe deferral.
>
> This time around we really want these devices probed early. The main
> concern was using a device tree compatible. If I can instead just
> early probe all devices whose drivers are registered as early without
> touching the device tree (as Frank Rowand suggested) then maybe the

* It was actually Mark Rutland.

> response of the community would be better.
>
> Thanks,
> Bart
>
>> Early initialization of clocks and dependency with timer is a pretty
>> common theme across SoCs. As and when a better way to support is found,
>> I am sure DaVinci can be converted over along with rest of the devices.
>>
>>> and PSC drivers loadable with or without a platform device and let
>>> each SoC pick which one it should use.
>>
>> This sounds flexible. We have to see how the patches look. But I would
>> caution against adding a lot of dead code. If there is no way some of
>> the clocks will be useful as platform device, I see no point of
>> supporting them as such just in anticipation.
>>
>> Thanks,
>> Sekhar

Powered by blists - more mailing lists