From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751664AbdFIIBt (ORCPT ); Fri, 9 Jun 2017 04:01:49 -0400 Received: from mail-he1eur01on0082.outbound.protection.outlook.com ([104.47.0.82]:8320 "EHLO EUR01-HE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751505AbdFIIBp (ORCPT ); Fri, 9 Jun 2017 04:01:45 -0400 From: "A.S. Dong" To: Andy Shevchenko CC: "linux-serial@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm Mailing List" , Greg Kroah-Hartman , Jiri Slaby , Andy Duan , Stefan Agner , Mingkai Hu , "Y.B. Lu" , Dong Aisheng Subject: RE: [PATCH 6/6] tty: serial: lpuart: add a more accurate baud rate calculation method Thread-Topic: [PATCH 6/6] tty: serial: lpuart: add a more accurate baud rate calculation method Thread-Index: AQHSyJkTP2kvMIG3AE6J+8TQN3PcYKII+rCAgAVBh5CAA7kdAIAKGxRA Date: Fri, 9 Jun 2017 08:01:40 +0000 Message-ID: References: <1494316248-24052-1-git-send-email-aisheng.dong@nxp.com> <1494316248-24052-7-git-send-email-aisheng.dong@nxp.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nxp.com; x-originating-ip: [199.59.226.141] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;DB6PR0401MB2262;7:m3oQKoe/zxnpsP4NOney+VomDXic+WvDajcvrgHDZhDOOQUrTrX4kDS4dkAUZDBk+DRbCzmxIHHSyTmln2sB0IAbKDNYaVzfdnnkb1HK/aBh8GMl28jdPY23cX2MMoIDBBCnzWrzFTjz3Ya47ejlCGCKsvVXe+z8fPyE95iRcfLYKsej2tflN7yqk7aAjh0yukgFEGSuXD186N9rw1IsJTQjxDZMJS+gKhDZ5phM8ZSGwYri6inUQmksEvpGm0QjS2sCDNVzFekyKwmJEK6ksLJdiYJ2oOo78dDSV+OQ5C9Oaje+7sQUQq8OGfCPIkZ+VnBVGDFTVhRz9I3lcBHxbA== x-forefront-antispam-report: SFV:SKI;SCL:-1SFV:NSPM;SFS:(10009020)(6009001)(39450400003)(39400400002)(39410400002)(39840400002)(39860400002)(39850400002)(24454002)(13464003)(377454003)(66066001)(189998001)(3660700001)(6246003)(3280700002)(54906002)(5250100002)(99286003)(478600001)(55016002)(38730400002)(86362001)(8676002)(93886004)(6506006)(81166006)(74316002)(6436002)(4326008)(5660300001)(2906002)(39060400002)(110136004)(53936002)(305945005)(7736002)(8936002)(3846002)(54356999)(76176999)(25786009)(50986999)(14454004)(33656002)(6116002)(53546009)(9686003)(229853002)(102836003)(2900100001)(7696004)(6916009)(2950100002);DIR:OUT;SFP:1101;SCL:1;SRVR:DB6PR0401MB2262;H:AM3PR04MB306.eurprd04.prod.outlook.com;FPR:;SPF:None;MLV:ovrnspm;PTR:InfoNoRecords;LANG:en; x-ms-traffictypediagnostic: DB6PR0401MB2262: x-ms-office365-filtering-correlation-id: 0f8fdeab-2af3-4188-af43-08d4af0dc342 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);SRVR:DB6PR0401MB2262; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(9452136761055)(185117386973197); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:DB6PR0401MB2262;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:DB6PR0401MB2262; x-forefront-prvs: 03333C607F spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2017 08:01:41.0351 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0401MB2262 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v5981tLc030520 Hi Andy, > -----Original Message----- > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com] > Sent: Saturday, June 03, 2017 1:11 AM > To: A.S. Dong > Cc: linux-serial@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm > Mailing List; Greg Kroah-Hartman; Jiri Slaby; Andy Duan; Stefan Agner; > Mingkai Hu; Y.B. Lu > Subject: Re: [PATCH 6/6] tty: serial: lpuart: add a more accurate baud > rate calculation method > > On Wed, May 31, 2017 at 5:18 PM, A.S. Dong wrote: > >> On Tue, May 9, 2017 at 10:50 AM, Dong Aisheng > wrote: > > By some reason my previous message went privately. > It didn't have anything major anyway and here I'm suggesting optimization > of finding factors of the formula in use. See below. > > >> > + u32 sbr, osr, baud_diff, tmp_osr, tmp_sbr, tmp_diff, tmp; > >> > + u32 clk = sport->port.uartclk; > >> > + > >> > + /* > >> > + * The idea is to use the best OSR (over-sampling rate) > possible. > >> > + * Note, OSR is typically hard-set to 16 in other LPUART > >> instantiations. > >> > + * Loop to find the best OSR value possible, one that > >> > + generates > >> minimum > >> > + * baud_diff iterate through the rest of the supported > >> > + values of > >> OSR. > >> > + * > >> > + * Calculation Formula: > >> > + * Baud Rate = baud clock / ((OSR+1) × SBR) > >> > + */ > >> > + baud_diff = baudrate; > >> > + osr = 0; > >> > + sbr = 0; > >> > + > >> > >> > + for (tmp_osr = 4; tmp_osr <= 32; tmp_osr++) { > > I missed one thing, what happened by default to OSR? What is the value in > use? > No valid default value. (osc/sbr are 0 by default) If no proper osc and sbr calculated, a WARNING will show. > >> I _think_ you may simplify this and avoid for-loop if you reconsider > >> approach. > > > But there is indeed a optimization way, see below. > > > To optimize the looping, we probably could do: > > If (!baud_diff) > > Break; > > It's a small one, we may have more interesting approach. > > So, the algo is the following: > > Assume the ranges like this: > OSR = [4 ... 32] > SBR = [2 ... 8192] > Baud Rate = baud clock / ((OSR+1) × SBR) In HW: OSR range : 3 – 31 SBR range: 1 – 8191 > Then: > > 1. Get ratio factor as > ratio = CLK / desired baud rate > 2. If ratio < 8192 * 9 / 2, just use (ratio / 4, 4) as (OSR, SBR) setting. > (Needs clarification on OSR < 4) Sorry that I'm a bit mess here. What is 8192 * 9 /2 meaning? And for (ratio / 4, 4) as (OSR,SBR), take 115200 as an example: Assuming baud clock 24Mhz. Ratio = 24000000 / 115200 = 208 OSR = Ratio / 4 = 52 Then OSR is out of range which seems wrong. > 3. if ratio >= 8192 * 31, just use those > two numbers (8192, 31). You can't do anything better there. This actually may not happen. Even take a 9600 as example, the clk becomes: 8191 * 31 * 9600 = 2.4GHz Which is theoretically not exist. > 4. Otherwise, get a minimum required factor of OSR > osr_min = ratio / 8192 > 5. Start your loop from osr_min + 1 to 31. > > 6 (optional). Of course you may not consider baud_diff > osr_min, it's I > suppose obvious > > P.S. Note, all divisions by 2^n are just simple right shifts. Diffs are > calculated as multiplication of OSR and SBR in comparison to ratio. One > division so far. > I'm not quite understand the approach. How about you send a separate baud algorithm improvement patch later? Then it first can provide us a good patch history and also better to understand for review. Last, very appreciate for your kind and professional review. Regards Dong Aisheng From mboxrd@z Thu Jan 1 00:00:00 1970 From: aisheng.dong@nxp.com (A.S. Dong) Date: Fri, 9 Jun 2017 08:01:40 +0000 Subject: [PATCH 6/6] tty: serial: lpuart: add a more accurate baud rate calculation method In-Reply-To: References: <1494316248-24052-1-git-send-email-aisheng.dong@nxp.com> <1494316248-24052-7-git-send-email-aisheng.dong@nxp.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Andy, > -----Original Message----- > From: Andy Shevchenko [mailto:andy.shevchenko at gmail.com] > Sent: Saturday, June 03, 2017 1:11 AM > To: A.S. Dong > Cc: linux-serial at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm > Mailing List; Greg Kroah-Hartman; Jiri Slaby; Andy Duan; Stefan Agner; > Mingkai Hu; Y.B. Lu > Subject: Re: [PATCH 6/6] tty: serial: lpuart: add a more accurate baud > rate calculation method > > On Wed, May 31, 2017 at 5:18 PM, A.S. Dong wrote: > >> On Tue, May 9, 2017 at 10:50 AM, Dong Aisheng > wrote: > > By some reason my previous message went privately. > It didn't have anything major anyway and here I'm suggesting optimization > of finding factors of the formula in use. See below. > > >> > + u32 sbr, osr, baud_diff, tmp_osr, tmp_sbr, tmp_diff, tmp; > >> > + u32 clk = sport->port.uartclk; > >> > + > >> > + /* > >> > + * The idea is to use the best OSR (over-sampling rate) > possible. > >> > + * Note, OSR is typically hard-set to 16 in other LPUART > >> instantiations. > >> > + * Loop to find the best OSR value possible, one that > >> > + generates > >> minimum > >> > + * baud_diff iterate through the rest of the supported > >> > + values of > >> OSR. > >> > + * > >> > + * Calculation Formula: > >> > + * Baud Rate = baud clock / ((OSR+1) ? SBR) > >> > + */ > >> > + baud_diff = baudrate; > >> > + osr = 0; > >> > + sbr = 0; > >> > + > >> > >> > + for (tmp_osr = 4; tmp_osr <= 32; tmp_osr++) { > > I missed one thing, what happened by default to OSR? What is the value in > use? > No valid default value. (osc/sbr are 0 by default) If no proper osc and sbr calculated, a WARNING will show. > >> I _think_ you may simplify this and avoid for-loop if you reconsider > >> approach. > > > But there is indeed a optimization way, see below. > > > To optimize the looping, we probably could do: > > If (!baud_diff) > > Break; > > It's a small one, we may have more interesting approach. > > So, the algo is the following: > > Assume the ranges like this: > OSR = [4 ... 32] > SBR = [2 ... 8192] > Baud Rate = baud clock / ((OSR+1) ? SBR) In HW: OSR range : 3 ? 31 SBR range: 1 ? 8191 > Then: > > 1. Get ratio factor as > ratio = CLK / desired baud rate > 2. If ratio < 8192 * 9 / 2, just use (ratio / 4, 4) as (OSR, SBR) setting. > (Needs clarification on OSR < 4) Sorry that I'm a bit mess here. What is 8192 * 9 /2 meaning? And for (ratio / 4, 4) as (OSR,SBR), take 115200 as an example: Assuming baud clock 24Mhz. Ratio = 24000000 / 115200 = 208 OSR = Ratio / 4 = 52 Then OSR is out of range which seems wrong. > 3. if ratio >= 8192 * 31, just use those > two numbers (8192, 31). You can't do anything better there. This actually may not happen. Even take a 9600 as example, the clk becomes: 8191 * 31 * 9600 = 2.4GHz Which is theoretically not exist. > 4. Otherwise, get a minimum required factor of OSR > osr_min = ratio / 8192 > 5. Start your loop from osr_min + 1 to 31. > > 6 (optional). Of course you may not consider baud_diff > osr_min, it's I > suppose obvious > > P.S. Note, all divisions by 2^n are just simple right shifts. Diffs are > calculated as multiplication of OSR and SBR in comparison to ratio. One > division so far. > I'm not quite understand the approach. How about you send a separate baud algorithm improvement patch later? Then it first can provide us a good patch history and also better to understand for review. Last, very appreciate for your kind and professional review. Regards Dong Aisheng