mbox series

[GIT,PULL] intel-pinctrl for 5.6-1

Message ID 20200120100957.GA11113@black.fi.intel.com
State New
Headers show
Series [GIT,PULL] intel-pinctrl for 5.6-1 | expand

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel.git tags/intel-pinctrl-v5.6-1

Message

Andy Shevchenko Jan. 20, 2020, 10:09 a.m. UTC 
Hi Linus,

Intel pin control drivers update for v5.6 (next release cycle).

Thanks,

With Best Regards,
Andy Shevchenko

The following changes since commit b9a19bdbc843abd659e8ec6b1b3c32ae3a2455eb:

  pinctrl: cherryview: Pass irqchip when adding gpiochip (2019-12-09 12:55:53 +0200)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel.git tags/intel-pinctrl-v5.6-1

for you to fetch changes up to cd0a32371db73d0b50536a7ca4f036abddff0d1d:

  pinctrl: tigerlake: Tiger Lake uses _HID enumeration (2020-01-16 13:30:40 +0200)

----------------------------------------------------------------
intel-pinctrl for v5.6-1

* Tiger Lake appears to have _HID enumeration, thus driver has been updated
* Coffee Lake-S has the same IP as Sunrisepoint, thus ID has been added
* Baytrail has got more clean ups and bug fixes, such as direct IRQ handling
* Lynxpoint GPIO has been converted to true pin control driver
* The common driver now uses IRQ chip enumeration via GPIO chip

The following is an automated git shortlog grouped by driver:

baytrail:
 -  Replace WARN with dev_info_once when setting direct-irq pin to output
 -  Do not clear IRQ flags on direct-irq enabled pins
 -  Reuse struct intel_pinctrl in the driver
 -  Use local variable to keep device pointer
 -  Keep pointer to struct device instead of its container
 -  Use GPIO direction definitions
 -  Move IRQ valid mask initialization to a dedicated callback
 -  Group GPIO IRQ chip initialization
 -  Allocate IRQ chip dynamic

cherryview:
 -  Use GPIO direction definitions

intel:
 -  Pass irqchip when adding gpiochip
 -  Add GPIO <-> pin mapping ranges via callback
 -  Share struct intel_pinctrl for wider use
 -  Use GPIO direction definitions

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

sunrisepoint:
 -  Add Coffee Lake-S ACPI ID
 -  Add missing Interrupt Status register offset

tigerlake:
 -  Tiger Lake uses _HID enumeration

----------------------------------------------------------------
Andy Shevchenko (31):
      pinctrl: baytrail: Allocate IRQ chip dynamic
      pinctrl: baytrail: Group GPIO IRQ chip initialization
      pinctrl: baytrail: Move IRQ valid mask initialization to a dedicated callback
      pinctrl: intel: Share struct intel_pinctrl for wider use
      pinctrl: baytrail: Keep pointer to struct device instead of its container
      pinctrl: baytrail: Use local variable to keep device pointer
      pinctrl: baytrail: Reuse struct intel_pinctrl in the driver
      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

Boyan Ding (1):
      pinctrl: sunrisepoint: Add missing Interrupt Status register offset

Hans de Goede (2):
      pinctrl: baytrail: Do not clear IRQ flags on direct-irq enabled pins
      pinctrl: baytrail: Replace WARN with dev_info_once when setting direct-irq pin to output

Linus Walleij (2):
      pinctrl: intel: Add GPIO <-> pin mapping ranges via callback
      pinctrl: intel: Pass irqchip when adding gpiochip

Matti Vaittinen (3):
      pinctrl: baytrail: Use GPIO direction definitions
      pinctrl: cherryview: Use GPIO direction definitions
      pinctrl: intel: Use GPIO direction definitions

Mika Westerberg (2):
      pinctrl: sunrisepoint: Add Coffee Lake-S ACPI ID
      pinctrl: tigerlake: Tiger Lake uses _HID enumeration

 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-baytrail.c     | 311 +++++----
 drivers/pinctrl/intel/pinctrl-cherryview.c   |   5 +-
 drivers/pinctrl/intel/pinctrl-intel.c        | 101 ++-
 drivers/pinctrl/intel/pinctrl-intel.h        |  44 ++
 drivers/pinctrl/intel/pinctrl-lynxpoint.c    | 975 +++++++++++++++++++++++++++
 drivers/pinctrl/intel/pinctrl-sunrisepoint.c |   2 +
 drivers/pinctrl/intel/pinctrl-tigerlake.c    | 547 +++++++--------
 13 files changed, 1479 insertions(+), 1001 deletions(-)
 delete mode 100644 drivers/gpio/gpio-lynxpoint.c
 create mode 100644 drivers/pinctrl/intel/pinctrl-lynxpoint.c

Comments

Linus Walleij Jan. 23, 2020, 2:45 p.m. UTC | #1 
On Mon, Jan 20, 2020 at 11:10 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:

> Intel pin control drivers update for v5.6 (next release cycle).
>
> Thanks,
>
> With Best Regards,
> Andy Shevchenko
>
> The following changes since commit b9a19bdbc843abd659e8ec6b1b3c32ae3a2455eb:
>
>   pinctrl: cherryview: Pass irqchip when adding gpiochip (2019-12-09 12:55:53 +0200)
>
> are available in the Git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel.git tags/intel-pinctrl-v5.6-1
>
> for you to fetch changes up to cd0a32371db73d0b50536a7ca4f036abddff0d1d:

Thanks Andy!

Pulled this into my "devel" branch for v5.6.

Yours,
Linus Walleij
Andy Shevchenko Jan. 24, 2020, 10:57 a.m. UTC | #2 
On Thu, Jan 23, 2020 at 03:45:14PM +0100, Linus Walleij wrote:
> On Mon, Jan 20, 2020 at 11:10 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:

> > Intel pin control drivers update for v5.6 (next release cycle).

...

> Pulled this into my "devel" branch for v5.6.

Thanks!
How long usually does it take to see in linux-next?
Linus Walleij Jan. 24, 2020, 1:02 p.m. UTC | #3 
On Fri, Jan 24, 2020 at 11:57 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> On Thu, Jan 23, 2020 at 03:45:14PM +0100, Linus Walleij wrote:

> > Pulled this into my "devel" branch for v5.6.
>
> Thanks!
> How long usually does it take to see in linux-next?

What I need before I put it for-next is successful builds on a few
archs.

Zeroday has been smacky before so I could quickly cornfirm the branches
build fine and that made things quicker in the past. But as of lately
zeroday comes and goes a bit sporadically.

I can do local builds of some archs but my computer isn't the most
fantastic workhorse really.

Lately I am investigating a cloud build service, it is quite promising,
you see the branch "testmerge" in linux-gpio where I merge all
the new stuff for GPIO and pin control and toss at the build server,
so I am working on something here.

Sometimes I just give up trying to build all stuff and submit it for
next anyway but I'd rather not have to do that, it usually results
in a patch storm of 4 different people fixing the same trivial
issue in linux-next...

Yours,
Linus Walleij
Andy Shevchenko Jan. 24, 2020, 1:21 p.m. UTC | #4 
On Fri, Jan 24, 2020 at 02:02:56PM +0100, Linus Walleij wrote:
> On Fri, Jan 24, 2020 at 11:57 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Thu, Jan 23, 2020 at 03:45:14PM +0100, Linus Walleij wrote:
> 
> > > Pulled this into my "devel" branch for v5.6.
> >
> > Thanks!
> > How long usually does it take to see in linux-next?
> 
> What I need before I put it for-next is successful builds on a few
> archs.
> 
> Zeroday has been smacky before so I could quickly cornfirm the branches
> build fine and that made things quicker in the past. But as of lately
> zeroday comes and goes a bit sporadically.
> 
> I can do local builds of some archs but my computer isn't the most
> fantastic workhorse really.
> 
> Lately I am investigating a cloud build service, it is quite promising,
> you see the branch "testmerge" in linux-gpio where I merge all
> the new stuff for GPIO and pin control and toss at the build server,
> so I am working on something here.
> 
> Sometimes I just give up trying to build all stuff and submit it for
> next anyway but I'd rather not have to do that, it usually results
> in a patch storm of 4 different people fixing the same trivial
> issue in linux-next...

Thank you for so detailed answer! I didn't mean to complain or so,
I was just wondering...
Linus Walleij Jan. 24, 2020, 1:33 p.m. UTC | #5 
On Fri, Jan 24, 2020 at 2:21 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> On Fri, Jan 24, 2020 at 02:02:56PM +0100, Linus Walleij wrote:
> > On Fri, Jan 24, 2020 at 11:57 AM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Thu, Jan 23, 2020 at 03:45:14PM +0100, Linus Walleij wrote:
> >
> > > > Pulled this into my "devel" branch for v5.6.
> > >
> > > Thanks!
> > > How long usually does it take to see in linux-next?
> >
> > What I need before I put it for-next is successful builds on a few
> > archs.
> >
> > Zeroday has been smacky before so I could quickly cornfirm the branches
> > build fine and that made things quicker in the past. But as of lately
> > zeroday comes and goes a bit sporadically.
> >
> > I can do local builds of some archs but my computer isn't the most
> > fantastic workhorse really.
> >
> > Lately I am investigating a cloud build service, it is quite promising,
> > you see the branch "testmerge" in linux-gpio where I merge all
> > the new stuff for GPIO and pin control and toss at the build server,
> > so I am working on something here.
> >
> > Sometimes I just give up trying to build all stuff and submit it for
> > next anyway but I'd rather not have to do that, it usually results
> > in a patch storm of 4 different people fixing the same trivial
> > issue in linux-next...
>
> Thank you for so detailed answer! I didn't mean to complain or so,
> I was just wondering...

Don't worry about that, it's a good question.

I am looking a bit into automation and testing right now so these
things are very much on my mind.

Yours,
Linus Walleij