[v2,00/24] pinctrl: intel: Move Lynxpoint to pin control umbrella
mbox series

Message ID 20191209130926.86483-1-andriy.shevchenko@linux.intel.com
Headers show
Series
  • pinctrl: intel: Move Lynxpoint to pin control umbrella
Related show

Message

Andy Shevchenko Dec. 9, 2019, 1:09 p.m. UTC
Intel Lynxpoint GPIO is actually half way to the Chassis specification
that has been established starting from Intel Skylake. It has some pin control
properties we may utilize. To achieve this, move the driver under pin control
umbrella and do a bunch of clean ups.

The series has been tested on Broadwell Ultrabook where Lynxpoint GPIO
is exposed to the OS.

It has a dependency to patches in my review branch [1]. That dependency patch
is supposed to be submitted soon as a part of Baytrail clean up. In the
mentioned branch the patches are represented in the correct order.

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel.git/log/?h=review-andy

Changes v2:
- fixed ordering in Kconfig and Makefile (Mika)
- finished conversion to pin control

Andy Shevchenko (24):
  pinctrl: lynxpoint: Move GPIO driver to pin controller folder
  pinctrl: lynxpoint: Use raw_spinlock for locking
  pinctrl: lynxpoint: Correct amount of pins
  pinctrl: lynxpoint: Drop useless assignment
  pinctrl: lynxpoint: Use %pR to print IO resource
  pinctrl: lynxpoint: Use standard pattern for memory allocation
  pinctrl: lynxpoint: Assume 2 bits for mode selector
  pinctrl: lynxpoint: Relax GPIO request rules
  pinctrl: lynxpoint: Keep pointer to struct device instead of its
    container
  pinctrl: lynxpoint: Switch to memory mapped IO accessors
  pinctrl: lynxpoint: Convert unsigned to unsigned int
  pinctrl: lynxpoint: Extract lp_gpio_acpi_use() for future use
  pinctrl: lynxpoint: Move ->remove closer to ->probe()
  pinctrl: lynxpoint: Move lp_irq_type() closer to IRQ related routines
  pinctrl: lynxpoint: Move ownership check to IRQ chip
  pinctrl: lynxpoint: Implement ->irq_ack() callback
  pinctrl: lynxpoint: Implement intel_gpio_get_direction callback
  pinctrl: lynxpoint: Add pin control data structures
  pinctrl: lynxpoint: Reuse struct intel_pinctrl in the driver
  pinctrl: lynxpoint: Add pin control operations
  pinctrl: lynxpoint: Implement ->pin_dbg_show()
  pinctrl: lynxpoint: Add GPIO <-> pin mapping ranges via callback
  pinctrl: lynxpoint: Switch to pin control API
  pinctrl: lynxpoint: Update summary in the driver

 MAINTAINERS                               |   1 -
 drivers/gpio/Kconfig                      |   8 -
 drivers/gpio/Makefile                     |   1 -
 drivers/gpio/gpio-lynxpoint.c             | 471 -----------
 drivers/pinctrl/intel/Kconfig             |  13 +
 drivers/pinctrl/intel/Makefile            |   1 +
 drivers/pinctrl/intel/pinctrl-lynxpoint.c | 975 ++++++++++++++++++++++
 7 files changed, 989 insertions(+), 481 deletions(-)
 delete mode 100644 drivers/gpio/gpio-lynxpoint.c
 create mode 100644 drivers/pinctrl/intel/pinctrl-lynxpoint.c

Comments

Mika Westerberg Dec. 11, 2019, 1:19 p.m. UTC | #1
On Mon, Dec 09, 2019 at 03:09:02PM +0200, Andy Shevchenko wrote:
> Andy Shevchenko (24):
>   pinctrl: lynxpoint: Move GPIO driver to pin controller folder
>   pinctrl: lynxpoint: Use raw_spinlock for locking
>   pinctrl: lynxpoint: Correct amount of pins
>   pinctrl: lynxpoint: Drop useless assignment
>   pinctrl: lynxpoint: Use %pR to print IO resource
>   pinctrl: lynxpoint: Use standard pattern for memory allocation
>   pinctrl: lynxpoint: Assume 2 bits for mode selector
>   pinctrl: lynxpoint: Relax GPIO request rules
>   pinctrl: lynxpoint: Keep pointer to struct device instead of its
>     container
>   pinctrl: lynxpoint: Switch to memory mapped IO accessors
>   pinctrl: lynxpoint: Convert unsigned to unsigned int
>   pinctrl: lynxpoint: Extract lp_gpio_acpi_use() for future use
>   pinctrl: lynxpoint: Move ->remove closer to ->probe()
>   pinctrl: lynxpoint: Move lp_irq_type() closer to IRQ related routines
>   pinctrl: lynxpoint: Move ownership check to IRQ chip
>   pinctrl: lynxpoint: Implement ->irq_ack() callback
>   pinctrl: lynxpoint: Implement intel_gpio_get_direction callback
>   pinctrl: lynxpoint: Add pin control data structures
>   pinctrl: lynxpoint: Reuse struct intel_pinctrl in the driver
>   pinctrl: lynxpoint: Add pin control operations
>   pinctrl: lynxpoint: Implement ->pin_dbg_show()
>   pinctrl: lynxpoint: Add GPIO <-> pin mapping ranges via callback
>   pinctrl: lynxpoint: Switch to pin control API
>   pinctrl: lynxpoint: Update summary in the driver

Looks great to me! For the whole series,

Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Linus Walleij Dec. 13, 2019, 1:36 p.m. UTC | #2
On Mon, Dec 9, 2019 at 2:09 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:

> Intel Lynxpoint GPIO is actually half way to the Chassis specification
> that has been established starting from Intel Skylake. It has some pin control
> properties we may utilize. To achieve this, move the driver under pin control
> umbrella and do a bunch of clean ups.
>
> The series has been tested on Broadwell Ultrabook where Lynxpoint GPIO
> is exposed to the OS.
>
> It has a dependency to patches in my review branch [1]. That dependency patch
> is supposed to be submitted soon as a part of Baytrail clean up. In the
> mentioned branch the patches are represented in the correct order.
>
> [1]: https://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel.git/log/?h=review-andy
>
> Changes v2:
> - fixed ordering in Kconfig and Makefile (Mika)
> - finished conversion to pin control

This is some really nice development and just go ahead:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

If you want to make my life simple could you do this:

- One pull request just moving the driver to the pin control
  subsystem. I will pull this into both the pinctrl and the GPIO
  tree.

- One pull request based on top of the last commit in the first
  pull request with just the rest of refactorings and improvements.
  I will just pull this into the pinctrl tree on top of the moved driver.

Yours,
Linus Walleij
Andy Shevchenko Dec. 13, 2019, 2:44 p.m. UTC | #3
On Fri, Dec 13, 2019 at 02:36:36PM +0100, Linus Walleij wrote:
> On Mon, Dec 9, 2019 at 2:09 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> 
> > Intel Lynxpoint GPIO is actually half way to the Chassis specification
> > that has been established starting from Intel Skylake. It has some pin control
> > properties we may utilize. To achieve this, move the driver under pin control
> > umbrella and do a bunch of clean ups.
> >
> > The series has been tested on Broadwell Ultrabook where Lynxpoint GPIO
> > is exposed to the OS.
> >
> > It has a dependency to patches in my review branch [1]. That dependency patch
> > is supposed to be submitted soon as a part of Baytrail clean up. In the
> > mentioned branch the patches are represented in the correct order.
> >
> > [1]: https://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel.git/log/?h=review-andy
> >
> > Changes v2:
> > - fixed ordering in Kconfig and Makefile (Mika)
> > - finished conversion to pin control
> 
> This is some really nice development and just go ahead:
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> 
> If you want to make my life simple could you do this:

I want, though I think above makes it harder. I'll not expecting any patches
against gpio-lynxpoint.c (and if they will be an author should Cc me anyway).
Besides the series nicely grouped on top of prerequisites which are solely
Intel pin control (no need for GPIO). Thus I prefer to send simple 1 PR during
this cycle to pin control subsystem and that's it.

Tell me if you think it won't work.

> - One pull request just moving the driver to the pin control
>   subsystem. I will pull this into both the pinctrl and the GPIO
>   tree.
> 
> - One pull request based on top of the last commit in the first
>   pull request with just the rest of refactorings and improvements.
>   I will just pull this into the pinctrl tree on top of the moved driver.
Linus Walleij Dec. 16, 2019, 10:19 a.m. UTC | #4
On Fri, Dec 13, 2019 at 3:44 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:

> > If you want to make my life simple could you do this:
>
> I want, though I think above makes it harder. I'll not expecting any patches
> against gpio-lynxpoint.c (and if they will be an author should Cc me anyway).
> Besides the series nicely grouped on top of prerequisites which are solely
> Intel pin control (no need for GPIO). Thus I prefer to send simple 1 PR during
> this cycle to pin control subsystem and that's it.

Fair enough, if you are convinced that will work then go ahead.

Yours,
Linus Walleij