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 D0418C48BC3 for ; Wed, 14 Feb 2024 13:45:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Zkb0fTg1lRT6Zw4wFUtgcw4ou40uOdfLXwiuQMbcNbA=; b=XEhIdKiL6TFEoA 1aUKMHRsEr/87mFX4UT+amN7bMK2B6Sx+vTQUT+hY0nfp4q0FI8DtgHyJKZ4HQA+7HtQSZa1BoQHi nkLSAmrprraMDeJ4yKwxm31UM0BXW6N8Q47cVbEFBC80DzmA1h7MWbz1olXia4cb6NCz++drACYop VgqhkTNTB2ibudOiyrheWNo8jOoQkHAla/EXQN1YBI1J5KA7gtkRCCOElbbP7zXUv8oujj6DDZO80 yF19Wy3p5LHgYzFhyvZhtuu3RtvDBnW07HAp9Ir6xf8a3DFyP7xVA4B+lwrKVZCRaTn0HA5d7/wRz 3TJmDR3ORBA62ZoetHtA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1raFZk-0000000D3ad-34OX; Wed, 14 Feb 2024 13:45:24 +0000 Received: from mgamail.intel.com ([192.198.163.14]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1raFZh-0000000D3aJ-2vEh for linux-arm-kernel@lists.infradead.org; Wed, 14 Feb 2024 13:45:22 +0000 X-IronPort-AV: E=McAfee;i="6600,9927,10982"; a="2104672" X-IronPort-AV: E=Sophos;i="6.06,159,1705392000"; d="scan'208";a="2104672" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmvoesa108.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Feb 2024 05:45:20 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10982"; a="935616662" X-IronPort-AV: E=Sophos;i="6.06,159,1705392000"; d="scan'208";a="935616662" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga001.fm.intel.com with ESMTP; 14 Feb 2024 05:45:17 -0800 Received: by black.fi.intel.com (Postfix, from userid 1003) id 36400195; Wed, 14 Feb 2024 15:45:16 +0200 (EET) Date: Wed, 14 Feb 2024 15:45:16 +0200 From: Andy Shevchenko To: Serge Semin Cc: Greg Kroah-Hartman , Jiri Slaby , Andy Shevchenko , Serge Semin , Alexey Malahov , Pavel Parkhomenko , Andy Shevchenko , Maxime Ripard , Will Deacon , Russell King , linux-arm-kernel@lists.infradead.org, linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v9 1/4] serial: 8250: Add 8250 port clock update method Message-ID: References: <20200723003357.26897-1-Sergey.Semin@baikalelectronics.ru> <20200723003357.26897-2-Sergey.Semin@baikalelectronics.ru> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200723003357.26897-2-Sergey.Semin@baikalelectronics.ru> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240214_054521_770183_FBB92D34 X-CRM114-Status: GOOD ( 24.51 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jul 23, 2020 at 03:33:54AM +0300, Serge Semin wrote: > Some platforms can be designed in a way so the UART port reference clock > might be asynchronously changed at some point. In Baikal-T1 SoC this may > happen due to the reference clock being shared between two UART ports, on > the Allwinner SoC the reference clock is derived from the CPU clock, so > any CPU frequency change should get to be known/reflected by/in the UART > controller as well. But it's not enough to just update the > uart_port->uartclk field of the corresponding UART port, the 8250 > controller reference clock divisor should be altered so to preserve > current baud rate setting. All of these things is done in a coherent > way by calling the serial8250_update_uartclk() method provided in this > patch. Though note that it isn't supposed to be called from within the > UART port callbacks because the locks using to the protect the UART port > data are already taken in there. ... > +/* > + * Note in order to avoid the tty port mutex deadlock don't use the next method > + * within the uart port callbacks. Primarily it's supposed to be utilized to > + * handle a sudden reference clock rate change. > + */ > +void serial8250_update_uartclk(struct uart_port *port, unsigned int uartclk) > +{ > + struct uart_8250_port *up = up_to_u8250p(port); > + unsigned int baud, quot, frac = 0; > + struct ktermios *termios; > + unsigned long flags; > + > + mutex_lock(&port->state->port.mutex); > + > + if (port->uartclk == uartclk) > + goto out_lock; > + > + port->uartclk = uartclk; > + termios = &port->state->port.tty->termios; > + > + baud = serial8250_get_baud_rate(port, termios, NULL); > + quot = serial8250_get_divisor(port, baud, &frac); > + > + serial8250_rpm_get(up); > + spin_lock_irqsave(&port->lock, flags); > + > + uart_update_timeout(port, termios->c_cflag, baud); > + > + serial8250_set_divisor(port, baud, quot, frac); > + serial_port_out(port, UART_LCR, up->lcr); > + serial8250_out_MCR(up, UART_MCR_DTR | UART_MCR_RTS); > + > + spin_unlock_irqrestore(&port->lock, flags); > + serial8250_rpm_put(up); > + > +out_lock: > + mutex_unlock(&port->state->port.mutex); While looking for something else I have stumbled over this function. My Q is, since it has some duplications with serial8250_do_set_termios(), can we actually call the latter (or derevative that can be called in both) in the above code instead of duplicating some lines? if (port UART clock has to be updated) call (unlocked version of) serial8250_do_set_termios() Serge, what do you think? > +} -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel