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 X-Spam-Level: X-Spam-Status: No, score=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 198C1C433E0 for ; Sat, 13 Feb 2021 14:45:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D645264E35 for ; Sat, 13 Feb 2021 14:45:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229772AbhBMOp2 (ORCPT ); Sat, 13 Feb 2021 09:45:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37852 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229531AbhBMOpV (ORCPT ); Sat, 13 Feb 2021 09:45:21 -0500 Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 06D3AC061574; Sat, 13 Feb 2021 06:44:40 -0800 (PST) Received: by mail-pj1-x1031.google.com with SMTP id nm1so1225594pjb.3; Sat, 13 Feb 2021 06:44:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Clxbg1NQpCvPFEarfm0To7I3vKJpGaiNXI2i281I7Rw=; b=W+dBEZlCNadlIzeZWv/YGZQTDie+YXuykOE/f8tiy8//PRkmN87eWg+diFlAJbsPLo AP++b0SbrQlNMirtgKoBAb0xGfTPNSRLVrMD7wo9G7szbfObmqhdx22r28xwZ7K39vqk ROEkUiopqVPELhcL/3eVUfHcg0aE4ZeX3OD572QovE7YeO+8Lc9tQN3Ani+jrhnObgDR AzcJuQJxJ93TSEiWsErfTj9A/nqRdDB35HGO4wEZYa+lU955pw0nfCenmEktF4bOJhGQ vtqfXgO9uVwi9pzO9H/016J0JSROUyUY8SqIQWMtK/g0ORYWR/ECDVgrFpSWKJ9WPfGi deiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Clxbg1NQpCvPFEarfm0To7I3vKJpGaiNXI2i281I7Rw=; b=hcM8IOXliE883OkIdjbgHqi5vhXzZ9NwPIzb7giziN/wD6TTG0ocRvQtLRiodZT3Yv qEIcZ70tU/JL7Gx03+5PEkqJJiXCbrvPxMm8WAfhiQ7hj7kSFihg7TvystTxUZ3FHLBy XrLDNJq9jfCI4j38dtgg0zyvMj5YHV9Ep4TUO/KIyexHLSN6CUkpSNWp5N6vZIF9Vbm3 mjrrLgNrrxMpsPtPKD6o2cZ0YsX9Mg9st/l31b82BTuZa8ngTtFjVySE6alRNHmFredK mbs7xSm8Ze+dZBReOHk891uE+8kdEO/rmkSK52aG1rMLuiKPRJD1kjv/tNUfk6FxVhV0 9ocw== X-Gm-Message-State: AOAM531rprX1W2pyqNsAwdGn57ot/MEvi1fWu6fFJY2w0ArSYoa/nNDN GrKAqaWe4gkqKGO/X9DlBACK9kkSKuWXgcZANRQ= X-Google-Smtp-Source: ABdhPJyQflbftXv7GvNOE5gtCApEhN+4XtEadPJAB7B+KQGWan+Nt0DGjVri0hbD2Rw4pX1dzBL2Sg3Z7TBjUNm1Ru4= X-Received: by 2002:a17:90a:9f96:: with SMTP id o22mr2524278pjp.119.1613227479289; Sat, 13 Feb 2021 06:44:39 -0800 (PST) MIME-Version: 1.0 References: <20210115182909.314756-1-aford173@gmail.com> <20210118125204.hxsanoohwvdtdvym@fsr-ub1664-175> <20210120144454.f6b72lnasw4q3bde@fsr-ub1664-175> <20210120151305.GC19063@pengutronix.de> <20210120152813.x2pbs5vprevkly23@fsr-ub1664-175> <20210120155001.GD19063@pengutronix.de> <20210120161421.h3yng57m3fetwwih@fsr-ub1664-175> <20210121095617.GI19063@pengutronix.de> <20210121102450.lisl3mzqczdsmzda@fsr-ub1664-175> In-Reply-To: From: Adam Ford Date: Sat, 13 Feb 2021 08:44:28 -0600 Message-ID: Subject: Re: [PATCH V3] clk: imx: Fix reparenting of UARTs not associated with sdout To: Abel Vesa Cc: Sascha Hauer , arm-soc , Adam Ford-BE , Aisheng Dong , Michael Turquette , Stephen Boyd , Shawn Guo , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Linus Walleij , Jerome Brunet , linux-clk , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 3, 2021 at 3:22 PM Adam Ford wrote: > > On Thu, Jan 21, 2021 at 4:24 AM Abel Vesa wrote: > > > > On 21-01-21 10:56:17, Sascha Hauer wrote: > > > On Wed, Jan 20, 2021 at 06:14:21PM +0200, Abel Vesa wrote: > > > > On 21-01-20 16:50:01, Sascha Hauer wrote: > > > > > On Wed, Jan 20, 2021 at 05:28:13PM +0200, Abel Vesa wrote: > > > > > > On 21-01-20 16:13:05, Sascha Hauer wrote: > > > > > > > Hi Abel, > > > > > > > > > > > > > > On Wed, Jan 20, 2021 at 04:44:54PM +0200, Abel Vesa wrote: > > > > > > > > On 21-01-18 08:00:43, Adam Ford wrote: > > > > > > > > > On Mon, Jan 18, 2021 at 6:52 AM Abel Vesa wrote: > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > TBH, I'm against the idea of having to call consumer AP= I from a clock provider driver. > > > > > > > > > > I'm still investigating a way of moving the uart clock = control calls in drivers/serial/imx, > > > > > > > > > > where they belong. > > > > > > > > > > > > > > > > > > That makes sense. > > > > > > > > > > > > > > > > > > > > > > > > > Just a thought. The uart clock used for console remains on = from u-boot, > > > > > > > > so maybe it's enough to just add the CLK_IGNORE_UNUSED flag= to all the > > > > > > > > uart root clocks and remove the prepare/enable calls for ua= rt clocks > > > > > > > > for good. I don't really have a way to test it right now, b= ut maybe > > > > > > > > you could give it a try. > > > > > > > > > > > > > > That would mean that UART clocks will never be disabled, rega= rdless of > > > > > > > whether they are used for console or not. That doesn't sound = very > > > > > > > appealing. > > > > > > > > > > > > AFAIK, the only uart clock that is enabled by u-boot is the one= used for > > > > > > the console. Later on, when the serial driver probes, it will e= nable it itself. > > > > > > > > > > > > Unless I'm missing something, this is exactly what we need. > > > > > > > > > > It might enable it, but with CLK_IGNORE_UNUSED the clock won't be > > > > > disabled again when a port is closed after usage > > > > > > > > OK, tell me what I'm getting wrong in the following scenario: > > > > > > > > U-boot leaves the console uart clock enabled. All the other ones ar= e disabled. > > > > > > > > Kernel i.MX clk driver registers the uart clocks with flag CLK_IGNO= RE_UNUSED. > > > > > > I was wrong at that point. I originally thought the kernel will never > > > disable these clocks, but in fact it only leaves them enabled during = the > > > clk_disable_unused call. > > > > > > However, when CLK_IGNORE_UNUSED becomes relevant it's too late alread= y. > > > I just chatted with Lucas and he told me what the original problem wa= s > > > that his patch solved. > > > > > > The problem comes when an unrelated device and the earlycon UART have > > > the same parent clocks. The parent clock is enabled, but it's referen= ce > > > count is zero. Now when the unrelated device probes and toggles its > > > clocks then the shared parent clock will be disabled due to the > > > reference count being zero. Next time earlycon prints a character the > > > system hangs because the UART gates are still enabled, but their pare= nt > > > clocks no longer are. > > > > > > > Hmm, that is indeed a problem. That's why I think there should be some > > kind of NOCACHE flag for almost all the types of clocks. For example, > > in this case, it makes sense for the core to check the bit in the regis= ter > > and then disable the parent based on that instead of relying on the ref= count. > > Anyway, that's something that needs to be added in the CCF. > > > > > Overall I think Lucas' patches are still valid and relevant and with > > > Adams patches we even no longer have to enable all UART clocks, but > > > only the ones which are actually needed. > > > > Yeah, for now, I think we can go with Adam's patches. But longterm, I w= ould > > like to remove the special case of the uart clocks we have right now in= all > > the i.MX clock drivers. I looked around at other serial drivers, and I found nothing like this function for enabling all UART clocks. There are generic functions for registering consoles, earlycon etc, and the serial driver fetches the per and igp clocks from the device tree, so I attempted to simply remove imx_register_uart_clocks(). I booted an i.MX8M Nano from a fully-powered off state, and my serial console came up just fine. I checked the clk_summary, and the clock parents are set correctly and the respective clock rates appear to be correct (ie, the console is working at the desired baud rate, and Bluetooth is happy) Since I don't fully understand the serial driver and the clock dependencies, I don't want to just simply remove the function without discussing it, because I don't know the ramifications. However, when testing on the i.MX8M Nano, things look OK. I also tested suspend-resume and the console UART appears to return and the Bluetooth UART set to 4Mbps works just fine too. I'd like to post a V4 which just removes imx_register_uart_clocks and the corresponding calls to it. I don't know enough about the older 32-bit i.MX SoC's, but I have build-tested it, and I can generate a patch. Are there any objections and/or concerns? adam > > > > Is the patch I submitted good enough for someone's acked-by or > reviewed-by, or are there changes I need to implement? > > adam > > > > > > > Sascha > > > > > > > > > -- > > > Pengutronix e.K. | = | > > > Steuerwalder Str. 21 | https://eur01.safelinks.= protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.pengutronix.de%2F&data= =3D04%7C01%7Cabel.vesa%40nxp.com%7Ceed68987c68f4aeaa63408d8bdf2d051%7C686ea= 1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637468197861821302%7CUnknown%7CTWFpbG= Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C= 1000&sdata=3DX1J8KgxFquNin80zKVz0Ao22vv1MuTMWf91BUTczh9Y%3D&reserve= d=3D0 | > > > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0= | > > > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5= 555 | 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 X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8E55FC433E0 for ; Sat, 13 Feb 2021 14:45:53 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 53D5164E35 for ; Sat, 13 Feb 2021 14:45:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 53D5164E35 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=SbPTI+1LB1LzuHk4VqSOj7N1h41T7w3iex00nCuVfZ8=; b=u+rFbtR1tQbD2OQ4o01xDIzQm qHuDc8xMfikJAaAMcx+gJugVmAr+vBmhi6texD/StfhujlBZqGnDu1EH1O/hGNddbWS4crw+WekPx I7RxIiVMsCFvUWJ5I3AlVFnlJpbulDQRa3gzdNYezbVEqPQf9zVhOrETYYeX5gukQnJLLQUeWVTYJ maXLMbu5iNdIncueS4vbOo+XfBmjHFj5U/hZQgzbExvHGpTqbC4bxm6+TNe85yKViLZiFPYK58sw2 WPfznJbNOuvJAbxsXMjeehOrHGu28lKotXNkYWDmfMW1epW3wd/kjZtcG7LkAV/kIVZ2jZW0FkcKk ZvU+DnoyQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lAwA9-0004Sm-9C; Sat, 13 Feb 2021 14:44:45 +0000 Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1lAwA6-0004S8-M8 for linux-arm-kernel@lists.infradead.org; Sat, 13 Feb 2021 14:44:43 +0000 Received: by mail-pj1-x1029.google.com with SMTP id t2so1283534pjq.2 for ; Sat, 13 Feb 2021 06:44:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Clxbg1NQpCvPFEarfm0To7I3vKJpGaiNXI2i281I7Rw=; b=W+dBEZlCNadlIzeZWv/YGZQTDie+YXuykOE/f8tiy8//PRkmN87eWg+diFlAJbsPLo AP++b0SbrQlNMirtgKoBAb0xGfTPNSRLVrMD7wo9G7szbfObmqhdx22r28xwZ7K39vqk ROEkUiopqVPELhcL/3eVUfHcg0aE4ZeX3OD572QovE7YeO+8Lc9tQN3Ani+jrhnObgDR AzcJuQJxJ93TSEiWsErfTj9A/nqRdDB35HGO4wEZYa+lU955pw0nfCenmEktF4bOJhGQ vtqfXgO9uVwi9pzO9H/016J0JSROUyUY8SqIQWMtK/g0ORYWR/ECDVgrFpSWKJ9WPfGi deiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Clxbg1NQpCvPFEarfm0To7I3vKJpGaiNXI2i281I7Rw=; b=FKQZX+NRgACOeBnA5t0VJiE+8gCZUU0+LfK1ZL/ZzkmFMAReGCyttXMmeO7O2H8q/I YA8rE6/Pr0c+ftl6Yebm5NgCMEhj6gC9wxPIyUX3ByVYj5VNnbUt0IJrF/xbf10m45Xm OLeuav10Th1hb3ssz9UmNXhP1eYxvt0/5E48Yc4TrUz9g7zQqG49WhAjm76A0ZDKVem6 X5uVVaoO+RJmtE/xENiwS3NPtMfYHYLUDrE6LNzw2zx9J+vjKB9MCcc/4lYQ2WY5yvtj XobNb1sONLmvoFeKr1Mk/K9phxHPLRXLxKdtV2yUzRs0mhvq6zb7zF7Rke6Kr+WUo7N+ Kwrw== X-Gm-Message-State: AOAM5314cwQcmG5nSAST1YVX20kKwC34EqoBJ+i0z1SO2niovab6KqNq HrR05rBSq1Fqqc/yFEGpq+oCqSEo8sHjYm+Mf2U= X-Google-Smtp-Source: ABdhPJyQflbftXv7GvNOE5gtCApEhN+4XtEadPJAB7B+KQGWan+Nt0DGjVri0hbD2Rw4pX1dzBL2Sg3Z7TBjUNm1Ru4= X-Received: by 2002:a17:90a:9f96:: with SMTP id o22mr2524278pjp.119.1613227479289; Sat, 13 Feb 2021 06:44:39 -0800 (PST) MIME-Version: 1.0 References: <20210115182909.314756-1-aford173@gmail.com> <20210118125204.hxsanoohwvdtdvym@fsr-ub1664-175> <20210120144454.f6b72lnasw4q3bde@fsr-ub1664-175> <20210120151305.GC19063@pengutronix.de> <20210120152813.x2pbs5vprevkly23@fsr-ub1664-175> <20210120155001.GD19063@pengutronix.de> <20210120161421.h3yng57m3fetwwih@fsr-ub1664-175> <20210121095617.GI19063@pengutronix.de> <20210121102450.lisl3mzqczdsmzda@fsr-ub1664-175> In-Reply-To: From: Adam Ford Date: Sat, 13 Feb 2021 08:44:28 -0600 Message-ID: Subject: Re: [PATCH V3] clk: imx: Fix reparenting of UARTs not associated with sdout To: Abel Vesa X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210213_094442_790761_857A409E X-CRM114-Status: GOOD ( 49.41 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Aisheng Dong , Linus Walleij , Linux Kernel Mailing List , Stephen Boyd , Fabio Estevam , Michael Turquette , Adam Ford-BE , linux-clk , NXP Linux Team , Pengutronix Kernel Team , Shawn Guo , Sascha Hauer , arm-soc , Jerome Brunet 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 Wed, Feb 3, 2021 at 3:22 PM Adam Ford wrote: > > On Thu, Jan 21, 2021 at 4:24 AM Abel Vesa wrote: > > > > On 21-01-21 10:56:17, Sascha Hauer wrote: > > > On Wed, Jan 20, 2021 at 06:14:21PM +0200, Abel Vesa wrote: > > > > On 21-01-20 16:50:01, Sascha Hauer wrote: > > > > > On Wed, Jan 20, 2021 at 05:28:13PM +0200, Abel Vesa wrote: > > > > > > On 21-01-20 16:13:05, Sascha Hauer wrote: > > > > > > > Hi Abel, > > > > > > > > > > > > > > On Wed, Jan 20, 2021 at 04:44:54PM +0200, Abel Vesa wrote: > > > > > > > > On 21-01-18 08:00:43, Adam Ford wrote: > > > > > > > > > On Mon, Jan 18, 2021 at 6:52 AM Abel Vesa wrote: > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > TBH, I'm against the idea of having to call consumer API from a clock provider driver. > > > > > > > > > > I'm still investigating a way of moving the uart clock control calls in drivers/serial/imx, > > > > > > > > > > where they belong. > > > > > > > > > > > > > > > > > > That makes sense. > > > > > > > > > > > > > > > > > > > > > > > > > Just a thought. The uart clock used for console remains on from u-boot, > > > > > > > > so maybe it's enough to just add the CLK_IGNORE_UNUSED flag to all the > > > > > > > > uart root clocks and remove the prepare/enable calls for uart clocks > > > > > > > > for good. I don't really have a way to test it right now, but maybe > > > > > > > > you could give it a try. > > > > > > > > > > > > > > That would mean that UART clocks will never be disabled, regardless of > > > > > > > whether they are used for console or not. That doesn't sound very > > > > > > > appealing. > > > > > > > > > > > > AFAIK, the only uart clock that is enabled by u-boot is the one used for > > > > > > the console. Later on, when the serial driver probes, it will enable it itself. > > > > > > > > > > > > Unless I'm missing something, this is exactly what we need. > > > > > > > > > > It might enable it, but with CLK_IGNORE_UNUSED the clock won't be > > > > > disabled again when a port is closed after usage > > > > > > > > OK, tell me what I'm getting wrong in the following scenario: > > > > > > > > U-boot leaves the console uart clock enabled. All the other ones are disabled. > > > > > > > > Kernel i.MX clk driver registers the uart clocks with flag CLK_IGNORE_UNUSED. > > > > > > I was wrong at that point. I originally thought the kernel will never > > > disable these clocks, but in fact it only leaves them enabled during the > > > clk_disable_unused call. > > > > > > However, when CLK_IGNORE_UNUSED becomes relevant it's too late already. > > > I just chatted with Lucas and he told me what the original problem was > > > that his patch solved. > > > > > > The problem comes when an unrelated device and the earlycon UART have > > > the same parent clocks. The parent clock is enabled, but it's reference > > > count is zero. Now when the unrelated device probes and toggles its > > > clocks then the shared parent clock will be disabled due to the > > > reference count being zero. Next time earlycon prints a character the > > > system hangs because the UART gates are still enabled, but their parent > > > clocks no longer are. > > > > > > > Hmm, that is indeed a problem. That's why I think there should be some > > kind of NOCACHE flag for almost all the types of clocks. For example, > > in this case, it makes sense for the core to check the bit in the register > > and then disable the parent based on that instead of relying on the refcount. > > Anyway, that's something that needs to be added in the CCF. > > > > > Overall I think Lucas' patches are still valid and relevant and with > > > Adams patches we even no longer have to enable all UART clocks, but > > > only the ones which are actually needed. > > > > Yeah, for now, I think we can go with Adam's patches. But longterm, I would > > like to remove the special case of the uart clocks we have right now in all > > the i.MX clock drivers. I looked around at other serial drivers, and I found nothing like this function for enabling all UART clocks. There are generic functions for registering consoles, earlycon etc, and the serial driver fetches the per and igp clocks from the device tree, so I attempted to simply remove imx_register_uart_clocks(). I booted an i.MX8M Nano from a fully-powered off state, and my serial console came up just fine. I checked the clk_summary, and the clock parents are set correctly and the respective clock rates appear to be correct (ie, the console is working at the desired baud rate, and Bluetooth is happy) Since I don't fully understand the serial driver and the clock dependencies, I don't want to just simply remove the function without discussing it, because I don't know the ramifications. However, when testing on the i.MX8M Nano, things look OK. I also tested suspend-resume and the console UART appears to return and the Bluetooth UART set to 4Mbps works just fine too. I'd like to post a V4 which just removes imx_register_uart_clocks and the corresponding calls to it. I don't know enough about the older 32-bit i.MX SoC's, but I have build-tested it, and I can generate a patch. Are there any objections and/or concerns? adam > > > > Is the patch I submitted good enough for someone's acked-by or > reviewed-by, or are there changes I need to implement? > > adam > > > > > > > Sascha > > > > > > > > > -- > > > Pengutronix e.K. | | > > > Steuerwalder Str. 21 | https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.pengutronix.de%2F&data=04%7C01%7Cabel.vesa%40nxp.com%7Ceed68987c68f4aeaa63408d8bdf2d051%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637468197861821302%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X1J8KgxFquNin80zKVz0Ao22vv1MuTMWf91BUTczh9Y%3D&reserved=0 | > > > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > > > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel