Skip to contentSkip to conversation

intel-pinctrl for 5.6-1

GIT PULL Andy Shevchenko 2 participants 6 messages Jan 20, 2020 – Jan 24, 2020 GPIO

lore
Share & tools
lore
#0 lore raw

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
Signature · 2 lines
With Best Regards,
Andy Shevchenko
#1 lore raw
Quoted 9 lines · Andy Shevchenko

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

Thanks,

With Best Regards,
Andy Shevchenko

The following changes since commit b9a19bdbc843abd659e8ec6b1b3c32ae3a2455eb:

Quoted 7 lines

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

#2 lore raw
Quoted 4 lines · Linus Walleij
Quoted 1 line · Andy Shevchenko

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

...

Quoted 1 line

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

Thanks!
How long usually does it take to see in linux-next?

Signature · 2 lines
With Best Regards,
Andy Shevchenko
#3 lore raw
Quoted 6 lines · Andy Shevchenko
Quoted 1 line · Linus Walleij

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

#4 lore raw
Quoted 24 lines · Linus Walleij
Quoted 6 lines · Andy Shevchenko
Quoted 1 line · Linus Walleij

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.

Quoted 4 lines

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...

Signature · 2 lines
With Best Regards,
Andy Shevchenko
#5 lore raw
Quoted 25 lines · Andy Shevchenko
Quoted 24 lines · Linus Walleij
Quoted 6 lines · Andy Shevchenko
Quoted 1 line · Linus Walleij

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.

Quoted 7 lines
Quoted 4 lines

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