From: "Arnd Bergmann" <arnd@arndb.de> To: "Hawkins, Nick" <nick.hawkins@hpe.com> Cc: "Verdun, Jean-Marie" <verdun@hpe.com>, "Jean Delvare" <jdelvare@suse.com>, "Guenter Roeck" <linux@roeck-us.net>, "Rob Herring" <robh+dt@kernel.org>, "krzysztof.kozlowski+dt@linaro.org" <krzysztof.kozlowski+dt@linaro.org>, "Jonathan Corbet" <corbet@lwn.net>, "Russell King" <linux@armlinux.org.uk>, "linux-hwmon@vger.kernel.org" <linux-hwmon@vger.kernel.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v4 3/5] ARM: dts: add GXP Support for fans and SPI Date: Thu, 12 Jan 2023 17:00:52 +0100 [thread overview] Message-ID: <6bae68eb-866f-4b78-b4db-e3154feec28e@app.fastmail.com> (raw) In-Reply-To: <E2B35D8A-B8A6-40C1-8AC9-46E6C2CAE656@hpe.com> On Thu, Jan 12, 2023, at 16:40, Hawkins, Nick wrote: >> > - ahb@c0000000 { >> > + ahb@80000000 { >> > compatible = "simple-bus"; >> > #address-cells = <1>; >> > #size-cells = <1>; >> > - ranges = <0x0 0xc0000000 0x30000000>; >> > + ranges = <0x0 0x80000000 0xf000000>, /* 0x80000000 - 0x8f000000 */ >> > + <0x40000000 0xc0000000 0x7fffffff>; /* 0xc0000000 - 0xffffffff */ > > >> I'm a bit confused by the change in the mappings: are you >> sure this all the same ahb bus and not two separate buses? > > Yes this is the same bus, however we are not including all of > it as it maps some host registers that we do not want to access > at this time. If the two ranges are actually translated separately on the bus, you could also decide to enumerate the translations with a 64-bit local address and make the upper word an enumeration, such as ranges = <0x1 0x0 0x80000000 0xf000000>, <0x2 0x0 0xc0000000 0x30000000>; then you get small numbers again in the 'reg' properties that are easier to read and ideally match the bus-local numbers from the hardware manual. >> The comment for the second range looks wrong to me, as >> you define a 2GB (minus one byte) sized mapping but the >> comment only lists a 1GB (including the last byte) mapping. > > >> I would expect that the original 0x30000000 (including the >> last byte) was correct here. > > Yes this was incorrect, I believe it should be: > > ranges = <0x0 0x80000000 0xf000000>, /* 0x80000000 - 0x8f000000 */ > <0x40000000 0xc0000000 0x3fffffff>; /* 0xc0000000 - > 0xffffffff */ > > I will create a v5 version of this patchset with just this and the > defconfig for your review. Now it almost matches, except for the final byte, as the range actually ends at 0xfffffffe not 0xffffffff if you make the size one byte less than 1GB. Is there a special register in the last byte? >> > - vic1: interrupt-controller@80f00000 { >> > + vic1: interrupt-controller@f00000 { /* 0x80f00000 */ > > >> This is not the same address as before. I'm also not sure the >> comment is helpful here. > > My understanding was that the physical address would be the > 0x80000000 from the first range plus the 0xf00000 to be > 0x80f00000? I suppose the physical address in the old mapping was actually outside of the 0xc0000000-0xefffffff range, so it wasn't even accessible. If the addresses are interpreted to wrap around at the end of the mapping, that would have made the CPU visible address 0xe0f00000 (0xc0000000 + (0x80f00000 % 0x30000000)). If it just wrapped around as a 32-bit number, it would be 0x40f00000 ((0xc0000000 + 0x80f00000)% 0x100000000), but I don't see you you'd get to 80f00000. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: "Arnd Bergmann" <arnd@arndb.de> To: "Hawkins, Nick" <nick.hawkins@hpe.com> Cc: "Verdun, Jean-Marie" <verdun@hpe.com>, "Jean Delvare" <jdelvare@suse.com>, "Guenter Roeck" <linux@roeck-us.net>, "Rob Herring" <robh+dt@kernel.org>, "krzysztof.kozlowski+dt@linaro.org" <krzysztof.kozlowski+dt@linaro.org>, "Jonathan Corbet" <corbet@lwn.net>, "Russell King" <linux@armlinux.org.uk>, "linux-hwmon@vger.kernel.org" <linux-hwmon@vger.kernel.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v4 3/5] ARM: dts: add GXP Support for fans and SPI Date: Thu, 12 Jan 2023 17:00:52 +0100 [thread overview] Message-ID: <6bae68eb-866f-4b78-b4db-e3154feec28e@app.fastmail.com> (raw) In-Reply-To: <E2B35D8A-B8A6-40C1-8AC9-46E6C2CAE656@hpe.com> On Thu, Jan 12, 2023, at 16:40, Hawkins, Nick wrote: >> > - ahb@c0000000 { >> > + ahb@80000000 { >> > compatible = "simple-bus"; >> > #address-cells = <1>; >> > #size-cells = <1>; >> > - ranges = <0x0 0xc0000000 0x30000000>; >> > + ranges = <0x0 0x80000000 0xf000000>, /* 0x80000000 - 0x8f000000 */ >> > + <0x40000000 0xc0000000 0x7fffffff>; /* 0xc0000000 - 0xffffffff */ > > >> I'm a bit confused by the change in the mappings: are you >> sure this all the same ahb bus and not two separate buses? > > Yes this is the same bus, however we are not including all of > it as it maps some host registers that we do not want to access > at this time. If the two ranges are actually translated separately on the bus, you could also decide to enumerate the translations with a 64-bit local address and make the upper word an enumeration, such as ranges = <0x1 0x0 0x80000000 0xf000000>, <0x2 0x0 0xc0000000 0x30000000>; then you get small numbers again in the 'reg' properties that are easier to read and ideally match the bus-local numbers from the hardware manual. >> The comment for the second range looks wrong to me, as >> you define a 2GB (minus one byte) sized mapping but the >> comment only lists a 1GB (including the last byte) mapping. > > >> I would expect that the original 0x30000000 (including the >> last byte) was correct here. > > Yes this was incorrect, I believe it should be: > > ranges = <0x0 0x80000000 0xf000000>, /* 0x80000000 - 0x8f000000 */ > <0x40000000 0xc0000000 0x3fffffff>; /* 0xc0000000 - > 0xffffffff */ > > I will create a v5 version of this patchset with just this and the > defconfig for your review. Now it almost matches, except for the final byte, as the range actually ends at 0xfffffffe not 0xffffffff if you make the size one byte less than 1GB. Is there a special register in the last byte? >> > - vic1: interrupt-controller@80f00000 { >> > + vic1: interrupt-controller@f00000 { /* 0x80f00000 */ > > >> This is not the same address as before. I'm also not sure the >> comment is helpful here. > > My understanding was that the physical address would be the > 0x80000000 from the first range plus the 0xf00000 to be > 0x80f00000? I suppose the physical address in the old mapping was actually outside of the 0xc0000000-0xefffffff range, so it wasn't even accessible. If the addresses are interpreted to wrap around at the end of the mapping, that would have made the CPU visible address 0xe0f00000 (0xc0000000 + (0x80f00000 % 0x30000000)). If it just wrapped around as a 32-bit number, it would be 0x40f00000 ((0xc0000000 + 0x80f00000)% 0x100000000), but I don't see you you'd get to 80f00000. Arnd
next prev parent reply other threads:[~2023-01-12 16:03 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-01-03 20:36 [PATCH v4 0/5] ARM: Add GXP Fan and SPI controllers nick.hawkins 2023-01-03 20:36 ` nick.hawkins 2023-01-03 20:36 ` [PATCH v4 1/5] hwmon: (gxp-fan-ctrl) Add GXP fan controller nick.hawkins 2023-01-03 20:36 ` nick.hawkins 2023-01-03 21:34 ` Guenter Roeck 2023-01-03 21:34 ` Guenter Roeck 2023-01-03 20:36 ` [PATCH v4 2/5] dt-bindings: hwmon: Add hpe,gxp-fan-ctrl nick.hawkins 2023-01-03 20:36 ` nick.hawkins 2023-01-03 21:35 ` Guenter Roeck 2023-01-03 21:35 ` Guenter Roeck 2023-01-03 20:36 ` [PATCH v4 3/5] ARM: dts: add GXP Support for fans and SPI nick.hawkins 2023-01-03 20:36 ` nick.hawkins 2023-01-03 21:37 ` Guenter Roeck 2023-01-03 21:37 ` Guenter Roeck 2023-01-12 14:24 ` Arnd Bergmann 2023-01-12 14:24 ` Arnd Bergmann 2023-01-12 15:40 ` Hawkins, Nick 2023-01-12 15:40 ` Hawkins, Nick 2023-01-12 16:00 ` Arnd Bergmann [this message] 2023-01-12 16:00 ` Arnd Bergmann 2023-01-12 19:58 ` Hawkins, Nick 2023-01-12 19:58 ` Hawkins, Nick 2023-01-12 21:57 ` Arnd Bergmann 2023-01-12 21:57 ` Arnd Bergmann 2023-01-03 20:36 ` [PATCH v4 4/5] ARM: multi_v7_defconfig: Add GXP Fan and SPI support nick.hawkins 2023-01-03 20:36 ` nick.hawkins 2023-01-03 21:38 ` Guenter Roeck 2023-01-03 21:38 ` Guenter Roeck 2023-01-12 14:29 ` Arnd Bergmann 2023-01-12 14:29 ` Arnd Bergmann 2023-01-03 20:36 ` [PATCH v4 5/5] MAINTAINERS: add gxp fan controller and documents nick.hawkins 2023-01-03 20:36 ` nick.hawkins 2023-01-03 21:36 ` Guenter Roeck 2023-01-03 21:36 ` Guenter Roeck
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=6bae68eb-866f-4b78-b4db-e3154feec28e@app.fastmail.com \ --to=arnd@arndb.de \ --cc=corbet@lwn.net \ --cc=devicetree@vger.kernel.org \ --cc=jdelvare@suse.com \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-hwmon@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=linux@roeck-us.net \ --cc=nick.hawkins@hpe.com \ --cc=robh+dt@kernel.org \ --cc=verdun@hpe.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.