From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, UNPARSEABLE_RELAY autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EE25AC43387 for ; Mon, 24 Dec 2018 11:41:11 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BC66B2173C for ; Mon, 24 Dec 2018 11:41:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ouskec7k" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BC66B2173C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=0PZUh0lxK8bWJ9xj/4h3hD+bUCD9CVER1FtiCVHlADU=; b=ouskec7k3LxYxT spV4o4WO7nCPNgiuBhjABcdMuuv8sHK9HaHgJyRzf1cvpJFgBHefzNV205Uw1tUypuwyMg2hRzCBv kZesKZub/BrWKRJNutz8Mhh8HNxQCTLSaEWuWXJg9V3yVFYT2fQE7ynAU8YleKBwXFd8EnthmmR2D EK59Zx47FA+TFZuSNUmUC519jcF1p9oc+o+fFjOeO+ZSN3hTnmhE4VAvfO8wVXOokSauScq0hBBN+ ArtSNyr9frTIwuG9AoCF4AJYfC9BS85adfKrlbUr+8iRafgoVhj2tyPHYWEv/+mg4evSH3Wdpd5c5 dmSVwl3VZyoAgo69VV7w==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gbObZ-00052I-HS; Mon, 24 Dec 2018 11:41:05 +0000 Received: from [1.203.163.78] (helo=mailgw01.mediatek.com) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gbObU-000512-1a; Mon, 24 Dec 2018 11:41:02 +0000 X-UUID: 17015e1a01b24be7a11b9848953f31e2-20181224 X-UUID: 17015e1a01b24be7a11b9848953f31e2-20181224 Received: from mtkcas35.mediatek.inc [(172.27.4.250)] by mailgw01.mediatek.com (envelope-from ) (mailgw01.mediatek.com ESMTP with TLS) with ESMTP id 555504384; Mon, 24 Dec 2018 19:40:31 +0800 Received: from MTKCAS36.mediatek.inc (172.27.4.186) by MTKMBS31N2.mediatek.inc (172.27.4.87) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 24 Dec 2018 19:40:29 +0800 Received: from [10.17.3.153] (10.17.3.153) by MTKCAS36.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Mon, 24 Dec 2018 19:40:28 +0800 Message-ID: <1545651628.5634.57.camel@mhfsdcap03> Subject: Re: [PATCH 2/2] PCI: mediatek: Add controller support for MT7629 From: Jianjun Wang To: Bjorn Helgaas Date: Mon, 24 Dec 2018 19:40:28 +0800 In-Reply-To: <20181220182043.GC183878@google.com> References: <1544058553-10936-1-git-send-email-jianjun.wang@mediatek.com> <1544058553-10936-3-git-send-email-jianjun.wang@mediatek.com> <20181213145517.GB4701@google.com> <1545034779.8528.8.camel@mhfsdcap03> <20181217143247.GK20725@google.com> <20181217154645.GA24864@e107981-ln.cambridge.arm.com> <1545124764.25199.3.camel@mhfsdcap03> <20181220182043.GC183878@google.com> X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20181224_034100_513520_181E71EF X-CRM114-Status: GOOD ( 27.68 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Lorenzo Pieralisi , linux-pci@vger.kernel.org, youlin.pei@mediatek.com, linux-kernel@vger.kernel.org, robh+dt@kernel.org, jianjun.wang@mediatek.com, ryder.lee@mediatek.com, linux-mediatek@lists.infradead.org, honghui.zhang@mediatek.com, matthias.bgg@gmail.com, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 2018-12-20 at 12:20 -0600, Bjorn Helgaas wrote: > On Tue, Dec 18, 2018 at 05:19:24PM +0800, Jianjun Wang wrote: > > On Mon, 2018-12-17 at 15:46 +0000, Lorenzo Pieralisi wrote: > > > On Mon, Dec 17, 2018 at 08:32:47AM -0600, Bjorn Helgaas wrote: > > > > On Mon, Dec 17, 2018 at 04:19:39PM +0800, Jianjun Wang wrote: > > > > > On Thu, 2018-12-13 at 08:55 -0600, Bjorn Helgaas wrote: > > > > > > On Thu, Dec 06, 2018 at 09:09:13AM +0800, Jianjun Wang wrote: > > > > > > > The read value of BAR0 is 0xffff_ffff, it's size will be > > > > > > > calculated as 4GB in arm64 but bogus alignment values at > > > > > > > arm32, the pcie device and devices behind this bridge will > > > > > > > not be enabled. Fix it's BAR0 resource size to guarantee > > > > > > > the pcie devices will be enabled correctly. > > > > > > > > > > > > So this is a hardware erratum? Per spec, a memory BAR has > > > > > > bit 0 hardwired to 0, and an IO BAR has bit 1 hardwired to > > > > > > 0. > > > > > > > > > > Yes, it only works properly on 64bit platform. > > > > > > > > I don't understand. BARs are supposed to work the same > > > > regardless of whether it's a 32- or 64-bit platform. If this is > > > > a workaround for a hardware defect, please just say that > > > > explicitly. > > > > > > I do not understand this either. First thing to do is to describe > > > the problem properly so that we can actually find a solution to > > > it. > > > > This BAR0 is a 64-bit memory BAR, the HW default values for this BAR > > is 0xffff_ffff_0000_0000 and it could not be changed except by > > config write operation. > > If you literally get 0xffff_ffff_0000_0000 when reading the BAR, that > is out of spec because the low-order 4 bits of a 64-bit memory BAR > cannot all be zero. > > A 64-bit BAR consumes two DWORDS in config space. For a 64-bit BAR0, > the DWORD at 0x10 contains the low-order bits, and the DWORD at 0x14 > contains the upper 32 bits. Bits 0-3 of the low-order DWORD (the > one at 0x10) are read-only, and in this case should contain the value > 0b1100 (0xc). That means the range is prefetchable (bit 3 == 1) and > the BAR is 64 bits (bits 2:1 == 10). Sorry, I have confused the HW default value and the read value of BAR size. The hardware default value is 0xffff_ffff_0000_000c, it's a 64-bit BAR with prefetchable range. When we start to decoding the BAR, the read value of BAR0 at 0x10 is 0x0c, and the value at 0x14 is 0xffff_ffff, so the read value of BAR size is 0xffff_ffff_0000_0000, which will be decoded to 0xffff_ffff, and it will be set to the end value of BAR0 resource in the pci_dev. > > > The calculated BAR size will be 0 in 32-bit platform since the > > phys_addr_t is a 32bit value in 32-bit platform. > > Either (1) this is a hardware defect that feeds incorrect data to the > BAR size calculation, or (2) there's a problem in the BAR size > calculation code. We need to figure out which one and work around or > fix it correctly. The BAR size is calculated by the code (res->end - res->start + 1) is fine, I think it's a hardware defect because that we can not change the hardware default value or just disable it since we don't using it. > > > Actually MediaTek's HW does not using this BAR0, just omit it when > > assign resource is totally fine. > > It's totally fine to work around hardware defects, but we have to > clearly understand the problem so we do it correctly. For example, we > probably can't just clear out the BAR0 resource in the pci_dev, > because the BAR in the hardware device still contains a value, and if > we enable memory decoding for the device, it will still respond to the > region described by the BAR. The BAR0 resource value in the pci_dev is depend on the hardware value, it can be cleared out after all devices have been scanned, but we should set it's size bigger than MMIO space, so the software will think it's a invalid resource and won't assign a resource for it. Thanks. > > > When assign the resource for each device, software will check the > > resource alignment first, and the resource of length zero will be > > regarded as a bogus alignment resource, it will be ignored and won't > > claim a resource parent for it. > > > > When drivers try to enable the PCIe devices, the software will enable > > it's resources, but it will return an error number when found a > > unclaimed resource, in that case, the flow of enable devices will be > > interrupted and PCIe devices won't work properly. > > > > Thanks. > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel