On 02/09/2017 01:51 PM, Micha? Zegan wrote:

W dniu 09.02.2017 o 13:25, Sudeep Holla pisze:

quoted

On 09/02/17 12:19, Micha? Zegan wrote:

quoted

W dniu 09.02.2017 o 11:52, Sudeep Holla pisze:

quoted

On 08/02/17 19:45, Kevin Hilman wrote:

quoted

Sudeep Holla [off-list ref] writes:

quoted

On 04/02/17 21:03, Heiner Kallweit wrote:

quoted

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.

I knew this was coming :). I just wanted to shout at vendors who are not
validating their firmware. Sometimes I feel it's better have platform
driver and drive everything from Linux and don't use buggy firmware at
all instead of adding tons of workaround. It defeats the whole purpose
of having the firmware.

Well, at least in the case of odroid c2 from hardkernel, I believe those
unstable frequencies are supported intentionally. The wiki of the board
lists them explicitly, and says when they are stable.
So if that was intentional, then a frequency capping set by default
would be needed, it can be lifted by a specific user if he wants. Unless
hk should disable that "feature" instead.

If those frequency are known to cause any stability issues, they should
be considered as *not supported*. If it's just thermal constraints then
yes the user/developer should be allowed to use them as they can take
care of thermal management so that the platform remains stable for usage.

The unstability does not occur when you do not use all cores at once, so hmm

Hi Sudeep,

On Hardkernel ODroid C2 based on Amlogic S905, due to a bad hardware design the platform
crashes when using >1536MHz frequencies while activating all cores.

But Hardkernel kept the frequencies to be able to use them when having a single core enabled
using their off-tree highly modified linux kernel.

So we need to handle these kind of cases where the vendor leaves them for strong reasons
but mainlinux linux is not (yet) a strong reason to change the firmware.

I'm sure we can find a smart solution to handle these use cases without adding too much
ugly code.

Neil

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170209/d3339f8f/attachment-0001.sig>