[PATCH] ASoC: nau8821: Add driver for Nuvoton codec NAU88L21

Seven Lee scott6986 at gmail.com
Wed Sep 15 05:50:56 CEST 2021


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.



More information about the Alsa-devel mailing list