Messages in this thread | | | From | Linus Walleij <> | Date | Wed, 29 Nov 2017 13:49:01 +0100 | Subject | Re: [PATCH 0/3] pinctrl: Align Cannon Lake GPIO number space with Windows |
| |
On Mon, Nov 27, 2017 at 2:54 PM, Mika Westerberg <mika.westerberg@linux.intel.com> wrote:
> It turns out that the Cannon Lake GPIO driver in Windows uses different > GPIO numbering scheme than what Linux uses. Instead of hardware numbers it > has "banks" of 32 pins even if the hardware group actually does not have > that many pins. This is problematic for Linux because BIOS uses the same > Windows numbering scheme in ACPI GpioIo/GpioInt resources, making Linux to > pick a wrong pin. > > For example the SD card detection GPIO resource in BIOS ACPI tables looks > like: > > GpioInt (...) {231} // vSD3_CD_B > > Where the real hardware number would be 180 instead of 231. > > Unfortunately changing the BIOS and the Windows driver is not possible for > Cannon Lake anymore so we need to handle it in Linux instead. This should > be done properly in future platforms. > > The patch series updates the Intel pinctrl driver to allow passing custom > GPIO number space, taking advantage of pin ranges supported by the pinctrl > core. However, before we can add these pin ranges we need to drop the > custom Cherryview GPIO/ACPI translation first and make the driver to use > direct mapping instead (which turns out to be much simpler). > > Once that is done we update the Cannon Lake pinctrl driver to align with > the Windows GPIO driver numbering scheme. > > Mika Westerberg (3): > gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation > pinctrl: intel: Allow custom GPIO base for pad groups > pinctrl: cannonlake: Align GPIO number space with Windows
I applied these with Andy's ACKs.
I guess I vageuly understand what happened.
So the ACPI GPIO numberspace was misaligned with the actual hardware GPIO numberspace. That's unfortunate.
I hope these is nothing in here trying to align the *LINUX* global GPIO numberspace with this weirdness and that lsgpio still gives something reasonable per-gpiochip?
Yours, Linus Walleij
| |