Hi,
Yesterday i left the board running overnight with the *htop *to gather some
health info, today i got the error below, i don't have a battery attached.
* Kernel running: 5.8.4
* htop running (user application)
* the board was idle
What could trigger this?
BR,
@lex
Kernel message:
[
Hi Samuel
what about allwiinner A64??, for that also is POWE KEY irq is routed
through or r_intc??
what specific change need to make , in order to route it through r_intc
because i am not able to bring up device from deep sleep state??
On Monday, 13 January 2020 10:19:46 UTC+5:30, Samuel
This member of struct axp20x_usb_power is not used anywhere.
Remove it.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Samuel Holland
---
drivers/power/supply/axp20x_usb_power.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/power/supply/axp20x_usb_power.c
Investigation on the AXP803 shows that VBUS_PLUGIN/VBUS_REMOVAL IRQs are
triggered on the rising/falling edge of AXP20X_PWR_STATUS_VBUS_USED. The
reason IRQs do not arrive while N_VBUSEN/DRIVEVBUS is high is because
AXP20X_PWR_STATUS_VBUS_USED also never goes high.
This also means that if VBUS is
AXP803/AXP813 have a flag that enables/disables the USB power supply
input. Allow control of this flag via the ONLINE property on those
variants.
It may be necessary to offline the USB power supply input when using
the USB port in OTG mode, or to allow userspace to disable charging.
When the USB
The USB power supply input can be used as a wakeup source. Hook up the
VBUS_PLUGIN IRQ to trigger wakeup based on userspace configuration.
To do this, we must remember the list of IRQs for the life of the
device. To know how much space to allocate for the flexible array
member, we switch from
AXP803/AXP813 have a flag that enables/disables the AC power supply
input. Allow control of this flag via the ONLINE property on those
variants.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Samuel Holland
---
drivers/power/supply/axp20x_ac_power.c | 9 -
1 file changed, 8 insertions(+), 1
AXP803/AXP813 have a flag that enables/disables the AC power supply
input. This flag does not affect the status bits in PWR_INPUT_STATUS.
Its effect can be verified by checking the battery charge/discharge
state (bit 2 of PWR_INPUT_STATUS), or by examining the current draw on
the AC input.
Take
This series adds some improvements to the axp20x* power supply drivers
to better support suspend/resume and use on mobile devices.
The first two patches fix bugs I found while testing the ONLINE control
added in later patches.
Patches 3 and 7 allow userspace to take the power supplies offline.
The AC power supply input can be used as a wakeup source. Hook up the
ACIN_PLUGIN IRQ to trigger wakeup based on userspace configuration.
To do this, we must remember the list of IRQs for the life of the
device. To know how much space to allocate for the flexible array
member, we switch from
Instead of ad-hoc variant ID checks throughout the code, let's start
moving the variant-specific details to a match structure. This allows
for future flexibility, and it better matches the other axp20x power
supply drivers.
This commit removes most variant checks from axp20x_usb_power_probe().
On Mon, Jan 13, 2020 at 11:53 AM Samuel Holland wrote:
>
> Instead of ad-hoc variant ID checks throughout the code, let's start
> moving the variant-specific details to a match structure. This allows
> for future flexibility, and it better matches the other axp20x power
> supply drivers.
>
> This
Unlike most other power button drivers, this driver unconditionally
enables its wakeup IRQ. It should be using device_may_wakeup() to
respect the userspace configuration of wakeup sources.
Because the AXP20x MFD device uses regmap-irq, the AXP20x PEK IRQs are
nested off of regmap-irq's threaded
This driver attempts to avoid reporting wakeup events to userspace by
clearing a possible pending IRQ before IRQs are enabled during resume.
The assumption seems to be that userspace cannot cope with a KEY_POWER
press during resume. However, no other input driver does this, so it
would be a bug
There are many devices, including several mobile battery-powered
devices, using other AXP variants as their PMIC. Enable them to use
the power key as a wakeup source.
Signed-off-by: Samuel Holland
---
drivers/input/misc/axp20x-pek.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff
On Mon, Jan 13, 2020 at 3:58 AM 陈北宗 wrote:
>
> Quick question: can I share an interrupt pin across several peripherals in
> just device tree?
All the drivers must request the interrupt as shared. That's the only
requirement.
ChenYu
> Background: I am trying to design a V3s board (for
The H3 and H5 SoCs have an additional interrupt controller in the RTC
power domain that can be used to enable wakeup for certain IRQs.
Add a node for it.
Signed-off-by: Samuel Holland
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git
All IRQs that can be used to wake up the system must be routed through
r_intc, so they are visible to firmware while the system is suspended.
r_intc IRQ numbers are offset by 32 from the GIC IRQ numbers.
Signed-off-by: Samuel Holland
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 11 +++
1
The R_INTC in the A31 and newer sun8i/sun50i SoCs is more similar to the
original sun4i interrupt controller than the sun7i/sun9i NMI controller.
It is used for two distinct purposes:
1) To control the trigger and mask for the NMI input pin
2) To provide the interrupt input for the ARISC
We maintain a mask of wake-enabled IRQs, and enable them in hardware
during the syscore phase of suspend (once IRQs are globally turned off).
We restore the original mask (either nothing or NMI only) during resume.
This serves two purposes. First, it lets power management firmware
running on the
The Allwinner H3 SoC contains an R_INTC that is, as far as we know,
compatible with the R_INTC present in other sun8i/sun50i SoCs starting
with the A31. Since the R_INTC hardware is undocumented, introduce a new
compatible for the R_INTC variant in this SoC, in case there turns out
to be some
Allwinner sun8i/sun50i SoCs (A31 and newer) have two interrupt
controllers: GIC and R_INTC. GIC does not support wakeup, and is
inaccessible from the ARISC (power management coprocessor). R_INTC
controls the NMI pin, and provides 16-32 IRQs to the ARISC. The first 16
of these correspond 1:1 to a
All IRQs that can be used to wake up the system must be routed through
r_intc, so they are visible to firmware while the system is suspended.
r_intc IRQ numbers are offset by 32 from the GIC IRQ numbers.
Signed-off-by: Samuel Holland
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 9 ++---
1 file
This node was indented by two tabs when added instead of one.
Remove the extra tab.
Signed-off-by: Samuel Holland
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 22 ++--
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git
All IRQs that can be used to wake up the system must be routed through
r_intc, so they are visible to firmware while the system is suspended.
r_intc IRQ numbers are offset by 96 from the GIC IRQ numbers.
Signed-off-by: Samuel Holland
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 13
All IRQs that can be used to wake up the system must be routed through
r_intc, so they are visible to firmware while the system is suspended.
r_intc IRQ numbers are offset by 32 from the GIC IRQ numbers.
Signed-off-by: Samuel Holland
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 11
The A83T SoC contains a message box that can be used to send messages
and interrupts back and forth between the ARM application CPUs and the
ARISC coprocessor. Add a device tree node for it.
Tested-by: Ondrej Jirman
Signed-off-by: Samuel Holland
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 10
This series adds support for the "hardware message box" in sun8i, sun9i,
and sun50i SoCs, used for communication with the ARISC management
processor (the platform's equivalent of the ARM SCP). The end goal is to
use the arm_scpi driver as a client, communicating with firmware running
on the ARISC
The H6 SoC contains a message box that can be used to send messages and
interrupts back and forth between the ARM application CPUs and the ARISC
coprocessor. Add a device tree node for it.
Signed-off-by: Samuel Holland
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 10 ++
1 file
The H3 and H5 SoCs contain a message box that can be used to send
messages and interrupts back and forth between the ARM application CPUs
and the ARISC coprocessor. Add a device tree node for it.
Signed-off-by: Samuel Holland
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 10 ++
1 file
Allwinner sun6i, sun8i, sun9i, and sun50i SoCs contain a hardware
message box used for communication between the ARM CPUs and the ARISC
management coprocessor. This mailbox contains 8 unidirectional
4-message FIFOs.
Add a driver for it, so it can be used for SCPI or other communication
protocols.
This mailbox hardware is present in Allwinner sun6i, sun8i, sun9i, and
sun50i SoCs. Add a device tree binding for it.
Signed-off-by: Samuel Holland
---
.../mailbox/allwinner,sun6i-a31-msgbox.yaml | 80 +++
1 file changed, 80 insertions(+)
create mode 100644
The A64 SoC contains a message box that can be used to send messages and
interrupts back and forth between the ARM application CPUs and the ARISC
coprocessor. Add a device tree node for it.
Signed-off-by: Samuel Holland
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 10 ++
1 file
On Mon, Jan 13, 2020 at 11:53 AM Samuel Holland wrote:
>
> AXP803/AXP813 have a flag that enables/disables the AC power supply
> input. This flag does not affect the status bits in PWR_INPUT_STATUS.
> Its effect can be verified by checking the battery charge/discharge
> state (bit 2 of
On Mon, Jan 13, 2020 at 11:53 AM Samuel Holland wrote:
>
> AXP803/AXP813 have a flag that enables/disables the USB power supply
> input. Allow control of this flag via the ONLINE property on those
> variants.
>
> It may be necessary to offline the USB power supply input when using
> the USB port
Quick question: can I share an interrupt pin across several peripherals in just
device tree?
Background: I am trying to design a V3s board (for giggles,) but I have exactly
one interrupt-able pin left. I have several peripherals that may generate
interrupt, thankfully all as open drain
Hi @lex,
On Sat, 11 Jan 2020 at 15:45, @lex wrote:
> Here is a workaround that seems to be working so far for the kernel 5.3
> and 5.4.
>
Ok great,
So If you test the patch on linux-next could you add your Tested-by tag on
this patch ?
https://patchwork.kernel.org/patch/11326439/
Regards,
On 11/01/2020 17:26, Maxime Ripard wrote:
Hi Maxime,
> On Wed, Jan 08, 2020 at 10:10:05AM +, Andre Przywara wrote:
>> The Allwinner H6 SoC contains two SPI controllers similar to the H3/A64,
>> but with the added capability of 3-wire and 4-wire operation modes.
>> For now the driver does not
38 matches
Mail list logo
