From: Tony Lindgren <tony@atomide.com>
To: David Shah <dave@ds0.me>
Cc: Linux-OMAP <linux-omap@vger.kernel.org>, Tero Kristo <t-kristo@ti.com>
Subject: Re: Understanding OMAP5 DPLL_ABE and CM_CLKSEL_WKUPAON
Date: Mon, 27 Jul 2020 01:28:33 -0700 [thread overview]
Message-ID: <20200727082833.GB2811@atomide.com> (raw)
In-Reply-To: <c077ece056713ad120b3d2fd59916aab1248cd1c.camel@ds0.me>
Hi,
* David Shah <dave@ds0.me> [200723 14:08]:
> Hi,
>
> There has been a somewhat longstanding issue on the Pyra, where any kind of soft reboot causes
> it to hang (only a true power off and on again works). The background is at
> https://projects.goldelico.com/p/gta04-kernel/issues/876/.
>
> The failure is typically of the following form: https://dev.pyra-handheld.com/snippets/765
> (the exact failure sequence has changed a bit in different kernel versions).
>
> With the pertinent line being:
> [ 0.000000] clock: dpll_abe_ck failed transition to 'locked'
>
> This only happens on the Pyra, not the OMAP5 uEVM. This seems to be because
> the Pyra uses TIMER8 for the backlight PWM.
OK good to hear this one is tracked down now.
> Looking around at some other OMAP5 clocking code, I found
> https://gitlab.com/linux-omap4-dev/omapboot/-/blob/kexec_support/arch/omap5/clock.c#L335
> This to me suggests that both CM_CLKSEL_ABE_PLL_REF and CM_CLKSEL_WKUPAON
> should be set to 1. I found that only CM_CLKSEL_ABE_PLL_REF was 1 and
> CM_CLKSEL_WKUPAON was 0 at the point of checking DPLL lock.
>
> I wrote a very hacky patch just to force CM_CLKSEL_WKUPAON to 1 at startup, to test
> this theory: https://dev.pyra-handheld.com/snippets/770 (breaking every rule in the
> book, I know :)
>
> And indeed with this reboots now seem to work fine.
>
> The question is, what is the correct way/place to deal with this? Is this even a Linux
> issue at all, or should U-Boot be doing something here? A quick glance suggests that
> nothing in the kernel deals with CM_CLKSEL_WKUPAON at all but I may have missed
> something.
Not sure if CM_CLKSEL_WKUPAON can be always configured to 1 for ABE
usage. So probably configuring it with assigned-clocks does not sound
like a right solution.
If it only needs to be configured to 1 for reboot, sounds like it should
be set in omap44xx_restart(). And we should also set it to 1 for omap4
too.
Regards,
Tony
next prev parent reply other threads:[~2020-07-27 8:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-23 20:55 Understanding OMAP5 DPLL_ABE and CM_CLKSEL_WKUPAON David Shah
2020-07-27 8:28 ` Tony Lindgren [this message]
2020-07-27 8:58 ` David Shah
2020-07-28 8:42 ` Tony Lindgren
2020-11-23 20:10 ` H. Nikolaus Schaller
2020-12-01 7:37 ` Tony Lindgren
2020-12-02 15:10 ` H. Nikolaus Schaller
2020-12-05 14:48 ` H. Nikolaus Schaller
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=20200727082833.GB2811@atomide.com \
--to=tony@atomide.com \
--cc=dave@ds0.me \
--cc=linux-omap@vger.kernel.org \
--cc=t-kristo@ti.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.