All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@codeaurora.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Michael Turquette <mturquette@baylibre.com>,
	linux-clk <linux-clk@vger.kernel.org>,
	Janos Laube <janos.dev@gmail.com>,
	Paulius Zaleckas <paulius.zaleckas@gmail.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Hans Ulli Kroll <ulli.kroll@googlemail.com>,
	Florian Fainelli <f.fainelli@gmail.com>
Subject: Re: [PATCH 2/2 v4] clk: Add Gemini SoC clock controller
Date: Mon, 12 Jun 2017 14:02:48 -0700	[thread overview]
Message-ID: <20170612210248.GP20170@codeaurora.org> (raw)
In-Reply-To: <CACRpkdapAgHix2vw-woDFi4sh+H3_EX7w-5q=opBGMyegFrXbA@mail.gmail.com>

On 06/12, Linus Walleij wrote:
> On Thu, Jun 8, 2017 at 2:18 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> 
> > I think the timer may be more of an issue...
> >
> > It is using CLOCKSOURCE_OF_DECLARE(), at least last time
> > I checked there was no such thing as clocksources retrying their
> > calls, and that cannot be regular probes because of, yeah device
> > core is using the timer, I think.
> >
> > Yeah I looked in:
> > drivers/clocksource/clksrc-probe.c
> >
> > It will just fail if it can't initialize the clocksource.
> >
> > I don't understand what platforms can actually get their timers
> > up at all without the clock framework? Those hardcoding the
> > clock frequency in the device tree, or things like the ARM
> > TWD which has it encoded in hardware perhaps?
> 
> I just confirmed this to be the problem using a scratch patch for
> a platform device init and some earlydebug prints:
> 
> Uncompressing Linux... done, booting the kernel.
>  Booting Linux on physical CPU 0x0
> start_kernel
> (...)
>  NR_IRQS:16 nr_irqs:16 16
>  could not get PCLK
> Failed to initialize '/soc/timer@43000000': -517
>  clocksource_probe: no matching clocksources found
>  sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every
> 21474836475000000ns
>  Console: colour dummy device 80x30
>  Calibrating delay loop...
> 
> So the deferred clock makes the whole platform hang because the timer
> needs it. Without a clocksource, the delay loop cannot be calibrated, so
> it hangs there.
> 

Ok. So can the certain clks that are required to get the timer
going be put into CLK_OF_DECLARE_DRIVER() and then have a regular
platform driver for the rest of the clks that aren't required for
early boot? We've been doing this sort of hybrid design lately,
so hopefully that works here too.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

WARNING: multiple messages have this Message-ID (diff)
From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2 v4] clk: Add Gemini SoC clock controller
Date: Mon, 12 Jun 2017 14:02:48 -0700	[thread overview]
Message-ID: <20170612210248.GP20170@codeaurora.org> (raw)
In-Reply-To: <CACRpkdapAgHix2vw-woDFi4sh+H3_EX7w-5q=opBGMyegFrXbA@mail.gmail.com>

On 06/12, Linus Walleij wrote:
> On Thu, Jun 8, 2017 at 2:18 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> 
> > I think the timer may be more of an issue...
> >
> > It is using CLOCKSOURCE_OF_DECLARE(), at least last time
> > I checked there was no such thing as clocksources retrying their
> > calls, and that cannot be regular probes because of, yeah device
> > core is using the timer, I think.
> >
> > Yeah I looked in:
> > drivers/clocksource/clksrc-probe.c
> >
> > It will just fail if it can't initialize the clocksource.
> >
> > I don't understand what platforms can actually get their timers
> > up at all without the clock framework? Those hardcoding the
> > clock frequency in the device tree, or things like the ARM
> > TWD which has it encoded in hardware perhaps?
> 
> I just confirmed this to be the problem using a scratch patch for
> a platform device init and some earlydebug prints:
> 
> Uncompressing Linux... done, booting the kernel.
>  Booting Linux on physical CPU 0x0
> start_kernel
> (...)
>  NR_IRQS:16 nr_irqs:16 16
>  could not get PCLK
> Failed to initialize '/soc/timer at 43000000': -517
>  clocksource_probe: no matching clocksources found
>  sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every
> 21474836475000000ns
>  Console: colour dummy device 80x30
>  Calibrating delay loop...
> 
> So the deferred clock makes the whole platform hang because the timer
> needs it. Without a clocksource, the delay loop cannot be calibrated, so
> it hangs there.
> 

Ok. So can the certain clks that are required to get the timer
going be put into CLK_OF_DECLARE_DRIVER() and then have a regular
platform driver for the rest of the clks that aren't required for
early boot? We've been doing this sort of hybrid design lately,
so hopefully that works here too.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

  reply	other threads:[~2017-06-12 21:02 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-24  8:20 [PATCH 2/2 v4] clk: Add Gemini SoC clock controller Linus Walleij
2017-05-24  8:20 ` Linus Walleij
2017-06-01  7:02 ` Stephen Boyd
2017-06-01  7:02   ` Stephen Boyd
2017-06-05 13:34   ` Linus Walleij
2017-06-05 13:34     ` Linus Walleij
2017-06-05 19:58     ` Stephen Boyd
2017-06-05 19:58       ` Stephen Boyd
2017-06-08 12:18       ` Linus Walleij
2017-06-08 12:18         ` Linus Walleij
2017-06-12  6:21         ` Linus Walleij
2017-06-12  6:21           ` Linus Walleij
2017-06-12 21:02           ` Stephen Boyd [this message]
2017-06-12 21:02             ` Stephen Boyd
2017-06-14 11:31             ` Linus Walleij
2017-06-14 11:31               ` Linus Walleij
2017-06-14 15:55               ` Stephen Boyd
2017-06-14 15:55                 ` Stephen Boyd
2017-06-15  7:16             ` Linus Walleij
2017-06-15  7:16               ` Linus Walleij
2017-06-15  7:16               ` Linus Walleij
2017-06-15  8:55               ` Geert Uytterhoeven
2017-06-15  8:55                 ` Geert Uytterhoeven
2017-06-15 12:57                 ` Linus Walleij
2017-06-15 12:57                   ` Linus Walleij
2017-06-15 12:57                   ` Linus Walleij
2017-06-15 21:00                   ` Stephen Boyd
2017-06-15 21:00                     ` Stephen Boyd
2017-06-16  8:35                     ` Linus Walleij
2017-06-16  8:35                       ` Linus Walleij
2017-06-16  8:35                       ` Linus Walleij
2017-06-15 21:55                   ` Philipp Zabel
2017-06-15 21:55                     ` Philipp Zabel
2017-06-16  8:38                     ` Linus Walleij
2017-06-16  8:38                       ` Linus Walleij

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=20170612210248.GP20170@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --cc=f.fainelli@gmail.com \
    --cc=janos.dev@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=paulius.zaleckas@gmail.com \
    --cc=ulli.kroll@googlemail.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.