From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932201AbcBXRjq (ORCPT ); Wed, 24 Feb 2016 12:39:46 -0500 Received: from mx0a-001ae601.pphosted.com ([67.231.149.25]:47817 "EHLO mx0a-001ae601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758283AbcBXRjn (ORCPT ); Wed, 24 Feb 2016 12:39:43 -0500 Authentication-Results: ppops.net; spf=none smtp.mail=rf@opensource.wolfsonmicro.com Message-ID: <56CDEAD4.1050405@opensource.wolfsonmicro.com> Date: Wed, 24 Feb 2016 17:39:32 +0000 From: Richard Fitzgerald User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: Mark Brown CC: , , , Subject: Re: [PATCH] ASoC: arizona: Make logging of FLL calculations clearer References: <1456236992-32028-1-git-send-email-rf@opensource.wolfsonmicro.com> <20160224040832.GQ18327@sirena.org.uk> In-Reply-To: <20160224040832.GQ18327@sirena.org.uk> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602240180 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.