Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932289AbbFEBpp (ORCPT ); Thu, 4 Jun 2015 21:45:45 -0400 Received: from mailgw01.mediatek.com ([210.61.82.183]:44061 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1753430AbbFEBpm (ORCPT ); Thu, 4 Jun 2015 21:45:42 -0400 X-Listener-Flag: 11101 Message-ID: <1433468737.14416.7.camel@mtksdaap41> Subject: Re: [PATCH 0/5] Add Mediatek MT8173 subsystem clocks support From: James Liao To: Stephen Boyd CC: Sascha Hauer , Mike Turquette , , , , Henry Chen , Ricky Liang , Rob Herring , , Sascha Hauer , Matthias Brugger , "Yingjoe Chen" , Eddie Huang , Date: Fri, 5 Jun 2015 09:45:37 +0800 In-Reply-To: <20150604210212.GM676@codeaurora.org> References: <1432192376-6712-1-git-send-email-jamesjj.liao@mediatek.com> <20150528132452.GI26575@pengutronix.de> <1432867649.15597.46.camel@mtksdaap41> <20150529062345.GY6325@pengutronix.de> <20150604210212.GM676@codeaurora.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2254 Lines: 47 Hi Stephen, On Thu, 2015-06-04 at 14:02 -0700, Stephen Boyd wrote: > On 05/29, Sascha Hauer wrote: > > Yes. I previously got the impression that the subsystem clocks are not > > directly associated to the larbs, but needed to be handled by the larb > > code due to some side effect. Now that I saw that the larbs are directly > > in the subsystem register space it all makes sense. > > > > Note that the way Mediatek SoCs are designed around sub modules is bit > > unusual and does not fit very well in the Linux directory structure. > > Normally SoCs have a single clocks controller which controls all clocks > > in the SoC. Then you often have a reset controller providing reset lines > > in the SoC. In this case it's clear that the clk driver goes to > > drivers/clk/, the reset controller driver to drivers/reset/. Mediatek > > SoCs instead have several blocks, each with its own clock and reset > > controller. Splitting each block up into parts in drivers/clk/ and > > drivers/reset/ leads to quite a code fragmentation. > > This is my opinion, it would be great to hear something from others. > > Matthias? I'd like to avoid running into a direction that is not > > acceptable in the end. > > We already have drivers registering clocks and resets under > drivers/clk, so it's not unheard of. An alternative solution is > to make child devices for the clock part and the reset part at > runtime in the toplevel driver for the vencsys device (don't do > any sort of DT description for this) and use regmap to mediate > the register accesses and locking. That way we can put the clk > driver in drivers/clk/, the reset driver in drivers/reset, etc. > so that logically related code is grouped. I have a question about the alternative way you mentioned. Currently clock providers and consumers describe what clocks they will provide / consume in device tree. If we don't describe vencsys clocks in device tree, how to get vencsys clocks for drivers that need to control them? Best regards, James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/