[PATCH] ASoC: arizona: Make logging of FLL calculations clearer

[PATCH] ASoC: arizona: Make logging of FLL calculations clearer

[Richard Fitzgerald]

The debug logging of FLL calculations was confusing. Values were
printed in hex without indicating this by a leading 0x, and
despite these normally being required in decimal. Also where the
register value isn't the actual value (it s a power-of-two or
0 means 1, 1 means 2, ...)  it was unclear whether the actual or
register value was shown.

This patch changes the log print so that all mathematical values
are shown in decimal, all register values are shown in hex with a
0x prefix, and where the register value isn't the actual integer
value the decimal integer value is shown in () after the hex
register value.

Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
---
 sound/soc/codecs/arizona.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c
index 913cfa8..92d22a0 100644
--- a/sound/soc/codecs/arizona.c
+++ b/sound/soc/codecs/arizona.c
@@ -2149,11 +2149,12 @@ static int arizona_calc_fll(struct arizona_fll *fll,
 		return -EINVAL;
 	}
 
-	arizona_fll_dbg(fll, "N=%x THETA=%x LAMBDA=%x\n",
+	arizona_fll_dbg(fll, "N=%d THETA=%d LAMBDA=%d\n",
 			cfg->n, cfg->theta, cfg->lambda);
-	arizona_fll_dbg(fll, "FRATIO=%x(%d) OUTDIV=%x REFCLK_DIV=%x\n",
-			cfg->fratio, cfg->fratio, cfg->outdiv, cfg->refdiv);
-	arizona_fll_dbg(fll, "GAIN=%d\n", cfg->gain);
+	arizona_fll_dbg(fll, "FRATIO=0x%x(%d) OUTDIV=%d REFCLK_DIV=0x%x(%d)\n",
+			cfg->fratio, ratio, cfg->outdiv,
+			cfg->refdiv, 1 << cfg->refdiv);
+	arizona_fll_dbg(fll, "GAIN=0x%x(%d)\n", cfg->gain, 1 << cfg->gain);
 
 	return 0;
 
-- 
1.9.1

Re: [PATCH] ASoC: arizona: Make logging of FLL calculations clearer

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

On Tue, Feb 23, 2016 at 02:16:32PM +0000, Richard Fitzgerald wrote:
> The debug logging of FLL calculations was confusing. Values were
> printed in hex without indicating this by a leading 0x, and
> despite these normally being required in decimal. Also where the
> register value isn't the actual value (it s a power-of-two or
> 0 means 1, 1 means 2, ...)  it was unclear whether the actual or
> register value was shown.

I think that stuff was originally based on the way the datasheets quote
things:

> -	arizona_fll_dbg(fll, "FRATIO=%x(%d) OUTDIV=%x REFCLK_DIV=%x\n",

the hex(decimal) but there is certainly very familiar from some of
those.

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

Re: [PATCH] ASoC: arizona: Make logging of FLL calculations clearer

[Richard Fitzgerald]

On 24/02/16 04:08, Mark Brown wrote:
> On Tue, Feb 23, 2016 at 02:16:32PM +0000, Richard Fitzgerald wrote:
>> The debug logging of FLL calculations was confusing. Values were
>> printed in hex without indicating this by a leading 0x, and
>> despite these normally being required in decimal. Also where the
>> register value isn't the actual value (it s a power-of-two or
>> 0 means 1, 1 means 2, ...)  it was unclear whether the actual or
>> register value was shown.
> I think that stuff was originally based on the way the datasheets quote
> things:
>
>> -	arizona_fll_dbg(fll, "FRATIO=%x(%d) OUTDIV=%x REFCLK_DIV=%x\n",
> the hex(decimal) but there is certainly very familiar from some of
> those.
Indeed, and it was fine on the first codec. Now we've got various 
revisions of the FLL with some fields having different meanings, human 
error started to creep into interpreting the debug.

Re: [PATCH] ASoC: arizona: Make logging of FLL calculations clearer

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

On Wed, Feb 24, 2016 at 05:39:32PM +0000, Richard Fitzgerald wrote:
> On 24/02/16 04:08, Mark Brown wrote:

> >I think that stuff was originally based on the way the datasheets quote
> >things:

> >>-	arizona_fll_dbg(fll, "FRATIO=%x(%d) OUTDIV=%x REFCLK_DIV=%x\n",
> >the hex(decimal) but there is certainly very familiar from some of
> >those.

> Indeed, and it was fine on the first codec. Now we've got various revisions
> of the FLL with some fields having different meanings, human error started
> to creep into interpreting the debug.

I'm not saying it's a bad idea to change it, just pointing out where
it's likely to have come from (and the fact that the way the datasheets
were writing this was always a bit weird).

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