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

[Andrey Smirnov]

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?