On Tue, Aug 24, 2021 at 11:02:57AM -0500, Pierre-Louis Bossart wrote:
On 8/23/21 11:16 PM, Seven Lee wrote:
+static inline void nau8821_sema_release(struct nau8821 *nau8821) +{
- if (!nau8821->irq)
return;- up(&nau8821->jd_sem);
+}
is there any specific reason why Nuvoton codec drivers use a semaphore? isn't a mutex good enough?
I've been asking for documentation of what's going on with the locking on every revision of this so far to no success. As far as I can tell the driver is doing something weird where it needs to take and release the lock in different contexts which doesn't work with the kernel's mutex implementation where you need to take and release the mutex in the same context.
- switch (event) {
- case SND_SOC_DAPM_POST_PMU:
msleep(125);use a define to keep track of sleep times in a header file?
I'm never sure that moving the magic numbers for sleeps out of line is actually helpful, it's an extra barrier to figuring out the actual sequence of operations and unless there's multiple users of the same underlying delay it doesn't really buy anything.