On 25/10/2016 12:45, Marc Zyngier wrote:
> On 25/10/16 09:36, Mason wrote:
>> On 25/10/2016 10:29, Sebastian Frias wrote:
>>
>>> On 10/24/2016 06:55 PM, Thomas Gleixner wrote:
>>>
On Mon, 24 Oct 2016, Mason wrote:
> For the record, setting the IRQ_DISABLE_UNLAZY flag for this device
>
On Tue, 25 Oct 2016, Mason wrote:
> Is the irq_mask() call-back exposed via some module-visible API?
No. And there is no reason to do so.
Thanks,
tglx
On 25/10/16 09:36, Mason wrote:
> On 25/10/2016 10:29, Sebastian Frias wrote:
>
>> On 10/24/2016 06:55 PM, Thomas Gleixner wrote:
>>
>>> On Mon, 24 Oct 2016, Mason wrote:
>>>
For the record, setting the IRQ_DISABLE_UNLAZY flag for this device
makes the system lock-up disappear.
>>>
>>> T
On Tue, 25 Oct 2016, Sebastian Frias wrote:
> On 10/24/2016 06:55 PM, Thomas Gleixner wrote:
> > On Mon, 24 Oct 2016, Mason wrote:
> >>
> >> For the record, setting the IRQ_DISABLE_UNLAZY flag for this device
> >> makes the system lock-up disappear.
> >
> > The way how lazy irq disabling works is:
Hi Thomas,
On 10/24/2016 06:55 PM, Thomas Gleixner wrote:
> On Mon, 24 Oct 2016, Mason wrote:
>>
>> For the record, setting the IRQ_DISABLE_UNLAZY flag for this device
>> makes the system lock-up disappear.
>
> The way how lazy irq disabling works is:
>
> 1) Interrupt is marked disabled in softw
On 25/10/2016 10:29, Sebastian Frias wrote:
> On 10/24/2016 06:55 PM, Thomas Gleixner wrote:
>
>> On Mon, 24 Oct 2016, Mason wrote:
>>
>>> For the record, setting the IRQ_DISABLE_UNLAZY flag for this device
>>> makes the system lock-up disappear.
>>
>> The way how lazy irq disabling works is:
>>
>
On Mon, 24 Oct 2016, Mason wrote:
>
> For the record, setting the IRQ_DISABLE_UNLAZY flag for this device
> makes the system lock-up disappear.
The way how lazy irq disabling works is:
1) Interrupt is marked disabled in software, but the hardware is not masked
2) If the interrupt fires befor th
On 23/10/2016 01:10, Mason wrote:
> Maybe the fact that disable_irq locks the system up is an orthogonal
> issue that needs to be fixed anyway.
disable_irq_nosync() eventually calls irq_disable()
void irq_disable(struct irq_desc *desc)
{
irq_state_set_disabled(desc);
if (desc->ir
On 23/10/16 00:10, Mason wrote:
> On 22/10/2016 13:37, Marc Zyngier wrote:
>
>> Mason wrote:
>>
>>> In my mental picture of interrupts (which is obviously so
>>> incomplete as to be wrong) interrupts are a way for hardware
>>> to tell the CPU that they urgently need the CPU's attention.
>>
>> That
On 22/10/2016 13:37, Marc Zyngier wrote:
> Mason wrote:
>
>> In my mental picture of interrupts (which is obviously so
>> incomplete as to be wrong) interrupts are a way for hardware
>> to tell the CPU that they urgently need the CPU's attention.
>
> That's how the CPU interprets it, but this is
On Fri, 21 Oct 2016 22:27:23 +0200
Mason wrote:
> On 21/10/2016 21:49, Thomas Gleixner wrote:
> > On Fri, 21 Oct 2016, Mason wrote:
> >> On 21/10/2016 21:14, Marc Zyngier wrote:
> >>> If connecting a device that signals its interrupt as level low to an
> >>> input line configured as level hig
On 21/10/2016 21:49, Thomas Gleixner wrote:
> On Fri, 21 Oct 2016, Mason wrote:
>> On 21/10/2016 21:14, Marc Zyngier wrote:
>>> If connecting a device that signals its interrupt as level low to an
>>> input line configured as level high doesn't strike you as a major
>>> issue, nothing will. At that
On Fri, 21 Oct 2016, Mason wrote:
> On 21/10/2016 21:14, Marc Zyngier wrote:
> > If connecting a device that signals its interrupt as level low to an
> > input line configured as level high doesn't strike you as a major
> > issue, nothing will. At that point, you can put anything you want in
> > yo
On 21/10/2016 21:14, Marc Zyngier wrote:
> Mason wrote:
>
>> On 21/10/2016 19:46, Marc Zyngier wrote:
>>
>>> On 21/10/16 17:37, Mason wrote:
>>>
On my platform, one HW block pulls the interrupt line high
as long as it remains idle, and low when it is busy.
The device tree no
On Fri, 21 Oct 2016 20:39:41 +0200
Mason wrote:
> On 21/10/2016 19:46, Marc Zyngier wrote:
>
> > On 21/10/16 17:37, Mason wrote:
> >
> >> On my platform, one HW block pulls the interrupt line high
> >> as long as it remains idle, and low when it is busy.
> >>
> >> The device tree node is:
> >>
On 21/10/2016 19:46, Marc Zyngier wrote:
> On 21/10/16 17:37, Mason wrote:
>
>> On my platform, one HW block pulls the interrupt line high
>> as long as it remains idle, and low when it is busy.
>>
>> The device tree node is:
>>
>> test@2 {
>> compatible = "ve
On 21/10/16 17:37, Mason wrote:
> Hello,
>
> On my platform, one HW block pulls the interrupt line high
> as long as it remains idle, and low when it is busy.
>
> The device tree node is:
>
> test@2 {
> compatible = "vendor,testme";
>
Hello,
On my platform, one HW block pulls the interrupt line high
as long as it remains idle, and low when it is busy.
The device tree node is:
test@2 {
compatible = "vendor,testme";
interrupts = <23 IRQ_TYPE_LEVEL_HIGH>;
18 matches
Mail list logo
