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

[Charles Keepax <ckeepax@opensource.cirrus.com>]

On Fri, Sep 12, 2025 at 12:15:45PM +0200, Pierre-Louis Bossart wrote:
> 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 :-(

Ha, you and me both.

> 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.

Our devices only download a since chunk so we haven't added
support yet for the indirect FDL yet. Which keeps things a
little simpler and means we can file work out the chunk size as a
problem for later. Although my rough interpretation of that bit
is that the chunk size is defined by the UMP buffer itself, so
basically the host fills the whole buffer each time, but if the
file is larger than the buffer it takes a few goes to send it all.

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

Yeah mainly my question was that it says "wait until" but I have
never been able to define what that wait is. One possible
interpretation is as soon as you see the device not requesting
FDL you can progress, but perhaps a safer interpretation is if
you see X milliseconds without an FDL request you can progress
which is what we have gone with in the code for now. Was really
just hoping you were going to be like "you also missed this other
useful DisCo property" :-)

But I am just about to push up a v2 so we can carry on the chats
on those.

Thanks,
Charles