Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp743893ybb; Wed, 25 Mar 2020 08:46:52 -0700 (PDT) X-Google-Smtp-Source: ADFU+vssYD/5U0SNO5A2w4o0ikGl+UlrSy9uQXX/cXnNuHtK6NeoE6i2de9yaRMd3IgxS4E04XxQ X-Received: by 2002:aca:ecd7:: with SMTP id k206mr2897468oih.113.1585151211953; Wed, 25 Mar 2020 08:46:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585151211; cv=none; d=google.com; s=arc-20160816; b=gJI8SOFfDaDWceAWubHTsO5hyqH6Pjj5iUEDYbP+FiscUd05jl5XxEqZ0wIUhrfsaQ /TGxIiJRMXBkNUKvwMAvrbg6wp4y/4B7rxsULYScANriW8G7w5pB7NlgdY8UoA+prvXy i/j0DkxYsG0IIv0fkCuxq1/wa+fr6F7jICQw+sIMaIsEdtWnYZKT/kl22pDMySxfFPRJ EGZV8PCaJLcjuxFHEY+Uw78ZX+rwScB7nt6L67WO1n2XoUPMlmxgV2gDS3UHvuWOvFQN O/R3HLkCV0qBWSYRb/tVuB4g+eO4OsuXL7ly6y5l4tLSs8CxDlek32gwP0aEUF87ZCbi ftIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=8aqcNcj01L4Z760jEzBuqwbeO1kPaO/4o8rXuF1GPAY=; b=QxFkb7S1tOP2FuVzs3MZX8Tx8FOpTqZreIGudwL41lfIS6Slvv/ilLFvjJAB9UbPBO 6An/6khZyO9SfL4L1YFcnNBO29FAmWVqt1yX1o5HZfI1tloYB2ZDMtVY4W4dmJGMR3f9 yKX/U1loDU/jdJ5a/WZqcj11/v5iOlZEsfygN08W6BN792M2QwHcndm99Kb1r22XxgHr 69BOFE3XBlXO0mi3qHdmzYX54seamfyghtNnhdbO+g4mD+0Kf/Bln5T85bM4zSPmjvlh L1Fiq7FPNweIf+Wy4XEW+BeYYZweG8uRCbKoQaH/g/+vZLj9U6auAo0SyxEKcNi+bPsb VVHw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s63si2575734oig.69.2020.03.25.08.46.36; Wed, 25 Mar 2020 08:46:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727745AbgCYPqT (ORCPT + 99 others); Wed, 25 Mar 2020 11:46:19 -0400 Received: from elvis.franken.de ([193.175.24.41]:34398 "EHLO elvis.franken.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727386AbgCYPqT (ORCPT ); Wed, 25 Mar 2020 11:46:19 -0400 Received: from uucp (helo=alpha) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1jH8EN-0003EB-00; Wed, 25 Mar 2020 16:46:11 +0100 Received: by alpha.franken.de (Postfix, from userid 1000) id 36265C0C3F; Wed, 25 Mar 2020 16:46:00 +0100 (CET) Date: Wed, 25 Mar 2020 16:46:00 +0100 From: Thomas Bogendoerfer To: Jiaxun Yang Cc: Marc Zyngier , linux-mips@vger.kernel.org, Huacai Chen , Thomas Gleixner , Jason Cooper , Rob Herring , Mark Rutland , Mauro Carvalho Chehab , "David S. Miller" , Greg Kroah-Hartman , Jonathan Cameron , Andy Shevchenko , Allison Randal , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH v8 06/11] irqchip: mips-cpu: Convert to simple domain Message-ID: <20200325154600.GA14923@alpha.franken.de> References: <20200325035537.156911-7-jiaxun.yang@flygoat.com> <20200325123742.GA9911@alpha.franken.de> <5eb9ce9ea665ee32da40779f00fc9b37@kernel.org> <4BB367D3-B8AD-47B6-ACC2-30752137BC1B@flygoat.com> <39CF835E-D1D9-4B52-ABDC-BDB17B650936@flygoat.com> <20200325150437.GA14217@alpha.franken.de> <777D8DAA-F462-4E8D-9012-C114DE6D56DE@flygoat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <777D8DAA-F462-4E8D-9012-C114DE6D56DE@flygoat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 25, 2020 at 11:09:10PM +0800, Jiaxun Yang wrote: > > > 于 2020年3月25日 GMT+08:00 下午11:04:37, Thomas Bogendoerfer 写到: > >On Wed, Mar 25, 2020 at 10:31:21PM +0800, Jiaxun Yang wrote: > >> > >> > >> 于 2020年3月25日 GMT+08:00 下午10:15:16, Marc Zyngier 写到: > >> >On 2020-03-25 13:59, Jiaxun Yang wrote: > >> > > >> >[...] > >> > > >> >>>> So probably we can use legacy domain when MIPS IRQ BASE is in > >the > >> >>>> range of legacy IRQ > >> >>>> and switch to simple domain when it's not in that range? > >> >>> > >> >>> No, see below. > >> >>> > >> >>>> Here in Loongson systems IRQ 0-15 is occupied by I8259 so I did > >> >this > >> >>>> hack. > >> >>> > >> >>> Well, if you have to consider which Linux IRQ gets assigned, > >> >>> then your platform is definitely not ready for non-legacy > >> >>> irqdomains. Just stick to legacy for now until you have removed > >> >>> all the code that knows the hwirq mapping. > >> >> > >> >> Thanks. > >> >> > >> >> So I have to allocate irq_desc here in driver manually? > >> > > >> >No, you are probably better off just dropping this patch, as MIPS > >> >doesn't seem to be ready for a wholesale switch to virtual > >interrupts. > >> > >> It can't work without this patch. > >> > >> Legacy domain require IRQ number within 0-15 > >> however it's already occupied by i8259 or "HTPIC" driver. > > > >what's the problem here ? AFAIK there could be more than one > >legacy domain, at least that's what at least IP22/SNI in MIPS world > >are doing. > > MIPS_IRQ_BASE must be higher than 15, otherwise it will conflict with i8259. I still don't get it. We have following in arch/mips/include/asm/mach-generic/irq.h: #ifndef MIPS_CPU_IRQ_BASE #ifdef CONFIG_I8259 #define MIPS_CPU_IRQ_BASE 16 #else #define MIPS_CPU_IRQ_BASE 0 #endif /* CONFIG_I8259 */ #endif So every legacy platform with i8259 has MIPS_CPU_IRQ_BASE = 16. > However we have only preallocated irq_desc for 0-15. > And legacy domain require irq_desc being preallocated. maybe I'm too fast by judging the irq code, but without CONFIG_SPARSE_IRQ the whole irq_desc is pre-allocated. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ]