pinctrl: sunrisepoint: Align GPIO number space with Windows

Message ID 20180329143725.84781-1-mika.westerberg@linux.intel.com
State New
Headers show
Series
  • pinctrl: sunrisepoint: Align GPIO number space with Windows
Related show

Commit Message

Mika Westerberg March 29, 2018, 2:37 p.m.
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(-)

Comments

Hans de Goede March 29, 2018, 2:45 p.m. | #1
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
Andy Shevchenko April 2, 2018, 10:02 a.m. | #2
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 = {
Mika Westerberg April 3, 2018, 11:11 a.m. | #3
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
Mika Westerberg April 25, 2018, 9:48 a.m. | #4
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
Hans de Goede April 25, 2018, 11:15 a.m. | #5
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
Mika Westerberg April 27, 2018, 10:01 a.m. | #6
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
Linus Walleij April 30, 2018, 12:51 p.m. | #7
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
Mika Westerberg April 30, 2018, 1:30 p.m. | #8
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
Hans de Goede April 30, 2018, 3:18 p.m. | #9
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
Linus Walleij May 2, 2018, 12:37 p.m. | #10
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

Patch

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 = {