[PATCH RFC 02/24] dt-bindings: add switch-delay property for mali-utgard

[Qiang Yu]

On Thu, May 24, 2018 at 1:04 AM, Rob Herring <robh at kernel.org> wrote:
> On Fri, May 18, 2018 at 05:27:53PM +0800, Qiang Yu wrote:
>> Signed-off-by: Qiang Yu <yuq825 at gmail.com>
>> ---
>>  Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
>> index c1f65d1dac1d..062d4bee216a 100644
>> --- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
>> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
>> @@ -58,6 +58,10 @@ Optional properties:
>>      A power domain consumer specifier as defined in
>>      Documentation/devicetree/bindings/power/power_domain.txt
>>
>> +  - switch-delay:
>> +    This value is the number of Mali clock cycles it takes to
>> +    enable the power gates and turn on the power mesh.
>
> This should be implied by the SoC specific compatible string.

If so, we have to maintain a SoC-switch delay table inside the
driver. But this should be the DTS's work as it's an SoC parameter.

>
> Alternatively, can't the driver just pick a value long enough for
> everyone? Does it really vary that much, and is it timing critical?

In fact, I haven't tried setting 0xff SoC with 0xffff. I just use value
from official driver shipped with the board. But if a board need
0xffff, set to 0xff will cause it works unstable. So for setting 0xff
board to 0xffff, it may need time experiment to see if it affect
performance or stability. And need to do exp on more SoC.

Regards,
Qiang

>
> Rob
>
> P.S. Keep up the great work on this!