linux-kernel - Fwd: [PATCHv2] Input: omap4-keypad: Add pinctrl support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRpkdaBmg7wtX0WsaxMw=n1sKDN5YphK=y8tzAx_CF=JnUqvw@mail.gmail.com>
Date:	Thu, 1 Nov 2012 09:56:48 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Kevin Hilman <khilman@...prootsystems.com>,
	Arnd Bergmann <arnd@...db.de>, Olof Johansson <olof@...om.net>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Felipe Balbi <balbi@...com>, Benoit Cousson <b-cousson@...com>,
	Sourav Poddar <sourav.poddar@...com>, tony@...mide.com,
	linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org,
	devicetree-discuss@...ts.ozlabs.org,
	linux-arm-kernel@...ts.infradead.org, linux-input@...r.kernel.org
Subject: Fwd: [PATCHv2] Input: omap4-keypad: Add pinctrl support

On Wed, Oct 31, 2012 at 9:10 PM, Kevin Hilman
<khilman@...prootsystems.com> wrote:

> Linus Walleij <linus.walleij@...aro.org> writes:

>
> > 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,
>
> FYI... that code isn't the same as PM domain.

This sort of points to a core problem here. Our terminologies are
ambiguous that we cannot understand each others code. As long
as <linux/pm_domain.h> begins:

/*
 * pm_domain.h - Definitions and headers related to device power domains.
 *

But arguably that should just be patched (I think there are a few
remnants in the code still implying that these things are only about
power).

>
>  That code is for the
> *hardware* powerdomains, not the software concept of "PM domain."  In
> OMAP, PM domain is implmented at the omap_device level.  And omap_device
> is the abstraction of an IP block that knows about all the PM related
> register settings, clocks, HW powerdomain, voltage domain, PM related
> pin-muxing etc. etc.    All of these things are abstracted in an
> omap_device, so that the PM domain implementation for OMAP looks rather
> simple (c.f. omap_device_pm_domain in arch/arm/plat-omap/omap_device.c.)

OK following now...

>
> > I think the lesser of two evils is the distributed approach,
>
> The pinctrl examples I've seen mentioned so far are all PM related
>
> (sleep, idle, wakeup, etc.) so to me I think they still belong in
> PM domains (and that's how we handle the PM related pins in OMAP.)

Well, the pinctrl grabbers in these drivers are using these states also
for platforms that do not even select CONFIG_PM.  For example
mach-nomadik is quite happy that the PL011 driver is thusly
muxing in its pins. And would require refactoring to use PM
domains.

So basically this requirement comes down to:

- When dealing with a SoC IP block driver

- That need to multiplex pins

- Then your SoC must select CONFIG_PM and
  CONFIG_PM_RUNTIME and
  CONFIG_PM_GENERIC_DOMAINS and implement
  proper domain handling hooks.

Is this correct? And for Mark, Dmitry, does this correspond to
your view?

It's actually something that needs to be acknowledged by the
ARM SoC maintainers, because they will be the ones telling
all subarch maintainers to go implement full PM handling
with these three frameworks whenever an SoC driver want
to handle pins.

Bascially all subsystem maintainers dealing with embedded
SoCs need to be aligned on this as well...

And IIUC not only pins but also silicon block clocks?

I can surely fix these for "my" systems, but it really needs
to be enforced widely or it will be a mess.

>
> > 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.
>
> Yes, I agree that this means more code/data in arch/arm/mach-*, but
> IMO, that's really where it belongs.  It really is SoC integration
> details, and driver should really not know about it.

OK we need feedback from ARM SoC on this.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/