From: Claudiu Beznea claudiu.beznea.uj@bp.renesas.com
On the Renesas RZ/G3S SMARC Carrier II board having a DA7212 codec (using da7213 driver) connected to one SSIF-2 available on the Renesas RZ/G3S SoC it has been discovered that using the runtime PM API for suspend/resume (as will be proposed in the following commits) leads to the codec not being propertly initialized after resume. This is because w/o max_register populated to regmap_config the regcache_rbtree_sync() breaks on base_reg > max condition and the regcache_sync_block() call is skipped.
Fixes: ef5c2eba2412 ("ASoC: codecs: Add da7213 codec") Cc: stable@vger.kernel.org Signed-off-by: Claudiu Beznea claudiu.beznea.uj@bp.renesas.com --- sound/soc/codecs/da7213.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/da7213.c b/sound/soc/codecs/da7213.c index f3ef6fb55304..486db60bf2dd 100644 --- a/sound/soc/codecs/da7213.c +++ b/sound/soc/codecs/da7213.c @@ -2136,6 +2136,7 @@ static const struct regmap_config da7213_regmap_config = { .reg_bits = 8, .val_bits = 8,
+ .max_register = DA7213_TONE_GEN_OFF_PER, .reg_defaults = da7213_reg_defaults, .num_reg_defaults = ARRAY_SIZE(da7213_reg_defaults), .volatile_reg = da7213_volatile_register,
On Wed, Nov 06, 2024 at 10:18:17AM +0200, Claudiu wrote:
From: Claudiu Beznea claudiu.beznea.uj@bp.renesas.com
On the Renesas RZ/G3S SMARC Carrier II board having a DA7212 codec (using da7213 driver) connected to one SSIF-2 available on the Renesas RZ/G3S SoC it has been discovered that using the runtime PM API for suspend/resume (as will be proposed in the following commits) leads to the codec not being propertly initialized after resume. This is because w/o max_register populated to regmap_config the regcache_rbtree_sync() breaks on base_reg > max condition and the regcache_sync_block() call is skipped.
Fixes: ef5c2eba2412 ("ASoC: codecs: Add da7213 codec") Cc: stable@vger.kernel.org
Why is this a stable fix when it only enables further work?
Hi, Mark,
On 06.11.2024 15:43, Mark Brown wrote:
On Wed, Nov 06, 2024 at 10:18:17AM +0200, Claudiu wrote:
From: Claudiu Beznea claudiu.beznea.uj@bp.renesas.com
On the Renesas RZ/G3S SMARC Carrier II board having a DA7212 codec (using da7213 driver) connected to one SSIF-2 available on the Renesas RZ/G3S SoC it has been discovered that using the runtime PM API for suspend/resume (as will be proposed in the following commits) leads to the codec not being propertly initialized after resume. This is because w/o max_register populated to regmap_config the regcache_rbtree_sync() breaks on base_reg > max condition and the regcache_sync_block() call is skipped.
Fixes: ef5c2eba2412 ("ASoC: codecs: Add da7213 codec") Cc: stable@vger.kernel.org
Why is this a stable fix when it only enables further work?
I thought that not syncing the cached registers might impact other setups as well.
Also, Renesas is contributing to CIP (Civil Infrastructure Project) which is based on stable releases. The audio support in this series will be backported to CIP kernels. Marking it for stable ease the work to backport the RZ/G3S audio support to CIP.
With this, would you prefer to drop the "Cc: stable@vger.kernel.org"?
Thank you, Claudiu Beznea
Hi Claudiu,
From: Claudiu Beznea claudiu.beznea@tuxon.dev Sent: 06 November 2024 13:56
Hi, Mark,
On 06.11.2024 15:43, Mark Brown wrote:
On Wed, Nov 06, 2024 at 10:18:17AM +0200, Claudiu wrote:
From: Claudiu Beznea claudiu.beznea.uj@bp.renesas.com
On the Renesas RZ/G3S SMARC Carrier II board having a DA7212 codec
(using
da7213 driver) connected to one SSIF-2 available on the Renesas RZ/G3S
SoC
it has been discovered that using the runtime PM API for suspend/resume (as will be proposed in the following commits) leads to the codec not being propertly initialized after resume. This is because w/o max_register populated to regmap_config the regcache_rbtree_sync() breaks on base_reg > max condition and the regcache_sync_block() call
is
skipped.
Fixes: ef5c2eba2412 ("ASoC: codecs: Add da7213 codec") Cc: stable@vger.kernel.org
Why is this a stable fix when it only enables further work?
I thought that not syncing the cached registers might impact other setups as well.
Also, Renesas is contributing to CIP (Civil Infrastructure Project) which is based on stable releases. The audio support in this series will be backported to CIP kernels. Marking it for stable ease the work to backport the RZ/G3S audio support to CIP.
Whilst the above is true, we still must adhere to the "stable" rules - Only bug fixes etc. should be marked for stable. Any extra effort is for CIP to do.
As you say perhaps this patch will fix code functionality for other users. I'll leave it to the relevant maintainers to decide if this is a suitable bug fix or not :)
Kind regards, Chris
With this, would you prefer to drop the "Cc: stable@vger.kernel.org"?
Thank you, Claudiu Beznea
linux-stable-mirror@lists.linaro.org
-
Chris Paterson -
Claudiu -
Claudiu Beznea
-
Mark Brown