Re: [PATCH v6 10/10] arm_mpam: detect and enable MPAM-Fb PCC support

Hi Lee,

On 7/31/26 00:28, Lee Trager wrote:
> 
> On 7/30/26 8:25 AM, Andre Przywara wrote:
>> +static struct mpam_pcc_chan *mpam_pcc_chan_get(struct device *dev,
>> +                           int subspace_id)
>> +{
>> +    struct mpam_pcc_chan *cur;
>> +
>> +    guard(mutex)(&pcc_chan_list_lock);
>> +
>> +    list_for_each_entry(cur, &pcc_chan_list, pcc_chans) {
>> +        if (cur->subspace_id == subspace_id) {
>> +            kref_get(&cur->refcount);
>> +
>> +            return cur;
>> +        }
>> +    }
>> +
>> +    cur = kzalloc_obj(*cur);
>> +    if (!cur)
>> +        return ERR_PTR(-ENOMEM);
>> +
>> +    cur->pcc_cl.dev = dev;
>> +    cur->pcc_cl.tx_block = true;
>> +
>> +    cur->pcc_chan = pcc_mbox_request_channel(&cur->pcc_cl, subspace_id);
>> +    if (IS_ERR(cur->pcc_chan)) {
>> +        long err = PTR_ERR(cur->pcc_chan);
>> +
>> +        kfree(cur);
>> +        return ERR_PTR(err);
>> +    }
>> +
>> +    /* Timeout based on the "nominal latency" from the PCC ACPI 
>> table. */
>> +    cur->pcc_cl.tx_tout = cur->pcc_chan->latency * 5;
> I think this may need a unit conversion. ACPI 6.6 describes PCC nominal 
> latency in microseconds, and the PCC mailbox driver appears to copy that 
> value directly into pcc_chan->latency. However mbox_client::tx_tout is 
> documented in milliseconds.

Ah, good point, they are indeed using different units.
Will fix that.

Thanks,
Andre

> If I'm reading that correctly, assigning latency * 5 would make the 
> timeout 1000 times longer than intended. Would something like this be 
> better?
> 
> cur->pcc_cl.tx_tout = DIV_ROUND_UP_ULL((u64)cur->pcc_chan->latency * 5, 
> USEC_PER_MSEC);