[lkml]   [2016]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/2 v3] Add pl031 RTC support for Hi6220
On Tue, Jul 5, 2016 at 11:55 PM, John Stultz <> wrote:
> On Tue, Jul 5, 2016 at 10:22 PM, Olof Johansson <> wrote:
>> On Wed, Jun 29, 2016 at 05:48:43PM -0700, John Stultz wrote:
>>> This patchset enables the pl031 RTC on the Hi6220 SoC.
>>> I'd like to submit it to be merged.
>>> Wei has acked the second patch (modulo a whitespace fix which
>>> I've included in this v3), so it seems like both could go
>>> through the clk tree.
>>> But Wei also seemed open to pulling in a clk tree branch
>>> as it goes through arm-soc.
>>> Michael/Stephen: If there's no other objections, could you
>>> queue the first patch and make it avilable via the branch for
>>> Wei, or just take both patches?
>> I happen to dread these kind of patchsets these days. There's added
>> dependencies across trees just because a defined name for the clock
>> number is added to a header file.
>> I much prefer to use numerical clocks for one release, and then once
>> everything is in, switch over to the defines in the DTS.
>> That way there are no dependencies, no need to setup a shared branch
>> for a simple 3-line patch, etc.
>> So, mind respinning the DTS piece?
> Huh..

Sorry if it appeared random, I've complained about it for a while to
submaintainers. :)

> But trying to boot w/ the numerical clock in the DTS, without the clk
> change results in lots of noise:
> [ 116.491458] of_clk_src_onecell_get: invalid clock index 37
> [ 116.511627] of_clk_src_onecell_get: invalid clock index 38
> Is that acceptable?

Grmbl. Is it a lot of those? That's definitely not ideal either. If
it's one or two during probe (since clk_gets should ideally fail at
probe time) then I'd be less worried.


 \ /
  Last update: 2016-07-06 09:41    [W:0.045 / U:0.976 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site