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

[Michał Zegan]

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 at 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

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