From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935393AbcJUPpn (ORCPT ); Fri, 21 Oct 2016 11:45:43 -0400 Received: from metis.ext.4.pengutronix.de ([92.198.50.35]:51707 "EHLO metis.ext.4.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933352AbcJUPpl (ORCPT ); Fri, 21 Oct 2016 11:45:41 -0400 Message-ID: <1477064730.2508.24.camel@pengutronix.de> Subject: Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state From: Philipp Zabel To: Geert Uytterhoeven Cc: Michael Turquette , Stephen Boyd , Simon Horman , Magnus Damm , devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Date: Fri, 21 Oct 2016 17:45:30 +0200 In-Reply-To: <1477055857-17936-1-git-send-email-geert+renesas@glider.be> References: <1477055857-17936-1-git-send-email-geert+renesas@glider.be> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2001:67c:670:100:96de:80ff:fec2:9969 X-SA-Exim-Mail-From: p.zabel@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org A. Hi Geert, Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven: > Hi Philipp, Mike, Stephen, Simon, Magnus, > (see questions *** below!) > > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the > state of the mode pins either by a call from the platform code, or > directly by using a hardcoded register access. This is a bit messy, and > creates a dependency between driver and platform code. > > This patch series converts the various Renesas R-Car clock drivers > and support code from reading the mode pin states using a hardcoded > register access to using a new minimalistic R-Car RST driver. > > All R-Car clock drivers will rely on the presence in DT of a device node > for the RST module. Backwards compatibility with old DTBs is retained > only for R-Car Gen2, which has fallback code using its own private copy > of rcar_gen2_read_mode_pins(). I think you should add a binding doc even though the DT bindings are still trivial. > After this, there is still one remaining user of > rcar_gen2_read_mode_pins() left in platform code. A patch series to > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM: > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode"). > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3 > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT"). > > This series consists of 5 parts: > A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST > driver, > B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS > files, > C. Patches 12-17 convert the clock drivers to call into the new R-Car > RST driver, > D. Patches 18-20 remove passing mode pin state to the clock drivers > from the platform code, > E. Patches 21-23 remove dead code from the clock drivers. > > As is usually the case with moving functionality from platform code to > DT, there are lots of hard dependencies: > - The DT updates in Part B can be merged as soon as the DT bindings in > Part A have been approved, > - The clock driver updates in Part C depend functionally on the driver > code in Part A, and on the DT updates in Part B, > - The board code cleanups in Part D depend on the clock driver updates > in Part C, > - The block driver cleanups in part E depend on the board code > cleanups in part D. > > Hence to maintain the required lockstep between SoC driver, clock > drivers, shmobile platform code, and shmobile DT, I propose to queue up > all patches in a single branch against v4.9-rc1, and send pull requests > to both Mike/Stephen (clock) and Simon (rest). > > *** > > - Philip: While this is a driver for a reset-controller, currently it > doesn't provide any reset-controller functionality. Hence I added it > to drivers/soc/renesas/. Is that OK for you? Absolutely, as long as the driver isn't even a reset controller provider, this is the right place. regards Philipp From mboxrd@z Thu Jan 1 00:00:00 1970 From: Philipp Zabel Subject: Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state Date: Fri, 21 Oct 2016 17:45:30 +0200 Message-ID: <1477064730.2508.24.camel@pengutronix.de> References: <1477055857-17936-1-git-send-email-geert+renesas@glider.be> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1477055857-17936-1-git-send-email-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Geert Uytterhoeven Cc: Michael Turquette , Stephen Boyd , Simon Horman , Magnus Damm , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: devicetree@vger.kernel.org A. Hi Geert, Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven: > Hi Philipp, Mike, Stephen, Simon, Magnus, > (see questions *** below!) > > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the > state of the mode pins either by a call from the platform code, or > directly by using a hardcoded register access. This is a bit messy, and > creates a dependency between driver and platform code. > > This patch series converts the various Renesas R-Car clock drivers > and support code from reading the mode pin states using a hardcoded > register access to using a new minimalistic R-Car RST driver. > > All R-Car clock drivers will rely on the presence in DT of a device node > for the RST module. Backwards compatibility with old DTBs is retained > only for R-Car Gen2, which has fallback code using its own private copy > of rcar_gen2_read_mode_pins(). I think you should add a binding doc even though the DT bindings are still trivial. > After this, there is still one remaining user of > rcar_gen2_read_mode_pins() left in platform code. A patch series to > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM: > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode"). > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3 > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT"). > > This series consists of 5 parts: > A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST > driver, > B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS > files, > C. Patches 12-17 convert the clock drivers to call into the new R-Car > RST driver, > D. Patches 18-20 remove passing mode pin state to the clock drivers > from the platform code, > E. Patches 21-23 remove dead code from the clock drivers. > > As is usually the case with moving functionality from platform code to > DT, there are lots of hard dependencies: > - The DT updates in Part B can be merged as soon as the DT bindings in > Part A have been approved, > - The clock driver updates in Part C depend functionally on the driver > code in Part A, and on the DT updates in Part B, > - The board code cleanups in Part D depend on the clock driver updates > in Part C, > - The block driver cleanups in part E depend on the board code > cleanups in part D. > > Hence to maintain the required lockstep between SoC driver, clock > drivers, shmobile platform code, and shmobile DT, I propose to queue up > all patches in a single branch against v4.9-rc1, and send pull requests > to both Mike/Stephen (clock) and Simon (rest). > > *** > > - Philip: While this is a driver for a reset-controller, currently it > doesn't provide any reset-controller functionality. Hence I added it > to drivers/soc/renesas/. Is that OK for you? Absolutely, as long as the driver isn't even a reset controller provider, this is the right place. regards Philipp -- 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 From: p.zabel@pengutronix.de (Philipp Zabel) Date: Fri, 21 Oct 2016 17:45:30 +0200 Subject: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state In-Reply-To: <1477055857-17936-1-git-send-email-geert+renesas@glider.be> References: <1477055857-17936-1-git-send-email-geert+renesas@glider.be> Message-ID: <1477064730.2508.24.camel@pengutronix.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org A. Hi Geert, Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven: > Hi Philipp, Mike, Stephen, Simon, Magnus, > (see questions *** below!) > > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the > state of the mode pins either by a call from the platform code, or > directly by using a hardcoded register access. This is a bit messy, and > creates a dependency between driver and platform code. > > This patch series converts the various Renesas R-Car clock drivers > and support code from reading the mode pin states using a hardcoded > register access to using a new minimalistic R-Car RST driver. > > All R-Car clock drivers will rely on the presence in DT of a device node > for the RST module. Backwards compatibility with old DTBs is retained > only for R-Car Gen2, which has fallback code using its own private copy > of rcar_gen2_read_mode_pins(). I think you should add a binding doc even though the DT bindings are still trivial. > After this, there is still one remaining user of > rcar_gen2_read_mode_pins() left in platform code. A patch series to > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM: > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode"). > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3 > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT"). > > This series consists of 5 parts: > A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST > driver, > B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS > files, > C. Patches 12-17 convert the clock drivers to call into the new R-Car > RST driver, > D. Patches 18-20 remove passing mode pin state to the clock drivers > from the platform code, > E. Patches 21-23 remove dead code from the clock drivers. > > As is usually the case with moving functionality from platform code to > DT, there are lots of hard dependencies: > - The DT updates in Part B can be merged as soon as the DT bindings in > Part A have been approved, > - The clock driver updates in Part C depend functionally on the driver > code in Part A, and on the DT updates in Part B, > - The board code cleanups in Part D depend on the clock driver updates > in Part C, > - The block driver cleanups in part E depend on the board code > cleanups in part D. > > Hence to maintain the required lockstep between SoC driver, clock > drivers, shmobile platform code, and shmobile DT, I propose to queue up > all patches in a single branch against v4.9-rc1, and send pull requests > to both Mike/Stephen (clock) and Simon (rest). > > *** > > - Philip: While this is a driver for a reset-controller, currently it > doesn't provide any reset-controller functionality. Hence I added it > to drivers/soc/renesas/. Is that OK for you? Absolutely, as long as the driver isn't even a reset controller provider, this is the right place. regards Philipp