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 phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 85948C433EF for ; Tue, 22 Mar 2022 12:48:12 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 594BF839C7; Tue, 22 Mar 2022 13:48:09 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=akkea.ca Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=akkea.ca header.i=@akkea.ca header.b="io42bnWy"; dkim=pass (1024-bit key) header.d=akkea.ca header.i=@akkea.ca header.b="jZhEb7lp"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 87AB7839C7; Tue, 22 Mar 2022 13:48:06 +0100 (CET) Received: from node.akkea.ca (li1434-30.members.linode.com [45.33.107.30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id C4D098395F for ; Tue, 22 Mar 2022 13:48:00 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=akkea.ca Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=angus@akkea.ca Received: from localhost (localhost [127.0.0.1]) by node.akkea.ca (Postfix) with ESMTP id C0D114E2006; Tue, 22 Mar 2022 12:47:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akkea.ca; s=mail; t=1647953278; bh=squKIh1acuEx7ZGdSgN5LY7mZMeJ05hprXEHm88PfYo=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=io42bnWyjjbMdGPd7x2+btZbW91JQAMm+WwmkHvBFGu+s0a4XzxEdXxm2zGFXFjpO W65PkgWyBCbV3IZPa1P2yoGJBfLisQXycvMD0xrBNiAwpqNz1wTg+6hGgEgIQ6kFIs dFEtfmWQ4e/JEHf393++GdAk1eZFwNFfZuRZmdfs= Received: from node.akkea.ca ([127.0.0.1]) by localhost (mail.akkea.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JKuR-9B9fGz; Tue, 22 Mar 2022 12:47:57 +0000 (UTC) Received: from www.akkea.ca (localhost [127.0.0.1]) by node.akkea.ca (Postfix) with ESMTP id E44D44E2003; Tue, 22 Mar 2022 12:47:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akkea.ca; s=mail; t=1647953277; bh=squKIh1acuEx7ZGdSgN5LY7mZMeJ05hprXEHm88PfYo=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=jZhEb7lpOpsVrQKMjL8xg0JETzrvQJDI9+LodEHcmXuwhjioL7oDsZeKAimS257jq O1q7hpznFO2ZbFaBsk0Qbx8yQjXfCv2wfSUSRl3BXDGzF+bMXQff5PnrPVyH9ZFKj2 XPjc82H9mpQh0GAbl/28aN+2xSDIKFi0ed0TmCPQ= MIME-Version: 1.0 Date: Tue, 22 Mar 2022 05:47:57 -0700 From: Angus Ainslie To: Heiko Thiery Cc: u-boot@lists.denx.de, Marek Vasut , Michale Walle , Angus Ainslie , lukma@denx.de, seanga2@gmail.com, sbabic@denx.de, festevam@gmail.com, uboot-imx@nxp.com, peng.fan@nxp.com Subject: Re: [RFC] serial: mxc: get the clock frequency from the used clock for the device In-Reply-To: References: <20220317124127.1783768-1-heiko.thiery@gmail.com> <775d1b35685c64474efa90ae281726d5@akkea.ca> <187a931fce064feacb9e72b603d37140@akkea.ca> Message-ID: <07b0fe11ef637f518ff5d499e25a72ed@akkea.ca> X-Sender: angus@akkea.ca User-Agent: Roundcube Webmail/1.3.17 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean On 2022-03-21 06:50, Heiko Thiery wrote: > Hi Angus, > > [snip] > >> > So I'm not sure if the ipg clock is the right one for the boards that >> > has different clock for ipg and per. >> >> So I only looked at imx6qdl.dtsi where the clocks are different >> >> clocks = <&clks IMX6QDL_CLK_UART_IPG>, >> <&clks IMX6QDL_CLK_UART_SERIAL>; >> clock-names = "ipg", "per"; >> >> And from that file it looks like the per clock would be the correct >> one. > > Yes, 'per' seems to be the right one. > >> Should the clock be looked up by id instead of by name and then have a >> different code path for each imx board type ? > > But how to get the right clk id? The id's for all the implementations > are different. Or not? > Yeah you're correct that won't work. >> >> > >> >> > + } >> >> > + >> >> > + /* as fallback we try to get the clk rate that way */ >> >> > + if (rate == 0) >> >> > + rate = imx_get_uartclk(); >> >> >> >> Would it be better to re-write imx_get_uartclk so that both the >> >> getting >> >> and setting of clocks was correct ? >> > >> > I do not understand what you mean with that. >> > >> >> There are other places in the code that imx_get_uartclk gets called. >> If >> an index was added to imx_get_uartclk(int index) then you wouldn't >> need >> the code above in the mxc_serial_setbrg function. That would also make >> all of the places where imx_get_uartclk gets called return the correct >> value. > > By index do you mean the clk id? > No I was thinking number of the device uart[0-3]. Thinking about it some more it's probably not useful as you already have the udevice pointer. I was just trying to think of ways to reduce the amount of code change for the older SOCs. Using the 'per' clock is a better solution. >> >> It might make sense to create a new function imx7_get_uartclk that >> gets >> called on newer SOCs so that the imx6 and earlier code doesn't need to >> get changed. > > At what point should this be called instead of the imx_get_uartclk() > function? > I was thinking a CONFIG_IS_ENBLED switch between the old version and the new one based on SOC. Angus