All of lore.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 23:08:12 +0000	[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



WARNING: multiple messages have this Message-ID (diff)
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: 42+ 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 ` 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-06 11:05   ` Magnus Damm
2013-11-07 11:27   ` Daniel Lezcano
2013-11-07 11:27     ` Daniel Lezcano
2013-11-08  8:23     ` Magnus Damm
2013-11-08  8:23       ` Magnus Damm
2013-11-08 18:34       ` John Stultz
2013-11-08 18:34         ` John Stultz
2013-11-12 12:26         ` Magnus Damm
2013-11-12 12:26           ` Magnus Damm
2013-11-12 20:47           ` John Stultz
2013-11-12 20:47             ` John Stultz
2013-11-13 21:14             ` Daniel Lezcano
2013-11-13 21:14               ` Daniel Lezcano
2013-11-13 21:25               ` John Stultz
2013-11-13 21:25                 ` John Stultz
2013-11-28  5:42             ` Magnus Damm
2013-11-28  5:42               ` Magnus Damm
2013-12-02 23:08               ` John Stultz [this message]
2013-12-02 23:08                 ` John Stultz
2013-12-04 13:30                 ` Magnus Damm
2013-12-04 13:30                   ` Magnus Damm
2013-11-13 21:38   ` John Stultz
2013-11-13 21:38     ` John Stultz
2013-11-14 12:40     ` Arnd Bergmann
2013-11-14 12:40       ` Arnd Bergmann
2013-11-20  8:33       ` Daniel Lezcano
2013-11-20  8:33         ` Daniel Lezcano
2013-11-20 18:31       ` John Stultz
2013-11-20 18:31         ` John Stultz
2013-11-20 19:34         ` Arnd Bergmann
2013-11-20 19:34           ` Arnd Bergmann
2013-11-20 19:53           ` John Stultz
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   ` 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 11:05   ` Magnus Damm
2013-11-06 22:20 ` [PATCH v2 00/03] clocksource: Consolidate SH and ARM mach-shmobile Kconfig bits Laurent Pinchart
2013-11-06 22:20   ` 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 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.