Received: by 10.223.176.5 with SMTP id f5csp236070wra; Mon, 5 Feb 2018 20:52:40 -0800 (PST) X-Google-Smtp-Source: AH8x225lbCktVpZREOF9BDeJ16vU7nEM3nuZIrLkE5oBDXijP1tEJFjTD15wjx1LE1GfyNJubOqw X-Received: by 2002:a17:902:aa8e:: with SMTP id d14-v6mr1159615plr.94.1517892760488; Mon, 05 Feb 2018 20:52:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517892760; cv=none; d=google.com; s=arc-20160816; b=DC4KGTaFG30d3RmcPM7v4UAzWWmaqBuvFPT6spYEDfTXY/qQAaioGBCrIVYonCdeNW ghs29Ghq1GrQa+Jncq3N7rMumG2PqBeMkMhbSPXQUk400MYPmPWR5N+oWlnJ+m8IfI03 ORtm7kg9+vkmebW0dTQSsl4Sx2g9vSh90XdFaMHe4w99lSGXeMyvJGI8RIfVKiHw670Q 9RfIkAQp2BQuxf0GYL01zkYCrHFt/4qqckJk+nVUdn4Q4t1Mf3KbOKJ3Qf/iPms2AhBD T+l3zCMQpMTmeof9QZTJgvG7038t9I5GTcOIHJO6Uv+C4UN5PxkZga1c1Qx4WWMvjA/n I/VQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :arc-authentication-results; bh=a+z3PP4zPM3VjUKm+rcF4PPmziSIm6YKe4Ka6fT4jMs=; b=o/5+AKtbl+Neo4s2Low9nd/9z4Yaol8RgVe5VAv6rPRFj/c9ElYed/GzMKXmrgVhOb qG2OnA2+0m0yKiqoD3Tv+zTr/1os8kzoMDBfy+fDCpwhC+La0nMFVHfXQcjbEibg57gc PUZVdZXLKbLmnTtE9H5RoM6SR543BkncCVS61rWSC7lTw/madCgr0VnkP4auXus4caDK BtUAt5krOVfezTNJQTQm4ozEGNP+g4VZ9bGh9gcDbao686VQYiCdwX688+2V8XqOiNLi VwV/qP6GNG5ZnRiAXSMZo0hRyvbr+MV9GCTJbbPbigNXYW93Xiyq1Vpv+QC/k1Luw7zQ gVgA== 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 b3si1011779pfl.166.2018.02.05.20.52.26; Mon, 05 Feb 2018 20:52:40 -0800 (PST) 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 S1752733AbeBFEvc (ORCPT + 99 others); Mon, 5 Feb 2018 23:51:32 -0500 Received: from gate.crashing.org ([63.228.1.57]:45099 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752680AbeBFEvL (ORCPT ); Mon, 5 Feb 2018 23:51:11 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id w164oOv3003775; Mon, 5 Feb 2018 22:50:25 -0600 Message-ID: <1517892624.2312.167.camel@kernel.crashing.org> Subject: Re: [PATCH 1/2] of_pci_irq: add a check to fallback to standard device tree parsing From: Benjamin Herrenschmidt To: Ryder Lee Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Lorenzo Pieralisi , Arnd Bergmann , linux-pci@vger.kernel.org, "linux-kernel@vger.kernel.org" , Rob Herring , linux-mediatek@lists.infradead.org, Bjorn Helgaas , Frank Rowand , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" Date: Tue, 06 Feb 2018 15:50:24 +1100 In-Reply-To: <1517891471.20869.6.camel@mtkswgap22> References: <31c765c53e85e41bfc001d110d69e46c9967f4e7.1516961656.git.ryder.lee@mediatek.com> <1517563970.24622.9.camel@mtkswgap22> <1517866584.2312.140.camel@kernel.crashing.org> <1517884738.16010.27.camel@mtkswgap22> <1517889903.2312.151.camel@kernel.crashing.org> <1517891471.20869.6.camel@mtkswgap22> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.4 (3.26.4-1.fc27) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2018-02-06 at 12:31 +0800, Ryder Lee wrote: > On Tue, 2018-02-06 at 15:05 +1100, Benjamin Herrenschmidt wrote: > > On Tue, 2018-02-06 at 10:38 +0800, Ryder Lee wrote: > > > > > > I think the code should look at the bridge address <0x0800 ...> we list > > > in bindings for resolving interrupts in this case, but it seems like it > > > use the 'pdev->defvn << 8' which is not really we want and will lead to > > > mismatch. > > > > > > interrupt-map-mask = <0xf800 0 0 7>; > > > interrupt-map = <0x0000 0 0 1 ...>, > > > <0x0000 0 0 2 ...>, > > > <0x0000 0 0 3 ...>, > > > <0x0000 0 0 4 ...>, > > > > > > 0x0800 0 0 1 ...>, > > > 0x0800 0 0 2 ...>, > > > 0x0800 0 0 3 ...>, > > > 0x0800 0 0 4 ...>; > > > ... > > > pcie@1,0 { > > > reg = <0x0800 0 0 0 0>; > > > ... > > > }; > > > > > > > > > Or, alternatively, we could add a interrupt-map property in both child > > > and root node to solve this. The below example is my original version as > > > I don't want to change that function either. > > > > The code looks at devfn because it's meant to work for PCI including > > when the devices dont have a device node in the DT. > > > > What I'm trying to figure out is what is it that your parent and > > children are representing here. Which is/are the root complex ? > > This is a single root complex with 2 root port (children in DT). > > > What is the actual topology as visible on the PCIe bus (is lspci output > > basically) and how does that map to your representation ? > > # lspci > 00:00.0 Class 0604: 14c3:0801 //1st slot - pcie@0,0 > 00:01.0 Class 0604: 14c3:0801 //2nd slot - pcie@1,0 > > 01:00.0 Class 0280: 14c3:7603 //A device which is connected to 1st slot > 02:00.0 Class 0200: 8086:1521 //A 4 func device which is connected to > 2nd slot > 02:00.1 Class 0200: 8086:1521 > 02:00.2 Class 0200: 8086:1521 > 02:00.3 Class 0200: 8086:1521 Ok so that's a rather standard setup. The "devfn << 8" of your root ports should be the exact same thing as their first reg property entry, I'm not sure why you have a mismatch here. However, that map only represents the INTA..D lines going to the root ports, not how these get mapped to children of the root ports. of_irq_parse_pci() will implement standard swizzling if you don't have nodes for your devices at all. If you do, however, the code assumes you have a correct and complete interrupt tree in the device-tree. That means that you need in each "p2p bridge", including your root ports, an interrupt-map that will map the children INTA...D of that bridge to the parent INTA...D of that bridge. Alternatively, you can make the maps in the root ports point directly to the parent PIC. If you chose to do that, then the interrupt-map in your root complex becomes only useful to represent the root ports own interrutps (hotplug, AER,...) and could be replaced by just having interrupt-parent & interrupts in those root port nodes. Cheers, Ben.