| Message ID | 20210112015602.497-3-thunder.leizhen@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add Hisilicon L3 cache controller support | expand |
On Tue, Jan 12, 2021 at 2:56 AM Zhen Lei <thunder.leizhen@huawei.com> wrote: > +--- > +$id: http://devicetree.org/schemas/arm/hisilicon/l3cache.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Hisilicon L3 cache controller > + > +maintainers: > + - Wei Xu <xuwei5@hisilicon.com> > + > +description: | > + The Hisilicon L3 outer cache controller supports a maximum of 36-bit physical > + addresses. The data cached in the L3 outer cache can be operated based on the > + physical address range or the entire cache. > + > +properties: > + compatible: > + items: > + - const: hisilicon,l3cache > + The compatible string needs to be a little more specific, I'm sure you cannot guarantee that this is the only L3 cache controller ever designed in the past or future by HiSilicon. Normally when you have an IP block that is itself unnamed but that is specific to one or a few SoCs but that has no na, the convention is to include the name of the first SoC that contained it. Can you share which products actually use this L3 cache controller? On a related note, what does the memory map look like on this chip? Do you support more than 4GB of total installed memory? If you do, this becomes a problem in the future as highmem support winds down. In fact anything more than 1GB on a 32-bit system requires more work on the kernel to be completed before we remove highmem, and will incur a slowdown. If the total is under 4GB but the memory is not in a contiguous physical address range. See my Linaro connect presentation[1] for further information on the topic. Arnd [1] https://connect.linaro.org/resources/lvc20/lvc20-106/
On 2021/1/12 16:46, Arnd Bergmann wrote: > On Tue, Jan 12, 2021 at 2:56 AM Zhen Lei <thunder.leizhen@huawei.com> wrote: > >> +--- >> +$id: http://devicetree.org/schemas/arm/hisilicon/l3cache.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Hisilicon L3 cache controller >> + >> +maintainers: >> + - Wei Xu <xuwei5@hisilicon.com> >> + >> +description: | >> + The Hisilicon L3 outer cache controller supports a maximum of 36-bit physical >> + addresses. The data cached in the L3 outer cache can be operated based on the >> + physical address range or the entire cache. >> + >> +properties: >> + compatible: >> + items: >> + - const: hisilicon,l3cache >> + > > The compatible string needs to be a little more specific, I'm sure > you cannot guarantee that this is the only L3 cache controller ever > designed in the past or future by HiSilicon. > > Normally when you have an IP block that is itself unnamed but that is specific > to one or a few SoCs but that has no na, the convention is to include the name > of the first SoC that contained it. Right, thanks for your suggestion, I will rename it to "hisilicon,hi1381-l3cache" and "hisilicon,hi1215-l3cache". > > Can you share which products actually use this L3 cache controller? This L3 cache controller is used on Hi1381 and Hi1215 board. I don't know where these two boards are used. Our company is too large. Software is delivered level by level. I'm only involved in the Kernel-related part. > > On a related note, what does the memory map look like on this chip? memory@a00000 { device_type = "memory"; reg = <0x0 0xa00000 0x0 0x1aa00000>, <0x1 0xe0000000 0x0 0x1d000000>, <0x0 0x1f400000 0x0 0xb5c00000>; }; Currently, the DTS is being maintained by ourselves, I'll try to upstream it later. > Do you support more than 4GB of total installed memory? If you Currently, the total size does not exceed 4 GB. However, the physical address is wider than 32 bits. > do, this becomes a problem in the future as highmem support > winds down. In fact anything more than 1GB on a 32-bit system > requires more work on the kernel to be completed before we remove > highmem, and will incur a slowdown. If the total is under 4GB but the > memory is not in a contiguous physical address range. See my > Linaro connect presentation[1] for further information on the topic. Great. > > Arnd > > [1] https://connect.linaro.org/resources/lvc20/lvc20-106/ > > . >
On Tue, Jan 12, 2021 at 1:35 PM Leizhen (ThunderTown) <thunder.leizhen@huawei.com> wrote: > On 2021/1/12 16:46, Arnd Bergmann wrote: > > On Tue, Jan 12, 2021 at 2:56 AM Zhen Lei <thunder.leizhen@huawei.com> wrote: > > > >> +--- > >> +$id: http://devicetree.org/schemas/arm/hisilicon/l3cache.yaml# > >> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >> + > >> +title: Hisilicon L3 cache controller > >> + > >> +maintainers: > >> + - Wei Xu <xuwei5@hisilicon.com> > >> + > >> +description: | > >> + The Hisilicon L3 outer cache controller supports a maximum of 36-bit physical > >> + addresses. The data cached in the L3 outer cache can be operated based on the > >> + physical address range or the entire cache. > >> + > >> +properties: > >> + compatible: > >> + items: > >> + - const: hisilicon,l3cache > >> + > > > > The compatible string needs to be a little more specific, I'm sure > > you cannot guarantee that this is the only L3 cache controller ever > > designed in the past or future by HiSilicon. > > > > Normally when you have an IP block that is itself unnamed but that is specific > > to one or a few SoCs but that has no na, the convention is to include the name > > of the first SoC that contained it. > > Right, thanks for your suggestion, I will rename it to "hisilicon,hi1381-l3cache" > and "hisilicon,hi1215-l3cache". Sounds good. > > Can you share which products actually use this L3 cache controller? > > This L3 cache controller is used on Hi1381 and Hi1215 board. I don't know where > these two boards are used. Our company is too large. Software is delivered level > by level. I'm only involved in the Kernel-related part. > > > > > On a related note, what does the memory map look like on this chip? > > memory@a00000 { > device_type = "memory"; > reg = <0x0 0xa00000 0x0 0x1aa00000>, <0x1 0xe0000000 0x0 0x1d000000>, <0x0 0x1f400000 0x0 0xb5c00000>; > }; > > Currently, the DTS is being maintained by ourselves, I'll try to upstream it later. > > > Do you support more than 4GB of total installed memory? If you > > Currently, the total size does not exceed 4 GB. However, the physical address is wider than 32 bits. Ok, so it appears that the memory is actually contiguous in the first 3.5GB (with a few holes), plus the remaining 0.5GB being offset in the physical memory by 4GB (starting at 0x1e0000000 instead of 0xe0000000), presumably to allow the use of 32-bit DMA addresses. This works fine for the moment, but it does require support for a nonlinear virt_to_phys()/phys_to_virt() translation after highmem gets removed, and you would get at most 3.75GB anyway, so it might be easier at that point to just drop the entire last block at 0x1e0000000, but this will depend on how well we get the 4G:4G code to work, and whether the users will still need kernel updates for this platform then. Arnd
On 2021/1/12 21:55, Arnd Bergmann wrote: > On Tue, Jan 12, 2021 at 1:35 PM Leizhen (ThunderTown) > <thunder.leizhen@huawei.com> wrote: >> On 2021/1/12 16:46, Arnd Bergmann wrote: >>> On Tue, Jan 12, 2021 at 2:56 AM Zhen Lei <thunder.leizhen@huawei.com> wrote: >>> >>>> +--- >>>> +$id: http://devicetree.org/schemas/arm/hisilicon/l3cache.yaml# >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>> + >>>> +title: Hisilicon L3 cache controller >>>> + >>>> +maintainers: >>>> + - Wei Xu <xuwei5@hisilicon.com> >>>> + >>>> +description: | >>>> + The Hisilicon L3 outer cache controller supports a maximum of 36-bit physical >>>> + addresses. The data cached in the L3 outer cache can be operated based on the >>>> + physical address range or the entire cache. >>>> + >>>> +properties: >>>> + compatible: >>>> + items: >>>> + - const: hisilicon,l3cache >>>> + >>> >>> The compatible string needs to be a little more specific, I'm sure >>> you cannot guarantee that this is the only L3 cache controller ever >>> designed in the past or future by HiSilicon. >>> >>> Normally when you have an IP block that is itself unnamed but that is specific >>> to one or a few SoCs but that has no na, the convention is to include the name >>> of the first SoC that contained it. >> >> Right, thanks for your suggestion, I will rename it to "hisilicon,hi1381-l3cache" >> and "hisilicon,hi1215-l3cache". Sorry, Just received a response from the hardware developers, the SoC names need to be changed: hi1381 --> kunpeng509 hi1215 --> kunpeng506 So I want to rename the compatible string to "hisilicon,kunpeng-l3v1", Kunpeng L3 cache controller version 1. This is enough to distinguish other versions of cache controller. It also facilitates the naming of the config option and files. > > Sounds good. > >>> Can you share which products actually use this L3 cache controller? >> >> This L3 cache controller is used on Hi1381 and Hi1215 board. I don't know where >> these two boards are used. Our company is too large. Software is delivered level >> by level. I'm only involved in the Kernel-related part. >> >>> >>> On a related note, what does the memory map look like on this chip? >> >> memory@a00000 { >> device_type = "memory"; >> reg = <0x0 0xa00000 0x0 0x1aa00000>, <0x1 0xe0000000 0x0 0x1d000000>, <0x0 0x1f400000 0x0 0xb5c00000>; >> }; >> >> Currently, the DTS is being maintained by ourselves, I'll try to upstream it later. >> >>> Do you support more than 4GB of total installed memory? If you >> >> Currently, the total size does not exceed 4 GB. However, the physical address is wider than 32 bits. > > Ok, so it appears that the memory is actually contiguous in the first > 3.5GB (with a few holes), plus the remaining 0.5GB being offset in > the physical memory by 4GB (starting at 0x1e0000000 instead of > 0xe0000000), presumably to allow the use of 32-bit DMA addresses. > > This works fine for the moment, but it does require support for > a nonlinear virt_to_phys()/phys_to_virt() translation after highmem > gets removed, and you would get at most 3.75GB anyway, so it > might be easier at that point to just drop the entire last block at > 0x1e0000000, but this will depend on how well we get the 4G:4G > code to work, and whether the users will still need kernel updates for > this platform then.> > Arnd > > . >
On 2021/1/13 15:44, Leizhen (ThunderTown) wrote: > > > On 2021/1/12 21:55, Arnd Bergmann wrote: >> On Tue, Jan 12, 2021 at 1:35 PM Leizhen (ThunderTown) >> <thunder.leizhen@huawei.com> wrote: >>> On 2021/1/12 16:46, Arnd Bergmann wrote: >>>> On Tue, Jan 12, 2021 at 2:56 AM Zhen Lei <thunder.leizhen@huawei.com> wrote: >>>> >>>>> +--- >>>>> +$id: http://devicetree.org/schemas/arm/hisilicon/l3cache.yaml# >>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>>> + >>>>> +title: Hisilicon L3 cache controller >>>>> + >>>>> +maintainers: >>>>> + - Wei Xu <xuwei5@hisilicon.com> >>>>> + >>>>> +description: | >>>>> + The Hisilicon L3 outer cache controller supports a maximum of 36-bit physical >>>>> + addresses. The data cached in the L3 outer cache can be operated based on the >>>>> + physical address range or the entire cache. >>>>> + >>>>> +properties: >>>>> + compatible: >>>>> + items: >>>>> + - const: hisilicon,l3cache >>>>> + >>>> >>>> The compatible string needs to be a little more specific, I'm sure >>>> you cannot guarantee that this is the only L3 cache controller ever >>>> designed in the past or future by HiSilicon. >>>> >>>> Normally when you have an IP block that is itself unnamed but that is specific >>>> to one or a few SoCs but that has no na, the convention is to include the name >>>> of the first SoC that contained it. >>> >>> Right, thanks for your suggestion, I will rename it to "hisilicon,hi1381-l3cache" >>> and "hisilicon,hi1215-l3cache". > > Sorry, Just received a response from the hardware developers, the SoC names need to > be changed: > hi1381 --> kunpeng509 > hi1215 --> kunpeng506 > > So I want to rename the compatible string to "hisilicon,kunpeng-l3v1", Kunpeng L3 I thought about it. Let's name it "hisilicon,kunpeng-l3cache", and then add v2 in the future. Maybe the SoC name is changed later, and v2 is not required. > cache controller version 1. This is enough to distinguish other versions of cache > controller. It also facilitates the naming of the config option and files. > >> >> Sounds good. >> >>>> Can you share which products actually use this L3 cache controller? >>> >>> This L3 cache controller is used on Hi1381 and Hi1215 board. I don't know where >>> these two boards are used. Our company is too large. Software is delivered level >>> by level. I'm only involved in the Kernel-related part. >>> >>>> >>>> On a related note, what does the memory map look like on this chip? >>> >>> memory@a00000 { >>> device_type = "memory"; >>> reg = <0x0 0xa00000 0x0 0x1aa00000>, <0x1 0xe0000000 0x0 0x1d000000>, <0x0 0x1f400000 0x0 0xb5c00000>; >>> }; >>> >>> Currently, the DTS is being maintained by ourselves, I'll try to upstream it later. >>> >>>> Do you support more than 4GB of total installed memory? If you >>> >>> Currently, the total size does not exceed 4 GB. However, the physical address is wider than 32 bits. >> >> Ok, so it appears that the memory is actually contiguous in the first >> 3.5GB (with a few holes), plus the remaining 0.5GB being offset in >> the physical memory by 4GB (starting at 0x1e0000000 instead of >> 0xe0000000), presumably to allow the use of 32-bit DMA addresses. >> >> This works fine for the moment, but it does require support for >> a nonlinear virt_to_phys()/phys_to_virt() translation after highmem >> gets removed, and you would get at most 3.75GB anyway, so it >> might be easier at that point to just drop the entire last block at >> 0x1e0000000, but this will depend on how well we get the 4G:4G >> code to work, and whether the users will still need kernel updates for >> this platform then.> >> Arnd >> >> . >> > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > . >
On Wed, Jan 13, 2021 at 9:13 AM Leizhen (ThunderTown) <thunder.leizhen@huawei.com> wrote: > On 2021/1/13 15:44, Leizhen (ThunderTown) wrote: > > On 2021/1/12 21:55, Arnd Bergmann wrote: > >> On Tue, Jan 12, 2021 at 1:35 PM Leizhen (ThunderTown) > >> <thunder.leizhen@huawei.com> wrote: > >>> On 2021/1/12 16:46, Arnd Bergmann wrote: > >>>> On Tue, Jan 12, 2021 at 2:56 AM Zhen Lei <thunder.leizhen@huawei.com> wrote: > >>>> > >>>>> +--- > >>>>> +$id: http://devicetree.org/schemas/arm/hisilicon/l3cache.yaml# > >>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >>>>> + > >>>>> +title: Hisilicon L3 cache controller > >>>>> + > >>>>> +maintainers: > >>>>> + - Wei Xu <xuwei5@hisilicon.com> > >>>>> + > >>>>> +description: | > >>>>> + The Hisilicon L3 outer cache controller supports a maximum of 36-bit physical > >>>>> + addresses. The data cached in the L3 outer cache can be operated based on the > >>>>> + physical address range or the entire cache. > >>>>> + > >>>>> +properties: > >>>>> + compatible: > >>>>> + items: > >>>>> + - const: hisilicon,l3cache > >>>>> + > >>>> > >>>> The compatible string needs to be a little more specific, I'm sure > >>>> you cannot guarantee that this is the only L3 cache controller ever > >>>> designed in the past or future by HiSilicon. > >>>> > >>>> Normally when you have an IP block that is itself unnamed but that is specific > >>>> to one or a few SoCs but that has no na, the convention is to include the name > >>>> of the first SoC that contained it. > >>> > >>> Right, thanks for your suggestion, I will rename it to "hisilicon,hi1381-l3cache" > >>> and "hisilicon,hi1215-l3cache". > > > > Sorry, Just received a response from the hardware developers, the SoC names need to > > be changed: > > hi1381 --> kunpeng509 > > hi1215 --> kunpeng506 > > > > So I want to rename the compatible string to "hisilicon,kunpeng-l3v1", Kunpeng L3 > > I thought about it. Let's name it "hisilicon,kunpeng-l3cache", and then add v2 in > the future. Maybe the SoC name is changed later, and v2 is not required. I would prefer the more specific name to be listed as well. You can use the generic "hisilicon,kunpeng-l3cache" as the key that the driver uses, but please also include the chip specific one here. We tend to use the chip identifiers (hi1381, ...), but if the marketing names (kunpeng509, ...) are now what they are known as in the data sheet, then use that. The problem with marketing names is that they are more often unrelated to the technology underneath. It's possible that there might be e.g. kunpeng507 chip that sold to the same customers but very different internally from kunpeng506/kunpeng509. This also happens with the chip numbers, but those tend to be more stable (at least for other manufacturers). Arnd
On 2021/1/13 19:15, Arnd Bergmann wrote: > On Wed, Jan 13, 2021 at 9:13 AM Leizhen (ThunderTown) > <thunder.leizhen@huawei.com> wrote: >> On 2021/1/13 15:44, Leizhen (ThunderTown) wrote: >>> On 2021/1/12 21:55, Arnd Bergmann wrote: >>>> On Tue, Jan 12, 2021 at 1:35 PM Leizhen (ThunderTown) >>>> <thunder.leizhen@huawei.com> wrote: >>>>> On 2021/1/12 16:46, Arnd Bergmann wrote: >>>>>> On Tue, Jan 12, 2021 at 2:56 AM Zhen Lei <thunder.leizhen@huawei.com> wrote: >>>>>> >>>>>>> +--- >>>>>>> +$id: http://devicetree.org/schemas/arm/hisilicon/l3cache.yaml# >>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>>>>> + >>>>>>> +title: Hisilicon L3 cache controller >>>>>>> + >>>>>>> +maintainers: >>>>>>> + - Wei Xu <xuwei5@hisilicon.com> >>>>>>> + >>>>>>> +description: | >>>>>>> + The Hisilicon L3 outer cache controller supports a maximum of 36-bit physical >>>>>>> + addresses. The data cached in the L3 outer cache can be operated based on the >>>>>>> + physical address range or the entire cache. >>>>>>> + >>>>>>> +properties: >>>>>>> + compatible: >>>>>>> + items: >>>>>>> + - const: hisilicon,l3cache >>>>>>> + >>>>>> >>>>>> The compatible string needs to be a little more specific, I'm sure >>>>>> you cannot guarantee that this is the only L3 cache controller ever >>>>>> designed in the past or future by HiSilicon. >>>>>> >>>>>> Normally when you have an IP block that is itself unnamed but that is specific >>>>>> to one or a few SoCs but that has no na, the convention is to include the name >>>>>> of the first SoC that contained it. >>>>> >>>>> Right, thanks for your suggestion, I will rename it to "hisilicon,hi1381-l3cache" >>>>> and "hisilicon,hi1215-l3cache". >>> >>> Sorry, Just received a response from the hardware developers, the SoC names need to >>> be changed: >>> hi1381 --> kunpeng509 >>> hi1215 --> kunpeng506 >>> >>> So I want to rename the compatible string to "hisilicon,kunpeng-l3v1", Kunpeng L3 >> >> I thought about it. Let's name it "hisilicon,kunpeng-l3cache", and then add v2 in >> the future. Maybe the SoC name is changed later, and v2 is not required. > > I would prefer the more specific name to be listed as well. You can > use the generic > "hisilicon,kunpeng-l3cache" as the key that the driver uses, but > please also include > the chip specific one here. Oh, yes. Sometimes, the "syscon" is used this way . The first string describes the component information，and the second string is used to match the driver. compatible = "hisilicon,kunpeng506-l3cache", "hisilicon,kunpeng-l3cache" > We tend to use the chip identifiers > (hi1381, ...), but if > the marketing names (kunpeng509, ...) are now what they are known as in the The hardware developers told me that hi1381 is the internal chip identifier, and should be deprecated. kunpeng509 is both chip identifier and marketing name. Kunpeng is the pinyin of two Chinese characters. They are two mythical animals. > data sheet, then use that. The problem with marketing names is that they are > more often unrelated to the technology underneath. It's possible that there > might be e.g. kunpeng507 chip that sold to the same customers but very different > internally from kunpeng506/kunpeng509. This also happens with the chip numbers, It shouldn't make a big difference，unless the first two numbers are different. > but those tend to be more stable (at least for other manufacturers). > > Arnd > > . >
diff --git a/Documentation/devicetree/bindings/arm/hisilicon/l3cache.yaml b/Documentation/devicetree/bindings/arm/hisilicon/l3cache.yaml new file mode 100644 index 000000000000000..f411818bad23741 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/hisilicon/l3cache.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/hisilicon/l3cache.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Hisilicon L3 cache controller + +maintainers: + - Wei Xu <xuwei5@hisilicon.com> + +description: | + The Hisilicon L3 outer cache controller supports a maximum of 36-bit physical + addresses. The data cached in the L3 outer cache can be operated based on the + physical address range or the entire cache. + +properties: + compatible: + items: + - const: hisilicon,l3cache + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + l3cache@f302b000 { + compatible = "hisilicon,l3cache"; + reg = <0xf302b000 0x1000>; + }; +...
Add devicetree binding for Hisilicon L3 cache controller. Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> --- .../bindings/arm/hisilicon/l3cache.yaml | 37 +++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/l3cache.yaml