Re: [PATCH v2 12/19] ASoC: SDCA: Add UMP buffer helper functions

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

On Wed, Sep 17, 2025 at 09:49:29PM +0200, Pierre-Louis Bossart wrote:
> I am still missing the big picture on when/where the timeouts
> read from DisCo properties are used.
> I looked at patch 14 and I don't see any timeouts used except
> for the reset.

Apologies I should have called out in the cover-letter patch 17
adds the timeouts.

> > + * The caller should first call sdca_ump_get_owner_host() to ensure the host
> > + * currently owns the UMP buffer, and then this function can be used to
> > + * retrieve a message. It is the callers responsibility to free the
> > + * message once it is finished with it. Finally sdca_ump_set_owner_device()
> > + * should be called to return the buffer to the device.
> 
> Maybe I misunderstood something in the UMP spec, but I could
> see a different flow where the host does a set_owner_device()
> and later reads the buffer updated by the device once the
> ownership is given back to the host.
> 
> I think you're assuming that a read is always initiated
> by the device, but what if the host wants to read something
> (volume/acoustic levels, etc) without getting any notification?
> 
> IOW, will a read only happen when the device throws an
> interrupt on its own? The spec doesn't seem very clear on
> this...

Assuming the host is currently holding ownership of the buffer,
then your example would look like:

1) host calls set_owner_device()
1.1) host optionally calls schedule_timeout() if it wants
2) the device then fills the buffer
3) device passes the ownership back to the host
4) host receives an IRQ on the buffer
4.1) host calls cancel_timeout() since ownership returned
5) host calls read_message() to get the data

The device should still throw an IRQ when it passes the buffer
back which the host responds to. IMHO there is no real difference
between the two use-cases you are talking about here.

A read can happen any time the host has ownership of the buffer
but the UMP helpers don't make assumptions here, if someone
implements code that calls read_message() not in response to an
IRQ that is fine. As long as they ensured they have ownership
first.

We do make slightly more assumptions in the current FDL code,
primarily that the FDL buffer has an ownership IRQ. There
is the slight corner case of a device that wanted to do FDL
but not support IRQs. But I think its fine not to support
everything especially kinda esoteric stuff in the first version
of the code.

Thanks,
Charles