Re: Audio Miniconference 2013 schedule II - Edinburgh 21st October

[Vinod Koul <vinod.koul@intel.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2603 bytes --]

On Tue, Oct 15, 2013 at 08:26:36PM +0100, Mark Brown wrote:
> On Tue, Oct 15, 2013 at 10:14:08PM +0530, Vinod Koul wrote:
> 
> > I want to bring the attention to DAPM framework bugs. Somehow recently I
> > stumbled on quite a few occasions of DAPM bugs and the best part was that the
> > fix was already availble upstream, ported to stable later version than I had or
> > NOT ported. Mark, can you pls help by ensuring the right fixes are marked to
> > stable so that users dont get hit by it!
> 
> Any specifics?  I'm generally very conservative about DAPM changes in
> stable because I don't want to break systems that are currently working
> by luck - giving people a reason to worry about stable updates isn't
> good.
I understand your point on that :)

On 3.4  was hit by DAPM sync bug as DAPM update gets triggered without holding
lock in few places, after realizing the problem I sae the fix was availble
mainline, clearly this should have been marked to stable.

commit 4edbb34577c98297f958f131e093a150b9f3226f

ASoC: dapm: lock mixer & mux update power with DAPM mutex

Both snd_soc_dapm_mux_update_power() and snd_soc_dapm_mixer_update_power() can
be called internally within DAPM core (with DAPM mutex held) and externally.

Provide some wrappers so that external users of both functions do not have to
remember to hold the DAPM mutex.

Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

Similar now on 3.10, I have this patch which was marked to stable :) but not in
version i was using.

commit: 2d49b5987561e480bdbd8692b27fc5f49a1e2f0b
regmap: cache: Make sure to sync the last register in a block

regcache_sync_block_raw_flush() expects the address of the register after last
register that needs to be synced as its parameter. But the last call to
regcache_sync_block_raw_flush() in regcache_sync_block_raw() passes the address
of the last register in the block. This effectively always skips over the last
register in a block, even if it needs to be synced. In order to fix it increase
the address by one register.
The issue was introduced in commit 75a5f89 ("regmap: cache: Write
consecutive registers in a single block write").
Cc: stable@vger.kernel.org # 3.10+
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>

> There's also sometimes some dependencies with development work which
> doesn't help.
And thats why I am not yet talking about DPCM as thats new and few issues need
to be ironed out :)

--
~Vinod



-- 

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]