* [GIT PULL] intel-pinctrl for 5.6-1
@ 2020-01-20 10:09 Andy Shevchenko
2020-01-23 14:45 ` Linus Walleij
0 siblings, 1 reply; 6+ messages in thread
From: Andy Shevchenko @ 2020-01-20 10:09 UTC (permalink / raw)
To: Linus Walleij; +Cc: Linux pin control, Mika Westerberg, Andy Shevchenko
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
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [GIT PULL] intel-pinctrl for 5.6-1
2020-01-20 10:09 [GIT PULL] intel-pinctrl for 5.6-1 Andy Shevchenko
@ 2020-01-23 14:45 ` Linus Walleij
2020-01-24 10:57 ` Andy Shevchenko
0 siblings, 1 reply; 6+ messages in thread
From: Linus Walleij @ 2020-01-23 14:45 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: Linux pin control, Mika Westerberg
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [GIT PULL] intel-pinctrl for 5.6-1
2020-01-23 14:45 ` Linus Walleij
@ 2020-01-24 10:57 ` Andy Shevchenko
2020-01-24 13:02 ` Linus Walleij
0 siblings, 1 reply; 6+ messages in thread
From: Andy Shevchenko @ 2020-01-24 10:57 UTC (permalink / raw)
To: Linus Walleij; +Cc: Linux pin control, Mika Westerberg
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?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [GIT PULL] intel-pinctrl for 5.6-1
2020-01-24 10:57 ` Andy Shevchenko
@ 2020-01-24 13:02 ` Linus Walleij
2020-01-24 13:21 ` Andy Shevchenko
0 siblings, 1 reply; 6+ messages in thread
From: Linus Walleij @ 2020-01-24 13:02 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: Linux pin control, Mika Westerberg
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [GIT PULL] intel-pinctrl for 5.6-1
2020-01-24 13:02 ` Linus Walleij
@ 2020-01-24 13:21 ` Andy Shevchenko
2020-01-24 13:33 ` Linus Walleij
0 siblings, 1 reply; 6+ messages in thread
From: Andy Shevchenko @ 2020-01-24 13:21 UTC (permalink / raw)
To: Linus Walleij; +Cc: Linux pin control, Mika Westerberg
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...
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [GIT PULL] intel-pinctrl for 5.6-1
2020-01-24 13:21 ` Andy Shevchenko
@ 2020-01-24 13:33 ` Linus Walleij
0 siblings, 0 replies; 6+ messages in thread
From: Linus Walleij @ 2020-01-24 13:33 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: Linux pin control, Mika Westerberg
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-01-24 13:33 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-01-20 10:09 [GIT PULL] intel-pinctrl for 5.6-1 Andy Shevchenko
2020-01-23 14:45 ` Linus Walleij
2020-01-24 10:57 ` Andy Shevchenko
2020-01-24 13:02 ` Linus Walleij
2020-01-24 13:21 ` Andy Shevchenko
2020-01-24 13:33 ` Linus Walleij
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox