From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 89CE1C6FA83 for ; Wed, 7 Sep 2022 11:31:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type: MIME-Version:References:Message-ID:In-Reply-To:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=BZe5koo7Znl2N1+/pw1zuITQpsgRCzgq1VcdvjP1QxA=; b=vmsVZ2TuKP4c9LfyrAbo6cTFwJ mavlEP3J2E2pVnpbRy0Pyza62lP96Ord52pO42MjhL95J785Zp+sxfrAQykNB410SfY8gHuV3VvIZ ZwgVotHXULOw+5JAbqSS8apHW7w0wpXAk80yRobmeoV8HEpka+ctbhhZvtyBHU19jePmtY4WtqozS vAmlGMdape4uTUhDdpGkRR98Q1E0xSwvYEyLS96kIMFE2NRHTWFUoV9STd4cZ5XVupVZmjU/R6QBh QuxjDG1qxTMM+cOTha/gTyYSeSZtxxXgo2bXIC3fvKN/gdERCzW+1tjE0USHGVrA5UGiK8LWNREl2 mvrO++Vw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oVtFu-005hkC-KN; Wed, 07 Sep 2022 11:30:06 +0000 Received: from mga05.intel.com ([192.55.52.43]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oVtFr-005heK-FC for linux-arm-kernel@lists.infradead.org; Wed, 07 Sep 2022 11:30:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1662550203; x=1694086203; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=TrnktqRIs+K86T7z1mbr+yegNoYFDmK9/RGPfMKeYaU=; b=lHHvRPvobDwYcRdVhoc7FWlP+5hJT7aIQld7kQVkKAoYiVrDS893MWJE YS8FFvuCz3apTgc0MtR7Ap+nvbYH8GjizCRbDboHwWnEmF2RoKGqXQ0/0 7jsrjO2aZGJYCBxiji0HLRedk1JhC4KVriyDZuxIH47j0IxtSRd0Fzu9Z OsiWAFGBvu9Vg4GXUCY+IWyGiYAYM4jdUVjmC+y8C9WrNThp85ptvhHSF UfdwdwAVVMryUI69kuaTQvGCYj2He23+OOMn0+XqYzgUdDOUbDqk1wOyD MJ8oJ72Io0vs/bny6C8iCHJY0b+itUNBtsSAvGgm5NGJppXYDkn99bk6b A==; X-IronPort-AV: E=McAfee;i="6500,9779,10462"; a="383142593" X-IronPort-AV: E=Sophos;i="5.93,296,1654585200"; d="scan'208";a="383142593" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Sep 2022 04:29:56 -0700 X-IronPort-AV: E=Sophos;i="5.93,296,1654585200"; d="scan'208";a="676146243" Received: from dmatouse-mobl.ger.corp.intel.com ([10.251.223.53]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Sep 2022 04:29:50 -0700 Date: Wed, 7 Sep 2022 14:29:49 +0300 (EEST) From: =?ISO-8859-15?Q?Ilpo_J=E4rvinen?= To: Sergiu.Moga@microchip.com Subject: Re: [PATCH v2 12/13] tty: serial: atmel: Make the driver aware of the existence of GCLK In-Reply-To: Message-ID: References: <20220906135511.144725-1-sergiu.moga@microchip.com> <20220906135511.144725-13-sergiu.moga@microchip.com> <3f98d634-789-a0bd-84e-cfc2a1de70af@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-565948247-1662550196=:1717" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220907_043003_563729_AC0F1455 X-CRM114-Status: GOOD ( 29.71 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alexandre.belloni@bootlin.com, mturquette@baylibre.com, LKML , admin@hifiphile.com, krzysztof.kozlowski+dt@linaro.org, Jiri Slaby , linux-clk@vger.kernel.org, lee@kernel.org, linux-serial , devicetree@vger.kernel.org, Tudor.Ambarus@microchip.com, radu_nicolae.pirea@upb.ro, robh+dt@kernel.org, linux-arm-kernel@lists.infradead.org, richard.genoud@gmail.com, Greg Kroah-Hartman , linux-spi@vger.kernel.org, sboyd@kernel.org, broonie@kernel.org, Kavyasree.Kotagiri@microchip.com, Claudiu.Beznea@microchip.com Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-565948247-1662550196=:1717 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT On Wed, 7 Sep 2022, Sergiu.Moga@microchip.com wrote: > On 07.09.2022 12:36, Ilpo Järvinen wrote: > > On Tue, 6 Sep 2022, Sergiu Moga wrote: > > > >> Previously, the atmel serial driver did not take into account the > >> possibility of using the more customizable generic clock as its > >> baudrate generator. Unless there is a Fractional Part available to > >> increase accuracy, there is a high chance that we may be able to > >> generate a baudrate closer to the desired one by using the GCLK as the > >> clock source. Now, depending on the error rate between > >> the desired baudrate and the actual baudrate, the serial driver will > >> fallback on the generic clock. The generic clock must be provided > >> in the DT node of the serial that may need a more flexible clock source. > >> > >> Signed-off-by: Sergiu Moga > >> --- > > Is percent accurate enough or would you perhaps want something slightly > > more accurate? > > > > > It is accurate enough for the all the baudrates I have tested. It > usually taps into the GCLK whenever high baudrates such as 921600 are > used. For 115200 for example, the error rate was slightly better in the > case of the peripheral clock and it acted accordingly, choosing the > latter as its baudrate source clock. I do not think that a higher > accuracy than this would be needed though. Say that using percent > accuracy yields that the error rates are equal, but the gclk would have > been better in this case by, say, a few 10 ^ -4, but the code logic does > not see it so it proceeds using the peripheral clock. In that case, the > error rate of the peripheral clock would still be low enough relative to > the desired baudrate for the communication to function properly. > > The higher the baudrate, the lower the error rate must be in order for > things to go smoothly. For example, for a baudrate of 57600 I noticed > that even an error rate as big as 6% is still enough for the > communication to work properly, while in the case of 921600 anything > bigger than 2% and things do not go smoothly anymore. So I guess that it > would be safe to say that, unless you go for baudrates as high as tens > of millions, things should work well with just percent accuracy. A > higher accuracy always definetely helps, but I believe it is not needed > in this case. > > > > Given you've abs() at the caller side, the error rate could be > > underestimated, is underestimating OK? > > > > > Yes, this should be fine. While (both empirically and after looking > stuff up) I noticed that in the case of negative error rates, their > absolute value needs to be smaller than the one of positive error rates, > it must be so by a very small margin that is negligible when estimating > through percent accuracy. OK. Thanks for checking. -- i. --8323329-565948247-1662550196=:1717 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --8323329-565948247-1662550196=:1717--