| Message ID | 20180329143725.84781-1-mika.westerberg@linux.intel.com |
|---|---|
| State | New |
| Headers | show |
| Series | pinctrl: sunrisepoint: Align GPIO number space with Windows | expand |
Hi, On 29-03-18 16:37, Mika Westerberg wrote: > It turns out that the Windows GPIO driver for Sunrisepoint PCH-H uses > similar bank structure than it does for Cannon Lake with the exception > that here the bank size is always 24 pins. Starting from pad group E the > BIOS/Windows GPIO numbering does not match the hardware anymore but > instead there are gaps to make each pad group ("bank") consume exactly > 24 pins. Because of this Linux does not use correct pins for > GpioIo/GpioIo resources exposed by the BIOS. > > This patch aligns the GPIO number space with BIOS/Windows to make sure > the same numbering scheme is used in Linux as well following what we did > already for Intel Cannon Lake. > > Link: https://bugzilla.redhat.com/show_bug.cgi?id=1543769 > Reported-by: Vivien FRASCA <vivien.frasca@gmail.com> > Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Thank you. > --- > This should go to stable as well with following tags > > Fixes: 551fa5801ef1 ("pinctrl: intel: sunrisepoint: Add Intel Sunrisepoint-H support") > Cc: stable@vger.kernel.org > > but there is dependency to following commits as well: > > 03c4749dd6c7 ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation") > a60eac3239f0 ("pinctrl: intel: Allow custom GPIO base for pad groups") > > I'm not sure whether they can be considered as stable material, though. Given that: https://github.com/torvalds/linux/commit/f5a26acf0162477af6ee4c11b4fb9cffe5d3e257.patch Which is in 4.15.4 and later is causing a black screen on some model laptops because the wrong GPIO number is causing the backlight-enable pin to get configured wrongly, I don't think we have much choice here, unless you want to revert that commit from stable, we are going to need this patch as well as its 2 dependencies to fix the regression in the 4.15.x series. Regards, Hans > > drivers/pinctrl/intel/pinctrl-sunrisepoint.c | 45 ++++++++++++++++++++++++++-- > 1 file changed, 42 insertions(+), 3 deletions(-) > > diff --git a/drivers/pinctrl/intel/pinctrl-sunrisepoint.c b/drivers/pinctrl/intel/pinctrl-sunrisepoint.c > index 8870a4100164..fee3435a6f15 100644 > --- a/drivers/pinctrl/intel/pinctrl-sunrisepoint.c > +++ b/drivers/pinctrl/intel/pinctrl-sunrisepoint.c > @@ -36,6 +36,27 @@ > .npins = ((e) - (s) + 1), \ > } > > +#define SPTH_GPP(r, s, e, g) \ > + { \ > + .reg_num = (r), \ > + .base = (s), \ > + .size = ((e) - (s) + 1), \ > + .gpio_base = (g), \ > + } > + > +#define SPTH_COMMUNITY(b, s, e, g) \ > + { \ > + .barno = (b), \ > + .padown_offset = SPT_PAD_OWN, \ > + .padcfglock_offset = SPT_PADCFGLOCK, \ > + .hostown_offset = SPT_HOSTSW_OWN, \ > + .ie_offset = SPT_GPI_IE, \ > + .pin_base = (s), \ > + .npins = ((e) - (s) + 1), \ > + .gpps = (g), \ > + .ngpps = ARRAY_SIZE(g), \ > + } > + > /* Sunrisepoint-LP */ > static const struct pinctrl_pin_desc sptlp_pins[] = { > /* GPP_A */ > @@ -531,10 +552,28 @@ static const struct intel_function spth_functions[] = { > FUNCTION("i2c2", spth_i2c2_groups), > }; > > +static const struct intel_padgroup spth_community0_gpps[] = { > + SPTH_GPP(0, 0, 23, 0), /* GPP_A */ > + SPTH_GPP(1, 24, 47, 24), /* GPP_B */ > +}; > + > +static const struct intel_padgroup spth_community1_gpps[] = { > + SPTH_GPP(0, 48, 71, 48), /* GPP_C */ > + SPTH_GPP(1, 72, 95, 72), /* GPP_D */ > + SPTH_GPP(2, 96, 108, 96), /* GPP_E */ > + SPTH_GPP(3, 109, 132, 120), /* GPP_F */ > + SPTH_GPP(4, 133, 156, 144), /* GPP_G */ > + SPTH_GPP(5, 157, 180, 168), /* GPP_H */ > +}; > + > +static const struct intel_padgroup spth_community3_gpps[] = { > + SPTH_GPP(0, 181, 191, 192), /* GPP_I */ > +}; > + > static const struct intel_community spth_communities[] = { > - SPT_COMMUNITY(0, 0, 47), > - SPT_COMMUNITY(1, 48, 180), > - SPT_COMMUNITY(2, 181, 191), > + SPTH_COMMUNITY(0, 0, 47, spth_community0_gpps), > + SPTH_COMMUNITY(1, 48, 180, spth_community1_gpps), > + SPTH_COMMUNITY(2, 181, 191, spth_community3_gpps), > }; > > static const struct intel_pinctrl_soc_data spth_soc_data = { > -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2018-03-29 at 17:37 +0300, Mika Westerberg wrote: > It turns out that the Windows GPIO driver for Sunrisepoint PCH-H uses > similar bank structure than it does for Cannon Lake with the exception > that here the bank size is always 24 pins. Starting from pad group E > the > BIOS/Windows GPIO numbering does not match the hardware anymore but > instead there are gaps to make each pad group ("bank") consume exactly > 24 pins. Because of this Linux does not use correct pins for > GpioIo/GpioIo resources exposed by the BIOS. > > This patch aligns the GPIO number space with BIOS/Windows to make sure > the same numbering scheme is used in Linux as well following what we > did > already for Intel Cannon Lake. > > Link: https://bugzilla.redhat.com/show_bug.cgi?id=1543769 > Reported-by: Vivien FRASCA <vivien.frasca@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Given what Hans said I agree we need this to go stable (I'm not fan of reverting that will break other chips). > Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> > --- > This should go to stable as well with following tags > > Fixes: 551fa5801ef1 ("pinctrl: intel: sunrisepoint: Add Intel > Sunrisepoint-H support") > Cc: stable@vger.kernel.org > > but there is dependency to following commits as well: > > 03c4749dd6c7 ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO > translation") > a60eac3239f0 ("pinctrl: intel: Allow custom GPIO base for pad > groups") > > I'm not sure whether they can be considered as stable material, > though. > > drivers/pinctrl/intel/pinctrl-sunrisepoint.c | 45 > ++++++++++++++++++++++++++-- > 1 file changed, 42 insertions(+), 3 deletions(-) > > diff --git a/drivers/pinctrl/intel/pinctrl-sunrisepoint.c > b/drivers/pinctrl/intel/pinctrl-sunrisepoint.c > index 8870a4100164..fee3435a6f15 100644 > --- a/drivers/pinctrl/intel/pinctrl-sunrisepoint.c > +++ b/drivers/pinctrl/intel/pinctrl-sunrisepoint.c > @@ -36,6 +36,27 @@ > .npins = ((e) - (s) + 1), \ > } > > +#define SPTH_GPP(r, s, e, g) \ > + { \ > + .reg_num = (r), \ > + .base = (s), \ > + .size = ((e) - (s) + 1), \ > + .gpio_base = (g), \ > + } > + > +#define SPTH_COMMUNITY(b, s, e, g) \ > + { \ > + .barno = (b), \ > + .padown_offset = SPT_PAD_OWN, \ > + .padcfglock_offset = SPT_PADCFGLOCK, \ > + .hostown_offset = SPT_HOSTSW_OWN, \ > + .ie_offset = SPT_GPI_IE, \ > + .pin_base = (s), \ > + .npins = ((e) - (s) + 1), \ > + .gpps = (g), \ > + .ngpps = ARRAY_SIZE(g), \ > + } > + > /* Sunrisepoint-LP */ > static const struct pinctrl_pin_desc sptlp_pins[] = { > /* GPP_A */ > @@ -531,10 +552,28 @@ static const struct intel_function > spth_functions[] = { > FUNCTION("i2c2", spth_i2c2_groups), > }; > > +static const struct intel_padgroup spth_community0_gpps[] = { > + SPTH_GPP(0, 0, 23, 0), /* GPP_A */ > + SPTH_GPP(1, 24, 47, 24), /* GPP_B */ > +}; > + > +static const struct intel_padgroup spth_community1_gpps[] = { > + SPTH_GPP(0, 48, 71, 48), /* GPP_C */ > + SPTH_GPP(1, 72, 95, 72), /* GPP_D */ > + SPTH_GPP(2, 96, 108, 96), /* GPP_E */ > + SPTH_GPP(3, 109, 132, 120), /* GPP_F */ > + SPTH_GPP(4, 133, 156, 144), /* GPP_G */ > + SPTH_GPP(5, 157, 180, 168), /* GPP_H */ > +}; > + > +static const struct intel_padgroup spth_community3_gpps[] = { > + SPTH_GPP(0, 181, 191, 192), /* GPP_I */ > +}; > + > static const struct intel_community spth_communities[] = { > - SPT_COMMUNITY(0, 0, 47), > - SPT_COMMUNITY(1, 48, 180), > - SPT_COMMUNITY(2, 181, 191), > + SPTH_COMMUNITY(0, 0, 47, spth_community0_gpps), > + SPTH_COMMUNITY(1, 48, 180, spth_community1_gpps), > + SPTH_COMMUNITY(2, 181, 191, spth_community3_gpps), > }; > > static const struct intel_pinctrl_soc_data spth_soc_data = {
On Thu, Mar 29, 2018 at 04:45:47PM +0200, Hans de Goede wrote: > > This should go to stable as well with following tags > > > > Fixes: 551fa5801ef1 ("pinctrl: intel: sunrisepoint: Add Intel Sunrisepoint-H support") > > Cc: stable@vger.kernel.org > > > > but there is dependency to following commits as well: > > > > 03c4749dd6c7 ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation") > > a60eac3239f0 ("pinctrl: intel: Allow custom GPIO base for pad groups") > > > > I'm not sure whether they can be considered as stable material, though. > > Given that: > > https://github.com/torvalds/linux/commit/f5a26acf0162477af6ee4c11b4fb9cffe5d3e257.patch > > Which is in 4.15.4 and later is causing a black screen on some model > laptops because the wrong GPIO number is causing the backlight-enable > pin to get configured wrongly, I don't think we have much choice here, > unless you want to revert that commit from stable, we are going to > need this patch as well as its 2 dependencies to fix the regression > in the 4.15.x series. Yes, I agree. Let's try to get this to stable with the dependencies. That should result a working touchpad and prevent the backlight issue as well. I guess stable tags would then look like following, if I read Documentation/process/stable-kernel-rules.rst correctly: Cc: stable@vger.kernel.org # 03c4749dd6c7 ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation") Cc: stable@vger.kernel.org # a60eac3239f0 ("pinctrl: intel: Allow custom GPIO base for pad groups") Cc: stable@vger.kernel.org # v4.15 Linus, do you want me to resend the patch with these tags or are you going to do that yourself? Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Apr 03, 2018 at 02:11:12PM +0300, Mika Westerberg wrote: > On Thu, Mar 29, 2018 at 04:45:47PM +0200, Hans de Goede wrote: > > > This should go to stable as well with following tags > > > > > > Fixes: 551fa5801ef1 ("pinctrl: intel: sunrisepoint: Add Intel Sunrisepoint-H support") > > > Cc: stable@vger.kernel.org > > > > > > but there is dependency to following commits as well: > > > > > > 03c4749dd6c7 ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation") > > > a60eac3239f0 ("pinctrl: intel: Allow custom GPIO base for pad groups") > > > > > > I'm not sure whether they can be considered as stable material, though. > > > > Given that: > > > > https://github.com/torvalds/linux/commit/f5a26acf0162477af6ee4c11b4fb9cffe5d3e257.patch > > > > Which is in 4.15.4 and later is causing a black screen on some model > > laptops because the wrong GPIO number is causing the backlight-enable > > pin to get configured wrongly, I don't think we have much choice here, > > unless you want to revert that commit from stable, we are going to > > need this patch as well as its 2 dependencies to fix the regression > > in the 4.15.x series. > > Yes, I agree. Let's try to get this to stable with the dependencies. > That should result a working touchpad and prevent the backlight issue as > well. > > I guess stable tags would then look like following, if I read > Documentation/process/stable-kernel-rules.rst correctly: > > Cc: stable@vger.kernel.org # 03c4749dd6c7 ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation") > Cc: stable@vger.kernel.org # a60eac3239f0 ("pinctrl: intel: Allow custom GPIO base for pad groups") > Cc: stable@vger.kernel.org # v4.15 > > Linus, do you want me to resend the patch with these tags or are you > going to do that yourself? Actually, it turns out that 03c4749dd6c7 ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation") needs another fix because otherwise certain Chromebook keyboards stop working (again). See: https://bugzilla.kernel.org/show_bug.cgi?id=199463 So I'm thinking it may be better not to include these in stable and revert https://github.com/torvalds/linux/commit/f5a26acf0162477af6ee4c11b4fb9cffe5d3e257.patch from stable trees. -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On 25-04-18 11:48, Mika Westerberg wrote: > On Tue, Apr 03, 2018 at 02:11:12PM +0300, Mika Westerberg wrote: >> On Thu, Mar 29, 2018 at 04:45:47PM +0200, Hans de Goede wrote: >>>> This should go to stable as well with following tags >>>> >>>> Fixes: 551fa5801ef1 ("pinctrl: intel: sunrisepoint: Add Intel Sunrisepoint-H support") >>>> Cc: stable@vger.kernel.org >>>> >>>> but there is dependency to following commits as well: >>>> >>>> 03c4749dd6c7 ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation") >>>> a60eac3239f0 ("pinctrl: intel: Allow custom GPIO base for pad groups") >>>> >>>> I'm not sure whether they can be considered as stable material, though. >>> >>> Given that: >>> >>> https://github.com/torvalds/linux/commit/f5a26acf0162477af6ee4c11b4fb9cffe5d3e257.patch >>> >>> Which is in 4.15.4 and later is causing a black screen on some model >>> laptops because the wrong GPIO number is causing the backlight-enable >>> pin to get configured wrongly, I don't think we have much choice here, >>> unless you want to revert that commit from stable, we are going to >>> need this patch as well as its 2 dependencies to fix the regression >>> in the 4.15.x series. >> >> Yes, I agree. Let's try to get this to stable with the dependencies. >> That should result a working touchpad and prevent the backlight issue as >> well. >> >> I guess stable tags would then look like following, if I read >> Documentation/process/stable-kernel-rules.rst correctly: >> >> Cc: stable@vger.kernel.org # 03c4749dd6c7 ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation") >> Cc: stable@vger.kernel.org # a60eac3239f0 ("pinctrl: intel: Allow custom GPIO base for pad groups") >> Cc: stable@vger.kernel.org # v4.15 >> >> Linus, do you want me to resend the patch with these tags or are you >> going to do that yourself? > > Actually, it turns out that 03c4749dd6c7 ("gpio / ACPI: Drop unnecessary > ACPI GPIO to Linux GPIO translation") needs another fix because > otherwise certain Chromebook keyboards stop working (again). See: > > https://bugzilla.kernel.org/show_bug.cgi?id=199463 > > So I'm thinking it may be better not to include these in stable and > revert > > https://github.com/torvalds/linux/commit/f5a26acf0162477af6ee4c11b4fb9cffe5d3e257.patch > > from stable trees. FWIW, that is fine with me. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Apr 25, 2018 at 01:15:31PM +0200, Hans de Goede wrote: > > Actually, it turns out that 03c4749dd6c7 ("gpio / ACPI: Drop unnecessary > > ACPI GPIO to Linux GPIO translation") needs another fix because > > otherwise certain Chromebook keyboards stop working (again). See: > > > > https://bugzilla.kernel.org/show_bug.cgi?id=199463 > > > > So I'm thinking it may be better not to include these in stable and > > revert > > > > https://github.com/torvalds/linux/commit/f5a26acf0162477af6ee4c11b4fb9cffe5d3e257.patch > > > from stable trees. > > FWIW, that is fine with me. OK, that patch has now been reverted from stable trees. Linus W, if you don't have any objections could you take this patch to your tree? -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 29, 2018 at 4:37 PM, Mika Westerberg <mika.westerberg@linux.intel.com> wrote: > It turns out that the Windows GPIO driver for Sunrisepoint PCH-H uses > similar bank structure than it does for Cannon Lake with the exception > that here the bank size is always 24 pins. Starting from pad group E the > BIOS/Windows GPIO numbering does not match the hardware anymore but > instead there are gaps to make each pad group ("bank") consume exactly > 24 pins. Because of this Linux does not use correct pins for > GpioIo/GpioIo resources exposed by the BIOS. > > This patch aligns the GPIO number space with BIOS/Windows to make sure > the same numbering scheme is used in Linux as well following what we did > already for Intel Cannon Lake. > > Link: https://bugzilla.redhat.com/show_bug.cgi?id=1543769 > Reported-by: Vivien FRASCA <vivien.frasca@gmail.com> > Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Patch applied to my "devel" branch for now. I figured out it should not go into stable. But should it rather go to fixes for v4.17-rc:s? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Apr 30, 2018 at 02:51:34PM +0200, Linus Walleij wrote: > On Thu, Mar 29, 2018 at 4:37 PM, Mika Westerberg > <mika.westerberg@linux.intel.com> wrote: > > > It turns out that the Windows GPIO driver for Sunrisepoint PCH-H uses > > similar bank structure than it does for Cannon Lake with the exception > > that here the bank size is always 24 pins. Starting from pad group E the > > BIOS/Windows GPIO numbering does not match the hardware anymore but > > instead there are gaps to make each pad group ("bank") consume exactly > > 24 pins. Because of this Linux does not use correct pins for > > GpioIo/GpioIo resources exposed by the BIOS. > > > > This patch aligns the GPIO number space with BIOS/Windows to make sure > > the same numbering scheme is used in Linux as well following what we did > > already for Intel Cannon Lake. > > > > Link: https://bugzilla.redhat.com/show_bug.cgi?id=1543769 > > Reported-by: Vivien FRASCA <vivien.frasca@gmail.com> > > Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> > > Patch applied to my "devel" branch for now. > > I figured out it should not go into stable. Right, it depends on so many other commits which not all can be considerd stable material. > But should it rather go to fixes for v4.17-rc:s? I would prefer v4.17-rcX if possible. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On 30-04-18 15:30, Mika Westerberg wrote: > On Mon, Apr 30, 2018 at 02:51:34PM +0200, Linus Walleij wrote: >> On Thu, Mar 29, 2018 at 4:37 PM, Mika Westerberg >> <mika.westerberg@linux.intel.com> wrote: >> >>> It turns out that the Windows GPIO driver for Sunrisepoint PCH-H uses >>> similar bank structure than it does for Cannon Lake with the exception >>> that here the bank size is always 24 pins. Starting from pad group E the >>> BIOS/Windows GPIO numbering does not match the hardware anymore but >>> instead there are gaps to make each pad group ("bank") consume exactly >>> 24 pins. Because of this Linux does not use correct pins for >>> GpioIo/GpioIo resources exposed by the BIOS. >>> >>> This patch aligns the GPIO number space with BIOS/Windows to make sure >>> the same numbering scheme is used in Linux as well following what we did >>> already for Intel Cannon Lake. >>> >>> Link: https://bugzilla.redhat.com/show_bug.cgi?id=1543769 >>> Reported-by: Vivien FRASCA <vivien.frasca@gmail.com> >>> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> >> >> Patch applied to my "devel" branch for now. >> >> I figured out it should not go into stable. > > Right, it depends on so many other commits which not all can be > considerd stable material. > >> But should it rather go to fixes for v4.17-rc:s? > > I would prefer v4.17-rcX if possible. Yes this fixes the touchpad not working on various Asus models, so v4.17-rcX would definitely be good. Thanks & Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Apr 30, 2018 at 3:30 PM, Mika Westerberg <mika.westerberg@linux.intel.com> wrote: > On Mon, Apr 30, 2018 at 02:51:34PM +0200, Linus Walleij wrote: >> Patch applied to my "devel" branch for now. >> >> I figured out it should not go into stable. > > Right, it depends on so many other commits which not all can be > considerd stable material. > >> But should it rather go to fixes for v4.17-rc:s? > > I would prefer v4.17-rcX if possible. OK I've moved it to fixes for v4.17. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/pinctrl/intel/pinctrl-sunrisepoint.c b/drivers/pinctrl/intel/pinctrl-sunrisepoint.c index 8870a4100164..fee3435a6f15 100644 --- a/drivers/pinctrl/intel/pinctrl-sunrisepoint.c +++ b/drivers/pinctrl/intel/pinctrl-sunrisepoint.c @@ -36,6 +36,27 @@ .npins = ((e) - (s) + 1), \ } +#define SPTH_GPP(r, s, e, g) \ + { \ + .reg_num = (r), \ + .base = (s), \ + .size = ((e) - (s) + 1), \ + .gpio_base = (g), \ + } + +#define SPTH_COMMUNITY(b, s, e, g) \ + { \ + .barno = (b), \ + .padown_offset = SPT_PAD_OWN, \ + .padcfglock_offset = SPT_PADCFGLOCK, \ + .hostown_offset = SPT_HOSTSW_OWN, \ + .ie_offset = SPT_GPI_IE, \ + .pin_base = (s), \ + .npins = ((e) - (s) + 1), \ + .gpps = (g), \ + .ngpps = ARRAY_SIZE(g), \ + } + /* Sunrisepoint-LP */ static const struct pinctrl_pin_desc sptlp_pins[] = { /* GPP_A */ @@ -531,10 +552,28 @@ static const struct intel_function spth_functions[] = { FUNCTION("i2c2", spth_i2c2_groups), }; +static const struct intel_padgroup spth_community0_gpps[] = { + SPTH_GPP(0, 0, 23, 0), /* GPP_A */ + SPTH_GPP(1, 24, 47, 24), /* GPP_B */ +}; + +static const struct intel_padgroup spth_community1_gpps[] = { + SPTH_GPP(0, 48, 71, 48), /* GPP_C */ + SPTH_GPP(1, 72, 95, 72), /* GPP_D */ + SPTH_GPP(2, 96, 108, 96), /* GPP_E */ + SPTH_GPP(3, 109, 132, 120), /* GPP_F */ + SPTH_GPP(4, 133, 156, 144), /* GPP_G */ + SPTH_GPP(5, 157, 180, 168), /* GPP_H */ +}; + +static const struct intel_padgroup spth_community3_gpps[] = { + SPTH_GPP(0, 181, 191, 192), /* GPP_I */ +}; + static const struct intel_community spth_communities[] = { - SPT_COMMUNITY(0, 0, 47), - SPT_COMMUNITY(1, 48, 180), - SPT_COMMUNITY(2, 181, 191), + SPTH_COMMUNITY(0, 0, 47, spth_community0_gpps), + SPTH_COMMUNITY(1, 48, 180, spth_community1_gpps), + SPTH_COMMUNITY(2, 181, 191, spth_community3_gpps), }; static const struct intel_pinctrl_soc_data spth_soc_data = {
It turns out that the Windows GPIO driver for Sunrisepoint PCH-H uses similar bank structure than it does for Cannon Lake with the exception that here the bank size is always 24 pins. Starting from pad group E the BIOS/Windows GPIO numbering does not match the hardware anymore but instead there are gaps to make each pad group ("bank") consume exactly 24 pins. Because of this Linux does not use correct pins for GpioIo/GpioIo resources exposed by the BIOS. This patch aligns the GPIO number space with BIOS/Windows to make sure the same numbering scheme is used in Linux as well following what we did already for Intel Cannon Lake. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1543769 Reported-by: Vivien FRASCA <vivien.frasca@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> --- This should go to stable as well with following tags Fixes: 551fa5801ef1 ("pinctrl: intel: sunrisepoint: Add Intel Sunrisepoint-H support") Cc: stable@vger.kernel.org but there is dependency to following commits as well: 03c4749dd6c7 ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation") a60eac3239f0 ("pinctrl: intel: Allow custom GPIO base for pad groups") I'm not sure whether they can be considered as stable material, though. drivers/pinctrl/intel/pinctrl-sunrisepoint.c | 45 ++++++++++++++++++++++++++-- 1 file changed, 42 insertions(+), 3 deletions(-)