| Message ID | 20191209130926.86483-1-andriy.shevchenko@linux.intel.com |
|---|---|
| Headers | show |
| Series | pinctrl: intel: Move Lynxpoint to pin control umbrella | expand |
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>
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
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.
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
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