Linux clock framework development
 help / color / mirror / Atom feed
From: Chad LeClair <leclair@gmail.com>
To: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: Ilya K <me@0upti.me>,
	"andy.yan@rock-chips.com" <andy.yan@rock-chips.com>,
	"heiko@sntech.de" <heiko@sntech.de>,
	"huangtao@rock-chips.com" <huangtao@rock-chips.com>,
	"kernel@collabora.com" <kernel@collabora.com>,
	"kever.yang@rock-chips.com" <kever.yang@rock-chips.com>,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
	"linux-rockchip@lists.infradead.org"
	<linux-rockchip@lists.infradead.org>,
	"mturquette@baylibre.com" <mturquette@baylibre.com>,
	"sboyd@kernel.org" <sboyd@kernel.org>,
	"zhangqing@rock-chips.com" <zhangqing@rock-chips.com>
Subject: Re: [PATCH v8 7/7] clk: rockchip: implement proper GATE_LINK support
Date: Wed, 20 Mar 2024 22:50:48 -0400	[thread overview]
Message-ID: <97f8b9e7-983c-435e-8fad-11e71be158b8@gmail.com> (raw)
In-Reply-To: <2rsu6qa3pwbqic6b7ej6txa34jw4ztrnybzcfcfysue2mky37h@dyrdefbimzdn>

Sebastian,

On 3/20/24 12:36, Sebastian Reichel wrote:

> I also worked on a cleaner solution for the issue you described and
> integrated it in the patch adding proper gate clock support. So
> please also test with HCLK_NVM not being marked as CRITICAL.
> 
> [0] https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commits/rk3588-test
> 
> If everything is fine I will prepare a v9.
> 
>> Hope this additional data point helps!
> 
> Thanks for the detailed analysis.
> 
> Greetings,
> 
> -- Sebastian


No luck unfortunately.  I still see the SFC dma timeouts.  It looks like
aclk_nvm_root is still getting disabled.  It now has both an enable count of 0
and a prepare count of 0.

Unlike your previous version, I _do_ see the driver bound to the device and
the rpm_resume() call finds its way to pm_clk_resume().  So it looks like
you resolved the original issue I was seeing.

However, when I reach __pm_clk_enable() it looks like the clock entry (ce)
is not in a good state:
  (gdb) print *ce
  $3 = {node = {next = 0xffff0001f0ce1930, prev = 0xffff0001f0ce1930}, con_id =
  0xffff0001f0a214f0 "aclk_nvm_root", clk = 0xfffffffffffffffe, status =
  PCE_STATUS_ERROR, enabled_when_prepared = false}

The immediate problem at hand is that ce->status is PCE_STATUS_ERROR so the 
switch statement will take the default case and return without doing anything. 
Also the ce->clk pointer looks like some sort of error pointer value so I'm
wondering if something went wrong in the setup you were doing in 
clk_gate_link_probe().

Note: I ran to that same __pm_clk_enable() breakpoint for a number of of 
GATE_LINK clocks.  They all looked to be in that same bad state.  I put the 
"aclk_nvm_root" one in the message here since that is the one that is most 
relevant to the discussion, but they all look to be broken in the same way.

Hopefully this gives you a hint as to what is going on.

BTW, In case it is of interest to you or Ilya, I have my "working" tree
available here: 
  https://github.com/sesca128/linux-rk3588/tree/v6.8-rk3588-test

My quick and dirty hack is at the tip of the branch. The rest is pretty 
much your rk3588-test branch from a few days ago. 

--
Chad LeClair

  parent reply	other threads:[~2024-03-21  2:50 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1456131709882456@mail.yandex.ru>
2024-03-08 13:27 ` [PATCH v8 7/7] clk: rockchip: implement proper GATE_LINK support Sebastian Reichel
     [not found]   ` <20561709904626@c6cdvt45gvthiay5.myt.yp-c.yandex.net>
2024-03-08 13:59     ` Sebastian Reichel
2024-03-17 23:34   ` Chad LeClair
2024-03-20 16:36     ` Sebastian Reichel
2024-03-20 17:20       ` Ilya K
2024-03-21  2:50       ` Chad LeClair [this message]
2024-03-21 18:31         ` Sebastian Reichel
2024-03-21 19:01           ` Ilya K
2024-03-21 20:45             ` Sebastian Reichel
2024-03-22  0:57               ` Chad LeClair
2024-03-22  7:06               ` Ilya K
2024-01-26 18:18 [PATCH v8 0/7] rockchip: clk: improve " Sebastian Reichel
2024-01-26 18:18 ` [PATCH v8 7/7] clk: rockchip: implement proper " Sebastian Reichel
2024-01-26 19:36   ` Dmitry Osipenko
2024-01-30 14:47     ` Sebastian Reichel
2024-01-31 16:10       ` Dmitry Osipenko

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=97f8b9e7-983c-435e-8fad-11e71be158b8@gmail.com \
    --to=leclair@gmail.com \
    --cc=andy.yan@rock-chips.com \
    --cc=heiko@sntech.de \
    --cc=huangtao@rock-chips.com \
    --cc=kernel@collabora.com \
    --cc=kever.yang@rock-chips.com \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=me@0upti.me \
    --cc=mturquette@baylibre.com \
    --cc=sboyd@kernel.org \
    --cc=sebastian.reichel@collabora.com \
    --cc=zhangqing@rock-chips.com \
    /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