[RFC PATCH 11/13] arm64: tegra: Add SOR power-domain node

2016-06-20 Thread Thierry Reding
On Mon, Jun 20, 2016 at 10:18:42AM +0100, Jon Hunter wrote:
> 
> On 17/06/16 17:42, Thierry Reding wrote:
> > * PGP Signed by an unknown key
> > 
> > On Fri, Jun 17, 2016 at 01:03:45PM +0100, Jon Hunter wrote:
> >> Add node for SOR power-domain for Tegra210 and populate the SOR
> >> power-domain phandle for SOR and DPAUX nodes that are dependent
> >> on this power-domain.
> >>
> >> Please note that although neither the SOR or DPAUX drivers currently
> >> support runtime power-management, by populating the power-domain node
> >> the SOR power-domain will be turned on before probing SOR or DPAUX
> >> devices and kept on while the devices are bound.
> >>
> >> Signed-off-by: Jon Hunter 
> >> ---
> >>  arch/arm64/boot/dts/nvidia/tegra210.dtsi | 18 ++
> >>  1 file changed, 18 insertions(+)
> > 
> > I've got patches queued in my drm-tegra tree to add support for runtime
> > PM for the SOR driver. Will that in some way clash with this work if
> > merged in parallel?
> 
> Yes I had seen those. I was wondering if I should include them here but
> opted not too (as it was becoming a massive series). It should be fine
> to enable RPM later, you just need to be aware that the partition could
> turn off on a RPM put so you just need to ensure that any register
> context is saved and restored.

This doesn't matter much for Tegra DRM because we always program the
entire set of registers after pm_runtime_get(), which already resets
the IP block anyway.

> By the way, one item I am not certain about is the relationship between
> the HDMI device and the SOR device. If the HDMI is in the SOR partition
> it should also have the SOR power-domain populated, but it just uses the
> SOR, then the SOR driver should handle this.

On Tegra210 the HDMI output is driven by the SOR, and that's implemented
by the SOR driver, too, so the partition setup should be correct
already.

On Tegra124 and earlier the HDMI output is driven by a separate IP block
that's not at all related to SOR, and I haven't found any evidence that
it would be in the SOR power partition either.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 



[RFC PATCH 11/13] arm64: tegra: Add SOR power-domain node

2016-06-20 Thread Jon Hunter

On 17/06/16 17:44, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Fri, Jun 17, 2016 at 01:03:45PM +0100, Jon Hunter wrote:
>> Add node for SOR power-domain for Tegra210 and populate the SOR
>> power-domain phandle for SOR and DPAUX nodes that are dependent
>> on this power-domain.
>>
>> Please note that although neither the SOR or DPAUX drivers currently
>> support runtime power-management, by populating the power-domain node
>> the SOR power-domain will be turned on before probing SOR or DPAUX
>> devices and kept on while the devices are bound.
>>
>> Signed-off-by: Jon Hunter 
>> ---
>>  arch/arm64/boot/dts/nvidia/tegra210.dtsi | 18 ++
>>  1 file changed, 18 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi 
>> b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
>> index ebf44f4059f8..94f780b43037 100644
>> --- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
>> +++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
>> @@ -34,6 +34,7 @@
>>  clock-names = "dpaux", "parent";
>>  resets = <_car 207>;
>>  reset-names = "dpaux";
>> +power-domains = <_sor>;
>>  status = "disabled";
>>  };
>>  
>> @@ -154,6 +155,7 @@
>>  clock-names = "sor", "parent", "dp", "safe";
>>  resets = <_car 182>;
>>  reset-names = "sor";
>> +power-domains = <_sor>;
>>  status = "disabled";
>>  };
>>  
>> @@ -168,6 +170,7 @@
>>  clock-names = "sor", "parent", "dp", "safe";
>>  resets = <_car 183>;
>>  reset-names = "sor";
>> +power-domains = <_sor>;
>>  status = "disabled";
>>  };
>>  
>> @@ -180,6 +183,7 @@
>>  clock-names = "dpaux", "parent";
>>  resets = <_car 181>;
>>  reset-names = "dpaux";
>> +power-domains = <_sor>;
>>  status = "disabled";
>>  };
>>  
>> @@ -592,6 +596,20 @@
>>  resets = <_car 198>;
>>  #power-domain-cells = <0>;
>>  };
>> +
>> +pd_sor: sor {
>> +clocks = <_car TEGRA210_CLK_SOR0>,
>> + <_car TEGRA210_CLK_DSIA>,
>> + <_car TEGRA210_CLK_DSIB>,
>> + <_car TEGRA210_CLK_MIPI_CAL>,
> 
> Does this mean that all of these clocks will be running while the SOR
> partition is enabled? Seems like a waste because we rarely need MIPI_CAL
> and DSIA and DSIB are completely unused on boards that for example have
> only an HDMI output.
> 
> I vaguely remember the power domain driver only making sure these are
> enabled during the partition power transitions, so perhaps my concerns
> aren't justified?

Right, these are only enabled during the transition of the partition. So
the SOR driver still needs to enable the clocks it needs.

Cheers
Jon

-- 
nvpublic


[RFC PATCH 11/13] arm64: tegra: Add SOR power-domain node

2016-06-20 Thread Jon Hunter

On 17/06/16 17:42, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Fri, Jun 17, 2016 at 01:03:45PM +0100, Jon Hunter wrote:
>> Add node for SOR power-domain for Tegra210 and populate the SOR
>> power-domain phandle for SOR and DPAUX nodes that are dependent
>> on this power-domain.
>>
>> Please note that although neither the SOR or DPAUX drivers currently
>> support runtime power-management, by populating the power-domain node
>> the SOR power-domain will be turned on before probing SOR or DPAUX
>> devices and kept on while the devices are bound.
>>
>> Signed-off-by: Jon Hunter 
>> ---
>>  arch/arm64/boot/dts/nvidia/tegra210.dtsi | 18 ++
>>  1 file changed, 18 insertions(+)
> 
> I've got patches queued in my drm-tegra tree to add support for runtime
> PM for the SOR driver. Will that in some way clash with this work if
> merged in parallel?

Yes I had seen those. I was wondering if I should include them here but
opted not too (as it was becoming a massive series). It should be fine
to enable RPM later, you just need to be aware that the partition could
turn off on a RPM put so you just need to ensure that any register
context is saved and restored.

By the way, one item I am not certain about is the relationship between
the HDMI device and the SOR device. If the HDMI is in the SOR partition
it should also have the SOR power-domain populated, but it just uses the
SOR, then the SOR driver should handle this.

Cheers
Jon

-- 
nvpublic


[RFC PATCH 11/13] arm64: tegra: Add SOR power-domain node

2016-06-17 Thread Thierry Reding
On Fri, Jun 17, 2016 at 01:03:45PM +0100, Jon Hunter wrote:
> Add node for SOR power-domain for Tegra210 and populate the SOR
> power-domain phandle for SOR and DPAUX nodes that are dependent
> on this power-domain.
> 
> Please note that although neither the SOR or DPAUX drivers currently
> support runtime power-management, by populating the power-domain node
> the SOR power-domain will be turned on before probing SOR or DPAUX
> devices and kept on while the devices are bound.
> 
> Signed-off-by: Jon Hunter 
> ---
>  arch/arm64/boot/dts/nvidia/tegra210.dtsi | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi 
> b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> index ebf44f4059f8..94f780b43037 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> @@ -34,6 +34,7 @@
>   clock-names = "dpaux", "parent";
>   resets = <_car 207>;
>   reset-names = "dpaux";
> + power-domains = <_sor>;
>   status = "disabled";
>   };
>  
> @@ -154,6 +155,7 @@
>   clock-names = "sor", "parent", "dp", "safe";
>   resets = <_car 182>;
>   reset-names = "sor";
> + power-domains = <_sor>;
>   status = "disabled";
>   };
>  
> @@ -168,6 +170,7 @@
>   clock-names = "sor", "parent", "dp", "safe";
>   resets = <_car 183>;
>   reset-names = "sor";
> + power-domains = <_sor>;
>   status = "disabled";
>   };
>  
> @@ -180,6 +183,7 @@
>   clock-names = "dpaux", "parent";
>   resets = <_car 181>;
>   reset-names = "dpaux";
> + power-domains = <_sor>;
>   status = "disabled";
>   };
>  
> @@ -592,6 +596,20 @@
>   resets = <_car 198>;
>   #power-domain-cells = <0>;
>   };
> +
> + pd_sor: sor {
> + clocks = <_car TEGRA210_CLK_SOR0>,
> +  <_car TEGRA210_CLK_DSIA>,
> +  <_car TEGRA210_CLK_DSIB>,
> +  <_car TEGRA210_CLK_MIPI_CAL>,

Does this mean that all of these clocks will be running while the SOR
partition is enabled? Seems like a waste because we rarely need MIPI_CAL
and DSIA and DSIB are completely unused on boards that for example have
only an HDMI output.

I vaguely remember the power domain driver only making sure these are
enabled during the partition power transitions, so perhaps my concerns
aren't justified?

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 



[RFC PATCH 11/13] arm64: tegra: Add SOR power-domain node

2016-06-17 Thread Thierry Reding
On Fri, Jun 17, 2016 at 01:03:45PM +0100, Jon Hunter wrote:
> Add node for SOR power-domain for Tegra210 and populate the SOR
> power-domain phandle for SOR and DPAUX nodes that are dependent
> on this power-domain.
> 
> Please note that although neither the SOR or DPAUX drivers currently
> support runtime power-management, by populating the power-domain node
> the SOR power-domain will be turned on before probing SOR or DPAUX
> devices and kept on while the devices are bound.
> 
> Signed-off-by: Jon Hunter 
> ---
>  arch/arm64/boot/dts/nvidia/tegra210.dtsi | 18 ++
>  1 file changed, 18 insertions(+)

I've got patches queued in my drm-tegra tree to add support for runtime
PM for the SOR driver. Will that in some way clash with this work if
merged in parallel?

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 



[RFC PATCH 11/13] arm64: tegra: Add SOR power-domain node

2016-06-17 Thread Jon Hunter
Add node for SOR power-domain for Tegra210 and populate the SOR
power-domain phandle for SOR and DPAUX nodes that are dependent
on this power-domain.

Please note that although neither the SOR or DPAUX drivers currently
support runtime power-management, by populating the power-domain node
the SOR power-domain will be turned on before probing SOR or DPAUX
devices and kept on while the devices are bound.

Signed-off-by: Jon Hunter 
---
 arch/arm64/boot/dts/nvidia/tegra210.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index ebf44f4059f8..94f780b43037 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
@@ -34,6 +34,7 @@
clock-names = "dpaux", "parent";
resets = <_car 207>;
reset-names = "dpaux";
+   power-domains = <_sor>;
status = "disabled";
};

@@ -154,6 +155,7 @@
clock-names = "sor", "parent", "dp", "safe";
resets = <_car 182>;
reset-names = "sor";
+   power-domains = <_sor>;
status = "disabled";
};

@@ -168,6 +170,7 @@
clock-names = "sor", "parent", "dp", "safe";
resets = <_car 183>;
reset-names = "sor";
+   power-domains = <_sor>;
status = "disabled";
};

@@ -180,6 +183,7 @@
clock-names = "dpaux", "parent";
resets = <_car 181>;
reset-names = "dpaux";
+   power-domains = <_sor>;
status = "disabled";
};

@@ -592,6 +596,20 @@
resets = <_car 198>;
#power-domain-cells = <0>;
};
+
+   pd_sor: sor {
+   clocks = <_car TEGRA210_CLK_SOR0>,
+<_car TEGRA210_CLK_DSIA>,
+<_car TEGRA210_CLK_DSIB>,
+<_car TEGRA210_CLK_MIPI_CAL>,
+<_car TEGRA210_CLK_DPAUX>;
+   resets = <_car TEGRA210_CLK_SOR0>,
+<_car TEGRA210_CLK_DSIA>,
+<_car TEGRA210_CLK_DSIB>,
+<_car TEGRA210_CLK_DPAUX>,
+<_car TEGRA210_CLK_MIPI_CAL>;
+   #power-domain-cells = <0>;
+   };
};
};

-- 
2.1.4