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

[Michał Zegan]

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.
>> Even if the source were provided for the firmware (it's not), it
>> usually needs signing by the vendor, and we know how likely that will
>> be provided by the vendors.
>>
> 
> I agree, but the main reason for raising my voice is to communicate the
> message to those vendors. Blindly accepting whatever they give is also
> not a good practice.
> 
>> 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 
>> firmware takes a very idealistic view of firmware, and is not based
>> on historical reality with ARM SoC vendors.
>>
> 
> Yes but things should start to improve somewhere sometime. It really
> stupid to keep working around everything vendor screws up giving them no
> incentive to get things right the next time. We need to accept the fact
> that firmware will do more as the complex systems evolve and that won't
> go away. It's time we make them aware of that and ensure they take
> necessary steps to fix it for future platforms.
> 
>>> 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.
>>
> 
> OK, I understand the concern. I will look into the patches.
> 

-------------- 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/062bd2ae/attachment-0001.sig>