Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S947978AbcJaXZn (ORCPT ); Mon, 31 Oct 2016 19:25:43 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:49096 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S947835AbcJaXZl (ORCPT ); Mon, 31 Oct 2016 19:25:41 -0400 DMARC-Filter: OpenDMARC Filter v1.3.1 smtp.codeaurora.org B63C16232B Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=pass smtp.mailfrom=sboyd@codeaurora.org Date: Mon, 31 Oct 2016 16:25:37 -0700 From: Stephen Boyd To: Geert Uytterhoeven Cc: Michael Turquette , Arnd Bergmann , Olof Johansson , Kevin Hilman , Philipp Zabel , Magnus Damm , "devicetree@vger.kernel.org" , Linux-Renesas , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Simon Horman Subject: Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state Message-ID: <20161031232537.GT16026@codeaurora.org> References: <1477055857-17936-1-git-send-email-geert+renesas@glider.be> <20161031081923.GF18195@verge.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4153 Lines: 87 On 10/31, Geert Uytterhoeven wrote: > Hi Mike, Stephen, Arnd, Olof, Kevin, > > Is the merge strategy [see ##### below] OK for you? > Thanks a lot! > > On Mon, Oct 31, 2016 at 9:19 AM, Simon Horman wrote: > > On Wed, Oct 26, 2016 at 02:00:24PM +0200, Geert Uytterhoeven wrote: > >> On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven > >> wrote: > >> > 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(). > >> > > >> > 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). > >> > > >> > *** > >> > >> > - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge > >> > approach above? > >> > >> Is this OK for you? > > ##### > > (link to the full series at > https://groups.google.com/forum/#!topic/linux.kernel/fLSFsjOgPT8) Would the pull requests for clk also have dts changes at the base of the tree? Perhaps clk side can just ack the clk patches and then have it all routed through arm-soc? The only worry I have is if we need to make some sort of change in clk side that conflicts with these changes. I don't usually like taking dts changes through clk tree, so I'd like to avoid that if possible. Part E could happen anytime after everything else happens, so that doesn't seem like a concern. Part C could also be made to only call into the new reset drivers if the reset dts nodes are present? If that's done then we could merge clk patches anytime and remove the dead code and the node search at some later time when everything has settled? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project