| Message ID | 1456236992-32028-1-git-send-email-rf@opensource.wolfsonmicro.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 2595b7fe1aa3a1dfc47e549b39f7c35c5ce8a56d |
| Headers | show |
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.
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.
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).
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;
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(-)