From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from Atcsqr.andestech.com (60-248-80-70.hinet-ip.hinet.net [60.248.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 01868328619; Thu, 16 Oct 2025 11:16:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=60.248.80.70 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760613445; cv=none; b=qQW+Xj5u0lLvaA5bhzDpJ/oNyt34Wv8zGTQ2KDjMEEnm8jP/KamdA5aFLeujjLZ2VbeXylr0IZQmrjNL02gKi/KxFhyjuZr3SyU0lNkasUjfXYlXHnK/kJDIcqweFu0Rx8CIq840e+AjZJWmQqmaxd8L+eeE0zMpqbZkI9Vkibg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760613445; c=relaxed/simple; bh=MZYkKkorzjs2AyVDuXTTrCkl4SEuv4JZG9Dfc8N2vlE=; h=Date:From:To:CC:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=aYNiaxnr9H1F5Oa5udReXBILtVCKkqEZzuAyPe18R2sKCKrH8nZ77xoWqtUKirLTK6lczlyGmOTXkzJAsY54zX0VpRJYWiR0tHHYU2nRN53qh5zzxPQQW+VH5STR9oPQ3Xqhn/ZVH6uQbIoA30mxUmNrAG8MSfsewJ/AZ0p4vFs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=permerror header.from=andestech.com; spf=unknown smtp.mailfrom=andestech.com; arc=none smtp.client-ip=60.248.80.70 Authentication-Results: smtp.subspace.kernel.org; dmarc=permerror header.from=andestech.com Authentication-Results: smtp.subspace.kernel.org; spf=tempfail smtp.mailfrom=andestech.com Received: from mail.andestech.com (ATCPCS31.andestech.com [10.0.1.89]) by Atcsqr.andestech.com with ESMTPS id 59GBCfS4020808 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 16 Oct 2025 19:12:41 +0800 (+08) (envelope-from randolph@andestech.com) Received: from swlinux02 (10.0.15.183) by ATCPCS31.andestech.com (10.0.1.89) with Microsoft SMTP Server id 14.3.498.0; Thu, 16 Oct 2025 19:12:41 +0800 Date: Thu, 16 Oct 2025 19:12:36 +0800 From: Randolph Lin To: Niklas Cassel CC: , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v6 1/5] PCI: dwc: Allow adjusting the number of ob/ib windows in glue driver Message-ID: References: <20251003023527.3284787-1-randolph@andestech.com> <20251003023527.3284787-2-randolph@andestech.com> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.12 (2023-09-09) X-DKIM-Results: atcpcs31.andestech.com; dkim=none; X-DNSRBL: X-SPAM-SOURCE-CHECK: pass X-MAIL:Atcsqr.andestech.com 59GBCfS4020808 Hi Niklas, On Tue, Oct 14, 2025 at 11:43:53AM +0200, Niklas Cassel wrote: > [EXTERNAL MAIL] > > On Fri, Oct 03, 2025 at 10:35:23AM +0800, Randolph Lin wrote: > > The number of ob/ib windows is determined through write-read loops > > on registers in the core driver. Some glue drivers need to adjust > > the number of ob/ib windows to meet specific requirements,such as > > Missing space after comma. > > Thanks a lot. I will fix it in the next patch. > > hardware limitations. This change allows the glue driver to adjust > > the number of ob/ib windows to satisfy platform-specific constraints. > > The glue driver may adjust the number of ob/ib windows, but the values > > must stay within hardware limits. > > Could we please get a better explaination than "satisfy platform-specific > constraints" ? > Due to this SoC design, only iATU regions with mapped addresses within the 32-bits address range need to be programmed. However, this SoC has a design limitation in which the maximum region size supported by a single iATU entry is restricted to 4 GB, as it is based on a 32-bits address region. For most EP devices, we can only define one entry in the "ranges" property of the devicetree that maps an address within the 32-bit range, as shown below: ranges = <0x02000000 0x0 0x10000000 0x0 0x10000000 0x0 0xf0000000>; For EP devices that require 64-bits address mapping (e.g., GPUs), BAR resources cannot be assigned. To support such devices, an additional entry for 64-bits address mapping is required, as shown below: ranges = <0x02000000 0x0 0x10000000 0x0 0x10000000 0x0 0xf0000000>, <0x43000000 0x1 0x00000000 0x1 0x00000000 0x7 0x00000000>; In the current common implementation, all ranges entries are programmed to the iATU. However, the size of entry for 64-bit address mapping exceeds the maximum region size that a single iATU entry can support. As a result, an error is reported during iATU programming, showing that the size of 64-bit address entry exceeds the region limit. In this SoC design, 64-bit addresses are hard-wired and can skip iATU programming. Thus, the driver needs to recount the "ranges" entries whose size fits within the 4GB platform limit. There are four scenarios: 32-bits address, size < 4GB: program to iATU 64-bits address, size < 4GB: program to iATU 32-bits address, size > 4GB: assuming this condition does not exist 64-bits address, size > 4GB: skip case We will recount how many outbound windows will be programmed to the iATU; this is why we need to adjust the number of entries programmed to the iATU. > Your PCIe controller is synthesized with a certain number of {in,out}bound > windows, and I assume that dw_pcie_iatu_detect() correctly detects the number > of {in,out}bound windows, and initializes num_ob_windows/num_ib_windows > accordingly. > > So, is the problem that because of some errata, you cannot use all the > {in,out}bound windows of the iATU? > Similar to the erratum, all inbound and outbound windows remain functional, as long as each iATU entry complies with the 4 GB size constraint. > Because it is hard to understand what kind of "hardware limit" that would > cause your SoC to not be able to use all the available {in,out}bound windows. > > Because it is simply a mapping in the iATU (internal Address Translation Unit). > > In fact, in many cases, e.g. the NVMe EPF driver, then number of {in,out}bound > windows is a major limiting factor of how many outstanding I/Os you can have, > so usually, you really want to be able to use the maximum that the hardware > supports. > > > TL;DR: to modify this common code, I think your reasoning has to be more > detailed. > I will include additional explanations along with the application scenarios of this SoC, and refactor the commit message. > > > Kind regards, > Niklas Sincerely, Randolph