Date:   Wed, 13 Jan 2021 16:13:32 +0800
From:   "Leizhen (ThunderTown)" <thunder.leizhen@...wei.com>
To:     Arnd Bergmann <arnd@...nel.org>
CC:     devicetree <devicetree@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Will Deacon <will.deacon@....com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "Haojian Zhuang" <haojian.zhuang@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Wei Xu <xuwei5@...ilicon.com>,
        Russell King <rmk+kernel@....linux.org.uk>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v3 2/3] dt-bindings: arm: hisilicon: Add binding for L3
 cache controller



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@...wei.com> wrote:
>>> On 2021/1/12 16:46, Arnd Bergmann wrote:
>>>> On Tue, Jan 12, 2021 at 2:56 AM Zhen Lei <thunder.leizhen@...wei.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@...ilicon.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@...000 {
>>>      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@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> .
> 

Powered by blists - more mailing lists