lkml.org 
[lkml]   [2017]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 4/4] clk: mvebu: Expand mv98dx3236-core-clock support
Date
On 07/02/17 14:03, Stephen Boyd wrote:
> On 02/06, Chris Packham wrote:
>> On 07/02/17 12:14, Stephen Boyd wrote:
>>> On 02/03, Chris Packham wrote:
>>>> The initial implementation in commit e120c17a70e5 ("clk: mvebu: support
>>>> for 98DX3236 SoC") hardcoded a fixed value for the main PLL frequency.
>>>> Port code from the Marvell supplied Linux kernel to support different
>>>> PLL frequencies and provide clock gating support.
>>>>
>>>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>>>> ---
>>>> .../devicetree/bindings/clock/mvebu-core-clock.txt | 7 +
>>>> .../bindings/clock/mvebu-gated-clock.txt | 11 ++
>>>> arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 14 +-
>>>> drivers/clk/mvebu/Makefile | 2 +-
>>>> drivers/clk/mvebu/armada-xp.c | 13 --
>>>> drivers/clk/mvebu/mv98dx3236.c | 144 +++++++++++++++++++++
>>>
>>> This mixes dts and clk driver changes. Any chance it can be split
>>> up and just have the clk part go through clk tree? Otherwise, I
>>> can ack this if you want to take it all through arm-soc?
>>
>> I'm happy to split it if it will make life easier.
>>
>
> Well do things keep booting if the clk driver parts merge without
> the associated dts changes? It's nice to maintain backwards
> compatibility even for a short time to make the merge path
> easier.
>

Unfortunately not. I could put the clk changes first (then I'd just have
checkpatch.pl complaining about new compatible strings). But if the clk
patches don't land before the dts changes the boards won't boot. However
that affects 1 person that we know of (me).

\
 
 \ /
  Last update: 2017-02-07 02:14    [W:0.054 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site