On Thu, May 24, 2018 at 1:04 AM, Rob Herring <robh@xxxxxxxxxx> wrote: > On Fri, May 18, 2018 at 05:27:53PM +0800, Qiang Yu wrote: >> Signed-off-by: Qiang Yu <yuq825@xxxxxxxxx> >> --- >> 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! -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
