On 2/12/26 4:05 PM, Shameer Kolothum Thodi wrote:
>
>> -----Original Message-----
>> From: Eric Auger <[email protected]>
>> Sent: 12 February 2026 14:57
>> To: Shameer Kolothum Thodi <[email protected]>; Nicolin Chen
>> <[email protected]>
>> Cc: [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected]; Nathan Chen
>> <[email protected]>; Matt Ochs <[email protected]>; Jiandi An
>> <[email protected]>; Jason Gunthorpe <[email protected]>;
>> [email protected]; [email protected];
>> [email protected]; Krishnakant Jaju <[email protected]>
>> Subject: Re: [PATCH v2 05/24] hw/arm/smmuv3-accel: Introduce CMDQV ops
>> interface
>>>> I had
>>>> the impression you reverted to a fallback impl. If there is
>>>> specialization, I still think ops are relevant. Eric
>>> There is no fallback implementation. So just to confirm, you are suggesting
>>> to remove the ops completely or just keep the ops for reset/init only?
>> Depends on the code to come next. If your reset and init really differs
>> between normal accel SMMU and vcmdq enhanced accel SMMU, to me it is
>> still relevant to have separate implementations in different callbacks.
> It is not an either/or case.
>
> The vCMDQ path does not replace the normal accelerated SMMU init/reset.
> Instead, it requires additional init/reset steps on top of the regular accel
> flow.
>
> if (accel)
> accel_init();
>
> if (accel && cmdqv)
> cmdqv_init();
>
> So the vCMDQ logic is an extension of the accelerated mode, not a fallback
> or alternative implementation.
>
> I think the later patches in the series make this clearer.
> Please let me know if you still feel the ops necessary.
do we have any way to introspect from the kernel what cmdq type we have,
so that we could have a cmdqv option with ON/OFF/AUTO value instead of
duplication cmdq option for each vendor?
Eric
>
> Thanks,
> Shameer
