linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Abel Vesa <abel.vesa@nxp.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Adam Ford <aford173@gmail.com>,
	arm-soc <linux-arm-kernel@lists.infradead.org>,
	Adam Ford-BE <aford@beaconembedded.com>,
	Aisheng Dong <aisheng.dong@nxp.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>, Shawn Guo <shawnguo@kernel.org>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	NXP Linux Team <linux-imx@nxp.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Jerome Brunet <jbrunet@baylibre.com>,
	linux-clk <linux-clk@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V3] clk: imx: Fix reparenting of UARTs not associated with sdout
Date: Thu, 21 Jan 2021 12:24:50 +0200	[thread overview]
Message-ID: <20210121102450.lisl3mzqczdsmzda@fsr-ub1664-175> (raw)
In-Reply-To: <20210121095617.GI19063@pengutronix.de>

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 <abel.vesa@nxp.com> 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.

> 
> Sascha
> 
> 
> -- 
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       | https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.pengutronix.de%2F&amp;data=04%7C01%7Cabel.vesa%40nxp.com%7Ceed68987c68f4aeaa63408d8bdf2d051%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637468197861821302%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=X1J8KgxFquNin80zKVz0Ao22vv1MuTMWf91BUTczh9Y%3D&amp;reserved=0  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

  reply	other threads:[~2021-01-21 10:30 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-15 18:29 [PATCH V3] clk: imx: Fix reparenting of UARTs not associated with sdout Adam Ford
2021-01-18 12:52 ` Abel Vesa
2021-01-18 14:00   ` Adam Ford
2021-01-20 14:44     ` Abel Vesa
2021-01-20 15:13       ` Sascha Hauer
2021-01-20 15:28         ` Abel Vesa
2021-01-20 15:50           ` Sascha Hauer
2021-01-20 16:14             ` Abel Vesa
2021-01-21  9:56               ` Sascha Hauer
2021-01-21 10:24                 ` Abel Vesa [this message]
2021-02-03 21:22                   ` Adam Ford
2021-02-13 14:44                     ` Adam Ford
2021-02-15 13:06                       ` Abel Vesa
2021-03-02 19:03                         ` Adam Ford
2021-03-03  8:31                           ` Abel Vesa
2021-03-10 22:24                             ` Abel Vesa
2021-03-10 22:43                               ` Adam Ford
2021-03-05 12:21 ` Ahmad Fatoum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210121102450.lisl3mzqczdsmzda@fsr-ub1664-175 \
    --to=abel.vesa@nxp.com \
    --cc=aford173@gmail.com \
    --cc=aford@beaconembedded.com \
    --cc=aisheng.dong@nxp.com \
    --cc=festevam@gmail.com \
    --cc=jbrunet@baylibre.com \
    --cc=kernel@pengutronix.de \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=s.hauer@pengutronix.de \
    --cc=sboyd@kernel.org \
    --cc=shawnguo@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).