From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751606AbdFIOUq (ORCPT ); Fri, 9 Jun 2017 10:20:46 -0400 Received: from mail-db5eur01on0041.outbound.protection.outlook.com ([104.47.2.41]:49392 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751527AbdFIOUo (ORCPT ); Fri, 9 Jun 2017 10:20:44 -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+rCAgAVBh5CAA7kdAIAKGxRAgABjTQCAAEwkoA== Date: Fri, 9 Jun 2017 14:20:41 +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.231.64] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;AM5PR04MB3075;7:5o8ULDokjuSQL9uEezhpkd1XZe0at7uNiNSOwW+ozP93iN8e5zA+8ntPXG6OAGCsZVlEnsC/opOSdausX/lO+QXfJiBmdM14g1jtfas2gAMPyLoBejJj5+O3B98YYsRHOMKy86Bx55eVQhu9ILr7LpyXPh+8SjqoKhXOlIuAr9sQaMHVbDfGJmlW/g/26dcTMHiJVnrwmlc6L4irV3dGoG1ZKVugjSOgz4k/buhfO0lNZdjkyToUywMlt5LB4nCE3i1MgrJo0hopHLxwBnk8KwVRqjMn18eyBznQbqkxiYNTIXnKh/FQQDnn/udz5gXXtLzVfdir2jvomBkQEiVVbw== x-forefront-antispam-report: SFV:SKI;SCL:-1SFV:NSPM;SFS:(10009020)(6009001)(39860400002)(39840400002)(39850400002)(39410400002)(39400400002)(39450400003)(24454002)(13464003)(377454003)(81166006)(229853002)(2900100001)(54906002)(55016002)(99286003)(50986999)(76176999)(54356999)(93886004)(478600001)(8936002)(86362001)(14454004)(6436002)(6916009)(2950100002)(6506006)(33656002)(25786009)(5250100002)(6246003)(53546009)(5660300001)(74316002)(8676002)(110136004)(38730400002)(7736002)(305945005)(3846002)(2906002)(102836003)(53936002)(6116002)(7696004)(3280700002)(39060400002)(9686003)(4326008)(189998001)(3660700001)(66066001);DIR:OUT;SFP:1101;SCL:1;SRVR:AM5PR04MB3075;H:AM3PR04MB306.eurprd04.prod.outlook.com;FPR:;SPF:None;MLV:ovrnspm;PTR:InfoNoRecords;LANG:en; x-ms-traffictypediagnostic: AM5PR04MB3075: x-ms-office365-filtering-correlation-id: 66aa4c11-ef2a-4c7b-ad88-08d4af42b57e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075);SRVR:AM5PR04MB3075; 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)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:AM5PR04MB3075;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:AM5PR04MB3075; 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 14:20:41.1887 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR04MB3075 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 v59EL2fk025593 > -----Original Message----- > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com] > Sent: Friday, June 09, 2017 5:26 PM > 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; Dong Aisheng > Subject: Re: [PATCH 6/6] tty: serial: lpuart: add a more accurate baud > rate calculation method > > On Fri, Jun 9, 2017 at 11:01 AM, A.S. Dong wrote: > > >> >> > + 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. > > Okay, so, it means the maximum supported speed is UART clock / 4. Correct? > Yes. > >> 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 > > I've read that, but think outside the box. > > >> 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? > > I forgot the details... > > > 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. > > ...yes... > > >> 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. > > ...lemme prepare a python script demonstrating it. > Great, thanks > > How about you send a separate baud algorithm improvement patch later? > > Why not to do it right a way? > Because I thought that could be a separate patch which is doing algorithm improvement, then we can have the full history and a clear comparison. And also we are still not sure whether it works, we don't want to block on it too long. But if you're pretty sure about it, I would wait for some more time. However, personally I would still rather keep them in two separate Patches for clearer history and comparison. > Just describe it in a comment if you afraid of reader can't understand > from the code. > That is good. Regards Dong Aisheng > -- > With Best Regards, > Andy Shevchenko From mboxrd@z Thu Jan 1 00:00:00 1970 From: aisheng.dong@nxp.com (A.S. Dong) Date: Fri, 9 Jun 2017 14:20:41 +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 > -----Original Message----- > From: Andy Shevchenko [mailto:andy.shevchenko at gmail.com] > Sent: Friday, June 09, 2017 5:26 PM > 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; Dong Aisheng > Subject: Re: [PATCH 6/6] tty: serial: lpuart: add a more accurate baud > rate calculation method > > On Fri, Jun 9, 2017 at 11:01 AM, A.S. Dong wrote: > > >> >> > + 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. > > Okay, so, it means the maximum supported speed is UART clock / 4. Correct? > Yes. > >> 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 > > I've read that, but think outside the box. > > >> 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? > > I forgot the details... > > > 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. > > ...yes... > > >> 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. > > ...lemme prepare a python script demonstrating it. > Great, thanks > > How about you send a separate baud algorithm improvement patch later? > > Why not to do it right a way? > Because I thought that could be a separate patch which is doing algorithm improvement, then we can have the full history and a clear comparison. And also we are still not sure whether it works, we don't want to block on it too long. But if you're pretty sure about it, I would wait for some more time. However, personally I would still rather keep them in two separate Patches for clearer history and comparison. > Just describe it in a comment if you afraid of reader can't understand > from the code. > That is good. Regards Dong Aisheng > -- > With Best Regards, > Andy Shevchenko