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
> 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.
> Allocating all interrupts and creating mappings upfront is a waste of
>
On Tue, Apr 13, 2021 at 05:09:53PM +1200, 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
e 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 cares about being able to
stash the interrupt in vcpu->arch.interrupt.injected. It is indeed
w
On 12/04/21 23:43, Sean Christopherson wrote:
where kvm_arch_interrupt_allowed() checks EFLAGS.IF (and an edge case related to
nested virtualization). KVM also captures EFLAGS.IF in vcpu->run->if_flag.
For whatever reason, QEMU checks both vcpu->run flags before injecting an IRQ,
maybe to handle
ge-podge of conditions, hacked together to get something that
> > > more or less works. But what is actually needed is much simpler;
> > > in both cases the fundamental question is, do we have a place to stash
> > > an interrupt if userspace does KVM_INTERRUPT?
> > &
On 13.04.2021 10:16, Artur Petrosyan wrote:
If core doesn't support hibernation or partial power
down power saving options, power can still be saved
using clock gating on all the clocks.
- Added entering clock gating state from USB_SUSPEND
interrupt.
Signed-off-by: Artur Petrosyan
rq_create_mapping(priv->irq_domain, p);
> > >
> > > This seems odd. Why aren't the MDIO IRQs allocated on demand as
> > > endpoint attached to this interrupt controller are being probed
> > > individually? In general, doing this allocation upfront is
Added clock gating exit flow from session
request interrupt handler according programming guide.
Signed-off-by: Artur Petrosyan
---
Changes in v2:
- None
drivers/usb/dwc2/core_intr.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dwc2
Added exit from clock gating mode when wakeup interrupt
is detected. To exit from the clock gating
in device mode "dwc2_gadget_exit_clock_gating()"
function is used with rem_wakeup parameter 0. To exit
clock gating in host mode "dwc2_host_exit_clock_gating()"
with rem_wakeup
If core doesn't support hibernation or partial power
down power saving options, power can still be saved
using clock gating on all the clocks.
- Added entering clock gating state from USB_SUSPEND
interrupt.
Signed-off-by: Artur Petrosyan
Acked-by: Minas Harutyunyan
---
drivers/usb
Added exit from clock gating mode when wakeup interrupt
is detected. To exit from the clock gating
in device mode "dwc2_gadget_exit_clock_gating()"
function is used with rem_wakeup parameter 0. To exit
clock gating in host mode "dwc2_host_exit_clock_gating()"
with rem_wakeup
If core doesn't support hibernation or partial power
down power saving options, power can still be saved
using clock gating on all the clocks.
- Added entering clock gating state from USB_SUSPEND
interrupt.
Signed-off-by: Artur Petrosyan
Acked-by: Minas Harutyunyan
---
drivers/usb
Added clock gating exit flow from session
request interrupt handler according programming guide.
Signed-off-by: Artur Petrosyan
---
drivers/usb/dwc2/core_intr.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb
With the implementation of napi-tx in virtio driver, we clean tx
descriptors from rx napi handler, for the purpose of reducing tx
complete interrupts. But this introduces a race where tx complete
interrupt has been raised, but the handler finds there is no work to do
because we have done the work
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
if (BIT(p) & ds->phys_mii_mask) {
> > > + unsigned int irq;
> > > +
> > > + irq = irq_create_mapping(priv->irq_domain, p);
> >
> > This seems odd. Why aren't the MDIO IRQs allocated on demand as
> > endpoint at
Fix interrupt cells in DT AB8500/AB8505 source files. The
compiled DTB files will stay the same.
Signed-off-by: Sebastian Reichel
---
arch/arm/boot/dts/ste-ab8500.dtsi | 26 +-
arch/arm/boot/dts/ste-ab8505.dtsi | 22 +++---
2 files changed, 24 insertions
On Sat, Apr 10, 2021 at 11:15 PM Wolfram Sang wrote:
>
> On Mon, Mar 29, 2021 at 02:52:06PM +1300, 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
> > a
orks. But what is actually needed is much simpler;
> > in both cases the fundamental question is, do we have a place to stash
> > an interrupt if userspace does KVM_INTERRUPT?
> >
> > In userspace irqchip mode, that is !vcpu->arch.interrupt.injected.
> > Curr
Hi Chris,
> Yep I plan on being around. I've got access to a couple of designs with
> P2040 and T2081 so hopefully that's sufficient to deal with any
> regressions. One issue is a lack of different i2c devices (the systems
> we have tend to use the same devices) but hopefully any reports of
>
On Mon, Apr 12, 2021 at 09:21:12AM +0100, Marc Zyngier wrote:
> On Mon, 12 Apr 2021 04:42:35 +0100,
> DENG Qingfang wrote:
> >
> > Add support for MT7530 interrupt controller to handle internal PHYs.
> > In order to assign an IRQ number to each PHY, the registration of M
On Mon Apr 12 2021, DENG Qingfang wrote:
> Add device tree binding to support MT7530 interrupt controller.
>
> Signed-off-by: DENG Qingfang
> Reviewed-by: Andrew Lunn
> ---
> RFC v3 -> RFC v4:
> - Add #interrupt-cells property.
>
> Documentation/devicetree/b
1 - 100 of 7494 matches
Mail list logo
