+/*
- 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.