Date: Tue, 1 Nov 2016 16:44:00 +0200
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Jon Hunter <jonathanh@nvidia.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>,
        Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org
Subject: Re: BUG? genirq: irq 14 uses trigger mode 8; requested 0
Message-ID: <20161101144400.GE1436@lahna.fi.intel.com>
References: <20161101130231.GD1436@lahna.fi.intel.com>
 <57b67069-8fc0-800f-b869-1eec3d64111f@nvidia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <57b67069-8fc0-800f-b869-1eec3d64111f@nvidia.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
User-Agent: Mutt/1.7.1 (2016-10-04)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2513
Lines: 62

On Tue, Nov 01, 2016 at 02:24:38PM +0000, Jon Hunter wrote:
> Hi Mika,
> 
> On 01/11/16 13:02, Mika Westerberg wrote:
> > Hi,
> > 
> > I started seeing following messages on Intel Broxton when the
> > pinctrl/GPIO driver [1] loads:
> > 
> >   [    0.645786] genirq: irq 14 uses trigger mode 8; requested 0
> > 
> > The driver shares interrupt with other GPIO "communities" or banks so it
> > uses request_irq() instead of irq_set_chained_handler_and_data(). The
> > driver does not specify IRQ flags as those come from ACPI resources.
> > 
> > This started happen after commit 4b357daed698 ("genirq: Look-up trigger
> > type if not specified by caller").
> > 
> > I think this is what happens:
> > 
> >   1. ACPI platform sets up the interrupt according what is in the _CRS
> >   of the GPIO device. This ends up setting trigger type for irq_data of
> >   the irq.
> > 
> >   2. First GPIO device is found and the driver calls request_irq() which
> >   calls __setup_irq() where shared == 0.
> > 
> >   3. Since new->flags is read back from irq_data we call __irq_set_trigger()
> >   passing the flags.
> > 
> >   4. The parent IRQ chip, IO-APIC, does not have ->irq_set_type callback
> >   so __irq_set_trigger() never calls irq_settings_set_trigger_mask() for
> >   the desciptor.
> >
> >   5. The second GPIO device is found and this time shared == 1 so we
> >   end up comparing nmsk with omsk where nmsk was read from irq_data
> >   and omsk is read using irq_settings_get_trigger_mask().
> > 
> >   6. Because we never called irq_settings_set_trigger_mask() for the
> >   descriptor, omsk is 0 and we print out a warning:
> > 
> >   [    0.645786] genirq: irq 14 uses trigger mode 8; requested 0
> > 
> > If I revert commit 4b357daed698 the warning goes away.
> > 
> > Do you have any ideas how to get rid of the warning properly?
> 
> May be I am misunderstanding something here, but if the parent does not have
> a ->irq_set_type callback, then it would seem that the type for the
> interrupt should be not specified/set in the ACPI _CRS for the GPIO device,
> right?

Not sure.

Why the parent driver (IO-APIC) does not have ->irq_set_type callback is
beyond me. I guess it might have something to do with the IRQ hierarchy
domains it is part of.

When the ACPI core parses _CRS for the GPIO device it calls
acpi_register_gsi() with the triggering flags from _CRS and that ends up
calling acpi_register_gsi_ioapic() that programs the hardware
accordingly. So we definitely need to have the type in _CRS.