[alsa-devel] [PATCH] ASoC: si476x: Remove custom register I/O implementation

Andrey Smirnov andrew.smirnov at gmail.com
Fri Sep 27 21:28:14 CEST 2013

On Fri, Sep 27, 2013 at 10:02 AM, Mark Brown <broonie at kernel.org> wrote:
> On Fri, Sep 27, 2013 at 08:53:58AM -0700, Andrey Smirnov wrote:
>> > OK, so if it's purely about send_command() then why is the locking not
>> > being done in that function?  Surely the most obvious and robust place
>> > to protect the function is within the function itself?
>> Not having send_command acquire any locks allows me to have variable
>> levels of granularity of locking, for example in the worker thread
>> that fetches RDS data from the chip it allows me to get exclusive
>> access to the chip for the duration of the FIFO draining. Also any
>> band switch for that chip, like AM to FM, etc. require chip to be
>> power cycled which translates to multiple calls to send_command as
>> well, I think having those performed atomically simplifies the driver
>> as well.
> Right, so it's not just protecting send_command() but is instead
> protecting higher level things.  In that case shouldn't the locking be
> performed further up in this driver too rather than on each register
> write?

That is the case for the V4L driver, in that code the locking is
acquired for logical operations, such "tune" or "power up" rather than
for a single register write, but for the codec driver, to the best of
my knowledge, read and write register are the highest level operations
that it provides. Or am I just unaware of some codec driver
functionality that driver can provide and SoC sound subsystem will use
that would allow the lock to be obtained at higher levels?

More information about the Alsa-devel mailing list