[PATCH 1/2] clk: scpi: RfC - Allow to ignore invalid SCPI DVFS clock rates

[narmstrong@baylibre.com (Neil Armstrong)]

On 02/09/2017 01:51 PM, Micha? Zegan wrote:
> 
> 
> W dniu 09.02.2017 o 13:25, Sudeep Holla pisze:
>>
>>
>> On 09/02/17 12:19, Micha? Zegan wrote:
>>>
>>>
>>> W dniu 09.02.2017 o 11:52, Sudeep Holla pisze:
>>>>
>>>>
>>>> On 08/02/17 19:45, Kevin Hilman wrote:
>>>>> 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.
>>>>>
>>>>
>>>> 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-amlogic/attachments/20170209/d3339f8f/attachment.sig>