Re: [PATCH 09/15] ASoC: SDCA: Add UMP buffer helper functions

[Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>]

On 9/11/25 15:07, Charles Keepax wrote:
> On Thu, Sep 11, 2025 at 02:33:46PM +0200, Pierre-Louis Bossart wrote:
>>> Once these timeouts exist we have to pick values for them,
>>> because SDCA is a huge huge fan of asking you to wait for
>>> something but not saying for how long. If you have any thoughts
>>> on this that would be appreciated too, but mostly I will just
>>> pluck some vaguely reasonable sounding values as I did for the
>>> existing FDL timeouts.
>>
>> The SDCA 1.0 spec defines DisCo properties for UMP timeouts,
>> just do a search for "ownership-transition-max-delay". Table 139
>> page 236 defines this property specifically for XUs and hence
>> the low-level protocol FDL is based on.
>>
>> The description reads:
>>
>> "
>> The maximum time allowed for Device to change the
>> ownership from Device to Host in an Rx UMP when Host
>> Software is waiting for the owner to change back to Host.
>> "
>>
>> As usual it's quite possible that platform firmware is broken
>> with bad values, but the design intent was to provide a timeout
>> value for software to use. Ignoring these properties doesn't
>> seem quite right to me...
> 
> No, I had missed this property! That is excellent. Don't suppose
> you have a similar magic touch with the "Wait until there are
> no new requests for File Download" in the Class Software Load
> Sequence?

Glad I was able to help!

The FDL state machine is rather complicated, I can't pretend understanding it fully :-(

My limited understanding is that the Host doesn't control which firmware files need to be downloaded. The Device will provide detailed information back to the host. That's how I interpret the vague statement in Figure 213:

"Device interprets
FDL_Host_request and perhaps
requests one or more new
FDL_Set_Index(es)."

IOW the number of sets to download is indicated in the FDLD_Needs_set control. Based on the bit pattern in Table 240, there can be up to 8 sets (3 bits).

The main issue I have is that the files will be transmitted by chunks. I am not quite sure who defines the size of the chunks, but each chunk should be handled by the same "ownership-transition-max-delay" property. It's rather odd that the timeout doesn't depend on the size of the chunk, but assuming this is correct the time to download should be bound by number of sets x number of chunks per set x ownership-transition-max-delay.

That's the limited extended of my FDL "magic touch" I am afraid...