[PATCH 1/5] ASoC: fsl_asrc: use flat regmap cache

[PATCH 1/5] ASoC: fsl_asrc: use flat regmap cache

[Marek Vasut]

Same as commit ce492b3b8f99cf9d2f807ec22d8805c996a09503
Subject: drm/fsl-dcu: use flat regmap cache

Using flat regmap cache instead of RB-tree to avoid the following
lockdep warning on driver load:
WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2871 lockdep_trace_alloc+0x104/0x128
DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))

The RB-tree regmap cache needs to allocate new space on first
writes. However, allocations in an atomic context (e.g. when a
spinlock is held) are not allowed. The function regmap_write
calls map->lock, which acquires a spinlock in the fast_io case.
Since the driver uses MMIO, the regmap bus of type regmap_mmio
is being used which has fast_io set to true.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Nicolin Chen <nicoleotsuka@gmail.com>
Cc: Timur Tabi <timur@tabi.org>
Cc: Xiubo Li <Xiubo.Lee@gmail.com>
---
 sound/soc/fsl/fsl_asrc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index b7157ce..1d82f68 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -726,7 +726,7 @@ static const struct regmap_config fsl_asrc_regmap_config = {
 	.readable_reg = fsl_asrc_readable_reg,
 	.volatile_reg = fsl_asrc_volatile_reg,
 	.writeable_reg = fsl_asrc_writeable_reg,
-	.cache_type = REGCACHE_RBTREE,
+	.cache_type = REGCACHE_FLAT,
 };
 
 /**
-- 
2.9.3

[PATCH 2/5] ASoC: fsl_esai: use flat regmap cache

[Marek Vasut]

Same as commit ce492b3b8f99cf9d2f807ec22d8805c996a09503
Subject: drm/fsl-dcu: use flat regmap cache

Using flat regmap cache instead of RB-tree to avoid the following
lockdep warning on driver load:
WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2871 lockdep_trace_alloc+0x104/0x128
DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))

The RB-tree regmap cache needs to allocate new space on first
writes. However, allocations in an atomic context (e.g. when a
spinlock is held) are not allowed. The function regmap_write
calls map->lock, which acquires a spinlock in the fast_io case.
Since the driver uses MMIO, the regmap bus of type regmap_mmio
is being used which has fast_io set to true.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Nicolin Chen <nicoleotsuka@gmail.com>
Cc: Timur Tabi <timur@tabi.org>
Cc: Xiubo Li <Xiubo.Lee@gmail.com>
---
 sound/soc/fsl/fsl_esai.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index e927955..38bfd46 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -781,7 +781,7 @@ static const struct regmap_config fsl_esai_regmap_config = {
 	.readable_reg = fsl_esai_readable_reg,
 	.volatile_reg = fsl_esai_volatile_reg,
 	.writeable_reg = fsl_esai_writeable_reg,
-	.cache_type = REGCACHE_RBTREE,
+	.cache_type = REGCACHE_FLAT,
 };
 
 static int fsl_esai_probe(struct platform_device *pdev)
-- 
2.9.3

Applied "ASoC: fsl_esai: use flat regmap cache" to the asoc tree

[Mark Brown]

The patch

   ASoC: fsl_esai: use flat regmap cache

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 0effb8651ee3b00513fbba9ef3912bbcbbd38af6 Mon Sep 17 00:00:00 2001
From: Marek Vasut <marex@denx.de>
Date: Mon, 19 Sep 2016 21:30:26 +0200
Subject: [PATCH] ASoC: fsl_esai: use flat regmap cache

Same as commit ce492b3b8f99cf9d2f807ec22d8805c996a09503
Subject: drm/fsl-dcu: use flat regmap cache

Using flat regmap cache instead of RB-tree to avoid the following
lockdep warning on driver load:
WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2871 lockdep_trace_alloc+0x104/0x128
DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))

The RB-tree regmap cache needs to allocate new space on first
writes. However, allocations in an atomic context (e.g. when a
spinlock is held) are not allowed. The function regmap_write
calls map->lock, which acquires a spinlock in the fast_io case.
Since the driver uses MMIO, the regmap bus of type regmap_mmio
is being used which has fast_io set to true.

Signed-off-by: Marek Vasut <marex@denx.de>
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 sound/soc/fsl/fsl_esai.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index e927955ba982..38bfd46f4ad8 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -781,7 +781,7 @@ static const struct regmap_config fsl_esai_regmap_config = {
 	.readable_reg = fsl_esai_readable_reg,
 	.volatile_reg = fsl_esai_volatile_reg,
 	.writeable_reg = fsl_esai_writeable_reg,
-	.cache_type = REGCACHE_RBTREE,
+	.cache_type = REGCACHE_FLAT,
 };
 
 static int fsl_esai_probe(struct platform_device *pdev)
-- 
2.8.1

[PATCH 3/5] ASoC: fsl_spdif: use flat regmap cache

[Marek Vasut]

Same as commit ce492b3b8f99cf9d2f807ec22d8805c996a09503
Subject: drm/fsl-dcu: use flat regmap cache

Using flat regmap cache instead of RB-tree to avoid the following
lockdep warning on driver load:
WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2871 lockdep_trace_alloc+0x104/0x128
DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))

The RB-tree regmap cache needs to allocate new space on first
writes. However, allocations in an atomic context (e.g. when a
spinlock is held) are not allowed. The function regmap_write
calls map->lock, which acquires a spinlock in the fast_io case.
Since the driver uses MMIO, the regmap bus of type regmap_mmio
is being used which has fast_io set to true.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Nicolin Chen <nicoleotsuka@gmail.com>
Cc: Timur Tabi <timur@tabi.org>
Cc: Xiubo Li <Xiubo.Lee@gmail.com>
---
 sound/soc/fsl/fsl_spdif.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
index beec793..1ff467c 100644
--- a/sound/soc/fsl/fsl_spdif.c
+++ b/sound/soc/fsl/fsl_spdif.c
@@ -1103,7 +1103,7 @@ static const struct regmap_config fsl_spdif_regmap_config = {
 	.readable_reg = fsl_spdif_readable_reg,
 	.volatile_reg = fsl_spdif_volatile_reg,
 	.writeable_reg = fsl_spdif_writeable_reg,
-	.cache_type = REGCACHE_RBTREE,
+	.cache_type = REGCACHE_FLAT,
 };
 
 static u32 fsl_spdif_txclk_caldiv(struct fsl_spdif_priv *spdif_priv,
-- 
2.9.3

Applied "ASoC: fsl_spdif: use flat regmap cache" to the asoc tree

[Mark Brown]

The patch

   ASoC: fsl_spdif: use flat regmap cache

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 35ddb15757cd1c817e424c6252d2f11f268cfebf Mon Sep 17 00:00:00 2001
From: Marek Vasut <marex@denx.de>
Date: Mon, 19 Sep 2016 21:30:27 +0200
Subject: [PATCH] ASoC: fsl_spdif: use flat regmap cache

Same as commit ce492b3b8f99cf9d2f807ec22d8805c996a09503
Subject: drm/fsl-dcu: use flat regmap cache

Using flat regmap cache instead of RB-tree to avoid the following
lockdep warning on driver load:
WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2871 lockdep_trace_alloc+0x104/0x128
DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))

The RB-tree regmap cache needs to allocate new space on first
writes. However, allocations in an atomic context (e.g. when a
spinlock is held) are not allowed. The function regmap_write
calls map->lock, which acquires a spinlock in the fast_io case.
Since the driver uses MMIO, the regmap bus of type regmap_mmio
is being used which has fast_io set to true.

Signed-off-by: Marek Vasut <marex@denx.de>
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 sound/soc/fsl/fsl_spdif.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
index beec7934a265..1ff467c9598a 100644
--- a/sound/soc/fsl/fsl_spdif.c
+++ b/sound/soc/fsl/fsl_spdif.c
@@ -1103,7 +1103,7 @@ static const struct regmap_config fsl_spdif_regmap_config = {
 	.readable_reg = fsl_spdif_readable_reg,
 	.volatile_reg = fsl_spdif_volatile_reg,
 	.writeable_reg = fsl_spdif_writeable_reg,
-	.cache_type = REGCACHE_RBTREE,
+	.cache_type = REGCACHE_FLAT,
 };
 
 static u32 fsl_spdif_txclk_caldiv(struct fsl_spdif_priv *spdif_priv,
-- 
2.8.1

[PATCH 4/5] ASoC: fsl_ssi: use flat regmap cache

[Marek Vasut]

Same as commit ce492b3b8f99cf9d2f807ec22d8805c996a09503
Subject: drm/fsl-dcu: use flat regmap cache

Using flat regmap cache instead of RB-tree to avoid the following
lockdep warning on driver load:
WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2871 lockdep_trace_alloc+0x104/0x128
DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))

The RB-tree regmap cache needs to allocate new space on first
writes. However, allocations in an atomic context (e.g. when a
spinlock is held) are not allowed. The function regmap_write
calls map->lock, which acquires a spinlock in the fast_io case.
Since the driver uses MMIO, the regmap bus of type regmap_mmio
is being used which has fast_io set to true.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Nicolin Chen <nicoleotsuka@gmail.com>
Cc: Timur Tabi <timur@tabi.org>
Cc: Xiubo Li <Xiubo.Lee@gmail.com>
---
 sound/soc/fsl/fsl_ssi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index bedec4a..5034943 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -182,7 +182,7 @@ static const struct regmap_config fsl_ssi_regconfig = {
 	.volatile_reg = fsl_ssi_volatile_reg,
 	.precious_reg = fsl_ssi_precious_reg,
 	.writeable_reg = fsl_ssi_writeable_reg,
-	.cache_type = REGCACHE_RBTREE,
+	.cache_type = REGCACHE_FLAT,
 };
 
 struct fsl_ssi_soc_data {
-- 
2.9.3

Applied "ASoC: fsl_ssi: use flat regmap cache" to the asoc tree

[Mark Brown]

The patch

   ASoC: fsl_ssi: use flat regmap cache

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From bfcf928d7604692668a7c33b783d05b8e3459d09 Mon Sep 17 00:00:00 2001
From: Marek Vasut <marex@denx.de>
Date: Mon, 19 Sep 2016 21:30:28 +0200
Subject: [PATCH] ASoC: fsl_ssi: use flat regmap cache

Same as commit ce492b3b8f99cf9d2f807ec22d8805c996a09503
Subject: drm/fsl-dcu: use flat regmap cache

Using flat regmap cache instead of RB-tree to avoid the following
lockdep warning on driver load:
WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2871 lockdep_trace_alloc+0x104/0x128
DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))

The RB-tree regmap cache needs to allocate new space on first
writes. However, allocations in an atomic context (e.g. when a
spinlock is held) are not allowed. The function regmap_write
calls map->lock, which acquires a spinlock in the fast_io case.
Since the driver uses MMIO, the regmap bus of type regmap_mmio
is being used which has fast_io set to true.

Signed-off-by: Marek Vasut <marex@denx.de>
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 sound/soc/fsl/fsl_ssi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index bedec4a32581..50349437d961 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -182,7 +182,7 @@ static const struct regmap_config fsl_ssi_regconfig = {
 	.volatile_reg = fsl_ssi_volatile_reg,
 	.precious_reg = fsl_ssi_precious_reg,
 	.writeable_reg = fsl_ssi_writeable_reg,
-	.cache_type = REGCACHE_RBTREE,
+	.cache_type = REGCACHE_FLAT,
 };
 
 struct fsl_ssi_soc_data {
-- 
2.8.1

Re: [PATCH 4/5] ASoC: fsl_ssi: use flat regmap cache

[Maciej S. Szmigiero]

Hi Marek,

On 19.09.2016 21:30, Marek Vasut wrote:
> Same as commit ce492b3b8f99cf9d2f807ec22d8805c996a09503
> Subject: drm/fsl-dcu: use flat regmap cache
> 
> Using flat regmap cache instead of RB-tree to avoid the following
> lockdep warning on driver load:
> WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2871 lockdep_trace_alloc+0x104/0x128
> DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
> 
> The RB-tree regmap cache needs to allocate new space on first
> writes.

That's why SSI driver had .num_reg_defaults_raw set in regmap config.
With this set and .reg_defaults_raw unset regcache_hw_init() will read
existing register content which then will be used to populate cache
(and so allocate RB tree nodes) at regcache initialization time.

This means that allocation of new cache RB tree nodes should never happen
during actual write.
If you get a warning that it happened then maybe there is a write to
some register not covered by .num_reg_defaults_raw - this should be
fixed.

The problem with flat cache is that it is zero-initialized, that is,
all registers are assumed to contain zeros by default.
This is generally not true in case of SSI so reads from and bit updates
in non-volatile registers will corrupt their value.

You can also refer to discussion when .num_reg_defaults_raw was first
added here:
http://www.gossamer-threads.com/lists/linux/kernel/2330573

Maciej

Re: [PATCH 4/5] ASoC: fsl_ssi: use flat regmap cache

[Marek Vasut]

On 09/21/2016 06:28 PM, Maciej S. Szmigiero wrote:
> Hi Marek,

Hi!

> On 19.09.2016 21:30, Marek Vasut wrote:
>> Same as commit ce492b3b8f99cf9d2f807ec22d8805c996a09503
>> Subject: drm/fsl-dcu: use flat regmap cache
>>
>> Using flat regmap cache instead of RB-tree to avoid the following
>> lockdep warning on driver load:
>> WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2871 lockdep_trace_alloc+0x104/0x128
>> DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
>>
>> The RB-tree regmap cache needs to allocate new space on first
>> writes.
> 
> That's why SSI driver had .num_reg_defaults_raw set in regmap config.
> With this set and .reg_defaults_raw unset regcache_hw_init() will read
> existing register content which then will be used to populate cache
> (and so allocate RB tree nodes) at regcache initialization time.

OK

> This means that allocation of new cache RB tree nodes should never happen
> during actual write.
> If you get a warning that it happened then maybe there is a write to
> some register not covered by .num_reg_defaults_raw - this should be
> fixed.

I might be blind, but I really don't see that. I just discussed it with
Mark and he thinks the same. I will revisit this one more time.

> The problem with flat cache is that it is zero-initialized, that is,
> all registers are assumed to contain zeros by default.
> This is generally not true in case of SSI so reads from and bit updates
> in non-volatile registers will corrupt their value.

This will let the driver init the hardware into a well-defined state.
Are there any bits in the SSI config registers which we must preserve?

> You can also refer to discussion when .num_reg_defaults_raw was first
> added here:
> http://www.gossamer-threads.com/lists/linux/kernel/2330573

Thanks!

> Maciej
> 


-- 
Best regards,
Marek Vasut

Re: [PATCH 4/5] ASoC: fsl_ssi: use flat regmap cache

[Maciej S. Szmigiero]

On 21.09.2016 21:32, Marek Vasut wrote:
> On 09/21/2016 06:28 PM, Maciej S. Szmigiero wrote:
>> Hi Marek,
> 
> Hi!
> 
>> On 19.09.2016 21:30, Marek Vasut wrote:
(..)
>>> The RB-tree regmap cache needs to allocate new space on first
>>> writes.
>>
>> That's why SSI driver had .num_reg_defaults_raw set in regmap config.
>> With this set and .reg_defaults_raw unset regcache_hw_init() will read
>> existing register content which then will be used to populate cache
>> (and so allocate RB tree nodes) at regcache initialization time.
> 
> OK
> 
>> This means that allocation of new cache RB tree nodes should never happen
>> during actual write.
>> If you get a warning that it happened then maybe there is a write to
>> some register not covered by .num_reg_defaults_raw - this should be
>> fixed.
> 
> I might be blind, but I really don't see that. I just discussed it with
> Mark and he thinks the same. I will revisit this one more time.

Maybe it would be possible to get a backtrace when that warning was
generated so we know which register write or update triggers new cache
allocation?

>> The problem with flat cache is that it is zero-initialized, that is,
>> all registers are assumed to contain zeros by default.
>> This is generally not true in case of SSI so reads from and bit updates
>> in non-volatile registers will corrupt their value.
> 
> This will let the driver init the hardware into a well-defined state.
> Are there any bits in the SSI config registers which we must preserve?

Hard to tell, this would need to be checked, but when datasheet values
were used as cache defaults the SoC locked up when the fsl_ssi module
was reloaded, at least in AC'97 mode.

I guess with zeros as defaults similar problems could occur.

Maciej

Re: [PATCH 4/5] ASoC: fsl_ssi: use flat regmap cache

[Marek Vasut]

On 09/22/2016 12:18 AM, Maciej S. Szmigiero wrote:
> On 21.09.2016 21:32, Marek Vasut wrote:
>> On 09/21/2016 06:28 PM, Maciej S. Szmigiero wrote:
>>> Hi Marek,
>>
>> Hi!
>>
>>> On 19.09.2016 21:30, Marek Vasut wrote:
> (..)
>>>> The RB-tree regmap cache needs to allocate new space on first
>>>> writes.
>>>
>>> That's why SSI driver had .num_reg_defaults_raw set in regmap config.
>>> With this set and .reg_defaults_raw unset regcache_hw_init() will read
>>> existing register content which then will be used to populate cache
>>> (and so allocate RB tree nodes) at regcache initialization time.
>>
>> OK
>>
>>> This means that allocation of new cache RB tree nodes should never happen
>>> during actual write.
>>> If you get a warning that it happened then maybe there is a write to
>>> some register not covered by .num_reg_defaults_raw - this should be
>>> fixed.
>>
>> I might be blind, but I really don't see that. I just discussed it with
>> Mark and he thinks the same. I will revisit this one more time.
> 
> Maybe it would be possible to get a backtrace when that warning was
> generated so we know which register write or update triggers new cache
> allocation?

See patch 5/5 .

>>> The problem with flat cache is that it is zero-initialized, that is,
>>> all registers are assumed to contain zeros by default.
>>> This is generally not true in case of SSI so reads from and bit updates
>>> in non-volatile registers will corrupt their value.
>>
>> This will let the driver init the hardware into a well-defined state.
>> Are there any bits in the SSI config registers which we must preserve?
> 
> Hard to tell, this would need to be checked, but when datasheet values
> were used as cache defaults the SoC locked up when the fsl_ssi module
> was reloaded, at least in AC'97 mode.
> 
> I guess with zeros as defaults similar problems could occur.

I don't observe any problem either way on MX6SX , which should cover
also most of the MX6es.

> Maciej
> 


-- 
Best regards,
Marek Vasut

Re: [PATCH 4/5] ASoC: fsl_ssi: use flat regmap cache

[Maciej S. Szmigiero]

On 22.09.2016 00:45, Marek Vasut wrote:
> On 09/22/2016 12:18 AM, Maciej S. Szmigiero wrote:
>> On 21.09.2016 21:32, Marek Vasut wrote:
>>> On 09/21/2016 06:28 PM, Maciej S. Szmigiero wrote:
>>>> Hi Marek,
>>>
>>> Hi!
>>>
>>>> On 19.09.2016 21:30, Marek Vasut wrote:
>> (..)
>>>>> The RB-tree regmap cache needs to allocate new space on first
>>>>> writes.
>>>>
>>>> That's why SSI driver had .num_reg_defaults_raw set in regmap config.
>>>> With this set and .reg_defaults_raw unset regcache_hw_init() will read
>>>> existing register content which then will be used to populate cache
>>>> (and so allocate RB tree nodes) at regcache initialization time.
>>>
>>> OK
>>>
>>>> This means that allocation of new cache RB tree nodes should never happen
>>>> during actual write.
>>>> If you get a warning that it happened then maybe there is a write to
>>>> some register not covered by .num_reg_defaults_raw - this should be
>>>> fixed.
>>>
>>> I might be blind, but I really don't see that. I just discussed it with
>>> Mark and he thinks the same. I will revisit this one more time.
>>
>> Maybe it would be possible to get a backtrace when that warning was
>> generated so we know which register write or update triggers new cache
>> allocation?
> 
> See patch 5/5 .

In you patch 5/5 there is backtrace with flat cache, but I meant a
backtrace with original RB tree cache code when warning about allocation
being done in atomic context was generated.

Maciej

Re: [PATCH 4/5] ASoC: fsl_ssi: use flat regmap cache

[Mark Brown]

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

On Thu, Sep 22, 2016 at 01:33:47AM +0200, Maciej S. Szmigiero wrote:

> In you patch 5/5 there is backtrace with flat cache, but I meant a
> backtrace with original RB tree cache code when warning about allocation
> being done in atomic context was generated.

I think the conclusion of this and some IRC discussion yesterday is that
removing patch 5 fixes things - is that right?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

Re: [PATCH 4/5] ASoC: fsl_ssi: use flat regmap cache

[Maciej S. Szmigiero]

On 22.09.2016 12:45, Mark Brown wrote:
> On Thu, Sep 22, 2016 at 01:33:47AM +0200, Maciej S. Szmigiero wrote:
> 
>> In you patch 5/5 there is backtrace with flat cache, but I meant a
>> backtrace with original RB tree cache code when warning about allocation
>> being done in atomic context was generated.
> 
> I think the conclusion of this and some IRC discussion yesterday is that
> removing patch 5 fixes things - is that right?

There are three possible solutions:
1) Go back to RB tree cache (revert patch 4) and debug the lockdep warning,
2) Keep the flat cache introduced by patch 4 but debug the oops at
cache init time (while keeping defaults read from hardware),
3) Keep both patches and risk the same issues that were previously
caused by hardcoded register defaults in driver.
However, Marek says the device works fine for him with the patches.

It looks to me 1) is an easier and safer solution, especially that
the driver previously worked fine with RB tree cache.
I would test this myself but unfortunately I don't have access to
hardware this week.

Maciej

Re: [PATCH 4/5] ASoC: fsl_ssi: use flat regmap cache

[Marek Vasut]

On 09/22/2016 04:37 PM, Maciej S. Szmigiero wrote:
> On 22.09.2016 12:45, Mark Brown wrote:
>> On Thu, Sep 22, 2016 at 01:33:47AM +0200, Maciej S. Szmigiero wrote:
>>
>>> In you patch 5/5 there is backtrace with flat cache, but I meant a
>>> backtrace with original RB tree cache code when warning about allocation
>>> being done in atomic context was generated.
>>
>> I think the conclusion of this and some IRC discussion yesterday is that
>> removing patch 5 fixes things - is that right?
> 
> There are three possible solutions:
> 1) Go back to RB tree cache (revert patch 4) and debug the lockdep warning,
> 2) Keep the flat cache introduced by patch 4 but debug the oops at
> cache init time (while keeping defaults read from hardware),
> 3) Keep both patches and risk the same issues that were previously
> caused by hardcoded register defaults in driver.
> However, Marek says the device works fine for him with the patches.
> 
> It looks to me 1) is an easier and safer solution, especially that
> the driver previously worked fine with RB tree cache.
> I would test this myself but unfortunately I don't have access to
> hardware this week.

I believe switching to flat cache is harmless and it should be a better
mode for devices with small mmio address spaces. After some discussion
on IRC, I believe [1] should resolve the RBTREE crash (?).

[1]
http://git.kernel.org/cgit/linux/kernel/git/broonie/regmap.git/commit/?h=for-next&id=b2c7f5d9c939a37c1ce7f86a642de70e3033ee9e

> Maciej
> 


-- 
Best regards,
Marek Vasut

Re: [PATCH 4/5] ASoC: fsl_ssi: use flat regmap cache

[Maciej S. Szmigiero]

On 22.09.2016 17:27, Marek Vasut wrote:
> On 09/22/2016 04:37 PM, Maciej S. Szmigiero wrote:
>> On 22.09.2016 12:45, Mark Brown wrote:
>>> On Thu, Sep 22, 2016 at 01:33:47AM +0200, Maciej S. Szmigiero wrote:
>>>
(..)
>> It looks to me 1) is an easier and safer solution, especially that
>> the driver previously worked fine with RB tree cache.
>> I would test this myself but unfortunately I don't have access to
>> hardware this week.
> 
> I believe switching to flat cache is harmless and it should be a better
> mode for devices with small mmio address spaces. After some discussion
> on IRC, I believe [1] should resolve the RBTREE crash (?).
> 
> [1]
> http://git.kernel.org/cgit/linux/kernel/git/broonie/regmap.git/commit/?h=for-next&id=b2c7f5d9c939a37c1ce7f86a642de70e3033ee9e

I assume you meant "flat cache crash" not "RBTREE crash".

I will test flat cache version with this patch as soon as I get
my UDOO board back (probably next week) - maybe everything will be
fine.

Maciej

Re: [PATCH 4/5] ASoC: fsl_ssi: use flat regmap cache

[Mark Brown]

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

On Thu, Sep 22, 2016 at 05:27:42PM +0200, Marek Vasut wrote:
> On 09/22/2016 04:37 PM, Maciej S. Szmigiero wrote:

> > There are three possible solutions:
> > 1) Go back to RB tree cache (revert patch 4) and debug the lockdep warning,
> > 2) Keep the flat cache introduced by patch 4 but debug the oops at
> > cache init time (while keeping defaults read from hardware),
> > 3) Keep both patches and risk the same issues that were previously
> > caused by hardcoded register defaults in driver.
> > However, Marek says the device works fine for him with the patches.

> I believe switching to flat cache is harmless and it should be a better
> mode for devices with small mmio address spaces. After some discussion
> on IRC, I believe [1] should resolve the RBTREE crash (?).

So, can we get a clear decision on this after testing?  The discussion
here and the discussion on IRC are a bit disjointed and I'd like to make
sure we end up with something that definitely works.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

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

Re: [PATCH 4/5] ASoC: fsl_ssi: use flat regmap cache

[Marek Vasut]

On 09/26/2016 09:13 PM, Mark Brown wrote:
> On Thu, Sep 22, 2016 at 05:27:42PM +0200, Marek Vasut wrote:
>> On 09/22/2016 04:37 PM, Maciej S. Szmigiero wrote:
> 
>>> There are three possible solutions:
>>> 1) Go back to RB tree cache (revert patch 4) and debug the lockdep warning,
>>> 2) Keep the flat cache introduced by patch 4 but debug the oops at
>>> cache init time (while keeping defaults read from hardware),
>>> 3) Keep both patches and risk the same issues that were previously
>>> caused by hardcoded register defaults in driver.
>>> However, Marek says the device works fine for him with the patches.
> 
>> I believe switching to flat cache is harmless and it should be a better
>> mode for devices with small mmio address spaces. After some discussion
>> on IRC, I believe [1] should resolve the RBTREE crash (?).
> 
> So, can we get a clear decision on this after testing?  The discussion
> here and the discussion on IRC are a bit disjointed and I'd like to make
> sure we end up with something that definitely works.
> 
I think 1,2,3,4 are certainly harmless. I think even 5 is harmless (at
least according to my testing on MX6Q and MX6SX, which is not the
greatest sample), but can be safely reverted if there are concerns.

I also believe the following two patches should be backported for stable
4.7 (they were part of tag 'regmap-fix-v4.8-rc5' of
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap):

commit b2c7f5d9c939a37c1ce7f86a642de70e3033ee9e
Author: Maarten ter Huurne <maarten@treewalker.org>
Date:   Fri Jul 29 23:42:12 2016 +0200

    regmap: cache: Fix num_reg_defaults computation from reg_defaults_raw

commit 1bc8da4e143c0fd8807e061a66d91d5972601ab1
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Thu Aug 4 17:22:16 2016 +0200

    regmap: rbtree: Avoid overlapping nodes

-- 
Best regards,
Marek Vasut

Re: [PATCH 4/5] ASoC: fsl_ssi: use flat regmap cache

[Mark Brown]

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

On Mon, Sep 26, 2016 at 09:25:51PM +0200, Marek Vasut wrote:

> commit 1bc8da4e143c0fd8807e061a66d91d5972601ab1
> Author: Lars-Peter Clausen <lars@metafoo.de>
> Date:   Thu Aug 4 17:22:16 2016 +0200

>     regmap: rbtree: Avoid overlapping nodes

This one is aimed for stable but we want to let it cook for a longer
than normal time (I was thinking just after the merge window) as it
feels unusually risky given that we keep uncovering unintended
consequences in this area.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

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

Re: [PATCH 4/5] ASoC: fsl_ssi: use flat regmap cache

[Maciej S. Szmigiero]

On 26.09.2016 21:25, Marek Vasut wrote:
> On 09/26/2016 09:13 PM, Mark Brown wrote:
(..)
>> So, can we get a clear decision on this after testing?  The discussion
>> here and the discussion on IRC are a bit disjointed and I'd like to make
>> sure we end up with something that definitely works.
>>
> I think 1,2,3,4 are certainly harmless. I think even 5 is harmless (at
> least according to my testing on MX6Q and MX6SX, which is not the
> greatest sample), but can be safely reverted if there are concerns.

I've tested current sound/for-next on UDOO board and was able to reproduce
a lockup on reloading fsl sound modules.
The exact test was playing 30 second sound file and reloading modules in
a loop.
The lockup would happen sometimes almost immediately and sometimes after
~30 minutes of such testing.

When I reverted commit 7de2763d9b325ee5e7e24ac513c93394406cfefa
(that is, number 5) it seems that it no longer locks up.

> I also believe the following two patches should be backported for stable
> 4.7 (they were part of tag 'regmap-fix-v4.8-rc5' of
> git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap):
> 
> commit b2c7f5d9c939a37c1ce7f86a642de70e3033ee9e
> Author: Maarten ter Huurne <maarten@treewalker.org>
> Date:   Fri Jul 29 23:42:12 2016 +0200
> 
>     regmap: cache: Fix num_reg_defaults computation from reg_defaults_raw
> 
> commit 1bc8da4e143c0fd8807e061a66d91d5972601ab1
> Author: Lars-Peter Clausen <lars@metafoo.de>
> Date:   Thu Aug 4 17:22:16 2016 +0200
> 
>     regmap: rbtree: Avoid overlapping nodes
> 

I can see that
"regmap: cache: Fix num_reg_defaults computation from reg_defaults_raw" is
present in the tree that I have tested.
 
Maciej

Re: [PATCH 4/5] ASoC: fsl_ssi: use flat regmap cache

[Marek Vasut]

On 09/28/2016 01:23 AM, Maciej S. Szmigiero wrote:
> On 26.09.2016 21:25, Marek Vasut wrote:
>> On 09/26/2016 09:13 PM, Mark Brown wrote:
> (..)
>>> So, can we get a clear decision on this after testing?  The discussion
>>> here and the discussion on IRC are a bit disjointed and I'd like to make
>>> sure we end up with something that definitely works.
>>>
>> I think 1,2,3,4 are certainly harmless. I think even 5 is harmless (at
>> least according to my testing on MX6Q and MX6SX, which is not the
>> greatest sample), but can be safely reverted if there are concerns.
> 
> I've tested current sound/for-next on UDOO board and was able to reproduce
> a lockup on reloading fsl sound modules.
> The exact test was playing 30 second sound file and reloading modules in
> a loop.
> The lockup would happen sometimes almost immediately and sometimes after
> ~30 minutes of such testing.
> 
> When I reverted commit 7de2763d9b325ee5e7e24ac513c93394406cfefa
> (that is, number 5) it seems that it no longer locks up.

Do you have an explanation how would #5 cause this problem if it was
supposed to fix it ? ;-) Can you share the backtrace ?

>> I also believe the following two patches should be backported for stable
>> 4.7 (they were part of tag 'regmap-fix-v4.8-rc5' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap):
>>
>> commit b2c7f5d9c939a37c1ce7f86a642de70e3033ee9e
>> Author: Maarten ter Huurne <maarten@treewalker.org>
>> Date:   Fri Jul 29 23:42:12 2016 +0200
>>
>>     regmap: cache: Fix num_reg_defaults computation from reg_defaults_raw
>>
>> commit 1bc8da4e143c0fd8807e061a66d91d5972601ab1
>> Author: Lars-Peter Clausen <lars@metafoo.de>
>> Date:   Thu Aug 4 17:22:16 2016 +0200
>>
>>     regmap: rbtree: Avoid overlapping nodes
>>
> 
> I can see that
> "regmap: cache: Fix num_reg_defaults computation from reg_defaults_raw" is
> present in the tree that I have tested.

And the rbtree patch is also present ?

> Maciej
> 


-- 
Best regards,
Marek Vasut

Re: [PATCH 4/5] ASoC: fsl_ssi: use flat regmap cache

[Maciej S. Szmigiero]

On 28.09.2016 01:29, Marek Vasut wrote:
> On 09/28/2016 01:23 AM, Maciej S. Szmigiero wrote:
>> On 26.09.2016 21:25, Marek Vasut wrote:
>>> On 09/26/2016 09:13 PM, Mark Brown wrote:
>> (..)
>>>> So, can we get a clear decision on this after testing?  The discussion
>>>> here and the discussion on IRC are a bit disjointed and I'd like to make
>>>> sure we end up with something that definitely works.
>>>>
>>> I think 1,2,3,4 are certainly harmless. I think even 5 is harmless (at
>>> least according to my testing on MX6Q and MX6SX, which is not the
>>> greatest sample), but can be safely reverted if there are concerns.
>>
>> I've tested current sound/for-next on UDOO board and was able to reproduce
>> a lockup on reloading fsl sound modules.
>> The exact test was playing 30 second sound file and reloading modules in
>> a loop.
>> The lockup would happen sometimes almost immediately and sometimes after
>> ~30 minutes of such testing.
>>
>> When I reverted commit 7de2763d9b325ee5e7e24ac513c93394406cfefa
>> (that is, number 5) it seems that it no longer locks up.
> 
> Do you have an explanation how would #5 cause this problem if it was
> supposed to fix it ? ;-) Can you share the backtrace ?

I think the reason why it locks up is similar to previous case that it
locked up in similar circumstances with hardcoded register defaults -
there is some inconsistency between register value in cache and actual
value in hardware which then gets (partially?) rewritten with cached
value.
But I don't know the exact problematic register.

It looks like the SoC just locks up after this error:
ac97-codec ac97-codec.0: ASoC: codec DAI prepare error: -22

>>> I also believe the following two patches should be backported for
>>> 4.7 (they were part of tag 'regmap-fix-v4.8-rc5' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap):
>>>
>>> commit b2c7f5d9c939a37c1ce7f86a642de70e3033ee9e
>>> Author: Maarten ter Huurne <maarten@treewalker.org>
>>> Date:   Fri Jul 29 23:42:12 2016 +0200
>>>
>>>     regmap: cache: Fix num_reg_defaults computation from reg_defaults_raw
>>>
>>> commit 1bc8da4e143c0fd8807e061a66d91d5972601ab1
>>> Author: Lars-Peter Clausen <lars@metafoo.de>
>>> Date:   Thu Aug 4 17:22:16 2016 +0200
>>>
>>>     regmap: rbtree: Avoid overlapping nodes
>>>
>>
>> I can see that
>> "regmap: cache: Fix num_reg_defaults computation from reg_defaults_raw" is
>> present in the tree that I have tested.
> 
> And the rbtree patch is also present ?

Yes - I commented only on the first one since you said it would probably
fix the rbtree crash (which I understand is the one which
patch 5 was also trying to fix).

Maciej

Re: [PATCH 4/5] ASoC: fsl_ssi: use flat regmap cache

[Marek Vasut]

On 09/28/2016 02:04 AM, Maciej S. Szmigiero wrote:
> On 28.09.2016 01:29, Marek Vasut wrote:
>> On 09/28/2016 01:23 AM, Maciej S. Szmigiero wrote:
>>> On 26.09.2016 21:25, Marek Vasut wrote:
>>>> On 09/26/2016 09:13 PM, Mark Brown wrote:
>>> (..)
>>>>> So, can we get a clear decision on this after testing?  The discussion
>>>>> here and the discussion on IRC are a bit disjointed and I'd like to make
>>>>> sure we end up with something that definitely works.
>>>>>
>>>> I think 1,2,3,4 are certainly harmless. I think even 5 is harmless (at
>>>> least according to my testing on MX6Q and MX6SX, which is not the
>>>> greatest sample), but can be safely reverted if there are concerns.
>>>
>>> I've tested current sound/for-next on UDOO board and was able to reproduce
>>> a lockup on reloading fsl sound modules.
>>> The exact test was playing 30 second sound file and reloading modules in
>>> a loop.
>>> The lockup would happen sometimes almost immediately and sometimes after
>>> ~30 minutes of such testing.
>>>
>>> When I reverted commit 7de2763d9b325ee5e7e24ac513c93394406cfefa
>>> (that is, number 5) it seems that it no longer locks up.
>>
>> Do you have an explanation how would #5 cause this problem if it was
>> supposed to fix it ? ;-) Can you share the backtrace ?
> 
> I think the reason why it locks up is similar to previous case that it
> locked up in similar circumstances with hardcoded register defaults -
> there is some inconsistency between register value in cache and actual
> value in hardware which then gets (partially?) rewritten with cached
> value.
> But I don't know the exact problematic register.
> 
> It looks like the SoC just locks up after this error:
> ac97-codec ac97-codec.0: ASoC: codec DAI prepare error: -22

This looks like a different error, can you poke into this please ?

>>>> I also believe the following two patches should be backported for
>>>> 4.7 (they were part of tag 'regmap-fix-v4.8-rc5' of
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap):
>>>>
>>>> commit b2c7f5d9c939a37c1ce7f86a642de70e3033ee9e
>>>> Author: Maarten ter Huurne <maarten@treewalker.org>
>>>> Date:   Fri Jul 29 23:42:12 2016 +0200
>>>>
>>>>     regmap: cache: Fix num_reg_defaults computation from reg_defaults_raw
>>>>
>>>> commit 1bc8da4e143c0fd8807e061a66d91d5972601ab1
>>>> Author: Lars-Peter Clausen <lars@metafoo.de>
>>>> Date:   Thu Aug 4 17:22:16 2016 +0200
>>>>
>>>>     regmap: rbtree: Avoid overlapping nodes
>>>>
>>>
>>> I can see that
>>> "regmap: cache: Fix num_reg_defaults computation from reg_defaults_raw" is
>>> present in the tree that I have tested.
>>
>> And the rbtree patch is also present ?
> 
> Yes - I commented only on the first one since you said it would probably
> fix the rbtree crash (which I understand is the one which
> patch 5 was also trying to fix).

Seems like we have more problems then, sigh.

btw I also had to revert 5881826ded79cf3c3314ee2d84c3bfa94e111b42 on
latest next as it made my AC97 misbehave.

> Maciej
> 


-- 
Best regards,
Marek Vasut

Re: [PATCH 4/5] ASoC: fsl_ssi: use flat regmap cache

[Marek Vasut]

On 09/22/2016 01:33 AM, Maciej S. Szmigiero wrote:
> On 22.09.2016 00:45, Marek Vasut wrote:
>> On 09/22/2016 12:18 AM, Maciej S. Szmigiero wrote:
>>> On 21.09.2016 21:32, Marek Vasut wrote:
>>>> On 09/21/2016 06:28 PM, Maciej S. Szmigiero wrote:
>>>>> Hi Marek,
>>>>
>>>> Hi!
>>>>
>>>>> On 19.09.2016 21:30, Marek Vasut wrote:
>>> (..)
>>>>>> The RB-tree regmap cache needs to allocate new space on first
>>>>>> writes.
>>>>>
>>>>> That's why SSI driver had .num_reg_defaults_raw set in regmap config.
>>>>> With this set and .reg_defaults_raw unset regcache_hw_init() will read
>>>>> existing register content which then will be used to populate cache
>>>>> (and so allocate RB tree nodes) at regcache initialization time.
>>>>
>>>> OK
>>>>
>>>>> This means that allocation of new cache RB tree nodes should never happen
>>>>> during actual write.
>>>>> If you get a warning that it happened then maybe there is a write to
>>>>> some register not covered by .num_reg_defaults_raw - this should be
>>>>> fixed.
>>>>
>>>> I might be blind, but I really don't see that. I just discussed it with
>>>> Mark and he thinks the same. I will revisit this one more time.
>>>
>>> Maybe it would be possible to get a backtrace when that warning was
>>> generated so we know which register write or update triggers new cache
>>> allocation?
>>
>> See patch 5/5 .
> 
> In you patch 5/5 there is backtrace with flat cache, but I meant a
> backtrace with original RB tree cache code when warning about allocation
> being done in atomic context was generated.

Here you go:

> fsl-ssi-dai 202c000.ssi: No cache defaults, reading back from HW
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2871 lockdep_trace_alloc+0x104/0x128
> DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.7.4-00041-g0260041 #2
> Hardware name: Freescale i.MX6 SoloX (Device Tree)
> Backtrace: 
> [<c010c188>] (dump_backtrace) from [<c010c380>] (show_stack+0x18/0x1c)
>  r7:00000000 r6:60000093 r5:00000000 r4:c0f1e77c
> [<c010c368>] (show_stack) from [<c03f8184>] (dump_stack+0xb4/0xe8)
> [<c03f80d0>] (dump_stack) from [<c0123638>] (__warn+0xd8/0x104)
>  r9:c016f054 r8:00000b37 r7:00000009 r6:c0c59f68 r5:00000000 r4:db453b10
> [<c0123560>] (__warn) from [<c01236a0>] (warn_slowpath_fmt+0x3c/0x44)
>  r9:00000012 r8:024000c0 r7:024000c0 r6:00000040 r5:024000c0 r4:c0c570f0
> [<c0123668>] (warn_slowpath_fmt) from [<c016f054>] (lockdep_trace_alloc+0x104/0x128)
>  r3:c0c5b07c r2:c0c570f0
>  r4:60000093
> [<c016ef50>] (lockdep_trace_alloc) from [<c0215e24>] (__kmalloc_track_caller+0x44/0x230)
>  r5:024000c0 r4:db401e80
> [<c0215de0>] (__kmalloc_track_caller) from [<c01f01d0>] (krealloc+0x54/0xc0)
>  r10:00000058 r9:00000012 r8:c050d4f0 r7:024000c0 r6:00000040 r5:0000004c
>  r4:dacd7d80
> [<c01f017c>] (krealloc) from [<c050d4f0>] (regcache_rbtree_write+0x364/0x608)
>  r9:00000012 r8:00000004 r7:00000010 r6:dacd9a00 r5:dacd7d50 r4:00000010
> [<c050d18c>] (regcache_rbtree_write) from [<c050c230>] (regcache_write+0x5c/0x64)
>  r10:dacd9818 r9:dacd9964 r8:00000000 r7:dacd9a00 r6:000000ff r5:00000058
>  r4:dacd9a00
> [<c050c1d4>] (regcache_write) from [<c050a3ac>] (_regmap_write+0x74/0x9c)
>  r7:dacd9a00 r6:000000ff r5:00000058 r4:dacd9a00
> [<c050a338>] (_regmap_write) from [<c050b5bc>] (regmap_write+0x44/0x64)
>  r7:00000006 r6:000000ff r5:00000058 r4:dacd9a00
> [<c050b578>] (regmap_write) from [<c0731090>] (_fsl_ssi_set_dai_fmt+0x31c/0x4fc)
>  r7:00000006 r6:00000000 r5:dacd9a00 r4:dacd9810
> [<c0730d74>] (_fsl_ssi_set_dai_fmt) from [<c0731f94>] (fsl_ssi_probe+0x58c/0x7b4)
>  r9:dacd9964 r8:00000000 r7:dbbbf164 r6:db4f0000 r5:db4f0010 r4:dacd9810
> [<c0731a08>] (fsl_ssi_probe) from [<c0501994>] (platform_drv_probe+0x3c/0x74)
>  r10:c0e00618 r9:00000000 r8:c0f608b4 r7:00000000 r6:c1753a70 r5:c0f608b4                                                                        
>  r4:db4f0010                                                                                                                                     
> [<c0501958>] (platform_drv_probe) from [<c0500134>] (really_probe+0x1b8/0x264)                                                                   
>  r5:c1753a68 r4:db4f0010                                                                                                                         
> [<c04fff7c>] (really_probe) from [<c05002b4>] (__driver_attach+0xd4/0xd8)                                                                        
>  r9:c0e58858 r8:00000000 r7:00000000 r6:db4f0044 r5:c0f608b4 r4:db4f0010                                                                         
> [<c05001e0>] (__driver_attach) from [<c04fe2c4>] (bus_for_each_dev+0x74/0xa8)
>  r7:00000000 r6:c05001e0 r5:c0f608b4 r4:00000000
> [<c04fe250>] (bus_for_each_dev) from [<c04ffaa4>] (driver_attach+0x20/0x28)
>  r6:c0f2ef08 r5:dacd6480 r4:c0f608b4
> [<c04ffa84>] (driver_attach) from [<c04ff5f4>] (bus_add_driver+0x104/0x214)
> [<c04ff4f0>] (bus_add_driver) from [<c05008e0>] (driver_register+0x80/0xfc)
>  r7:c0d498e0 r6:c0e58850 r5:ffffe000 r4:c0f608b4
> [<c0500860>] (driver_register) from [<c0501944>] (__platform_driver_register+0x38/0x4c)
>  r5:ffffe000 r4:c0e4cdf8
> [<c050190c>] (__platform_driver_register) from [<c0e4ce10>] (fsl_ssi_driver_init+0x18/0x20)
> [<c0e4cdf8>] (fsl_ssi_driver_init) from [<c0101924>] (do_one_initcall+0x44/0x178)
> [<c01018e0>] (do_one_initcall) from [<c0e00e74>] (kernel_init_freeable+0x124/0x1e8)
>  r8:000000ed r7:c0d498e0 r6:c0e58850 r5:c0f6e000 r4:c0e6b590
> [<c0e00d50>] (kernel_init_freeable) from [<c0958080>] (kernel_init+0x10/0x11c)
>  r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c0958070
>  r4:00000000
> [<c0958070>] (kernel_init) from [<c0107c70>] (ret_from_fork+0x14/0x24)
>  r5:c0958070 r4:00000000
> ---[ end trace 4907f763bc504c04 ]---
> imx-wm9712 sound: wm9712-hifi <-> 202c000.ssi mapping ok
> wm9712-codec wm9712-codec: ASoC: mux Capture Phone Mux has no paths
> wm9712-codec wm9712-codec: ASoC: mux Differential Source has no paths


-- 
Best regards,
Marek Vasut

[PATCH 5/5] ASoC: fsl_ssi: Remove .num_reg_defaults_raw from regmap_config

[Marek Vasut]

This driver provides no .reg_defaults_raw in regmap_config, so
the .num_reg_defaults_raw is useless, and, in fact harmful. It
triggers kernel crash in regmap_init which tries to access the
register defaults.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Nicolin Chen <nicoleotsuka@gmail.com>
Cc: Timur Tabi <timur@tabi.org>
Cc: Xiubo Li <Xiubo.Lee@gmail.com>
--
fsl-ssi-dai 202c000.ssi: No cache defaults, reading back from HW
Unable to handle kernel paging request at virtual address 920bd77c
pgd = c0004000
[920bd77c] *pgd=00000000
Internal error: Oops: 805 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.7.3-00033-g54f2571 #3
Hardware name: Freescale i.MX6 SoloX (Device Tree)
task: db468000 ti: db462000 task.ti: db462000
PC is at regcache_flat_init+0x8c/0xb0
LR is at 0x2
pc : [<c04c8e84>]    lr : [<00000002>]    psr: 20000013
sp : db463bc8  ip : dac1afd8  fp : db463bdc
r10: 00000003  r9 : 00000017  r8 : 00000001
r7 : 00000009  r6 : 00000058  r5 : dac1ca00  r4 : dac1ca00
r3 : dac1afd0  r2 : 2da38bff  r1 : f6fafde8  r0 : db7da780
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5387d  Table: 8000404a  DAC: 00000051
Process swapper/0 (pid: 1, stack limit = 0xdb462210)
Stack: (0xdb463bc8 to 0xdb464000)
3bc0:                   00000000 dac1ca00 db463c14 db463be0 c04c7068 c04c8e04
3be0: c01f1a80 00000000 db463d38 dac1ca00 db463d38 db4e2210 c0ea742c 00000000
3c00: dac1f000 00000001 db463c54 db463c18 c04c44cc c04c6eb0 c04c473c db4e2210
3c20: dac1f000 db463d38 e0b18000 c094fa2c dac1f090 db4e2210 dac1f000 db463d38
3c40: e0b18000 dac1c818 db463c84 db463c58 c04c47b8 c04c3acc 00000000 00000000
3c60: dac1c810 db4e2210 db463d38 db4e2200 dbbc58d4 db4e0840 db463ca4 db463c88
3c80: c04cac60 c04c4760 00000000 00000000 dac1c810 db4e2210 db463ddc db463ca8
3ca0: c06e85d4 c04cac24 00000000 00000000 db463d0c dbbc58d4 c0bca51c c0bc9dbc
3cc0: c0e5483c 00000000 db463cfc db463cd8 c069522c c06936d0 c03ba0ac 80000000
3ce0: db4e2210 dbbc58d4 c0ebaf98 00000000 db463d1c db463d00 c06936a0 c03be9f4
3d00: c0ebed00 dbbc58d4 a0000013 c0bca5d0 db463d44 db463d20 c069370c c08bcaec
3d20: db4e2210 dbbc58d4 c0ebaf98 00000000 c0e5483c 00000000 00000000 00000020
3d40: 00000004 00000000 00000020 c06e6ff4 c06e6d3c c06e6d68 c06e6ed4 00000000
3d60: 00000000 00000000 00000000 00000000 00000000 00000058 00000000 00000000
3d80: 00000000 00000000 00000000 00000000 00000003 00000000 00000017 00000000
3da0: 00000000 00000003 00000000 00000000 c0e5483c db4e2210 c0e5483c c0ebaf98
3dc0: 00000000 c0e5483c 00000000 c0d00618 db463df4 db463de0 c04bc578 c06e8410
3de0: db4e2210 c0ebaf90 db463e1c db463df8 c04bad04 c04bc548 db4e2210 c0e5483c
3e00: db4e2244 00000000 00000000 c0d5f83c db463e3c db463e20 c04bae7c c04bab58
3e20: 00000000 c0e5483c c04badb0 00000000 db463e64 db463e40 c04b9004 c04badbc
3e40: db42795c db4df3b4 db427970 c0e5483c dac1ae80 c0e27150 db463e74 db463e68
3e60: c04ba680 c04b8f9c db463e9c db463e78 c04ba1f0 c04ba66c c0bd70d4 db463e88
3e80: c0e5483c ffffe000 c0d5f834 c0c2d010 db463eb4 db463ea0 c04bb4d0 c04ba0f8
3ea0: c0d4c49c ffffe000 db463ec4 db463eb8 c04bc528 c04bb45c db463ed4 db463ec8
3ec0: c0d4c4b4 c04bc4fc db463f4c db463ed8 c01018c4 c0d4c4a8 c0c2dad8 dbfffac0
3ee0: db463f04 db463ef0 c013e200 c03beb8c 00000000 c0921520 db463f4c db463f08
3f00: c013e528 c0d00624 00000006 00000006 00000000 c0c2d010 c0bb17c0 00000000
3f20: 00000000 00000006 c0e60000 c0d71264 c0e60000 c0d5f834 c0c2d010 000000e9
3f40: db463f94 db463f50 c0d00e48 c010188c 00000006 00000006 00000000 c0d00618
3f60: 00000008 00000007 c08b8124 00000000 c08b8124 00000000 00000000 00000000
3f80: 00000000 00000000 db463fac db463f98 c08b8134 c0d00d30 00000000 c08b8124
3fa0: 00000000 db463fb0 c0107b18 c08b8130 00000000 00000000 00000000 00000000
3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 80110460 20000000
Backtrace:
[<c04c8df8>] (regcache_flat_init) from [<c04c7068>] (regcache_init+0x1c4/0x424)
 r5:dac1ca00 r4:00000000
[<c04c6ea4>] (regcache_init) from [<c04c44cc>] (__regmap_init+0xa0c/0xbc8)
 r10:00000001 r9:dac1f000 r8:00000000 r7:c0ea742c r6:db4e2210 r5:db463d38
 r4:dac1ca00
[<c04c3ac0>] (__regmap_init) from [<c04c47b8>] (__devm_regmap_init+0x64/0xa0)
 r10:dac1c818 r9:e0b18000 r8:db463d38 r7:dac1f000 r6:db4e2210 r5:dac1f090
 r4:c094fa2c
[<c04c4754>] (__devm_regmap_init) from [<c04cac60>] (__devm_regmap_init_mmio_clk+0x48/0x54)
 r8:db4e0840 r7:dbbc58d4 r6:db4e2200 r5:db463d38 r4:db4e2210
[<c04cac18>] (__devm_regmap_init_mmio_clk) from [<c06e85d4>] (fsl_ssi_probe+0x1d0/0x798)
 r5:db4e2210 r4:dac1c810
[<c06e8404>] (fsl_ssi_probe) from [<c04bc578>] (platform_drv_probe+0x3c/0x74)
 r10:c0d00618 r9:00000000 r8:c0e5483c r7:00000000 r6:c0ebaf98 r5:c0e5483c
 r4:db4e2210
[<c04bc53c>] (platform_drv_probe) from [<c04bad04>] (really_probe+0x1b8/0x264)
 r5:c0ebaf90 r4:db4e2210
[<c04bab4c>] (really_probe) from [<c04bae7c>] (__driver_attach+0xcc/0xd0)
 r9:c0d5f83c r8:00000000 r7:00000000 r6:db4e2244 r5:c0e5483c r4:db4e2210
[<c04badb0>] (__driver_attach) from [<c04b9004>] (bus_for_each_dev+0x74/0xa8)
 r7:00000000 r6:c04badb0 r5:c0e5483c r4:00000000
[<c04b8f90>] (bus_for_each_dev) from [<c04ba680>] (driver_attach+0x20/0x28)
 r6:c0e27150 r5:dac1ae80 r4:c0e5483c
[<c04ba660>] (driver_attach) from [<c04ba1f0>] (bus_add_driver+0x104/0x214)
[<c04ba0ec>] (bus_add_driver) from [<c04bb4d0>] (driver_register+0x80/0xfc)
 r7:c0c2d010 r6:c0d5f834 r5:ffffe000 r4:c0e5483c
[<c04bb450>] (driver_register) from [<c04bc528>] (__platform_driver_register+0x38/0x4c)
 r5:ffffe000 r4:c0d4c49c
[<c04bc4f0>] (__platform_driver_register) from [<c0d4c4b4>] (fsl_ssi_driver_init+0x18/0x20)
[<c0d4c49c>] (fsl_ssi_driver_init) from [<c01018c4>] (do_one_initcall+0x44/0x174)
[<c0101880>] (do_one_initcall) from [<c0d00e48>] (kernel_init_freeable+0x124/0x1e8)
 r8:000000e9 r7:c0c2d010 r6:c0d5f834 r5:c0e60000 r4:c0d71264
[<c0d00d24>] (kernel_init_freeable) from [<c08b8134>] (kernel_init+0x10/0x11c)
 r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c08b8124
 r4:00000000
[<c08b8124>] (kernel_init) from [<c0107b18>] (ret_from_fork+0x14/0x3c)
 r5:c08b8124 r4:00000000
Code: e5931004 e4932008 e15c0003 e1a02e32 (e7801102)
---[ end trace b0f9b6e515f8132b ]---
mmc0: host does not support reading read-only switch, assuming write-enable
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
---
 sound/soc/fsl/fsl_ssi.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 5034943..b73c102 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -177,7 +177,6 @@ static const struct regmap_config fsl_ssi_regconfig = {
 	.val_bits = 32,
 	.reg_stride = 4,
 	.val_format_endian = REGMAP_ENDIAN_NATIVE,
-	.num_reg_defaults_raw = CCSR_SSI_SACCDIS / sizeof(uint32_t) + 1,
 	.readable_reg = fsl_ssi_readable_reg,
 	.volatile_reg = fsl_ssi_volatile_reg,
 	.precious_reg = fsl_ssi_precious_reg,
@@ -1501,8 +1500,6 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 		 * don't have SACC{ST,EN,DIS} regs.
 		 */
 		regconfig.max_register = CCSR_SSI_SRMSK;
-		regconfig.num_reg_defaults_raw =
-			CCSR_SSI_SRMSK / sizeof(uint32_t) + 1;
 	}
 
 	ret = of_property_match_string(np, "clock-names", "ipg");
-- 
2.9.3

Re: [PATCH 5/5] ASoC: fsl_ssi: Remove .num_reg_defaults_raw from regmap_config

[Mark Brown]

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

On Mon, Sep 19, 2016 at 09:30:29PM +0200, Marek Vasut wrote:

> Cc: Xiubo Li <Xiubo.Lee@gmail.com>
> --
> fsl-ssi-dai 202c000.ssi: No cache defaults, reading back from HW

This probably shouldn't have been part of the signoff chain and also
please think hard before including complete backtraces in upstream
reports, they are very large and contain almost no useful information
relative to their size so often obscure the relevant content in your
message. If part of the backtrace is usefully illustrative then it's
usually better to pull out the relevant sections.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

Re: [PATCH 5/5] ASoC: fsl_ssi: Remove .num_reg_defaults_raw from regmap_config

[Marek Vasut]

On 09/20/2016 07:56 PM, Mark Brown wrote:
> On Mon, Sep 19, 2016 at 09:30:29PM +0200, Marek Vasut wrote:
> 
>> Cc: Xiubo Li <Xiubo.Lee@gmail.com>
>> --
>> fsl-ssi-dai 202c000.ssi: No cache defaults, reading back from HW
> 
> This probably shouldn't have been part of the signoff chain and also
> please think hard before including complete backtraces in upstream
> reports, they are very large and contain almost no useful information
> relative to their size so often obscure the relevant content in your
> message. If part of the backtrace is usefully illustrative then it's
> usually better to pull out the relevant sections.
> 
My intent was to include the full backtrace, but not as a part of the
commit message. I can see some parts were not exactly useful, sorry.

-- 
Best regards,
Marek Vasut

Applied "ASoC: fsl_ssi: Remove .num_reg_defaults_raw from regmap_config" to the asoc tree

[Mark Brown]

The patch

   ASoC: fsl_ssi: Remove .num_reg_defaults_raw from regmap_config

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 7de2763d9b325ee5e7e24ac513c93394406cfefa Mon Sep 17 00:00:00 2001
From: Marek Vasut <marex@denx.de>
Date: Mon, 19 Sep 2016 21:30:29 +0200
Subject: [PATCH] ASoC: fsl_ssi: Remove .num_reg_defaults_raw from
 regmap_config

This driver provides no .reg_defaults_raw in regmap_config, so
the .num_reg_defaults_raw is useless, and, in fact harmful. It
triggers kernel crash in regmap_init which tries to access the
register defaults.

Signed-off-by: Marek Vasut <marex@denx.de>
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 sound/soc/fsl/fsl_ssi.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 50349437d961..b73c102f1cf2 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -177,7 +177,6 @@ static const struct regmap_config fsl_ssi_regconfig = {
 	.val_bits = 32,
 	.reg_stride = 4,
 	.val_format_endian = REGMAP_ENDIAN_NATIVE,
-	.num_reg_defaults_raw = CCSR_SSI_SACCDIS / sizeof(uint32_t) + 1,
 	.readable_reg = fsl_ssi_readable_reg,
 	.volatile_reg = fsl_ssi_volatile_reg,
 	.precious_reg = fsl_ssi_precious_reg,
@@ -1501,8 +1500,6 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 		 * don't have SACC{ST,EN,DIS} regs.
 		 */
 		regconfig.max_register = CCSR_SSI_SRMSK;
-		regconfig.num_reg_defaults_raw =
-			CCSR_SSI_SRMSK / sizeof(uint32_t) + 1;
 	}
 
 	ret = of_property_match_string(np, "clock-names", "ipg");
-- 
2.8.1

Re: [PATCH 1/5] ASoC: fsl_asrc: use flat regmap cache

[Nicolin Chen]

On Mon, Sep 19, 2016 at 09:30:25PM +0200, Marek Vasut wrote:
> Same as commit ce492b3b8f99cf9d2f807ec22d8805c996a09503
> Subject: drm/fsl-dcu: use flat regmap cache
> 
> Using flat regmap cache instead of RB-tree to avoid the following
> lockdep warning on driver load:
> WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2871 lockdep_trace_alloc+0x104/0x128
> DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
> 
> The RB-tree regmap cache needs to allocate new space on first
> writes. However, allocations in an atomic context (e.g. when a
> spinlock is held) are not allowed. The function regmap_write
> calls map->lock, which acquires a spinlock in the fast_io case.
> Since the driver uses MMIO, the regmap bus of type regmap_mmio
> is being used which has fast_io set to true.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Liam Girdwood <lgirdwood@gmail.com>
> Cc: Mark Brown <broonie@kernel.org>

Tested on i.MX6 Solo X SDB. For the whole series,

Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>

Thanks
Nicolin

> Cc: Timur Tabi <timur@tabi.org>
> Cc: Xiubo Li <Xiubo.Lee@gmail.com>
> ---
>  sound/soc/fsl/fsl_asrc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
> index b7157ce..1d82f68 100644
> --- a/sound/soc/fsl/fsl_asrc.c
> +++ b/sound/soc/fsl/fsl_asrc.c
> @@ -726,7 +726,7 @@ static const struct regmap_config fsl_asrc_regmap_config = {
>  	.readable_reg = fsl_asrc_readable_reg,
>  	.volatile_reg = fsl_asrc_volatile_reg,
>  	.writeable_reg = fsl_asrc_writeable_reg,
> -	.cache_type = REGCACHE_RBTREE,
> +	.cache_type = REGCACHE_FLAT,
>  };
>  
>  /**
> -- 
> 2.9.3
> 

Re: [PATCH 1/5] ASoC: fsl_asrc: use flat regmap cache

[Fabio Estevam]

Hi Marek,

On Mon, Sep 19, 2016 at 4:30 PM, Marek Vasut <marex@denx.de> wrote:
> Same as commit ce492b3b8f99cf9d2f807ec22d8805c996a09503
> Subject: drm/fsl-dcu: use flat regmap cache

Just one minor nit:

The most standard way to reference a commit is:
commit ce492b3b8f99 ("drm/fsl-dcu: use flat regmap cache")

Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>






> Using flat regmap cache instead of RB-tree to avoid the following
> lockdep warning on driver load:
> WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2871 lockdep_trace_alloc+0x104/0x128
> DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
>
> The RB-tree regmap cache needs to allocate new space on first
> writes. However, allocations in an atomic context (e.g. when a
> spinlock is held) are not allowed. The function regmap_write
> calls map->lock, which acquires a spinlock in the fast_io case.
> Since the driver uses MMIO, the regmap bus of type regmap_mmio
> is being used which has fast_io set to true.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Liam Girdwood <lgirdwood@gmail.com>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Nicolin Chen <nicoleotsuka@gmail.com>
> Cc: Timur Tabi <timur@tabi.org>
> Cc: Xiubo Li <Xiubo.Lee@gmail.com>
> ---
>  sound/soc/fsl/fsl_asrc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
> index b7157ce..1d82f68 100644
> --- a/sound/soc/fsl/fsl_asrc.c
> +++ b/sound/soc/fsl/fsl_asrc.c
> @@ -726,7 +726,7 @@ static const struct regmap_config fsl_asrc_regmap_config = {
>         .readable_reg = fsl_asrc_readable_reg,
>         .volatile_reg = fsl_asrc_volatile_reg,
>         .writeable_reg = fsl_asrc_writeable_reg,
> -       .cache_type = REGCACHE_RBTREE,
> +       .cache_type = REGCACHE_FLAT,
>  };
>
>  /**
> --
> 2.9.3
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Applied "ASoC: fsl_asrc: use flat regmap cache" to the asoc tree

[Mark Brown]

The patch

   ASoC: fsl_asrc: use flat regmap cache

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From b413886886b9a8f845f7d1a5adafa0ca573d3828 Mon Sep 17 00:00:00 2001
From: Marek Vasut <marex@denx.de>
Date: Mon, 19 Sep 2016 21:30:25 +0200
Subject: [PATCH] ASoC: fsl_asrc: use flat regmap cache

Same as commit ce492b3b8f99cf9d2f807ec22d8805c996a09503
Subject: drm/fsl-dcu: use flat regmap cache

Using flat regmap cache instead of RB-tree to avoid the following
lockdep warning on driver load:
WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2871 lockdep_trace_alloc+0x104/0x128
DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))

The RB-tree regmap cache needs to allocate new space on first
writes. However, allocations in an atomic context (e.g. when a
spinlock is held) are not allowed. The function regmap_write
calls map->lock, which acquires a spinlock in the fast_io case.
Since the driver uses MMIO, the regmap bus of type regmap_mmio
is being used which has fast_io set to true.

Signed-off-by: Marek Vasut <marex@denx.de>
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 sound/soc/fsl/fsl_asrc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index b7157ce23479..1d82f68305c3 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -726,7 +726,7 @@ static const struct regmap_config fsl_asrc_regmap_config = {
 	.readable_reg = fsl_asrc_readable_reg,
 	.volatile_reg = fsl_asrc_volatile_reg,
 	.writeable_reg = fsl_asrc_writeable_reg,
-	.cache_type = REGCACHE_RBTREE,
+	.cache_type = REGCACHE_FLAT,
 };
 
 /**
-- 
2.8.1