The BCM590XX supports up to 128 internal interrupts, which are used by
various parts of the chip. Add regmap_irq-based interrupt handling and
helper functions to allow subdevice drivers to easily use the interrupts.
Signed-off-by: Artur Weber
---
This patch is a prerequisite for future subdevice
On Thu, 12 Jun 2025 10:39:31 +0800, Lijuan Gao wrote:
> The Ready and Handover interrupt numbers for sa8775p are incorrect. The
> correct interrupt numbers are as follows. So they need to be corrected.
>
> Fatal interrupt - 0
> Ready interrupt - 1
> Handover interrupt - 2
IOMMU and remapping HW together
GIC fully integrates it into the interrupt controller architecture.
Jason
On Thu, 12 Jun 2025 10:39:31 +0800, Lijuan Gao wrote:
> The Ready and Handover interrupt numbers for sa8775p are incorrect. The
> correct interrupt numbers are as follows. So they need to be corrected.
>
> Fatal interrupt - 0
> Ready interrupt - 1
> Handover interrupt - 2
gt; > >
> > > > Is a paravirtualized IOMMU with interrupt remapping something that makes
> > > > sense?
> > >
> > > IMHO linking interrupt remapping to the iommu is a poor design,
> > > interrupt routing belongs in the irq subsystem, not
On Tue, Jun 17, 2025 at 03:44:20PM -0400, Michael S. Tsirkin wrote:
> On Mon, Jun 16, 2025 at 10:20:31AM -0300, Jason Gunthorpe wrote:
> > On Sun, Jun 15, 2025 at 02:47:15PM -0400, Demi Marie Obenour wrote:
> >
> > > Is a paravirtualized IOMMU with interrupt remapp
On Sun, Jun 15, 2025 at 02:47:15PM -0400, Demi Marie Obenour wrote:
> Virtio-IOMMU interrupt remapping turned out to be much harder than I
> realized. The main problem is that interrupt remapping is set up
> very early in boot. In fact, Linux calls the interrupt remapping probe
> f
On Mon, Jun 16, 2025 at 10:20:31AM -0300, Jason Gunthorpe wrote:
> On Sun, Jun 15, 2025 at 02:47:15PM -0400, Demi Marie Obenour wrote:
>
> > Is a paravirtualized IOMMU with interrupt remapping something that makes
> > sense?
>
> IMHO linking interrupt remapping to th
On Mon, Jun 16, 2025 at 12:53:40PM -0400, Demi Marie Obenour wrote:
> > AFAIK hyperv shows how to build something like this.
> Would this need KVM patches? I'm concerned that implementing this
> in userspace would interact badly with the irqfd fast path.
I don't know. I think you get the same is
On 6/16/25 09:20, Jason Gunthorpe wrote:
> On Sun, Jun 15, 2025 at 02:47:15PM -0400, Demi Marie Obenour wrote:
>
>> Is a paravirtualized IOMMU with interrupt remapping something that makes
>> sense?
>
> IMHO linking interrupt remapping to the iommu is a poor design,
>
[+Eric]
On Sat, Jun 14, 2025 at 10:11:52AM +0200, Alyssa Ross wrote:
> Demi Marie Obenour writes:
>
> > On 6/13/25 14:13, Jean-Philippe Brucker wrote:
> >> Hi,
> >>
> >> On Fri, Jun 13, 2025 at 01:08:07PM -0400, Demi Marie Obenour wrote:
> >>&
On Sun, Jun 15, 2025 at 02:47:15PM -0400, Demi Marie Obenour wrote:
> Is a paravirtualized IOMMU with interrupt remapping something that makes
> sense?
IMHO linking interrupt remapping to the iommu is a poor design,
interrupt routing belongs in the irq subsystem, not in the iommu.
The fa
Virtio-IOMMU interrupt remapping turned out to be much harder than I
realized. The main problem is that interrupt remapping is set up
very early in boot. In fact, Linux calls the interrupt remapping probe
function from the APIC initialization code: x86_64_probe_apic ->
enable_IR_x2a
Demi Marie Obenour writes:
> On 6/13/25 14:13, Jean-Philippe Brucker wrote:
>> Hi,
>>
>> On Fri, Jun 13, 2025 at 01:08:07PM -0400, Demi Marie Obenour wrote:
>>> I’m working on virtio-IOMMU interrupt remapping for Spectrum OS [1],
>>> and am running into a
On 6/13/25 14:13, Jean-Philippe Brucker wrote:
> Hi,
>
> On Fri, Jun 13, 2025 at 01:08:07PM -0400, Demi Marie Obenour wrote:
>> I’m working on virtio-IOMMU interrupt remapping for Spectrum OS [1],
>> and am running into a problem. All of the current interrupt remapping
>&
Hi,
On Fri, Jun 13, 2025 at 01:08:07PM -0400, Demi Marie Obenour wrote:
> I’m working on virtio-IOMMU interrupt remapping for Spectrum OS [1],
> and am running into a problem. All of the current interrupt remapping
> drivers use __init code during initialization, and I’m not sure how t
I’m working on virtio-IOMMU interrupt remapping for Spectrum OS [1],
and am running into a problem. All of the current interrupt remapping
drivers use __init code during initialization, and I’m not sure how to
plumb the struct virtio_device * into the IOMMU initialization code.
What is the
On Thu, Jun 12, 2025 at 10:39:32AM +0800, Lijuan Gao wrote:
> Correct the interrupt number of ready and handover in the DTS example.
>
> Fixes: af5da7b0944c ("dt-bindings: remoteproc: qcom,sa8775p-pas: Document the
> SA8775p ADSP, CDSP and GPDSP")
>
On 6/12/25 4:39 AM, Lijuan Gao wrote:
> Fix the incorrect IRQ numbers for ready and handover on sa8775p.
> The correct values are as follows:
>
> Fatal interrupt - 0
> Ready interrupt - 1
> Handover interrupt - 2
> Stop acknowledge interrupt - 3
>
> Fixes: df54d
Correct the interrupt number of ready and handover in the DTS example.
Fixes: af5da7b0944c ("dt-bindings: remoteproc: qcom,sa8775p-pas: Document the
SA8775p ADSP, CDSP and GPDSP")
Signed-off-by: Lijuan Gao
---
Documentation/devicetree/bindings/remoteproc/qcom,sa8775p-pas.yaml | 2
The Ready and Handover interrupt numbers for sa8775p are incorrect. The
correct interrupt numbers are as follows. So they need to be corrected.
Fatal interrupt - 0
Ready interrupt - 1
Handover interrupt - 2
Stop acknowledge interrupt - 3
Signed-off-by: Lijuan Gao
---
Lijuan Gao (2):
dt
Fix the incorrect IRQ numbers for ready and handover on sa8775p.
The correct values are as follows:
Fatal interrupt - 0
Ready interrupt - 1
Handover interrupt - 2
Stop acknowledge interrupt - 3
Fixes: df54dcb34ff2e ("arm64: dts: qcom: sa8775p: add ADSP, CDSP and GPDSP
nodes")
Sig
Dynamic Capacity Devices (DCD) require event interrupts to process
memory addition or removal. BIOS may have control over non-DCD event
processing. DCD interrupt configuration needs to be separate from
memory event interrupt configuration.
Factor out event interrupt setting validation
Hello,
> This series solves some issues about global "irq_type" that is used for
> indicating the current type for users.
>
> In addition, avoid an unexpected warning that occur due to interrupts
> remaining after displaying an error caused by devm_request_irq().
>
> Patch 1 includes adding GET_
Add GET_IRQTYPE API checks to each interrupt test.
And change pci_ep_ioctl() to get the appropriate return value from
ioctl().
Suggested-by: Manivannan Sadhasivam
Signed-off-by: Kunihiko Hayashi
---
.../selftests/pci_endpoint/pci_endpoint_test.c| 11 ++-
1 file changed, 10
ot;devm" version of IRQ functions (patch 5/5)
Changes since v1:
- Divide original patch into two
- Add an error message example
- Add "pcitest" display example
- Add a patch to fix an interrupt remaining issue
Kunihiko Hayashi (6):
selftests: pci_endpoint: Add GET_IRQTYPE checks
>>> Introduced an interrupt handler for the virtio crypto device, as its
>>> queue usage differs from that of network devices. While virtio network
>>> device receives packets only on even-indexed queues, virtio crypto
>>> device utilize all available queues fo
>> Introduced an interrupt handler for the virtio crypto device, as its
>> queue usage differs from that of network devices. While virtio network
>> device receives packets only on even-indexed queues, virtio crypto
>> device utilize all available queues for processing data
On Thu, Nov 21, 2024 at 9:43 PM Shijith Thotton wrote:
>
> Introduced an interrupt handler for the virtio crypto device, as its
> queue usage differs from that of network devices. While virtio network
> device receives packets only on even-indexed queues, virtio crypto
> dev
Introduced an interrupt handler for the virtio crypto device, as its
queue usage differs from that of network devices. While virtio network
device receives packets only on even-indexed queues, virtio crypto
device utilize all available queues for processing data.
Signed-off-by: Shijith Thotton
Introduced an interrupt handler for the virtio crypto device, as its
queue usage differs from that of network devices. While virtio network
device receives packets only on even-indexed queues, virtio crypto
device utilize all available queues for processing data.
Signed-off-by: Shijith Thotton
On Tue, 16 Jul 2024 23:08:32 +0530, Sudeepgoud Patil wrote:
> This commit enhances the smp2p driver by adding support for using the device
> name in interrupt descriptions and introducing tracepoint functionality.
> These improvements facilitate more effective debugging of smp2
This commit enhances the smp2p driver by adding support for using the device
name in interrupt descriptions and introducing tracepoint functionality.
These improvements facilitate more effective debugging of smp2p-related issues.
The devname patch, along with the callback to print the irq chip
From: Chris Lew
When using /proc/interrupts to collect statistics on smp2p interrupt
counts, it is hard to distinguish the different instances of smp2p from
each other. For example to debug a processor boot issue, the ready and
handover interrupts are checked for sanity to ensure the firmware
On Thu, 27 Jun 2024 16:18:29 +0530, Sudeepgoud Patil wrote:
> This commit enhances the smp2p driver by adding support for using the device
> name in interrupt descriptions and introducing tracepoint functionality.
> These improvements facilitate more effective debugging of smp2
On Thu, Jun 27, 2024 at 04:18:30PM GMT, Sudeepgoud Patil wrote:
> From: Chris Lew
>
> When using /proc/interrupts to collect statistics on smp2p interrupt
> counts, it is hard to distinguish the different instances of smp2p from
> each other. For example to debug a processor
On 6/27/2024 4:18 PM, Sudeepgoud Patil wrote:
From: Chris Lew
When using /proc/interrupts to collect statistics on smp2p interrupt
counts, it is hard to distinguish the different instances of smp2p from
each other. For example to debug a processor boot issue, the ready and
handover
On 27.06.2024 12:48 PM, Sudeepgoud Patil wrote:
> From: Chris Lew
>
> When using /proc/interrupts to collect statistics on smp2p interrupt
> counts, it is hard to distinguish the different instances of smp2p from
> each other. For example to debug a processor boot issue, the ready
From: Chris Lew
When using /proc/interrupts to collect statistics on smp2p interrupt
counts, it is hard to distinguish the different instances of smp2p from
each other. For example to debug a processor boot issue, the ready and
handover interrupts are checked for sanity to ensure the firmware
This commit enhances the smp2p driver by adding support for using the device
name in interrupt descriptions and introducing tracepoint functionality.
These improvements facilitate more effective debugging of smp2p-related issues.
The devname patch, along with the callback to print the irq chip
On Tue, Jun 25, 2024 at 04:18:00PM +0800, Jason Wang wrote:
> > > >
> > > >
> > > >
> > > > But in conclusion ;) if you don't like my suggestion do something else
> > > > but make the APIs make sense,
> > >
> > > I don't say I don't like it:)
> > >
> > > Limiting it to virtio-net seems to be the mo
etween the virtio core and the
> > > > > > virtio driver.
> > > > > >
> > > > > > The counter is not allowed to be increased greater than one, this
> > > > > > simplifies the logic where the interrupt could be disabled
> >
> > > > config_enabled to be a integer counter. This allows the toggling of
> > > > > the config_enable to be synchronized between the virtio core and the
> > > > > virtio driver.
> > > > >
> > > > > The counter is not allowed to be increa
nable to be synchronized between the virtio core and the
> > > > virtio driver.
> > > >
> > > > The counter is not allowed to be increased greater than one, this
> > > > simplifies the logic where the interrupt could be disabled immediately
> > >
t; > > The counter is not allowed to be increased greater than one, this
> > > simplifies the logic where the interrupt could be disabled immediately
> > > without extra synchronization between driver and core.
> > >
> > > Signed-off-by: Jason Wang
> > > ---
; config_enabled to be a integer counter. This allows the toggling of
> > the config_enable to be synchronized between the virtio core and the
> > virtio driver.
> >
> > The counter is not allowed to be increased greater than one, this
> > simplifies the logic where t
enable to be synchronized between the virtio core and the
> virtio driver.
>
> The counter is not allowed to be increased greater than one, this
> simplifies the logic where the interrupt could be disabled immediately
> without extra synchronization between driver and core.
>
counter is not allowed to be increased greater than one, this
simplifies the logic where the interrupt could be disabled immediately
without extra synchronization between driver and core.
Signed-off-by: Jason Wang
---
drivers/virtio/virtio.c | 20 +---
include/linux/virtio.h | 2
On Thu, Jun 13, 2024 at 04:05:17PM +0530, Deepak Kumar Singh wrote:
>
>
> On 6/3/2024 3:07 PM, Caleb Connolly wrote:
> > Hi Deepak,
> >
> > On 03/06/2024 09:36, Deepak Kumar Singh wrote:
> > > There are certain usecases which require glink interrupt to be
On 6/3/2024 3:07 PM, Caleb Connolly wrote:
Hi Deepak,
On 03/06/2024 09:36, Deepak Kumar Singh wrote:
There are certain usecases which require glink interrupt to be
wakeup capable. For example if handset is in sleep state and
usb charger is plugged in, dsp wakes up and sends glink interrupt
On 6/3/2024 2:37 AM, Caleb Connolly wrote:
Hi Deepak,
On 03/06/2024 09:36, Deepak Kumar Singh wrote:
There are certain usecases which require glink interrupt to be
wakeup capable. For example if handset is in sleep state and
usb charger is plugged in, dsp wakes up and sends glink interrupt
Hi Deepak,
On 03/06/2024 09:36, Deepak Kumar Singh wrote:
There are certain usecases which require glink interrupt to be
wakeup capable. For example if handset is in sleep state and
usb charger is plugged in, dsp wakes up and sends glink interrupt
to host for glink pmic channel communication
There are certain usecases which require glink interrupt to be
wakeup capable. For example if handset is in sleep state and
usb charger is plugged in, dsp wakes up and sends glink interrupt
to host for glink pmic channel communication. Glink is suppose to
wakeup host processor completely for
From: "Steven Rostedt (Google)"
When the ring buffer timestamp verifier triggers, it dumps the content of
the sub-buffer. But currently it only dumps the timestamps and the offset
of the data as well as the deltas. It would be even more informative if
the event data also showed the
On Mon, 18 Dec 2023 17:01:06 -0500
Steven Rostedt wrote:
> @@ -3347,7 +3418,8 @@ static void check_buffer(struct ring_buffer_per_cpu
> *cpu_buffer,
> }
> }
> if ((full && ts > info->ts) ||
> - (!full && ts + info->delta != info->ts)) {
> + (!full && ts +
From: "Steven Rostedt (Google)"
When the ring buffer timestamp verifier triggers, it dumps the content of
the sub-buffer. But currently it only dumps the timestamps and the offset
of the data as well as the deltas. It would be even more informative if
the event data also showed the
From: "Steven Rostedt (Google)"
When the ring buffer timestamp verifier triggers, it dumps the content of
the sub-buffer. But currently it only dumps the timestamps and the offset
of the data as well as the deltas. It would be even more informative if
the event data also showed the
On Mon, 14 Aug 2023 15:21:41 +0530, MD Danish Anwar wrote:
> Add interrupts and interrupt-names protperties for PRU and RTU cores.
>
>
Applied, thanks!
[1/1] dt-bindings: remoteproc: pru: Add Interrupt property
commit: d93f191b95bec3c913978eb18c6297e797915993
Best regards,
Document DT bindings for IDT 79RC3243x Interrupt Controller.
Signed-off-by: Thomas Bogendoerfer
---
.../interrupt-controller/idt,3243x-pic.yaml | 48 +++
1 file changed, 48 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/idt,3243x
IDT 79rc3243x SoCs have rather simple interrupt controllers connected
to the MIPS CPU interrupt lines. Each of them has room for up to
32 interrupts.
Signed-off-by: Thomas Bogendoerfer
---
drivers/irqchip/Kconfig| 5 ++
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq
On Tue, Apr 20, 2021 at 06:34:59PM +0100, Marc Zyngier wrote:
> On 2021-04-20 13:34, Thomas Bogendoerfer wrote:
> > IDT 79rc3243x SoCs have rather simple interrupt controllers connected
> > to the MIPS CPU interrupt lines. Each of them has room for up to
> > 32 interrupts.
&
On 2021-04-20 13:34, Thomas Bogendoerfer wrote:
IDT 79rc3243x SoCs have rather simple interrupt controllers connected
to the MIPS CPU interrupt lines. Each of them has room for up to
32 interrupts.
Signed-off-by: Thomas Bogendoerfer
Is there a DT binding for this irqchip? The code looks fine
IDT 79rc3243x SoCs have rather simple interrupt controllers connected
to the MIPS CPU interrupt lines. Each of them has room for up to
32 interrupts.
Signed-off-by: Thomas Bogendoerfer
---
drivers/irqchip/Kconfig| 5 ++
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq
> >> !vcpu_dy_runnable(vcpu))
> >> continue;
> >> - if (READ_ONCE(vcpu->preempted) &&
> >> yield_to_kernel_mode &&
> >> - !kvm_arch_vc
continue;
+ if (READ_ONCE(vcpu->preempted) && yield_to_kernel_mode
&&
+ !kvm_arch_vcpu_in_kernel(vcpu)) {
+ /*
+* A vCPU running in userspace can get to kernel
mode via
+
Christopherson wrote:
> >>>> If false positives are a big concern, what about adding another pass to
> >>>> the loop
> >>>> and only yielding to usermode vCPUs with interrupts in the second full
> >>>> pass?
> >>>> I.e. g
usermode vCPUs with interrupts in the second full pass?
I.e. give vCPUs that are already in kernel mode priority, and only yield to
handle an interrupt if there are no vCPUs in kernel mode.
kvm_arch_dy_runnable() pulls in pv_unhalted, which seems like a good thing.
pv_unhalted won't help if y
> > and only yielding to usermode vCPUs with interrupts in the second full
> > > pass?
> > > I.e. give vCPUs that are already in kernel mode priority, and only yield
> > > to
> > > handle an interrupt if there are no vCPUs in kernel mode.
> > &g
> > I.e. give vCPUs that are already in kernel mode priority, and only yield to
> > handle an interrupt if there are no vCPUs in kernel mode.
> >
> > kvm_arch_dy_runnable() pulls in pv_unhalted, which seems like a good thing.
>
> pv_unhalted won't help if you'
interrupt if there are no vCPUs in kernel mode.
kvm_arch_dy_runnable() pulls in pv_unhalted, which seems like a good thing.
pv_unhalted won't help if you're waiting for a kernel spinlock though,
would it? Doing two passes (or looking for a "best" candidate that
prefers kernel mod
arge number
> > > of continuous PLE events because the IPI sender causes PLE events
> > > repeatedly until the receiver is scheduled while the receiver is not
> > > candidate for a boost.
> > >
> > > This patch boosts the vCPU candidiate in user mod
return -1; /* not a valid interrupt. */
diff --git a/arch/arm/mach-footbridge/ebsa285-pci.c
b/arch/arm/mach-footbridge/ebsa285-pci.c
index 6f28aaa9ca79..c3f280d08fa7 100644
--- a/arch/arm/mach-footbridge/ebsa285-pci.c
+++ b/arch/arm/mach-footbridge/ebsa285-pci.c
@@ -14,9 +14,9 @@
#include
return -1; /* not a valid interrupt. */
diff --git a/arch/arm/mach-footbridge/ebsa285-pci.c
b/arch/arm/mach-footbridge/ebsa285-pci.c
index 6f28aaa9ca79..c3f280d08fa7 100644
--- a/arch/arm/mach-footbridge/ebsa285-pci.c
+++ b/arch/arm/mach-footbridge/ebsa285-pci.c
@@ -14,9 +14,9 @@
#include
return -1; /* not a valid interrupt. */
diff --git a/arch/arm/mach-footbridge/ebsa285-pci.c
b/arch/arm/mach-footbridge/ebsa285-pci.c
index 6f28aaa9ca79..c3f280d08fa7 100644
--- a/arch/arm/mach-footbridge/ebsa285-pci.c
+++ b/arch/arm/mach-footbridge/ebsa285-pci.c
@@ -14,9 +14,9 @@
#include
tedly until the receiver is scheduled while the receiver is not
> > candidate for a boost.
> >
> > This patch boosts the vCPU candidiate in user mode which is delivery
> > interrupt. We can observe the speed of pbzip2 improves 10% in 96 vCPUs
> > VM in over-subscribe sc
On 4/16/2021 4:48 PM, Artur Petrosyan wrote:
> Squashed from Douglas Anderson's suggested commit
> "usb: dwc2: Get rid of useless error checks for
> hibernation/partial power down"
>
> - After this commit there should never be any
> case where dwc2_enter_partial_power_down() and
> dwc2_enter_hib
nning in user mode. It can lead to a large number
of continuous PLE events because the IPI sender causes PLE events
repeatedly until the receiver is scheduled while the receiver is not
candidate for a boost.
This patch boosts the vCPU candidiate in user mode which is delivery
interrupt. We can observ
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Wed, 14 Apr 2021 22:09:20 +0300 you wrote:
> Tx queue cleanup happens in interrupt handler on same core as rx queue
> processing. Both can take considerable amount of processing in high
> packet-per-second
very recently neither disabled interrupts
> > in the device or used IRQF_ONESHOT. This would lead to a deadlock if an
> > interrupt comes in while the threaded receive handler is running under
> > the port lock.
> >
> Greg told me there was a patch fixed this case. In case hard ir
doesn't disable interrupt in the device (it just disables all interrupts
in the threaded handler). The rest stands as is.
> in the device or used IRQF_ONESHOT. This would lead to a deadlock if an
> interrupt comes in while the threaded receive handler is running under
> the port
When DMA is enabled the receive handler runs in a threaded handler, but
the primary handler up until very recently neither disabled interrupts
in the device or used IRQF_ONESHOT. This would lead to a deadlock if an
interrupt comes in while the threaded receive handler is running under
the port
The uart_unlock_and_check_sysrq() helper can be used to defer processing
of sysrq until the interrupt handler has released the port lock and is
about to return.
Since commit 81e2073c175b ("genirq: Disable interrupts for force
threaded handlers") interrupt handlers that are not
Squashed from Douglas Anderson's suggested commit
"usb: dwc2: Get rid of useless error checks for
hibernation/partial power down"
- After this commit there should never be any
case where dwc2_enter_partial_power_down() and
dwc2_enter_hibernation() are called when
'params.power_down' is not correc
to a large number
of continuous PLE events because the IPI sender causes PLE events
repeatedly until the receiver is scheduled while the receiver is not
candidate for a boost.
This patch boosts the vCPU candidiate in user mode which is delivery
interrupt. We can observe the speed of pbzip2 improv
From: Marek Behún
commit a26c56ae67fa9fbb45a8a232dcd7ebaa7af16086 upstream.
Use the `marvell,reg-init` DT property to configure the LED[2]/INTn pin
of the Marvell 88E1514 ethernet PHY on Turris Omnia into interrupt mode.
Without this the pin is by default in LED[2] mode, and the Marvell PHY
e if (vcpu->arch.interrupt.injected) {
> >> static_call(kvm_x86_set_irq)(vcpu);
> >> can_inject = false;
> >
> > And comes here and vcpu->arch.interrupt.injected is true for there is
> > an interrupt queued by
On 4/9/21 7:56 PM, Radhey Shyam Pandey wrote:
Program IRQDelay for AXI DMA. The interrupt timeout mechanism causes
the DMA engine to generate an interrupt after the delay time period
has expired. It enables dmaengine to respond in real-time even though
interrupt coalescing is configured. It also
s here and vcpu->arch.interrupt.injected is true for there is
an interrupt queued by KVM_INTERRUPT for pure user irqchip. It then does
the injection of the interrupt without checking the EFLAGS.IF.
Ok, understood now. Yeah, that could be a problem for userspace irqchip
so we shoul
Squashed from Douglas Anderson's suggested commit
"usb: dwc2: Get rid of useless error checks for
hibernation/partial power down"
- After this commit there should never be any
case where dwc2_enter_partial_power_down() and
dwc2_enter_hibernation() are called when
'params.power_down' is not correc
> >>> stash the IRQ when EFLAGS.IF=0, but inject_pending_event() seams to ignore
> >>> EFLAGS.IF and queues the IRQ to the guest directly in the first branch
> >>> of using "kvm_x86_ops.set_irq(vcpu)".
> >>
> >> This is only true for pure
The fsl-i2c controller will generate an interrupt after every byte
transferred. Make use of this interrupt to drive a state machine which
allows the next part of a transfer to happen as soon as the interrupt is
received. This is particularly helpful with SMBUS devices like the LM81
which will
On Sat, Apr 10, 2021 at 01:22:18AM +0900, Kunihiko Hayashi wrote:
> This patch adds misc interrupt handler to detect and invoke PME/AER event.
>
> In UniPhier PCIe controller, PME/AER signals are assigned to the same
> signal as MSI by the internal logic. These signals should be detec
Tx queue cleanup happens in interrupt handler on same core as rx queue
processing. Both can take considerable amount of processing in high
packet-per-second scenarios.
Sending big amounts of packets can stall the rx processing which is
unfair and also can lead to out-of-memory condition since
directly in the first branch
of using "kvm_x86_ops.set_irq(vcpu)".
This is only true for pure-userspace irqchip. For split-irqchip, in
which case the "place to stash" the interrupt is
vcpu->arch.pending_external_vector.
For pure-userspace irqchip, KVM_INTERRUPT only ca
ctly in the first branch
> > of using "kvm_x86_ops.set_irq(vcpu)".
>
> This is only true for pure-userspace irqchip. For split-irqchip, in
> which case the "place to stash" the interrupt is
> vcpu->arch.pending_external_vector.
>
> For pure-user
On 14/04/21 10:28 am, Chris Packham wrote:
>
> On 14/04/21 1:52 am, Andy Shevchenko wrote:
>> On Tue, Apr 13, 2021 at 8:10 AM Chris Packham
>> wrote:
>>> The fsl-i2c controller will generate an interrupt after every byte
>>> transferred. Make use of this inte
On 14/04/21 1:52 am, Andy Shevchenko wrote:
> On Tue, Apr 13, 2021 at 8:10 AM Chris Packham
> wrote:
>> The fsl-i2c controller will generate an interrupt after every byte
>> transferred. Make use of this interrupt to drive a state machine which
>> allows the next part of
Hi Bjorn,
On 4/7/21 10:56 AM, Suman Anna wrote:
> Hi All,
>
> The following is a minor revised version of the series [1] that includes fixes
> for various different issues associated with the PRU firmware event/interrupt
> mapping configuration logic. Please see the v1 cover
On Tue, Apr 13, 2021 at 02:52:59PM +0200, Andrew Lunn wrote:
> > I guess this is depends whether the most usual case is to have all
> > these interrupts being actively in use or not. Most interrupts only
> > use a limited portion of their interrupt space at any given time.
On Tue, Apr 13, 2021 at 8:10 AM Chris Packham
wrote:
>
> The fsl-i2c controller will generate an interrupt after every byte
> transferred. Make use of this interrupt to drive a state machine which
> allows the next part of a transfer to happen as soon as the interrupt is
> re
1 - 100 of 7516 matches
Mail list logo
