From mboxrd@z Thu Jan 1 00:00:00 1970 From: Balaji T K Subject: Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts Date: Fri, 11 Oct 2013 21:13:35 +0530 Message-ID: <52581CA7.20606@ti.com> References: <20131003054104.8941.88857.stgit@localhost> <20131003054221.8941.87801.stgit@localhost> <5256AA7F.8030005@ti.com> <20131010160018.GA29913@atomide.com> <20131010162015.GC29913@atomide.com> <5257BD3E.5000707@ti.com> <20131011153654.GN29913@atomide.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20131011153654.GN29913@atomide.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Tony Lindgren Cc: "devicetree@vger.kernel.org" , Grygorii Strashko , Linus Walleij , "linux-kernel@vger.kernel.org" , Peter Ujfalusi , Haojian Zhuang , =?ISO-8859-1?Q?Beno=EEt_Co?= =?ISO-8859-1?Q?usson?= , Linux-OMAP , "linux-arm-kernel@lists.infradead.org" , Roger Quadros List-Id: devicetree@vger.kernel.org On Friday 11 October 2013 09:06 PM, Tony Lindgren wrote: >>> What the pin control driver should do is control the pins. Whether the registers >>> are spread out in the entire IO-memory does not matter. We did have one system >>> which placed the IO-muxing together with each peripheral (!) and I did >>> still want >>> that to be handled by a single pinctrl driver picking out windows to all these >>> IO-ranges. >>> >>> Things like the PRM which has (my guess) a gazillion registers related to its >>> deep-core SoC stuff should be handled by things like >>> drivers/mfd/syscon.c, which means it is dead simple for some other driver >>> using "just this one register" in that range to get a handle at it and poke it >>> using syscon_node_to_regmap() (just derference an ampersand ref) >>> syscon_regmap_lookup_by_compatible() (use a compatible string) >>> all returning a regmap * that you can use to poke these registers. >> >> The register handling is fine. But how do we deal with resource handling? >> e.g. the block that has the deep-core registers might need to be clocked or powered >> before the registers can be accessed. > > Right, that's the key issue here. The register access would have to be conditional > based on the hardware modules PM state. Otherwise we'll have hard to trace hangs > and oopses. > Hi Tony, How are the clocks/power state currently handled in case of omap4_pmx_core, omap4_pmx_wkup register access via pinctrl-single ? Thanks and Regards, Balaji T K