public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: John Stultz <john.stultz@linaro.org>
To: Magnus Damm <magnus.damm@gmail.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Kevin Hilman <khilman@linaro.org>, Arnd Bergmann <arnd@arndb.de>,
	SH-Linux <linux-sh@vger.kernel.org>,
	"Simon Horman [Horms]" <horms@verge.net.au>,
	Olof Johansson <olof@lixom.net>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v2 01/03] clocksource: Add Kconfig entries for CMT, MTU2, TMU and STI
Date: Mon, 02 Dec 2013 15:08:12 -0800	[thread overview]
Message-ID: <529D12DC.2000303@linaro.org> (raw)
In-Reply-To: <CANqRtoSC7EcJqjL9ockoHUS+vwVrurSD-EhnK1tV8SSr_baJSg@mail.gmail.com>

On 11/27/2013 09:42 PM, Magnus Damm wrote:
> Hi John, everyone,
>
> Let me get back to you all in a little while together with some code,
> but before that let me just clarify this:
>
> On Wed, Nov 13, 2013 at 5:47 AM, John Stultz <john.stultz@linaro.org> wrote:
>> On Tue, Nov 12, 2013 at 4:26 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
>>> On Sat, Nov 9, 2013 at 3:34 AM, John Stultz <john.stultz@linaro.org> wrote:
>>> Let me get back to the kernel configuration. Of course, it would be
>>> really nice if the kernel configuration was 100% fool proof, but what
>>> happens if the user doesn't compile-in certain parts? That hardware
>>> won't be used. What happens if wrong console device is passed on the
>>> kernel command line? The friendly answer is usually "don't do that".
>>>
>>> So in case of the serial console, no driver - no output. You can still
>>> use the network. If you have no timer then there won't be any timer
>>> ticks. You can still get to user space though, but don't try to rely
>>> on the timer. This CONFIG_TIMER=y/n case is pretty clear, but isn't
>>> there a grey zone too?
>> And on every new board, I have to fumble around with exactly those
>> sorts of no-serial output issues. Its never something I consider a
>> great use of my time :)
>>
>> And your example is a little flawed have no timer ticks, you're not
>> getting to userspace. The system won't boot.
> Correct me if I'm wrong here but I don't think so!
>
> On some platforms that may very well be the case, but on mach-shmobile
> we get to user space without any timers. If the timers are enabled
> then they are regular platform devices these days. From my experience
> the main blocker for going to user space without timer is on ARM
> usually the udelay() calculation and/or the TWD delay, but those can
> be handled with preset worst-case values for udelay() and getting the
> rate via CCF for the TWD.
>
> Also it of course depends on if some compiled-in driver needs to use
> the timer. If we just enable the serial console then all our platforms
> make it to initramfs-based user space without any clock source or
> clock event.
So something still triggers basic HZ timer functionality, and you get by
with the jiffies clocksource?

Ok, so thanks for the correction. But I still think booting in a
degraded mode isn't ideal when the user has already provided enough info
via config options that we could have sorted it out for them.

But yea, I look forward to your next patch so we can discuss things more
concretely, rather then in my more abstract handwaving rants ;)

thanks
-john



  reply	other threads:[~2013-12-02 23:08 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-06 11:05 [PATCH v2 00/03] clocksource: Consolidate SH and ARM mach-shmobile Kconfig bits Magnus Damm
2013-11-06 11:05 ` [PATCH v2 01/03] clocksource: Add Kconfig entries for CMT, MTU2, TMU and STI Magnus Damm
2013-11-07 11:27   ` Daniel Lezcano
2013-11-08  8:23     ` Magnus Damm
2013-11-08 18:34       ` John Stultz
2013-11-12 12:26         ` Magnus Damm
2013-11-12 20:47           ` John Stultz
2013-11-13 21:14             ` Daniel Lezcano
2013-11-13 21:25               ` John Stultz
2013-11-28  5:42             ` Magnus Damm
2013-12-02 23:08               ` John Stultz [this message]
2013-12-04 13:30                 ` Magnus Damm
2013-11-13 21:38   ` John Stultz
2013-11-14 12:40     ` Arnd Bergmann
2013-11-20  8:33       ` Daniel Lezcano
2013-11-20 18:31       ` John Stultz
2013-11-20 19:34         ` Arnd Bergmann
2013-11-20 19:53           ` John Stultz
2013-11-06 11:05 ` [PATCH v2 02/03] ARM: shmobile: Remove CMT, TMU and STI Kconfig entries Magnus Damm
2013-11-06 11:05 ` [PATCH v2 03/03] sh: Remove Kconfig entries for TMU, CMT and MTU2 Magnus Damm
2013-11-06 22:20 ` [PATCH v2 00/03] clocksource: Consolidate SH and ARM mach-shmobile Kconfig bits Laurent Pinchart

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=529D12DC.2000303@linaro.org \
    --to=john.stultz@linaro.org \
    --cc=arnd@arndb.de \
    --cc=daniel.lezcano@linaro.org \
    --cc=horms@verge.net.au \
    --cc=khilman@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=olof@lixom.net \
    --cc=tglx@linutronix.de \
    /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