From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751577AbdLLJpO (ORCPT ); Tue, 12 Dec 2017 04:45:14 -0500 Received: from mx2.suse.de ([195.135.220.15]:51048 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750715AbdLLJpJ (ORCPT ); Tue, 12 Dec 2017 04:45:09 -0500 Date: Tue, 12 Dec 2017 10:45:07 +0100 Message-ID: From: Takashi Iwai To: "Chen, Augustine" Cc: Ville =?UTF-8?B?U3lyasOkbMOk?= , "Anand, Jerome" , Thomas Gleixner , "intel-gfx@lists.freedesktop.org" , "alsa-devel@alsa-project.org" , "Bossart, Pierre-louis" , Ingo Molnar , "H. Peter Anvin" , Jiang Liu , Juergen Gross , Dou Liyang , "linux-kernel@vger.kernel.org" Subject: Re: [Intel-gfx] [PATCH] drm/i915: Remove unused IRQ chip data of HDMI LPE audio In-Reply-To: <9A1A7991592FAD49BCF9F28D9CF9FE3121AB7B0D@PGSMSX105.gar.corp.intel.com> References: <20171208093323.2212-1-augustine.chen@intel.com> <20171208114404.GN10981@intel.com> <20171211132023.GO10981@intel.com> <9A1A7991592FAD49BCF9F28D9CF9FE3121AB7B0D@PGSMSX105.gar.corp.intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 12 Dec 2017 10:26:08 +0100, Chen, Augustine wrote: > > > > > > 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. > > > > IMO, the primary question is whether the usage of irq chip without irq domain is > > valid or not. If an irq domain is mandatory, that's the thing to be fixed in i915 > > side. > In terms of functionality, the interrupt and hdmi audio work fine > without irq domain according to the validation. Sure, otherwise the patch never landed to mainline :) > And besides, there > are other drivers with similar implementation which doesn't set > chip data at all. Yes, dropping the chip data should be OK in the driver, but the only question is whether it is the right fix. Did you check whether the issue happens with 4.15-rc, too? This was never answered in bugzilla. If I understand correctly, the code triggering Oops has been changed largely there and it should prune the non-legacy irqs. Takashi From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [Intel-gfx] [PATCH] drm/i915: Remove unused IRQ chip data of HDMI LPE audio Date: Tue, 12 Dec 2017 10:45:07 +0100 Message-ID: References: <20171208093323.2212-1-augustine.chen@intel.com> <20171208114404.GN10981@intel.com> <20171211132023.GO10981@intel.com> <9A1A7991592FAD49BCF9F28D9CF9FE3121AB7B0D@PGSMSX105.gar.corp.intel.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 8343D267194 for ; Tue, 12 Dec 2017 10:45:08 +0100 (CET) In-Reply-To: <9A1A7991592FAD49BCF9F28D9CF9FE3121AB7B0D@PGSMSX105.gar.corp.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: "Chen, Augustine" Cc: Juergen Gross , Dou Liyang , "alsa-devel@alsa-project.org" , "intel-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , Ingo Molnar , "Anand, Jerome" , "H. Peter Anvin" , Thomas Gleixner , Jiang Liu , Ville =?UTF-8?B?U3lyasOkbMOk?= , "Bossart, Pierre-louis" List-Id: alsa-devel@alsa-project.org On Tue, 12 Dec 2017 10:26:08 +0100, Chen, Augustine wrote: > > > > > > 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. > > > > IMO, the primary question is whether the usage of irq chip without irq domain is > > valid or not. If an irq domain is mandatory, that's the thing to be fixed in i915 > > side. > In terms of functionality, the interrupt and hdmi audio work fine > without irq domain according to the validation. Sure, otherwise the patch never landed to mainline :) > And besides, there > are other drivers with similar implementation which doesn't set > chip data at all. Yes, dropping the chip data should be OK in the driver, but the only question is whether it is the right fix. Did you check whether the issue happens with 4.15-rc, too? This was never answered in bugzilla. If I understand correctly, the code triggering Oops has been changed largely there and it should prune the non-legacy irqs. Takashi