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 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 23876C61DA4 for ; Tue, 14 Feb 2023 05:31:37 +0000 (UTC) Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.96) (envelope-from ) id 1pRntf-0005A3-02; Tue, 14 Feb 2023 00:30:31 -0500 Received: from mscreen.etri.re.kr ([129.254.9.16]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (Exim 4.96) (envelope-from ) id 1pRntX-00059v-1s for kernelnewbies@kernelnewbies.org; Tue, 14 Feb 2023 00:30:29 -0500 Received: from unknown (HELO send002-relay.gov-dooray.com) (211.180.235.153) by 129.254.9.16 with ESMTP; 14 Feb 2023 14:30:03 +0900 X-Original-SENDERIP: 211.180.235.153 X-Original-MAILFROM: ckim@etri.re.kr X-Original-RCPTTO: kernelnewbies@kernelnewbies.org Received: from [10.162.225.106] (HELO smtp001-imp.gov-dooray.com) ([10.162.225.106]) by send002-relay.gov-dooray.com with SMTP id 8758b9fc63eb1c5b; Tue, 14 Feb 2023 14:30:03 +0900 DKIM-Signature: a=rsa-sha256; b=rfbi9wft1+HLrGJ7av68ilqBM777Qc1xddAhzNkspeRWaHBOGspqbByn+ehTetBzmHvZQgUAcG Hhk7a4R9cGhqFPrxcwtCmWJalCdSqNj0jqe/8kqAk4Nk5SnP0O4TRBhs3seN57mCYX0W/ANh8d5Q ebnw8kJInR2SCXBXo7cQuCayWI6mYfk6qnuhaMDnl7gMZ0pEpbpdL9Nb4Bz0xzFrpqEUULxh4RB+ iO8x3eYtSi8MuWML7JVyjemtw6tvRsevr1hIW3TaOPts2RueD6URTQkRTBHkvtboCpM/+jvP76eh z6ToDGyxf3Pqsy6GPb6eYVq0T6dSW+DGoy0TfL3w==; c=relaxed/relaxed; s=selector; d=dooray.com; v=1; bh=tOLkhiEnvy9zk56DPCw+uqTiElzQKfdQ9fC/i7frBPQ=; h=From:To:Subject:Message-ID; Received: from [129.254.132.39] (HELO CHANKIMPC) ([129.254.132.39]) by smtp001-imp.gov-dooray.com with SMTP id e3bd61db63eb1c5b; Tue, 14 Feb 2023 14:30:03 +0900 From: "Chan Kim" To: References: <03ab01d93a23$83ef3a60$8bcdaf20$@etri.re.kr> In-Reply-To: <03ab01d93a23$83ef3a60$8bcdaf20$@etri.re.kr> Subject: RE: In device tree, can't understand 'ranges' property of PCIe root complex node Date: Tue, 14 Feb 2023 14:30:02 +0900 Message-ID: <09f301d94035$635576d0$2a006470$@etri.re.kr> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Content-Language: ko Thread-Index: AQI6vUwoVyfhmTVZ7KGQmOTjppwPE64K67Cg X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org Hello all, I forgot that I asked this question here and I'll write what I have found later. I found in 'PCI bus bindings to : IEEE Std 1275-1994 standard for Boot firmware' document, this 'range' property is for pci-to-pci bridge (and RC contains bridge property I understand). So if an address range is behind that bridge, that should be included in the 'ranges' property. And '6. Probing PCI-to-PCI bridges' of the document says (after setting the bridge parameters during the scan) "After setting the Memory Base, Memory Limit, I/O Base and I/O Limit registers, create a "ranges" property that represents the Memory and I/O mappings that have been established." . So it looks like this parameter is set by the bus scanning entity like bootloader or kernel. So BAR is setting the PCIe address range for each device/function, and 'ranges' is for setting address ranges covering all the devices behind the RC. I think the ranges can be merged or combined for some devices and it provides also the translation relation(between PCIe address and host CPU address). And I haven't check in the linux source but this 'ranges' property should be set in the address translation unit inside the PCIe RC core. (For example, in Synopsys PCIe core, there is iATU-internal address translation unit- for which we can set address translation entries for some ranges.). and I also guess when we do ioremap for a PCIe BAR address, it will consider this address translation for that address too. But still, I'm curious what happens in the existing 'ranges' property in the device tree before the bus scanning. Does the bootloader/kernel respect the value always (and allocates address within that ranges when allocating BARs.)? or can it ignore and override the range assignment? I would appreciate if someone could clear things up for me. Thank you. Chan Kim >-----Original Message----- >From: Chan Kim >Sent: Monday, February 6, 2023 9:07 PM >To: kernelnewbies@kernelnewbies.org >Subject: In device tree, can't understand 'ranges' property of PCIe root >complex node > >Hello all, > >For example in linux-5.15.68's arch/arm64/boot/dts/ti/k3-am64-main.dtsi, > > &cbass_main { > > ... skip ... > > pcie0_rc: pcie@f102000 { > compatible = "ti,am64-pcie-host", "ti,j721e-pcie-host"; > reg = <0x00 0x0f102000 0x00 0x1000>, > <0x00 0x0f100000 0x00 0x400>, > <0x00 0x0d000000 0x00 0x00800000>, > <0x00 0x68000000 0x00 0x00001000>; > > reg-names = "intd_cfg", "user_cfg", "reg", "cfg"; > ... skip ... > > #address-cells = <3>; > #size-cells = <2>; > > ...skip ... > > msi-map = <0x0 &gic_its 0x0 0x10000>; > ranges = <0x01000000 0x00 0x68001000 0x00 0x68001000 0x00 >0x0010000>, > <0x02000000 0x00 0x68011000 0x00 0x68011000 0x00 >0x7fef000>; > dma-ranges = <0x02000000 0x0 0x0 0x0 0x0 0x00000010 0x0>; > }; > }; > >the 'ranges' property says >- IO space starting at address 0x68001000 with size 64KiB is mapped to the >parent bus address 0x68001000. >- a 32 bit memory address space starting with address 0x68011000 and size >0x7fef000 is mapped to parent bus address 0x68011000. > >The device tree document says these addresses are all physical. >What I can't understand is : > >I know the BIOS will set the BAR addresses during the enumeration process. >This is allocating the endpoint's function to a certain PCIe bus address and >I guess setting BAR can be done without this 'ranges' information(it will >assign free address range for that device according to the device's need). >By the time linux kernel later reads this 'ranges' property, the BIOS (or >bootloader) has already assigned different PCIe address to that device. >Then, how is this 'ranges' property used by the kernel? > >Thank you. > >Chan Kim > > > > > >_______________________________________________ >Kernelnewbies mailing list >Kernelnewbies@kernelnewbies.org >https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies