Hi,
On 02-02-17 14:12, Mika Westerberg wrote:
On Thu, Feb 02, 2017 at 01:50:58PM +0100, Hans de Goede wrote:
Hi,
On 02-02-17 13:32, Mika Westerberg wrote:
On Thu, Feb 02, 2017 at 02:10:18PM +0200, Mika Westerberg wrote:
I do not have a copy of the patch in this thread but sounds like
something that might work.
Actually, I seem have a copy of that patch.
So you are saying that the device has a power GPIO in ACPI _CRS but it
should not be used for some reason?
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Setti
{
Name (WBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x0040, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C6",
0x00, ResourceConsumer, , Exclusive,
)
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestri
"\\_SB.GPO1", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0019
}
GpioInt (Edge, ActiveHigh, Shared,// PullDefault, 0x0000,
"\\_SB.GPO1", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0013
}
})
Return (WBUF) /* \_SB_.PCI0.I2C6.TCS4._CRS.WBUF */
}
The setting of the special bit in the gpio control register leads to
drivers/pinctrl/intel/pinctrl-cherryview.c chv_gpio_request_enable()
returning -EBUSY, which in return makes gpiod_get_optional
return -EBUSY for this pin, rather then NULL (as we would like).
Actually what is wrong here is that your gpiod_get(dev, "power") falls
back to use plain indexes and returns the first GPIO even though it
should not as the driver specifically requests GPIO with name "power"
and there is no _DSD.
There is no clear "binding" for this device in ACPI, so the fallback
is actually used as a feature by the Silead driver (more or less),
the use of "power" as name here is for the ARM + devicetree usage
of the driver really, so IOW the series:
Andy (Cc'd) has a patch that tries to make the fallback mechanism more
stricter which should in theory fix the problem as well. The patch
series is here:
https://bitbucket.org/andy-shev/linux/commits/338c0226b631b8b497d143070a301d8b8883c349?at=master
You are referring to might fix this, but then we may need to add an
attempt to get the gpio by index for some boards which do not control
it themselves from _PS#.
I can give the linked series a try, but I would still like a fallback
plan if we indeed encounter boards where we need to fallback to
getting the gpio by index. Once we do that we're back to having the
same problem as then we would do the same fallback on boards where
the pin is reserved for _PS# usage, and end up with an -EBUSY error
again. I guess we could ignore -EBUSY in the fallback path, or only
do the fallback if acpi_bus_power_manageable() returns false.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
