Skip to contentSkip to conversation

ASoC: wm_hubs: Fix DC Servo readback

PATCH In review Nikesh Oswal 3 participants 6 messages Aug 13, 2014

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 ASoC: wm_hubs: Fix DC Servo readback

wm_hubs is a common driver code shared by WM8958, WM1811, WM8944 and WM8993 all these codecs have the DC Servo Values either in register 57h or 59h. Current code was reading register 58h for WM8958 and WM8994 revisions 2 and 3 but looking at the data sheet the DC Servo Values are stored in register 57h for these codecs. This patch fixes it by reading the correct register for DC Servo

---
 sound/soc/codecs/wm_hubs.c |    3 ---
 1 file changed, 3 deletions(-)
sound/soc/codecs/wm_hubs.c +0 -3
index 916817f..95c5d71 100644
@@ -210,9 +210,6 @@ static int wm_hubs_read_dc_servo(struct snd_soc_codec *codec,
 	case 2:
 		dcs_reg = WM8994_DC_SERVO_4E;
 		break;
-	case 1:
-		dcs_reg = WM8994_DC_SERVO_READBACK;
-		break;
 	default:
 		dcs_reg = WM8993_DC_SERVO_3;
 		break;
Signature · 1 line
1.7.9.5
#1 lore raw
Quoted 18 lines · Nikesh Oswal

wm_hubs is a common driver code shared by WM8958, WM1811, WM8944 and WM8993 all these codecs have the DC Servo Values either in register 57h or 59h. Current code was reading register 58h for WM8958 and WM8994 revisions 2 and 3 but looking at the data sheet the DC Servo Values are stored in register 57h for these codecs. This patch fixes it by reading the correct register for DC Servo

---
 sound/soc/codecs/wm_hubs.c |    3 ---
 1 file changed, 3 deletions(-)
sound/soc/codecs/wm_hubs.c +0 -0
index 916817f..95c5d71 100644

sound/soc/codecs/wm_hubs.c static int wm_hubs_read_dc_servo(struct snd_soc_codec *codec, · line 215

Quoted 9 lines
sound/soc/codecs/wm_hubs.c +0 -3
@@ -210,9 +210,6 @@ static int wm_hubs_read_dc_servo(struct snd_soc_codec *codec,
 	case 2:
 		dcs_reg = WM8994_DC_SERVO_4E;
 		break;
-	case 1:
-		dcs_reg = WM8994_DC_SERVO_READBACK;
-		break;
 	default:
 		dcs_reg = WM8993_DC_SERVO_3;
 		break;

This doesn't look right, firstly if it is the same register for all versions then surely we should change the code that sets dcs_readback_mode rather than setting that to different values but treating them the same. Although obviously if nothing still uses this case we could remove it as well.

Also I think the situation is more complex for example on version 4.4 of the datasheet for wm8994 the WR_VAL fields appear to be in register 59h. Which is not consistent with this.

Thanks,
Charles

maintainer
#2 lore raw
Quoted 18 lines · Charles Keepax

sound/soc/codecs/wm_hubs.c static int wm_hubs_read_dc_servo(struct snd_soc_codec *codec, · line 215

Quoted 9 lines · Nikesh Oswal
sound/soc/codecs/wm_hubs.c +0 -3
 	case 2:
 		dcs_reg = WM8994_DC_SERVO_4E;
 		break;
-	case 1:
-		dcs_reg = WM8994_DC_SERVO_READBACK;
-		break;
 	default:
 		dcs_reg = WM8993_DC_SERVO_3;
 		break;

This doesn't look right, firstly if it is the same register for all versions then surely we should change the code that sets dcs_readback_mode rather than setting that to different values but treating them the same. Although obviously if nothing still uses this case we could remove it as well.

Quoted 3 lines

Also I think the situation is more complex for example on version 4.4 of the datasheet for wm8994 the WR_VAL fields appear to be in register 59h. Which is not consistent with this.

There was a change in the DC servo between revisions of the WM8994 (at revision E from the look of the code). This isn't documented in the datasheets as they only document current silicon.

#3 lore raw
Quoted 19 lines · Mark Brown
Quoted 17 lines · Charles Keepax

sound/soc/codecs/wm_hubs.c static int wm_hubs_read_dc_servo(struct snd_soc_codec *codec, · line 215

Quoted 9 lines · Nikesh Oswal
sound/soc/codecs/wm_hubs.c +0 -3
 	case 2:
 		dcs_reg = WM8994_DC_SERVO_4E;
 		break;
-	case 1:
-		dcs_reg = WM8994_DC_SERVO_READBACK;
-		break;
 	default:
 		dcs_reg = WM8993_DC_SERVO_3;
 		break;

This doesn't look right, firstly if it is the same register for all versions then surely we should change the code that sets dcs_readback_mode rather than setting that to different values but treating them the same. Although obviously if nothing still uses this case we could remove it as well.

Quoted 7 lines
Quoted 3 lines

Also I think the situation is more complex for example on version 4.4 of the datasheet for wm8994 the WR_VAL fields appear to be in register 59h. Which is not consistent with this.

There was a change in the DC servo between revisions of the WM8994 (at revision E from the look of the code). This isn't documented in the datasheets as they only document current silicon.

Indeed, but this patch sets all revs of wm8994 to use register 57h. The lastest version of the datasheet has this register at 59h although some of the older versions of the datasheet (which likely match some older revs of the chip although no way to tell which one just from the datasheet) have it at 57h.

I think basically we need to get some clarity from hardware here on which revs use which address and update this patch to match, but either way it looks likely that this patch doesn't address the whole picture.

Thanks,
Charles

#4 lore raw
Quoted 34 lines · Charles Keepax
Quoted 19 lines · Mark Brown
Quoted 17 lines · Charles Keepax

Review

Quoted 9 lines · Nikesh Oswal
(quoted diff) +0 -3
 	case 2:
 		dcs_reg = WM8994_DC_SERVO_4E;
 		break;
-	case 1:
-		dcs_reg = WM8994_DC_SERVO_READBACK;
-		break;
 	default:
 		dcs_reg = WM8993_DC_SERVO_3;
 		break;

This doesn't look right, firstly if it is the same register for all versions then surely we should change the code that sets dcs_readback_mode rather than setting that to different values but treating them the same. Although obviously if nothing still uses this case we could remove it as well.

Quoted 7 lines
Quoted 3 lines

Also I think the situation is more complex for example on version 4.4 of the datasheet for wm8994 the WR_VAL fields appear to be in register 59h. Which is not consistent with this.

There was a change in the DC servo between revisions of the WM8994 (at revision E from the look of the code). This isn't documented in the datasheets as they only document current silicon.

Indeed, but this patch sets all revs of wm8994 to use register 57h. The lastest version of the datasheet has this register at 59h although some of the older versions of the datasheet (which likely match some older revs of the chip although no way to tell which one just from the datasheet) have it at 57h.

Quoted 4 lines

I think basically we need to get some clarity from hardware here on which revs use which address and update this patch to match, but either way it looks likely that this patch doesn't address the whole picture.

Sorry no ignore me I am talking non-sense here. It still treats the newer revs correctly, I suspect this might be a nice change though:

sound/soc/codecs/wm_hubs.c +0 -0
@@ -209,7 +209,7 @@ static int wm_hubs_read_dc_servo(struct

snd_soc_codec *codec,

                dcs_reg = WM8994_DC_SERVO_4E;
                break;
        case 1:
-               dcs_reg = WM8994_DC_SERVO_READBACK;
+               dcs_reg = WM8994_DC_SERVO_4;
                break;

Thanks,
Charles

maintainer
#5 lore raw
In reply to Charles Keepax
Quoted 11 lines · Charles Keepax
Quoted 9 lines · Mark Brown
Quoted 3 lines · Charles Keepax

Also I think the situation is more complex for example on version 4.4 of the datasheet for wm8994 the WR_VAL fields appear to be in register 59h. Which is not consistent with this.

There was a change in the DC servo between revisions of the WM8994 (at revision E from the look of the code). This isn't documented in the datasheets as they only document current silicon.

Quoted 5 lines

Indeed, but this patch sets all revs of wm8994 to use register 57h. The lastest version of the datasheet has this register at 59h although some of the older versions of the datasheet (which likely match some older revs of the chip although no way to tell which one just from the datasheet) have it at 57h.

Yes, I'm agreeing with you - I'm pointing out what Nikesh has missed (you can see this from the changelogs as well). The patch will break anything using older devices.

Quoted 4 lines

I think basically we need to get some clarity from hardware here on which revs use which address and update this patch to match, but either way it looks likely that this patch doesn't address the whole picture.

This code got rather a lot of attention...