lkml.org 
[lkml]   [2021]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v6 4/4] ARM: Add support for Hisilicon Kunpeng L3 cache controller
From
Date


On 2021/2/1 16:31, Arnd Bergmann wrote:
> On Mon, Feb 1, 2021 at 4:36 AM Zhen Lei <thunder.leizhen@huawei.com> wrote:
>>
>> Add support for the Hisilicon Kunpeng L3 cache controller as used with
>> Kunpeng506 and Kunpeng509 SoCs.
>>
>> These Hisilicon SoCs support LPAE, so the physical addresses is wider than
>> 32-bits, but the actual bit width does not exceed 36 bits. When the cache
>> operation is performed based on the address range, the upper 30 bits of
>> the physical address are recorded in registers L3_MAINT_START and
>> L3_MAINT_END, and ignore the lower 6 bits cacheline offset.
>>
>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
>
> If you add one more thing:
>
>> +static void l3cache_maint_common(u32 range, u32 op_type)
>> +{
>> + u32 reg;
>> +
>> + reg = readl_relaxed(l3_ctrl_base + L3_MAINT_CTRL);
>> + reg &= ~(L3_MAINT_RANGE_MASK | L3_MAINT_TYPE_MASK);
>> + reg |= range | op_type;
>> + reg |= L3_MAINT_STATUS_START;
>> + writel(reg, l3_ctrl_base + L3_MAINT_CTRL);
>> +
>> + /* Wait until the hardware maintenance operation is complete. */
>> + do {
>> + cpu_relax();
>> + reg = readl(l3_ctrl_base + L3_MAINT_CTRL);
>> + } while ((reg & L3_MAINT_STATUS_MASK) != L3_MAINT_STATUS_END);
>> +}
>> +
>> +static void l3cache_maint_range(phys_addr_t start, phys_addr_t end, u32 op_type)
>> +{
>> + start = start >> L3_CACHE_LINE_SHITF;
>> + end = ((end - 1) >> L3_CACHE_LINE_SHITF) + 1;
>> +
>> + writel_relaxed(start, l3_ctrl_base + L3_MAINT_START);
>> + writel_relaxed(end, l3_ctrl_base + L3_MAINT_END);
>> +
>> + l3cache_maint_common(L3_MAINT_RANGE_ADDR, op_type);
>> +}
>
> As mentioned, I'd like to see a code comment that explains the use
> the of relaxed() vs non-relaxed MMIO accessors, as it will be impossible
> for a reader to later understand why you picked a mix of the two,
> and it also ensures that you have considered which one is the best
> option to use here and that your explanation matches what you do.

OK, I'll test the performance and add the comment.

>
> Based on Russell's comments, I had expected that you would use
> only relaxed accessors, plus explicit barriers if you change it, matching
> what l2x0 does (l2x0 has to do it because of __l2c210_cache_sync(),
> while you don't have a sync callback and don't need to).

I might have been a little conservative, I'll change all of them to _relaxed and then test it. Thanks.

>
> Arnd
>
> .
>

\
 
 \ /
  Last update: 2021-02-01 12:41    [W:0.068 / U:1.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site