From: Linus Walleij <linus.walleij@linaro.org> To: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>, Felipe Balbi <balbi@ti.com>, Benoit Cousson <b-cousson@ti.com>, Sourav Poddar <sourav.poddar@ti.com>, tony@atomide.com, linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree-discuss@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, linux-input@vger.kernel.org, Kevin Hilman <khilman@ti.com> Subject: Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support Date: Tue, 30 Oct 2012 15:02:23 +0100 [thread overview] Message-ID: <CACRpkdapQJY0aoam741O0fb8EeM9BLk_Psq5TaPG84J7wEvCLw@mail.gmail.com> (raw) In-Reply-To: <20121030113407.GA24335@sirena.org.uk> On Tue, Oct 30, 2012 at 12:34 PM, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote: > On Sun, Oct 28, 2012 at 09:12:52PM +0100, Linus Walleij wrote: >> Moving this handling to bus code or anywhere else >> invariably implies that resource acquisition/release order >> does not matter, and my point is that it does. > > Doing this in the buses is definitely wrong, as you say it's not bus > specific. I do however think we can usefully do this stuff in a SoC > specific place like a power domain, keeping the SoC integration code > together and out of the drivers. IME the SoCs where you need to do > different things for different IPs shoudl mostly still get some reuse > out of such an approach. Talking to Kevin Hilman today he was also stressing that power domains is a good thing for handling resources, especially when replacing prior hacks in the custom clk code. However he pointed specifically to clocks and voltages, which may be true. What worries me is when knowledge of the hardware which is traditionally a concern for the device driver start to bubble up to the power domain (or better renamed resource domain if use like this, as Felipe points out). I worry that we will end up with power/resource domain code that start to look like this: suspend() switch (device.id) { case DEV_FOO: clk_disable(); pinctrl_set_state(); power_domain_off(); case DEV_BAR: pinctrl_set_state(); clk_disable(); // Always-on domain case DEV_BAZ: pinctrl_set_state(); clk_disable(); power_domain_off(); case ... Mutate the above with silicon errata, specific tweaks etc that Felipe was mentioning. What is happening is that device-specific behaviour which traditionally handled in the driver is now inside the power/resource domain. I agree that if the domain was doing the same thing for each piece of hardware, this would be the right thing to do, and I think the in-kernel examples are all "simple", e.g. arch/arm/mach-omap2/powerdomain* is all about power domains and nothing else, and the notifiers used by SHmobile is all about clock gating and nothing else. Another effect is that moving all resource handling to power domains is that if we do that for a widely shared device driver like the PL011 that mandates that power domains need to be implemented for U300, Ux500, Nomadik, SPEAr 13xx, 3xx, 6xx, Versatile, Versatile Express, Integrator (AP & CP) and BCM2835. Probably more. None of which has power domains (upstream) as of today. Some of which (U300, Ux500, Nomadik, SPEAr, Integrator, BCM2835) implement pin control. Basically power (resource) domains have the side-effect of in this light not doing one thing (power domains) but instead imposing all-or-nothing imperialistic characteristics. While avoiding a set of distributed, optional pinctrl hooks, it mandates a central piece of upfront powerdomain boilerplate to be present in each and every platform that wants to control its pins. I think the lesser of two evils is the distributed approach, and then I'm talking about pinctrl only, disregarding the fact that clocks and power domains are basically subject to the same kind of argument. I still buy into the concept of using power domains for exactly power domains only. Arguably this is an elegance opinion... I worry that the per-SoC power domain implementation which will live in arch/arm/mach-* as of today will become the new board file problem, overburdening the arch/* tree. Maybe I'm mistaken as to the size of these things, but just doing ls arch/arm/mach-omap2/powerdomain* makes me start worrying. Yours, Linus Walleij
WARNING: multiple messages have this Message-ID (diff)
From: linus.walleij@linaro.org (Linus Walleij) To: linux-arm-kernel@lists.infradead.org Subject: [PATCHv2] Input: omap4-keypad: Add pinctrl support Date: Tue, 30 Oct 2012 15:02:23 +0100 [thread overview] Message-ID: <CACRpkdapQJY0aoam741O0fb8EeM9BLk_Psq5TaPG84J7wEvCLw@mail.gmail.com> (raw) In-Reply-To: <20121030113407.GA24335@sirena.org.uk> On Tue, Oct 30, 2012 at 12:34 PM, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote: > On Sun, Oct 28, 2012 at 09:12:52PM +0100, Linus Walleij wrote: >> Moving this handling to bus code or anywhere else >> invariably implies that resource acquisition/release order >> does not matter, and my point is that it does. > > Doing this in the buses is definitely wrong, as you say it's not bus > specific. I do however think we can usefully do this stuff in a SoC > specific place like a power domain, keeping the SoC integration code > together and out of the drivers. IME the SoCs where you need to do > different things for different IPs shoudl mostly still get some reuse > out of such an approach. Talking to Kevin Hilman today he was also stressing that power domains is a good thing for handling resources, especially when replacing prior hacks in the custom clk code. However he pointed specifically to clocks and voltages, which may be true. What worries me is when knowledge of the hardware which is traditionally a concern for the device driver start to bubble up to the power domain (or better renamed resource domain if use like this, as Felipe points out). I worry that we will end up with power/resource domain code that start to look like this: suspend() switch (device.id) { case DEV_FOO: clk_disable(); pinctrl_set_state(); power_domain_off(); case DEV_BAR: pinctrl_set_state(); clk_disable(); // Always-on domain case DEV_BAZ: pinctrl_set_state(); clk_disable(); power_domain_off(); case ... Mutate the above with silicon errata, specific tweaks etc that Felipe was mentioning. What is happening is that device-specific behaviour which traditionally handled in the driver is now inside the power/resource domain. I agree that if the domain was doing the same thing for each piece of hardware, this would be the right thing to do, and I think the in-kernel examples are all "simple", e.g. arch/arm/mach-omap2/powerdomain* is all about power domains and nothing else, and the notifiers used by SHmobile is all about clock gating and nothing else. Another effect is that moving all resource handling to power domains is that if we do that for a widely shared device driver like the PL011 that mandates that power domains need to be implemented for U300, Ux500, Nomadik, SPEAr 13xx, 3xx, 6xx, Versatile, Versatile Express, Integrator (AP & CP) and BCM2835. Probably more. None of which has power domains (upstream) as of today. Some of which (U300, Ux500, Nomadik, SPEAr, Integrator, BCM2835) implement pin control. Basically power (resource) domains have the side-effect of in this light not doing one thing (power domains) but instead imposing all-or-nothing imperialistic characteristics. While avoiding a set of distributed, optional pinctrl hooks, it mandates a central piece of upfront powerdomain boilerplate to be present in each and every platform that wants to control its pins. I think the lesser of two evils is the distributed approach, and then I'm talking about pinctrl only, disregarding the fact that clocks and power domains are basically subject to the same kind of argument. I still buy into the concept of using power domains for exactly power domains only. Arguably this is an elegance opinion... I worry that the per-SoC power domain implementation which will live in arch/arm/mach-* as of today will become the new board file problem, overburdening the arch/* tree. Maybe I'm mistaken as to the size of these things, but just doing ls arch/arm/mach-omap2/powerdomain* makes me start worrying. Yours, Linus Walleij
next prev parent reply other threads:[~2012-10-30 14:02 UTC|newest] Thread overview: 162+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-10-22 13:13 [PATCHv2] Input: omap4-keypad: Add pinctrl support Sourav Poddar 2012-10-22 13:13 ` Sourav Poddar 2012-10-22 13:13 ` Sourav Poddar 2012-10-22 15:50 ` Dmitry Torokhov 2012-10-22 15:50 ` Dmitry Torokhov 2012-10-23 9:13 ` Linus Walleij 2012-10-23 9:13 ` Linus Walleij 2012-10-23 9:35 ` Benoit Cousson 2012-10-23 9:35 ` Benoit Cousson 2012-10-23 9:35 ` Benoit Cousson 2012-10-23 10:04 ` Linus Walleij 2012-10-23 10:04 ` Linus Walleij 2012-10-23 10:03 ` Felipe Balbi 2012-10-23 10:03 ` Felipe Balbi 2012-10-23 10:03 ` Felipe Balbi 2012-10-23 10:23 ` Thomas Petazzoni 2012-10-23 10:23 ` Thomas Petazzoni 2012-10-23 10:29 ` Linus Walleij 2012-10-23 10:29 ` Linus Walleij 2012-10-23 10:29 ` Felipe Balbi 2012-10-23 10:29 ` Felipe Balbi 2012-10-23 10:29 ` Felipe Balbi 2012-10-23 10:45 ` Linus Walleij 2012-10-23 10:45 ` Linus Walleij 2012-10-23 10:42 ` Felipe Balbi 2012-10-23 10:42 ` Felipe Balbi 2012-10-23 10:42 ` Felipe Balbi 2012-10-23 11:11 ` Thomas Petazzoni 2012-10-23 11:11 ` Thomas Petazzoni 2012-10-23 17:02 ` Mitch Bradley 2012-10-23 17:02 ` Mitch Bradley 2012-10-23 17:20 ` Felipe Balbi 2012-10-23 17:20 ` Felipe Balbi 2012-10-23 17:20 ` Felipe Balbi 2012-10-23 17:51 ` Mitch Bradley 2012-10-23 17:51 ` Mitch Bradley 2012-10-23 17:51 ` Felipe Balbi 2012-10-23 17:51 ` Felipe Balbi 2012-10-23 17:51 ` Felipe Balbi 2012-10-23 9:18 ` Benoit Cousson 2012-10-23 9:18 ` Benoit Cousson 2012-10-23 9:18 ` Benoit Cousson 2012-10-23 20:02 ` Dmitry Torokhov 2012-10-23 20:02 ` Dmitry Torokhov 2012-10-24 8:37 ` Felipe Balbi 2012-10-24 8:37 ` Felipe Balbi 2012-10-24 8:37 ` Felipe Balbi 2012-10-24 16:14 ` Dmitry Torokhov 2012-10-24 16:14 ` Dmitry Torokhov 2012-10-24 16:51 ` Linus Walleij 2012-10-24 16:51 ` Linus Walleij 2012-10-24 17:28 ` Dmitry Torokhov 2012-10-24 17:28 ` Dmitry Torokhov 2012-10-24 18:58 ` Felipe Balbi 2012-10-24 18:58 ` Felipe Balbi 2012-10-24 18:58 ` Felipe Balbi 2012-10-25 20:59 ` Mark Brown 2012-10-25 20:59 ` Mark Brown 2012-10-25 20:59 ` Mark Brown 2012-10-26 6:20 ` Felipe Balbi 2012-10-26 6:20 ` Felipe Balbi 2012-10-26 6:20 ` Felipe Balbi 2012-10-26 16:03 ` Mark Brown 2012-10-26 16:03 ` Mark Brown 2012-10-29 19:49 ` Felipe Balbi 2012-10-29 19:49 ` Felipe Balbi 2012-10-29 19:49 ` Felipe Balbi 2012-10-30 11:24 ` Mark Brown 2012-10-30 11:24 ` Mark Brown 2012-10-30 11:49 ` Felipe Balbi 2012-10-30 11:49 ` Felipe Balbi 2012-10-30 11:49 ` Felipe Balbi 2012-10-30 14:07 ` Mark Brown 2012-10-30 14:07 ` Mark Brown 2012-10-30 14:16 ` Linus Walleij 2012-10-30 14:16 ` Linus Walleij 2012-10-30 14:54 ` Mark Brown 2012-10-30 14:54 ` Mark Brown 2012-10-30 15:16 ` Felipe Balbi 2012-10-30 15:16 ` Felipe Balbi 2012-10-30 15:16 ` Felipe Balbi 2012-10-30 15:58 ` Mark Brown 2012-10-30 15:58 ` Mark Brown 2012-10-30 17:25 ` Felipe Balbi 2012-10-30 17:25 ` Felipe Balbi 2012-10-30 17:25 ` Felipe Balbi 2012-10-30 18:20 ` Dmitry Torokhov 2012-10-30 18:20 ` Dmitry Torokhov 2012-10-30 18:48 ` Felipe Balbi 2012-10-30 18:48 ` Felipe Balbi 2012-10-30 18:48 ` Felipe Balbi 2012-10-30 18:37 ` Mark Brown 2012-10-30 18:37 ` Mark Brown 2012-10-30 21:51 ` Linus Walleij 2012-10-30 21:51 ` Linus Walleij 2012-10-30 22:57 ` Rafael J. Wysocki 2012-10-30 22:57 ` Rafael J. Wysocki 2012-11-02 18:26 ` Mark Brown 2012-11-02 18:26 ` Mark Brown 2012-10-30 14:11 ` Linus Walleij 2012-10-30 14:11 ` Linus Walleij 2012-10-28 20:12 ` Linus Walleij 2012-10-28 20:12 ` Linus Walleij 2012-10-30 11:34 ` Mark Brown 2012-10-30 11:34 ` Mark Brown 2012-10-30 11:34 ` Mark Brown 2012-10-30 14:02 ` Linus Walleij [this message] 2012-10-30 14:02 ` Linus Walleij 2012-10-30 14:37 ` Mark Brown 2012-10-30 14:37 ` Mark Brown 2012-10-31 20:10 ` Kevin Hilman 2012-10-31 20:10 ` Kevin Hilman [not found] ` <87obji8kta.fsf-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org> 2012-11-01 8:54 ` Linus Walleij 2012-11-01 8:54 ` Linus Walleij 2012-11-01 8:56 ` Fwd: " Linus Walleij 2012-11-01 8:56 ` Linus Walleij 2012-11-01 11:42 ` Kevin Hilman 2012-11-01 11:42 ` Kevin Hilman 2012-11-01 13:22 ` Linus Walleij 2012-11-01 13:22 ` Linus Walleij 2012-11-01 12:07 ` Mark Brown 2012-11-01 12:07 ` Mark Brown 2012-11-01 14:01 ` Linus Walleij 2012-11-01 14:01 ` Linus Walleij 2012-11-01 14:19 ` Mark Brown 2012-11-01 14:19 ` Mark Brown 2012-11-11 12:32 ` Linus Walleij 2012-11-11 12:32 ` Linus Walleij 2012-10-31 13:19 ` Jean-Christophe PLAGNIOL-VILLARD 2012-10-31 13:19 ` Jean-Christophe PLAGNIOL-VILLARD 2012-10-24 16:52 ` Felipe Balbi 2012-10-24 16:52 ` Felipe Balbi 2012-10-24 16:52 ` Felipe Balbi 2012-10-24 17:13 ` Linus Walleij 2012-10-24 17:13 ` Linus Walleij 2012-10-24 17:34 ` Dmitry Torokhov 2012-10-24 17:34 ` Dmitry Torokhov 2012-10-24 17:46 ` Benoit Cousson 2012-10-24 17:46 ` Benoit Cousson 2012-10-24 17:46 ` Benoit Cousson 2012-10-24 12:54 ` Linus Walleij 2012-10-24 12:54 ` Linus Walleij 2012-10-24 16:18 ` Dmitry Torokhov 2012-10-24 16:18 ` Dmitry Torokhov 2012-10-24 16:57 ` Felipe Balbi 2012-10-24 16:57 ` Felipe Balbi 2012-10-24 16:57 ` Felipe Balbi 2012-10-24 17:18 ` Linus Walleij 2012-10-24 17:18 ` Linus Walleij 2012-10-24 17:58 ` Dmitry Torokhov 2012-10-24 17:58 ` Dmitry Torokhov 2012-10-24 19:10 ` Felipe Balbi 2012-10-24 19:10 ` Felipe Balbi 2012-10-24 19:10 ` Felipe Balbi 2012-10-24 19:38 ` Dmitry Torokhov 2012-10-24 19:38 ` Dmitry Torokhov 2012-10-24 19:38 ` Dmitry Torokhov 2012-10-24 19:51 ` Felipe Balbi 2012-10-24 19:51 ` Felipe Balbi 2012-10-24 19:51 ` Felipe Balbi 2012-10-24 17:01 ` Linus Walleij 2012-10-24 17:01 ` Linus Walleij
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CACRpkdapQJY0aoam741O0fb8EeM9BLk_Psq5TaPG84J7wEvCLw@mail.gmail.com \ --to=linus.walleij@linaro.org \ --cc=b-cousson@ti.com \ --cc=balbi@ti.com \ --cc=broonie@opensource.wolfsonmicro.com \ --cc=devicetree-discuss@lists.ozlabs.org \ --cc=dmitry.torokhov@gmail.com \ --cc=khilman@ti.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-input@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=sourav.poddar@ti.com \ --cc=tony@atomide.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.