From: khilman@baylibre.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] clk: scpi: RfC - Allow to ignore invalid SCPI DVFS clock rates
Date: Wed, 08 Feb 2017 11:45:39 -0800 [thread overview]
Message-ID: <m28tpgihzw.fsf@baylibre.com> (raw)
In-Reply-To: <209248b8-2a1c-e00f-d8a8-b82759772b5d@arm.com> (Sudeep Holla's message of "Wed, 8 Feb 2017 11:23:47 +0000")
Sudeep Holla <sudeep.holla@arm.com> writes:
> On 04/02/17 21:03, Heiner Kallweit wrote:
>> Introduce an optional property "clock-max-frequency" for SCPI DVFS
>> clocks. All frequencies for the respective clock exceeding this
>> threshold will be ignored.
>>
>> This is useful on systems where the firmware offers too optimistic
>> clock rates causing instabilities and crashes.
>>
>
> It clearly means the firmware/hardware(IOW platform) was not tested
> correctly before firmware advertised the OPPs. It needs to fixed in the
> firmware. The approach should be advertise the known minimal set working
> rather than the set for which hardware was designed.
>
> That's the whole reason while these are kept in firmware so the OS need
> not worry about such details.
>
> So NACK, go fix the firmware
Sorry, but "go fix the firmware" is not an option for most users of
these boards.
Even if the source were provided for the firwmare (it's not), it usually
needs signing by the vendor, and we know how likely that will be
provided by the vendors.
Firmware will will always be buggy and/or broken and we will be stuck
with it. IMO, not allowing the kernel to work around broken
firmwaretakes a very idealistic view of firmware, and is not based on
historical reality with ARM SoC vendors.
> or disable it completely and be happy with the boot frequency.
That's an awful solution also, when we know that most of the frequencies
work just fine.
Kevin
WARNING: multiple messages have this Message-ID (diff)
From: khilman@baylibre.com (Kevin Hilman)
To: linus-amlogic@lists.infradead.org
Subject: [PATCH 1/2] clk: scpi: RfC - Allow to ignore invalid SCPI DVFS clock rates
Date: Wed, 08 Feb 2017 11:45:39 -0800 [thread overview]
Message-ID: <m28tpgihzw.fsf@baylibre.com> (raw)
In-Reply-To: <209248b8-2a1c-e00f-d8a8-b82759772b5d@arm.com> (Sudeep Holla's message of "Wed, 8 Feb 2017 11:23:47 +0000")
Sudeep Holla <sudeep.holla@arm.com> writes:
> On 04/02/17 21:03, Heiner Kallweit wrote:
>> Introduce an optional property "clock-max-frequency" for SCPI DVFS
>> clocks. All frequencies for the respective clock exceeding this
>> threshold will be ignored.
>>
>> This is useful on systems where the firmware offers too optimistic
>> clock rates causing instabilities and crashes.
>>
>
> It clearly means the firmware/hardware(IOW platform) was not tested
> correctly before firmware advertised the OPPs. It needs to fixed in the
> firmware. The approach should be advertise the known minimal set working
> rather than the set for which hardware was designed.
>
> That's the whole reason while these are kept in firmware so the OS need
> not worry about such details.
>
> So NACK, go fix the firmware
Sorry, but "go fix the firmware" is not an option for most users of
these boards.
Even if the source were provided for the firwmare (it's not), it usually
needs signing by the vendor, and we know how likely that will be
provided by the vendors.
Firmware will will always be buggy and/or broken and we will be stuck
with it. IMO, not allowing the kernel to work around broken
firmwaretakes a very idealistic view of firmware, and is not based on
historical reality with ARM SoC vendors.
> or disable it completely and be happy with the boot frequency.
That's an awful solution also, when we know that most of the frequencies
work just fine.
Kevin
next prev parent reply other threads:[~2017-02-08 19:45 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3b60654a-88b6-6262-396e-a058ade1c586@gmail.com>
2017-02-04 21:03 ` [PATCH 1/2] clk: scpi: RfC - Allow to ignore invalid SCPI DVFS clock rates Heiner Kallweit
2017-02-04 21:03 ` Heiner Kallweit
2017-02-08 11:23 ` Sudeep Holla
2017-02-08 11:23 ` Sudeep Holla
2017-02-08 19:45 ` Kevin Hilman [this message]
2017-02-08 19:45 ` Kevin Hilman
2017-02-09 10:52 ` Sudeep Holla
2017-02-09 10:52 ` Sudeep Holla
2017-02-09 12:19 ` Michał Zegan
2017-02-09 12:19 ` Michał Zegan
2017-02-09 12:25 ` Sudeep Holla
2017-02-09 12:25 ` Sudeep Holla
2017-02-09 12:51 ` Michał Zegan
2017-02-09 12:51 ` Michał Zegan
2017-02-09 13:31 ` Neil Armstrong
2017-02-09 13:31 ` Neil Armstrong
2017-02-09 14:29 ` Sudeep Holla
2017-02-09 14:29 ` Sudeep Holla
2017-02-04 21:04 ` [PATCH 2/2] cpufreq: " Heiner Kallweit
2017-02-04 21:04 ` Heiner Kallweit
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=m28tpgihzw.fsf@baylibre.com \
--to=khilman@baylibre.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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.