On Fri, Sep 27, 2013 at 10:02 AM, Mark Brown broonie@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?