[RFC PATCH v6 7/9] accel/rocket: add RK3576 NPU (RKNN) support

Chaoyi Chen chaoyi.chen at rock-chips.com
Mon Aug 10 18:08:59 PDT 2026


Hi Jiaxing,

On 8/10/2026 6:47 PM, Jiaxing Hu wrote:
> Hi Chaoyi,
> 
> Thank you, that settles it, and no apology needed for not reading the
> series.
> 
>> For RK3576:
>>
>> - BIT[15:0] task_number
>> - BIT[16] task_pp_en
>> - BIT[17] task_count_clear
>> - BIT[18] task_last_layer_clear
> 
> That matches the register trace bit for bit, and it is worth more than
> the trace, because the trace could only say which word the vendor writes
> and not what the bits in it are.
> 
> BIT[18] is new to me. I was setting it because the vendor's word had it
> set and clearing it was not something I wanted to try blind. Now it can
> be named rather than shipped as 0x7 << 16:
> 
>   #define PC_TASK_CON_TASK_NUMBER		GENMASK(15, 0)
>   #define PC_TASK_CON_TASK_PP_EN		BIT(16)
>   #define PC_TASK_CON_TASK_COUNT_CLEAR		BIT(17)
>   #define PC_TASK_CON_TASK_LAST_LAYER_CLEAR	BIT(18)
> 
> with the RK3588 positions kept beside them, since the two differ only in
> the width of the first field and that is exactly what made v1 through v6
> wrong.
> 
> One question, if you have a moment. Is task_last_layer_clear meant to be
> set on every submit, or only on the task that ends a layer? Setting it
> unconditionally works on RK3576 here, but working and being right are
> not the same thing, and I would rather not encode a guess in a driver
> other people will copy from.

I think it should be for every submit. That is, when you set task_count_clear,
you should also set task_last_layer_clear at the same time.

> 
> Thanks again,
> Jiaxing
> 
> 

-- 
Best, 
Chaoyi



More information about the linux-arm-kernel mailing list