On 2021/8/25 上午 01:32, Mark Brown wrote:
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.
Currently, we have deleted the semaphore and actual measurement. We plan to
remove the semaphore after estimation and discussion. We estimate that the
operation time of jack detection is less 100ms so that the risk is much
smaller.
+ 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.
I agree with Mark description.
