On Mon, Dec 11, 2017 at 08:33:33AM +0000, Anand, Jerome wrote: > > > > -----Original Message----- > > From: Thomas Gleixner [mailto:[email protected]] > > Sent: Saturday, December 9, 2017 4:22 AM > > To: Ville Syrjälä <[email protected]> > > Cc: Chen, Augustine <[email protected]>; intel- > > [email protected]; [email protected]; Anand, Jerome > > <[email protected]>; Bossart, Pierre-louis <pierre- > > [email protected]>; [email protected]; Ingo Molnar <[email protected]>; > > H. Peter Anvin <[email protected]>; Jiang Liu <[email protected]>; > > Juergen > > Gross <[email protected]>; Dou Liyang <[email protected]>; linux- > > [email protected] > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Remove unused IRQ chip data of > > HDMI LPE audio > > > > On Fri, 8 Dec 2017, Ville Syrjälä wrote: > > > > > On Fri, Dec 08, 2017 at 05:33:23PM +0800, Augustine.Chen wrote: > > > > The chip data of HDMI LPE audio is set to drm_i915_private which is > > > > not consistent with the expectation by x86 APIC driver. > > > > > > Hmm. Why is the apic code looking at data for an irq chip it hasn't > > > created? > > > > > apic code expects an irq domain to be place as generic approach. > > > > Do we need something like > > > - dev_priv->lpe_audio.irq = irq_alloc_desc(0); > > > + dev_priv->lpe_audio.irq = irq_alloc_desc(-1); > > > > #define irq_alloc_desc(node) > > > > So instead of handing in node 0 you hand in node -1 which is NUMA_NO_NODE > >
Ah. I misread the macros. So we already pass irq=-1. > > Agree - am not sure whether it will make any difference. > > > > That *looks* more correct to me based on a cursory glance at the x86 > > > code, but I didn't trawl very deeply. > > > > The x86 core cares not at all about interrupt chips which are created in a > > driver > > and not connected to an actual apic/ioapic/msi interrupt. This interrupt > > chip is > > its own thing as we have others in GPIO etc. > > > > > > In the case of not enabling CONFIG_CPUMASK_OFFSTACK, this would > > > > cause kernel panic while doing CPU hotplug. > > > > And why so? Surely not because you set irq_chip_data. That's really no > > explanation at all. > > > > Ideally, I feel there needs to be an irq domain for mapping the irq numbers > with hwirq. > It is not created as part of the hdmi lpe audio bridge. > Since the logic to mask/unmask lpe audio interrupts is removed, there is no > need of the > Chip data or creation of the domain now. There is no need right now. But there might be a need in the future. LPE audio isn't even the only piece of hardware whose irq goes through the i915 display engine (there's also the ISP and VED). So I would much prefer a proper solution instead of sweeping the problem under the rug. -- Ville Syrjälä Intel OTC
