From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752711AbdBGBNq (ORCPT ); Mon, 6 Feb 2017 20:13:46 -0500 Received: from gate2.alliedtelesis.co.nz ([202.36.163.20]:43991 "EHLO gate2.alliedtelesis.co.nz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751524AbdBGBNn (ORCPT ); Mon, 6 Feb 2017 20:13:43 -0500 From: Chris Packham To: Stephen Boyd CC: "linux-arm-kernel@lists.infradead.org" , "linux-clk@vger.kernel.org" , Michael Turquette , Rob Herring , Mark Rutland , Jason Cooper , Andrew Lunn , "Gregory Clement" , Sebastian Hesselbarth , Russell King , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 4/4] clk: mvebu: Expand mv98dx3236-core-clock support Thread-Topic: [PATCH 4/4] clk: mvebu: Expand mv98dx3236-core-clock support Thread-Index: AQHSfc9C28CILxYjnUCUVa3hUDUJ8Q== Date: Tue, 7 Feb 2017 01:13:37 +0000 Message-ID: References: <20170203034012.29399-1-chris.packham@alliedtelesis.co.nz> <20170203034012.29399-5-chris.packham@alliedtelesis.co.nz> <20170206231400.GM25384@codeaurora.org> <9974653ab84040c3b12fad075790c123@svr-chch-ex1.atlnz.lc> <20170207010308.GN25384@codeaurora.org> Accept-Language: en-NZ, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.1.10] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v171DuGJ024402 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 >>>> --- >>>> .../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). From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Packham Subject: Re: [PATCH 4/4] clk: mvebu: Expand mv98dx3236-core-clock support Date: Tue, 7 Feb 2017 01:13:37 +0000 Message-ID: References: <20170203034012.29399-1-chris.packham@alliedtelesis.co.nz> <20170203034012.29399-5-chris.packham@alliedtelesis.co.nz> <20170206231400.GM25384@codeaurora.org> <9974653ab84040c3b12fad075790c123@svr-chch-ex1.atlnz.lc> <20170207010308.GN25384@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Return-path: Content-Language: en-US Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Stephen Boyd Cc: "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Michael Turquette , Rob Herring , Mark Rutland , Jason Cooper , Andrew Lunn , Gregory Clement , Sebastian Hesselbarth , Russell King , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: devicetree@vger.kernel.org On 07/02/17 14:03, Stephen Boyd wrote:=0A= > On 02/06, Chris Packham wrote:=0A= >> On 07/02/17 12:14, Stephen Boyd wrote:=0A= >>> On 02/03, Chris Packham wrote:=0A= >>>> The initial implementation in commit e120c17a70e5 ("clk: mvebu: suppor= t=0A= >>>> for 98DX3236 SoC") hardcoded a fixed value for the main PLL frequency.= =0A= >>>> Port code from the Marvell supplied Linux kernel to support different= =0A= >>>> PLL frequencies and provide clock gating support.=0A= >>>>=0A= >>>> Signed-off-by: Chris Packham =0A= >>>> ---=0A= >>>> .../devicetree/bindings/clock/mvebu-core-clock.txt | 7 +=0A= >>>> .../bindings/clock/mvebu-gated-clock.txt | 11 ++=0A= >>>> arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 14 +-=0A= >>>> drivers/clk/mvebu/Makefile | 2 +-=0A= >>>> drivers/clk/mvebu/armada-xp.c | 13 --=0A= >>>> drivers/clk/mvebu/mv98dx3236.c | 144 ++++++++++++= +++++++++=0A= >>>=0A= >>> This mixes dts and clk driver changes. Any chance it can be split=0A= >>> up and just have the clk part go through clk tree? Otherwise, I=0A= >>> can ack this if you want to take it all through arm-soc?=0A= >>=0A= >> I'm happy to split it if it will make life easier.=0A= >>=0A= >=0A= > Well do things keep booting if the clk driver parts merge without=0A= > the associated dts changes? It's nice to maintain backwards=0A= > compatibility even for a short time to make the merge path=0A= > easier.=0A= >=0A= =0A= Unfortunately not. I could put the clk changes first (then I'd just have = =0A= checkpatch.pl complaining about new compatible strings). But if the clk =0A= patches don't land before the dts changes the boards won't boot. However = =0A= that affects 1 person that we know of (me).=0A= -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Chris Packham To: Stephen Boyd CC: "linux-arm-kernel@lists.infradead.org" , "linux-clk@vger.kernel.org" , Michael Turquette , "Rob Herring" , Mark Rutland , "Jason Cooper" , Andrew Lunn , Gregory Clement , Sebastian Hesselbarth , Russell King , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 4/4] clk: mvebu: Expand mv98dx3236-core-clock support Date: Tue, 7 Feb 2017 01:13:37 +0000 Message-ID: References: <20170203034012.29399-1-chris.packham@alliedtelesis.co.nz> <20170203034012.29399-5-chris.packham@alliedtelesis.co.nz> <20170206231400.GM25384@codeaurora.org> <9974653ab84040c3b12fad075790c123@svr-chch-ex1.atlnz.lc> <20170207010308.GN25384@codeaurora.org> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 List-ID: On 07/02/17 14:03, Stephen Boyd wrote:=0A= > On 02/06, Chris Packham wrote:=0A= >> On 07/02/17 12:14, Stephen Boyd wrote:=0A= >>> On 02/03, Chris Packham wrote:=0A= >>>> The initial implementation in commit e120c17a70e5 ("clk: mvebu: suppor= t=0A= >>>> for 98DX3236 SoC") hardcoded a fixed value for the main PLL frequency.= =0A= >>>> Port code from the Marvell supplied Linux kernel to support different= =0A= >>>> PLL frequencies and provide clock gating support.=0A= >>>>=0A= >>>> Signed-off-by: Chris Packham =0A= >>>> ---=0A= >>>> .../devicetree/bindings/clock/mvebu-core-clock.txt | 7 +=0A= >>>> .../bindings/clock/mvebu-gated-clock.txt | 11 ++=0A= >>>> arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 14 +-=0A= >>>> drivers/clk/mvebu/Makefile | 2 +-=0A= >>>> drivers/clk/mvebu/armada-xp.c | 13 --=0A= >>>> drivers/clk/mvebu/mv98dx3236.c | 144 ++++++++++++= +++++++++=0A= >>>=0A= >>> This mixes dts and clk driver changes. Any chance it can be split=0A= >>> up and just have the clk part go through clk tree? Otherwise, I=0A= >>> can ack this if you want to take it all through arm-soc?=0A= >>=0A= >> I'm happy to split it if it will make life easier.=0A= >>=0A= >=0A= > Well do things keep booting if the clk driver parts merge without=0A= > the associated dts changes? It's nice to maintain backwards=0A= > compatibility even for a short time to make the merge path=0A= > easier.=0A= >=0A= =0A= Unfortunately not. I could put the clk changes first (then I'd just have = =0A= checkpatch.pl complaining about new compatible strings). But if the clk =0A= patches don't land before the dts changes the boards won't boot. However = =0A= that affects 1 person that we know of (me).=0A= From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris.Packham@alliedtelesis.co.nz (Chris Packham) Date: Tue, 7 Feb 2017 01:13:37 +0000 Subject: [PATCH 4/4] clk: mvebu: Expand mv98dx3236-core-clock support References: <20170203034012.29399-1-chris.packham@alliedtelesis.co.nz> <20170203034012.29399-5-chris.packham@alliedtelesis.co.nz> <20170206231400.GM25384@codeaurora.org> <9974653ab84040c3b12fad075790c123@svr-chch-ex1.atlnz.lc> <20170207010308.GN25384@codeaurora.org> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 >>>> --- >>>> .../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).