Update Pink Sardine platform ACP register header with Soundwire
Controller specific registers and other ACP registers.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Link: https://lore.kernel.org/r/20221010093941.2354783-1-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The audio unit of Marvell Armada38x SoC is similar to the ones comprised by
other Marvell SoCs (Kirkwood, Dove and Armada 370). Therefore KW audio
driver can be used to support it and this commit adds new compatible string
to identify Armada 38x variant.
Two new memory regions are added: first one for PLL configuration and
the second one for choosing one of audio I/O modes (I2S or S/PDIF).
For the latter purpose a new optional DT property is added ('spdif-mode').
kirkwood-i2s driver is extended by adding a new init function for Armada
38x flavor and also a routine that enables PLL output (i.e. MCLK)
configuration.
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Tested-by: Star_Automation <star@marvell.com>
Reviewed-by: Nadav Haklai <nadavh@marvell.com>
Reviewed-by: Lior Amsalem <alior@marvell.com>
Tested-by: Lior Amsalem <alior@marvell.com>
Signed-off-by: Hezi Shahmoon <hezi@marvell.com>
Reviewed-by: Neta Zur Hershkovits <neta@marvell.com>
[pali: Fix support for pre-38x SoCs]
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20220926110533.13475-1-pali@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Add optional reset control instead of GPIO to manage codec
PDN pin.
As there is reference counter for reset control, so need
to remove one ak4458_reset in runtime resume to make the
reference counter balance.
Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1665664611-21350-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The Hardware Voice Activity Detector (HWVAD) is a block
responsible for detect voice activity in a channel selected
by the user. It can be configured in Envelope-based or
Energy-based mode.
There are additional two interrupts for HWVAD, one is event
interrupt, another is error interrupt.
Enable hwvad in parallel with recording.
when voice activity detected, HWVAD will be disabled and
alsa control notification is triggerred.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1663925494-9941-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use DIV_ROUND_UP() instead of open-coding it, which intents and makes it
more clear what is going on for the casual reviewer.
The Coccinelle references Commit e4d8aef214 ("ALSA: usb: Use
DIV_ROUND_UP() instead of open-coding it").
Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
Link: https://lore.kernel.org/r/20220927140948.17696-5-shangxiaojing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use DIV_ROUND_UP() instead of open-coding it, which intents and makes it
more clear what is going on for the casual reviewer.
The Coccinelle references Commit e4d8aef214 ("ALSA: usb: Use
DIV_ROUND_UP() instead of open-coding it").
Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
Link: https://lore.kernel.org/r/20220927140948.17696-4-shangxiaojing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use DIV_ROUND_UP() instead of open-coding it, which intents and makes it
more clear what is going on for the casual reviewer.
The Coccinelle references Commit e4d8aef214 ("ALSA: usb: Use
DIV_ROUND_UP() instead of open-coding it").
Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220927140948.17696-3-shangxiaojing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use DIV_ROUND_UP() instead of open-coding it, which intents and makes it
more clear what is going on for the casual reviewer.
The Coccinelle references Commit e4d8aef214 ("ALSA: usb: Use
DIV_ROUND_UP() instead of open-coding it").
Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220927140948.17696-2-shangxiaojing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Each ASoC platform driver is named by rpmsg channel. ASoC machine
driver can parse "fsl,rpmsg-channel-name" property to figure out which
ASoC platform driver it should link with.
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com>
Link: https://lore.kernel.org/r/20220930064441.2548505-8-chancel.liu@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Some sound card based on rpmsg may support multi-channel. This patch
expands the maximum channels to 32.
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com>
Link: https://lore.kernel.org/r/20220930064441.2548505-7-chancel.liu@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This driver helps register ASoC machine device thus use of
PLATFORM_DEVID_AUTO macro in API can automatically create device for
each sound card based on rpmsg.
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com>
Link: https://lore.kernel.org/r/20220930064441.2548505-6-chancel.liu@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Some sound card based on rpmsg may support multi-channel. The number of
channels can be sent to Cortex-M in rpmsg for process.
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com>
Link: https://lore.kernel.org/r/20220930064441.2548505-5-chancel.liu@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch can register different ASoC platform drivers if there are
several rpmsg channels. Thus sound cards based on different rpmsg
channels can link to their respective platform drivers. Besides, the
name of driver is equal to the name of rpmsg channel.
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com>
Link: https://lore.kernel.org/r/20220930064441.2548505-4-chancel.liu@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Rpmsg channel for MICFIL can also be created through rpmsg name service
announcement. If this driver is probed, Cortex-A can access MICFIL
which is actually controlled by Cortex-M through rpmsg channel for
MICFIL. This driver also helps register ASoC platform device thus use
of PLATFORM_DEVID_AUTO macro in API can automatically create device for
each rpmsg channel.
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com>
Link: https://lore.kernel.org/r/20220930064441.2548505-3-chancel.liu@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a string property to assign the rpmsg channel this sound card sits
on. This property can be omitted if there is only one sound card and it
sits on "rpmsg-audio-channel".
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220930064441.2548505-2-chancel.liu@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In order to load proper board configuration it needs to be looked up in
ACPI. Add board configuration for MAXIM 98927 codec present on
Chromebooks.
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Link: https://lore.kernel.org/r/20220930124538.354992-3-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Allow the WM8961 driver to be enabled independently now that it is
usable with devicetree.
Signed-off-by: Doug Brown <doug@schmorgal.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20221003032414.248326-4-doug@schmorgal.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for devicetree to the WM8961 driver so it can be used with
modern DT-based kernels.
Signed-off-by: Doug Brown <doug@schmorgal.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20221003032414.248326-3-doug@schmorgal.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Create a simple DT schema for the existing Wolfson WM8961 driver so that
DT support can be added to the driver.
Signed-off-by: Doug Brown <doug@schmorgal.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20221003032414.248326-2-doug@schmorgal.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Most of the device with QUP SPI adapter are actually using GPIO-s for
chip select.
However, this stopped working after ("spi: Retire legacy GPIO handling")
as it introduced a check on ->use_gpio_descriptors flag and since spi-qup
driver does not set the flag it meant that all of boards using GPIO-s and
with QUP adapter SPI devices stopped working.
So, to enable using GPIO-s again set ->use_gpio_descriptors to true and
populate ->max_native_cs.
Fixes: f48dc6b966 ("spi: Retire legacy GPIO handling")
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Cc: luka.perkov@sartura.hr
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20221006194819.1536932-1-robert.marko@sartura.hr
Signed-off-by: Mark Brown <broonie@kernel.org>
Add the infrared receiver and its associated pinctrl entry. Note that
there is an external pullup to VCC3V3_SYS.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Tested-by: Dan Johansen <strit@manjaro.org>
Link: https://lore.kernel.org/r/20220930051246.391614-14-aurelien@aurel32.net
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Rockchip RK3568 has two USB XHCI controllers. The USB 2.0 signals
are connected to a PHY providing one host-only port and one OTG port.
The USB 3.0 signals are connected to two USB3.0/PCIE/SATA combo PHY.
The ODROID M1 has 2 type A USB 3.0 connectors, with the USB 3.0 signals
connected to the two combo PHYs. For the USB 2.0 signals, one connector
is connected to the host-only PHY and uses the same power switch as the
USB 2.0 ports. The other connector has its own power switch and is
connected to the OTG PHY, which is also connected to a device only
micro-USB connector. The purpose of this micro-USB connector is for
firmware update using the Rockusb vendor specific USB class. Therefore
it does not make sense to enable this port on Linux, and the PHY is
forced to host mode.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Tested-by: Dan Johansen <strit@manjaro.org>
Link: https://lore.kernel.org/r/20220930051246.391614-11-aurelien@aurel32.net
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Rockchip RK3568 has two USB OHCI/EHCI controllers connected to a PHY
providing one host-only port and one OTG port. On the ODROID-M1, they
are both used in host mode. The USB ports are powered by a DC/DC
converter providing 5V and named VCC5V0_SYS on the schematics, followed
by a power switch.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Tested-by: Dan Johansen <strit@manjaro.org>
Link: https://lore.kernel.org/r/20220930051246.391614-10-aurelien@aurel32.net
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
This enables the i2s0 controller and the hdmi-sound node on the
ODROID-M1.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Tested-by: Dan Johansen <strit@manjaro.org>
Link: https://lore.kernel.org/r/20220930051246.391614-8-aurelien@aurel32.net
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
On the ODROID-M1, the I2S1 TDM controller is connected to the rk809
codec in I2S mode. It is used to provide a stereo headphones output and
a mono speaker output. A GPIO with an external pullup is used as an
headphone detection input.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Tested-by: Dan Johansen <strit@manjaro.org>
Link: https://lore.kernel.org/r/20220930051246.391614-6-aurelien@aurel32.net
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Enable the Rockchip Serial Flash Controller for the ODROID-M1 and add
the corresponding SPI NOR flash entry. The SFC is used in dual I/O mode
and not quad I/O mode, as the FSPI_D2 pin is shared with the EMMC_RSTn
pin.
The partitions addresses and sizes are taken from the ODROID-M1
Partition Table page on the ODROID wiki.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Tested-by: Dan Johansen <strit@manjaro.org>
Link: https://lore.kernel.org/r/20220930051246.391614-5-aurelien@aurel32.net
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
This patch is to add a device tree for new board Hardkernel ODROID-M1
based on Rockchip RK3568, includes basic peripherals -
uart/eMMC/uSD/i2c and on-board ethernet.
Signed-off-by: Dongjin Kim <tobetter@gmail.com>
[aurelien@aurel32.net: addressed issues from initial review]
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Tested-by: Dan Johansen <strit@manjaro.org>
Link: https://lore.kernel.org/r/20220930051246.391614-3-aurelien@aurel32.net
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add device tree binding for Hardkernel ODROID-M1 board based on RK3568
SoC.
Signed-off-by: Dongjin Kim <tobetter@gmail.com>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Tested-by: Dan Johansen <strit@manjaro.org>
Link: https://lore.kernel.org/r/20220930051246.391614-2-aurelien@aurel32.net
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The PX30-uQ7 (Ringneck) SoM is a µQseven-compatible (40mmx70mm, MXM-230
connector) system-on-module from Theobroma Systems[1], featuring the
Rockchip PX30.
It provides the following feature set:
* up to 4GB DDR4
* up to 128GB on-module eMMC (with 8-bit 1.8V interface)
* SD card (on a baseboard) via edge connector
* Fast Ethernet with on-module TI DP83825I PHY
* MIPI-DSI/LVDS
* MIPI-CSI
* USB
- 1x USB 2.0 dual-role
- 3x USB 2.0 host
* on-module STM32 Cortex-M0 companion controller, implementing:
- low-power RTC functionality (ISL1208 emulation)
- fan controller (AMC6821 emulation)
- USB<->CAN bridge controller
* on-module Espressif ESP32 for Bluetooth + 2.4GHz WiFi
* on-module NXP SE05x Secure Element
[1] https://www.theobroma-systems.com/som-product/px30-%C2%B5q7/
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Link: https://lore.kernel.org/r/20220930-upstream-ringneck-v2-1-6671694b6934@theobroma-systems.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Back in the description of commit e440e30e26 ("arm64: dts: qcom:
sc7180: Avoid glitching SPI CS at bootup on trogdor") we described a
problem that we were seeing on trogdor devices. I'll re-summarize here
but you can also re-read the original commit.
On trogdor devices, the BIOS is setting up the SPI chip select as:
- mux special function (SPI chip select)
- output enable
- output low (unused because we've muxed as special function)
In the kernel, however, we've moved away from using the chip select
line as special function. Since the kernel wants to fully control the
chip select it's far more efficient to treat the line as a GPIO rather
than sending packet-like commands to the GENI firmware every time we
want the line to toggle.
When we transition from how the BIOS had the pin configured to how the
kernel has the pin configured we end up glitching the line. That's
because we _first_ change the mux of the line and then later set its
output. This glitch is bad and can confuse the device on the other end
of the line.
The old commit e440e30e26 ("arm64: dts: qcom: sc7180: Avoid
glitching SPI CS at bootup on trogdor") fixed the glitch, though the
solution was far from elegant. It essentially did the thing that
everyone always hates: encoding a sequential program in device tree,
even if it's a simple one. It also, unfortunately, got broken by
commit b991f8c362 ("pinctrl: core: Handling pinmux and pinconf
separately"). After that commit we did all the muxing _first_ even
though the config (set the pin to output high) was listed first. :(
I looked at ideas for how to solve this more properly. My first
thought was to use the "init" pinctrl state. In theory the "init"
pinctrl state is supposed to be exactly for achieving glitch-free
transitions. My dream would have been for the "init" pinctrl to do
nothing at all. That would let us delay the automatic pin muxing until
the driver could set things up and call pinctrl_init_done(). In other
words, my dream was:
/* Request the GPIO; init it 1 (because DT says GPIO_ACTIVE_LOW) */
devm_gpiod_get_index(dev, "cs", GPIOD_OUT_LOW);
/* Output should be right, so we can remux, yay! */
pinctrl_init_done(dev);
Unfortunately, it didn't work out. The primary reason is that the MSM
GPIO driver implements gpio_request_enable(). As documented in
pinmux.h, that function automatically remuxes a line as a GPIO. ...and
it does this remuxing _before_ specifying the output of the pin. You
can see in gpiod_get_index() that we call gpiod_request() before
gpiod_configure_flags(). gpiod_request() isn't passed any flags so it
has no idea what the eventual output will be.
We could have debates about whether or not the automatic remuxing to
GPIO for the MSM pinctrl was a good idea or not, but at this point I
think there is a plethora of code that's relying on it and I certainly
wouldn't suggest changing it.
Alternatively, we could try to come up with a way to pass the initial
output state to gpio_request_enable() and plumb all that through. That
seems like it would be doable, but we'd have to plumb it through
several layers in the stack.
This patch implements yet another alternative. Here, we specifically
avoid glitching the first time a pin is muxed to GPIO function if the
direction of the pin is output. The idea is that we can read the state
of the pin before we set the mux and make sure that the re-mux won't
change the state.
NOTES:
- We only do this the first time since later swaps between mux states
might want to preserve the old output value. In other words, I
wouldn't want to break a driver that did:
gpiod_set_value(g, 1);
pinctrl_select_state(pinctrl, special_state);
pinctrl_select_default_state();
/* We should be driving 1 even if "special_state" made the pin 0 */
- It's safe to do this the first time since the driver _couldn't_ have
explicitly set a state. In order to even be able to control the GPIO
(at least using gpiod) we have to have requested it which would have
counted as the first mux.
- In theory, instead of keeping track of the first time a pin was set
as a GPIO we could enable the glitch-free behavior only when
msm_pinmux_request_gpio() is in the callchain. That works an enables
my "dream" implementation above where we use an "init" state to
solve this. However, it's nice not to have to do this. By handling
just the first transition to GPIO we can simply let the normal
"default" remuxing happen and we can be assured that there won't be
a glitch.
Before this change I could see the glitch reported on the EC console
when booting. It would say this when booting the kernel:
Unexpected state 1 in CSNRE ISR
After this change there is no error reported.
Note that I haven't reproduced the original problem described in
e440e30e26 ("arm64: dts: qcom: sc7180: Avoid glitching SPI CS at
bootup on trogdor") but I could believe it might happen in certain
timing conditions.
Fixes: b991f8c362 ("pinctrl: core: Handling pinmux and pinconf separately")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20221014103217.1.I656bb2c976ed626e5d37294eb252c1cf3be769dc@changeid
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
GPIOLIB and PINCTRL config options are required by all ARM32/ARM64/RISC-V
Renesas SoCs, so instead of selecting them under ARCH_RENESAS for each
architecture just explicitly select them under SOC_RENESAS config option
which will be visible for all the three architectures (if ARCH_RENESAS is
enabled).
Suggested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://lore.kernel.org/r/20220919104606.96553-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
As serial communication requires a clock signal, the High Speed Serial
Communication Interfaces with FIFO (HSCIF) are clocked by a clock that
is not affected by Spread Spectrum or Fractional Multiplication.
Hence change the clock input for the HSCIF0 Baud Rate Generator internal
clock from the S0D3_PER clock to the SASYNCPERD1 clock (which has the
same clock rate), cfr. R-Car V4H Hardware User's Manual rev. 0.54.
Fixes: 987da486d8 ("arm64: dts: renesas: Add Renesas R8A779G0 SoC support")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://lore.kernel.org/r/a5bd4148f92806f7c8e577d383370f810315f586.1665155947.git.geert+renesas@glider.be
Some laptops have been reported to wake up from s2idle when plugging
in the AC adapter or by closing the lid. This is a surprising
behavior that is further clarified by commit cb3e7d624c ("PM:
wakeup: Add extra debugging statement for multiple active IRQs").
With that commit in place the following interaction can be seen
when the lid is closed:
[ 28.946038] PM: suspend-to-idle
[ 28.946083] ACPI: EC: ACPI EC GPE status set
[ 28.946101] ACPI: PM: Rearming ACPI SCI for wakeup
[ 28.950152] Timekeeping suspended for 3.320 seconds
[ 28.950152] PM: Triggering wakeup from IRQ 9
[ 28.950152] ACPI: EC: ACPI EC GPE status set
[ 28.950152] ACPI: EC: ACPI EC GPE dispatched
[ 28.995057] ACPI: EC: ACPI EC work flushed
[ 28.995075] ACPI: PM: Rearming ACPI SCI for wakeup
[ 28.995131] PM: Triggering wakeup from IRQ 9
[ 28.995271] ACPI: EC: ACPI EC GPE status set
[ 28.995291] ACPI: EC: ACPI EC GPE dispatched
[ 29.098556] ACPI: EC: ACPI EC work flushed
[ 29.207020] ACPI: EC: ACPI EC work flushed
[ 29.207037] ACPI: PM: Rearming ACPI SCI for wakeup
[ 29.211095] Timekeeping suspended for 0.739 seconds
[ 29.211095] PM: Triggering wakeup from IRQ 9
[ 29.211079] PM: Triggering wakeup from IRQ 7
[ 29.211095] ACPI: PM: ACPI non-EC GPE wakeup
[ 29.211095] PM: resume from suspend-to-idle
* IRQ9 on this laptop is used for the ACPI SCI.
* IRQ7 on this laptop is used for the GPIO controller.
What has occurred is when the lid was closed the EC woke up the
SoC from it's deepest sleep state and the kernel's s2idle loop
processed all EC events. When it was finished processing EC events,
it checked for any other reasons to wake (break the s2idle loop).
The IRQ for the GPIO controller was active so the loop broke, and
then this IRQ was processed. This is not a kernel bug but it is
certainly a surprising behavior, and to better debug it we should
have a dynamic debugging message that we can enact to catch it.
Acked-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Acked-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Mark Pearson <markpearson@lenovo.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20221013134729.5592-2-mario.limonciello@amd.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
