>> +/*
>> + * Hardware recommendations are to wait ~10us before checking any hardware transition
>> + * reported by bits changing status.
>> + * This value does not need to be super-precise, a slack of 5us is perfectly acceptable.
>> + * The worst-case is about 1ms before reporting an issue
>> + */
>> +#define HDAML_POLL_DELAY_MIN_US 10
>> +#define HDAML_POLL_DELAY_SLACK_US 5
>> +#define HDAML_POLL_DELAY_RETRY 100
>> +
>> +static int check_power_active(u32 __iomem *lctl, int sublink, bool enable)
>> +{
>> + int mask = BIT(sublink) << AZX_ML_LCTL_CPA_SHIFT;
>> + int retry = HDAML_POLL_DELAY_RETRY;
>> + u32 val;
>> +
>> + usleep_range(HDAML_POLL_DELAY_MIN_US,
>> + HDAML_POLL_DELAY_MIN_US + HDAML_POLL_DELAY_SLACK_US);
>> + do {
>> + val = readl(lctl);
>> + if (enable) {
>> + if (val & mask)
>> + return 0;
>> + } else {
>> + if (!(val & mask))
>> + return 0;
>> + }
>> + usleep_range(HDAML_POLL_DELAY_MIN_US,
>> + HDAML_POLL_DELAY_MIN_US + HDAML_POLL_DELAY_SLACK_US);
>> +
>> + } while (--retry);
>> +
>> + return -EIO;
>> +}
>
> Can read_poll_timeout() and co be alternative?
Yes they can. I chose the simple route because I find it clearer, and
because we modified the sleep/retries compared to previous implementations.
here's what I wrote in the commit message:
"
Note that the _check_power_active() implementation is similar to
previous helpers in sound/hda/ext, with sleep duration and timeout
aligned with hardware recommendations. If desired, this helper could
be modified in a second step with .e.g. readl_poll_timeout()
"
If you want to jump directly to the next step that'd be fine. Peter had
the same comment, so I'll go with the flow.
