Message-ID: <20141104185702.GR1618@lahna.fi.intel.com>
Date:	Tue, 4 Nov 2014 20:57:02 +0200
From:	Mika Westerberg <mika.westerberg@...ux.intel.com>
To:	David Cohen <david.a.cohen@...ux.intel.com>
Cc:	Felipe Balbi <balbi@...com>,
	Linus Walleij <linus.walleij@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	stable <stable@...r.kernel.org>, mathias.nyman@...ux.intel.com
Subject: Re: [PATCH] pinctrl: baytrail: show output gpio state correctly on
 Intel Baytrail

On Tue, Nov 04, 2014 at 10:05:26AM -0800, David Cohen wrote:
> On Tue, Nov 04, 2014 at 09:59:36AM +0200, Mika Westerberg wrote:
> > On Mon, Nov 03, 2014 at 02:19:03PM -0800, David Cohen wrote:
> > > Hi Mika,
> > > 
> > > Thanks for your feedbacks :)
> > > 
> > > On Mon, Nov 03, 2014 at 08:42:47PM +0200, Mika Westerberg wrote:
> > > > On Mon, Nov 03, 2014 at 09:50:11AM -0600, Felipe Balbi wrote:
> > > > > Hi,
> > > > > 
> > > > > On Mon, Nov 03, 2014 at 05:42:07PM +0200, Mika Westerberg wrote:
> > > > > > On Mon, Nov 03, 2014 at 05:27:43PM +0200, Mika Westerberg wrote:
> > > > > > > On Mon, Nov 03, 2014 at 09:00:48AM -0600, Felipe Balbi wrote:
> > > > > > > > On Mon, Nov 03, 2014 at 11:24:02AM +0200, Mika Westerberg wrote:
> > > > > > > > > On Fri, Oct 31, 2014 at 11:45:09AM -0700, David Cohen wrote:
> > > > > > > > > > > I think adding the module exit + allowing this driver to be a module
> > > > > > > > > > > would be a good approach. Then we don't need to force generic x86 kernel
> > > > > > > > > > > binaries to always have this driver. Unless Mathias or Mika knows a
> > > > > > > > > > > constraint to force this driver to be builtin only.
> > > > > > > > > > 
> > > > > > > > > > It helps if I CC them when asking for feedback :)
> > > > > > > > > > 
> > > > > > > > > > Mathias, Mika, do you know any constraint that forces pinctrl-baytrail
> > > > > > > > > > to be bool?
> > > > > > > > > 
> > > > > > > > > The only constraint that has been keeping this driver as bool is that
> > > > > > > > > some machines like, Asus T100, uses ACPI GPIO operation regions for
> > > > > > > > > toggling GPIOs to get things like sensor hub powered on. The GPIO
> > > > > > > > > operation region code does not yet handle -EPROBE_DEFER so only way to
> > > > > > > > > ensure that the operation region is there is to have the driver compiled
> > > > > > > > > in to the kernel.
> > > > > > > > 
> > > > > > > > But that's not enough excuse to have every single x86 in the market
> > > > > > > > shipping with this driver. Think about a distro kernel, most likely this
> > > > > > > > gets enabled and it's wrong in 80% of the cases.
> > > > > > > 
> > > > > > > True, but see below.
> > > > > > > 
> > > > > > > > It would be nicer to add EPROBE_DEFER support, convert this into
> > > > > > > > tristate and have default = M if BAYTRAIL, or something.
> > > > > > > 
> > > > > > > If it were simple as that we would have done that already. Please check
> > > > > > > drivers/gpio/gpiolib-acpi.c:acpi_gpio_adr_space_handler() and tell me
> > > > > > > how we can do that.
> > > > > > 
> > > > > > Actually the above is not the problem because we already have registered
> > > > > > the GPIO chip and hence we have the GPIO available to the firmware code.
> > > > > 
> > > > > what happens before you registered the gpio chip ? It takes some time
> > > > > from head.S to gpiochip_irqchip_add(). Anywhere between that time,
> > > > > firmware could try to access gpios and the same problem would occur.
> > > > 
> > > > The operation region is not ready and the firmware does not try to use
> > > > it. However, the subsys_initcall() is there just to be sure that the
> > > > GPIO driver gets loaded before anything that is going to use GPIOs from
> > > > firmware.
> > > 
> > > That sounds hackish and dangerous. There are shared registers between
> > > different GPIOs.
> > 
> > For one it certainly is not hackish and dangerous. It is well defined
> > in the ACPI specification as interfaces between firmware and OS.
> 
> It looks we have an implicit dependency to GPIO driver in Bay Trail, and
> having this window until load the module is not acceptable to fulfill
> this implicit dependency.

It is not implicit at all.

The user of the GPIO in ACPI DSDT table says something like:

	Name (_DEP, Package () { \_SB.GPO2 })

or similar. That is *explicit* dependency. Here \_SB.GPO2 is one of the
GPIO banks.

> But IMHO all dependency to a driver should be explicitly described
> (e.g. on Kconfigs, or maybe failing probe). With current situation if we
> do not select pinctrl_baytrail, instead of affecting just the drivers
> that explicitly depend on that, it affects others which we are unable to
> easily identify.

So how do you propose we describe the dependency? It is completely in
firmware. Should we make i2c-hid.c dependent on pinctrl-baytrail.c just
because some underlying firmware method (_PSx for example) needs the
GPIO but the driver itself does not?

> Maybe I don't like or fully agreee/understand ACPI, but I'd call that
> dangerous.
>
> > 
> > > > > > The real problem is that if the ACPI GPIO operation handler is not there
> > > > > > at the time firmware decides to do something it will just skip things
> > > > > > that depend on the operation region. So if it has a GPIO that is used to
> > > > > > turn on sensor hub or touch panel or whatever, this will not be done and
> > > > > > it results that the device in question might not work properly.
> > > > > 
> > > > > that's an issue that needs solving, but forcing every x86 kernel to ship
> > > > > with this driver, is not a proper solution.
> > > > 
> > > > I would rather have the driver build in to the kernel now (and btw it
> > > > has been already in mainline quite some time so I suspect many distros
> > > > have already enabled it), than turning it module and render some devices
> > > > that have been working previously, fail suddenly.
> > > 
> > > Hm.... it sounds like we're saying: we got it working somehow and from
> > > now on we'll avoid change it to not create regression.
> > 
> > That's exactly what I'm saying :-)
> 
> In this case, I think we need to carefully document our concerns about
> the driver to help others not involved in original implementation to
> easily contribute to it.
>
> > 
> > > Correct if I'm wrong, but there's nothing really preventing this driver
> > > to be a module beside the buggy ACPI interface that allows kernel and fw
> > > to play freely (and silently) with same piece of hw.
> > 
> > Not a buggy ACPI interface. Lack of implementation from Linux side.
> > 
> > > IMHO we could allow this driver be M, but default to Y and an
> > > explanation to set to Y in case FW needs to use GPIO before module gets
> > > loaded. Since we've development board (Minnow Max), we should let kernel
> > > more free for other developers as well.
> > 
> > All I'm saying both to you guys that this is the reasoning we have the
> > driver as a bool. Which is what you asked from me in the first place.
> 
> I apology for my frustration :)
> You've been more than helpful clarifying our questions.
> 
> > 
> > Since you both insist to turn it module, please send a patch with the
> > corresponding changelog telling why you think it does not need to build
> > in and let's see if we are getting any regressions. If yes, then we just
> > revert the patch. Does that work for you?
> 
> I'm in favor of not hardcoding kernel features based on possible hidden
> things that may happen on closed source FWs.
> Having the module option does help further development of this driver
> and others that depend on it. A clear explanation on Kconfig why we
> recommend Y for production and why M is still experimental should be
> enough to guide ppl working on distributions and at same time help
> kernel developers involved with the driver.

Like I said, send a patch describing why you think it needs to be module
and make it tristate instead. If it causes problems we can revert it.
--
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/

Powered by blists - more mailing lists