[PATCH v2 00/13] ARM: tegra: Enable DSI, panel and 3D support

[PATCH v2 00/13] ARM: tegra: Enable DSI, panel and 3D support

[Thierry Reding]

This series enables DSI, HDMI and gr2d support on Dalmore as well as
panel support for Cardhu and Harmony. gr3d support is also enabled on
Tegra20 through Tegra114.

I think I've addressed all comments from the initial version. A more
notable addition was that of gr3d support and a WIP patch for Tegra114
powergate support. I wanted to get some feedback on how to continue
with the powergate patch (array vs. map, see patch for details) before
finalizing it.

Thierry

Mikko Perttunen (2):
  ARM: tegra: Add host1x, DC and HDMI to Tegra114 device tree
  ARM: tegra: Enable HDMI support on Dalmore

Thierry Reding (11):
  ARM: tegra: Mark Tegra30 display controller compatible with Tegra20
  ARM: tegra: Enable LVDS and HDMI on Cardhu
  ARM: tegra: Enable LVDS output on Harmony
  ARM: tegra: Add MIPI calibration DT entries for Tegra114
  ARM: tegra: Add Tegra114 DSI support
  ARM: tegra: Add Tegra114 gr2d support
  ARM: tegra: Enable DSI support on Dalmore
  ARM: tegra: Enable DRM panel support
  ARM: tegra: Add Tegra114 gr3d support
  ARM: tegra: Use symbolic names for gr3d clocks
  WIP: ARM: tegra: Add Tegra114 powergate support

 arch/arm/boot/dts/tegra114-dalmore.dts | 58 +++++++++++++++++-----
 arch/arm/boot/dts/tegra114.dtsi        | 89 ++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/tegra20-harmony.dts  | 36 +++++++++++++-
 arch/arm/boot/dts/tegra30-cardhu.dtsi  | 50 ++++++++++++++++++-
 arch/arm/boot/dts/tegra30.dtsi         |  5 +-
 arch/arm/configs/tegra_defconfig       |  2 +
 arch/arm/mach-tegra/powergate.c        | 41 ++++++++++++++++
 include/linux/tegra-powergate.h        |  9 +++-
 8 files changed, 271 insertions(+), 19 deletions(-)

-- 
1.8.4

[PATCH v2 01/13] ARM: tegra: Mark Tegra30 display controller compatible with Tegra20

[Thierry Reding]

The display controller found on Tegra30 SoCs is backwards-compatible
with the one on Tegra20 SoCs.

Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 arch/arm/boot/dts/tegra30.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index 0022c12..d3d71ab 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -141,7 +141,7 @@
 		};
 
 		dc@54200000 {
-			compatible = "nvidia,tegra30-dc";
+			compatible = "nvidia,tegra30-dc", "nvidia,tegra20-dc";
 			reg = <0x54200000 0x00040000>;
 			interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&tegra_car TEGRA30_CLK_DISP1>,
-- 
1.8.4

[PATCH v2 02/13] ARM: tegra: Enable LVDS and HDMI on Cardhu

[Thierry Reding]

Add backlight and panel nodes for the Cardhu 10.1" WXGA TFT LCD panel
and enable the HDMI output and hotplug detection.

Note that HDMI doesn't work for some reason and I haven't found out why
yet. I remember someone reporting that it worked at some point in time
using this set of nodes but that no longer seems to be the case. Running
the same kernel on Beaver has working HDMI, though.

Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
Changes in v2:
- remove backlight-boot-off property for now

 arch/arm/boot/dts/tegra30-cardhu.dtsi | 50 +++++++++++++++++++++++++++++++++--
 1 file changed, 48 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index 5ea7dfa..849b699 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -51,6 +51,27 @@
 		};
 	};
 
+	host1x {
+		dc@54200000 {
+			rgb {
+				status = "okay";
+
+				nvidia,panel = <&panel>;
+			};
+		};
+
+		hdmi {
+			status = "okay";
+
+			vdd-supply = <&sys_3v3_reg>;
+			pll-supply = <&vio_reg>;
+
+			nvidia,hpd-gpio =
+				<&gpio TEGRA_GPIO(N, 7) GPIO_ACTIVE_HIGH>;
+			nvidia,ddc-i2c-bus = <&hdmiddc>;
+		};
+	};
+
 	pinmux {
 		pinctrl-names = "default";
 		pinctrl-0 = <&state_default>;
@@ -147,7 +168,11 @@
 		status = "okay";
 	};
 
-	i2c@7000c000 {
+	pwm {
+		status = "okay";
+	};
+
+	panelddc: i2c@7000c000 {
 		status = "okay";
 		clock-frequency = <100000>;
 	};
@@ -170,7 +195,7 @@
 		};
 	};
 
-	i2c@7000c700 {
+	hdmiddc: i2c@7000c700 {
 		status = "okay";
 		clock-frequency = <100000>;
 	};
@@ -367,6 +392,17 @@
 		status = "okay";
 	};
 
+	backlight: backlight {
+		compatible = "pwm-backlight";
+
+		enable-gpios = <&gpio TEGRA_GPIO(H, 2) GPIO_ACTIVE_HIGH>;
+		power-supply = <&vdd_bl_reg>;
+		pwms = <&pwm 0 5000000>;
+
+		brightness-levels = <0 4 8 16 32 64 128 255>;
+		default-brightness-level = <6>;
+	};
+
 	clocks {
 		compatible = "simple-bus";
 		#address-cells = <1>;
@@ -380,6 +416,16 @@
 		};
 	};
 
+	panel: panel {
+		compatible = "chunghwa,claa101wb01";
+		ddc-i2c-bus = <&panelddc>;
+
+		power-supply = <&vdd_pnl1_reg>;
+		enable-gpios = <&gpio TEGRA_GPIO(L, 2) GPIO_ACTIVE_HIGH>;
+
+		backlight = <&backlight>;
+	};
+
 	regulators {
 		compatible = "simple-bus";
 		#address-cells = <1>;
-- 
1.8.4

Re: [PATCH v2 02/13] ARM: tegra: Enable LVDS and HDMI on Cardhu

[Stephen Warren]

On 10/15/2013 09:27 AM, Thierry Reding wrote:
> Add backlight and panel nodes for the Cardhu 10.1" WXGA TFT LCD panel
> and enable the HDMI output and hotplug detection.
> 
> Note that HDMI doesn't work for some reason and I haven't found out why
> yet. I remember someone reporting that it worked at some point in time
> using this set of nodes but that no longer seems to be the case. Running
> the same kernel on Beaver has working HDMI, though.

I'm hesitant to apply this, since we know HDMI doesn't work. Wouldn't it
be better to just enable the panel, and hold off on HDMI until we've
located the problem?

On the panel side, have the DT bindings been acked by both DT
maintainers and both bindings and driver by someone involved in CDF. I
worry that since the simple panel framework overlaps with CDF's goals,
that people will be upset if we create some alternative to it. Still,
there's a lot to be said for code that exists and works right now, so I
hope there won't be any issue here, but it'd be good to be sure.

Re: [PATCH v2 02/13] ARM: tegra: Enable LVDS and HDMI on Cardhu

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2471 bytes --]

On Tue, Oct 15, 2013 at 02:39:35PM -0600, Stephen Warren wrote:
> On 10/15/2013 09:27 AM, Thierry Reding wrote:
> > Add backlight and panel nodes for the Cardhu 10.1" WXGA TFT LCD panel
> > and enable the HDMI output and hotplug detection.
> > 
> > Note that HDMI doesn't work for some reason and I haven't found out why
> > yet. I remember someone reporting that it worked at some point in time
> > using this set of nodes but that no longer seems to be the case. Running
> > the same kernel on Beaver has working HDMI, though.
> 
> I'm hesitant to apply this, since we know HDMI doesn't work. Wouldn't it
> be better to just enable the panel, and hold off on HDMI until we've
> located the problem?

Okay, I'll split up the patch so that the LVDS part can be applied and
we can hold off on the HDMI part until it's fixed.

> On the panel side, have the DT bindings been acked by both DT
> maintainers and both bindings and driver by someone involved in CDF. I
> worry that since the simple panel framework overlaps with CDF's goals,
> that people will be upset if we create some alternative to it. Still,
> there's a lot to be said for code that exists and works right now, so I
> hope there won't be any issue here, but it'd be good to be sure.

I haven't received any response from any of the DT maintainers so far,
even though the relevant patches had been posted to the devicetree
mailing list some time ago. I also don't think that anyone from the CDF
people has looked at the panel drivers so far. They must have seen the
patches because at least some of them are subscribed to the dri-devel
mailing list where the patches were posted.

I do have an IRC ACK from Dave Airlie to merge the DRM panel patches
though the Tegra tree, though. Furthermore there was some serious
pushback on the CDF patches from key DRM people in earlier discussions,
so I don't think we'll be finding any common ground here anytime soon.
That said it has been suggested that if CDF ever becomes a reality, a
DRM panel driver could be written as glue between the CDF and DRM if
that should ever prove to be valuable.

As for the bindings, I don't think the underlying kernel implementation
should have any influence on it. Furthermore the bindings are trivially
simple, so I really don't see how anybody could object. I mean, it's a
compatible string, a power supply and an enable GPIO. There's nothing
ground-breakingly new there.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2 02/13] ARM: tegra: Enable LVDS and HDMI on Cardhu

[Stephen Warren]

On 10/16/2013 05:09 AM, Thierry Reding wrote:
> On Tue, Oct 15, 2013 at 02:39:35PM -0600, Stephen Warren wrote:
>> On 10/15/2013 09:27 AM, Thierry Reding wrote:
>>> Add backlight and panel nodes for the Cardhu 10.1" WXGA TFT LCD panel
>>> and enable the HDMI output and hotplug detection.
>>>
>>> Note that HDMI doesn't work for some reason and I haven't found out why
>>> yet. I remember someone reporting that it worked at some point in time
>>> using this set of nodes but that no longer seems to be the case. Running
>>> the same kernel on Beaver has working HDMI, though.
>>
>> I'm hesitant to apply this, since we know HDMI doesn't work. Wouldn't it
>> be better to just enable the panel, and hold off on HDMI until we've
>> located the problem?
> 
> Okay, I'll split up the patch so that the LVDS part can be applied and
> we can hold off on the HDMI part until it's fixed.
> 
>> On the panel side, have the DT bindings been acked by both DT
>> maintainers and both bindings and driver by someone involved in CDF. I
>> worry that since the simple panel framework overlaps with CDF's goals,
>> that people will be upset if we create some alternative to it. Still,
>> there's a lot to be said for code that exists and works right now, so I
>> hope there won't be any issue here, but it'd be good to be sure.
> 
> I haven't received any response from any of the DT maintainers so far,
> even though the relevant patches had been posted to the devicetree
> mailing list some time ago. I also don't think that anyone from the CDF
> people has looked at the panel drivers so far. They must have seen the
> patches because at least some of them are subscribed to the dri-devel
> mailing list where the patches were posted.
> 
> I do have an IRC ACK from Dave Airlie to merge the DRM panel patches
> though the Tegra tree, though. Furthermore there was some serious
> pushback on the CDF patches from key DRM people in earlier discussions,
> so I don't think we'll be finding any common ground here anytime soon.
> That said it has been suggested that if CDF ever becomes a reality, a
> DRM panel driver could be written as glue between the CDF and DRM if
> that should ever prove to be valuable.
> 
> As for the bindings, I don't think the underlying kernel implementation
> should have any influence on it. Furthermore the bindings are trivially
> simple, so I really don't see how anybody could object. I mean, it's a
> compatible string, a power supply and an enable GPIO. There's nothing
> ground-breakingly new there.

Still, we do need DT maintainer ack to merge new bindings, and I really
do want explicit OK from people involved in CDF before applying
something that touches the same area.

[PATCH v2 03/13] ARM: tegra: Enable LVDS output on Harmony

[Thierry Reding]

Add backlight and panel modes for the Harmony TFT LCD panel.

Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
Changes in v2:
- no longer set panel regulator always-on, fixed in driver
- update commit message
- remove backlight-boot-off property for now

 arch/arm/boot/dts/tegra20-harmony.dts | 36 +++++++++++++++++++++++++++++++++--
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/tegra20-harmony.dts b/arch/arm/boot/dts/tegra20-harmony.dts
index e156ab3..a02e116 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -11,6 +11,14 @@
 	};
 
 	host1x {
+		dc@54200000 {
+			rgb {
+				status = "okay";
+
+				nvidia,panel = <&panel>;
+			};
+		};
+
 		hdmi {
 			status = "okay";
 
@@ -255,6 +263,10 @@
 		status = "okay";
 	};
 
+	pwm {
+		status = "okay";
+	};
+
 	i2c@7000c000 {
 		status = "okay";
 		clock-frequency = <400000>;
@@ -483,6 +495,17 @@
 		bus-width = <8>;
 	};
 
+	backlight: backlight {
+		compatible = "pwm-backlight";
+
+		enable-gpios = <&gpio TEGRA_GPIO(B, 5) GPIO_ACTIVE_HIGH>;
+		power-supply = <&vdd_bl_reg>;
+		pwms = <&pwm 0 5000000>;
+
+		brightness-levels = <0 4 8 16 32 64 128 255>;
+		default-brightness-level = <6>;
+	};
+
 	clocks {
 		compatible = "simple-bus";
 		#address-cells = <1>;
@@ -624,6 +647,15 @@
 				0x1F0400D6>;	/* KEY_QUESTION */
 	};
 
+	panel: panel {
+		compatible = "auo,b101aw03";
+
+		power-supply = <&vdd_pnl_reg>;
+		enable-gpios = <&gpio TEGRA_GPIO(B, 2) GPIO_ACTIVE_HIGH>;
+
+		backlight = <&backlight>;
+	};
+
 	regulators {
 		compatible = "simple-bus";
 		#address-cells = <1>;
@@ -667,7 +699,7 @@
 			enable-active-high;
 		};
 
-		regulator@4 {
+		vdd_pnl_reg: regulator@4 {
 			compatible = "regulator-fixed";
 			reg = <4>;
 			regulator-name = "vdd_pnl";
@@ -677,7 +709,7 @@
 			enable-active-high;
 		};
 
-		regulator@5 {
+		vdd_bl_reg: regulator@5 {
 			compatible = "regulator-fixed";
 			reg = <5>;
 			regulator-name = "vdd_bl";
-- 
1.8.4

[PATCH v2 04/13] ARM: tegra: Add MIPI calibration DT entries for Tegra114

[Thierry Reding]

Add a device node for the MIPI calibration block on Tegra114. There is
no need to disable it by default because it only enables the clock while
performing calibration and therefore shouldn't be consuming any power
when unused.

Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
Changes in v2:
- remove include/dt-bindings/gpu/host1x/tegra114-mipi.h

 arch/arm/boot/dts/tegra114.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 2905145..e45e619 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -398,6 +398,13 @@
 		};
 	};
 
+	mipi: mipi {
+		compatible = "nvidia,tegra114-mipi";
+		reg = <0x700e3000 0x100>;
+		clocks = <&tegra_car TEGRA114_CLK_MIPI_CAL>;
+		#calibrate-cells = <1>;
+	};
+
 	sdhci@78000000 {
 		compatible = "nvidia,tegra114-sdhci", "nvidia,tegra30-sdhci";
 		reg = <0x78000000 0x200>;
-- 
1.8.4

Re: [PATCH v2 04/13] ARM: tegra: Add MIPI calibration DT entries for Tegra114

[Stephen Warren]

On 10/15/2013 09:27 AM, Thierry Reding wrote:
> Add a device node for the MIPI calibration block on Tegra114. There is
> no need to disable it by default because it only enables the clock while
> performing calibration and therefore shouldn't be consuming any power
> when unused.

> diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi

> +	mipi: mipi {
> +		compatible = "nvidia,tegra114-mipi";
> +		reg = <0x700e3000 0x100>;
> +		clocks = <&tegra_car TEGRA114_CLK_MIPI_CAL>;
> +		#calibrate-cells = <1>;
> +	};

Do you have a link to the binding documentation for this? I'm still in
the dark re: why there's a need for #calibrate-cells at all. It seems
like this should be some internal implementation detail of the Tegra
DC/..., or implicit based on the compatible value (if cell count
changes, just rev the compatible value; it's not like this is a generic
service for loosely coupled drivers).

Re: [PATCH v2 04/13] ARM: tegra: Add MIPI calibration DT entries for Tegra114

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1718 bytes --]

On Tue, Oct 15, 2013 at 02:41:44PM -0600, Stephen Warren wrote:
> On 10/15/2013 09:27 AM, Thierry Reding wrote:
> > Add a device node for the MIPI calibration block on Tegra114. There is
> > no need to disable it by default because it only enables the clock while
> > performing calibration and therefore shouldn't be consuming any power
> > when unused.
> 
> > diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
> 
> > +	mipi: mipi {
> > +		compatible = "nvidia,tegra114-mipi";
> > +		reg = <0x700e3000 0x100>;
> > +		clocks = <&tegra_car TEGRA114_CLK_MIPI_CAL>;
> > +		#calibrate-cells = <1>;
> > +	};
> 
> Do you have a link to the binding documentation for this? I'm still in
> the dark re: why there's a need for #calibrate-cells at all. It seems
> like this should be some internal implementation detail of the Tegra
> DC/..., or implicit based on the compatible value (if cell count
> changes, just rev the compatible value; it's not like this is a generic
> service for loosely coupled drivers).

Here's the commit that adds the device tree binding:

	https://gitorious.org/thierryreding/linux/commit/43b798a54063156692e0fde2a9022c0ae44b862e

I was under the impression that we needed the #*-cells properties so
that the device tree code could verify that the content is actually
correct and so that it knows how to parse the specifier. I mean why
else do we have the #gpio-cells property for GPIO controller nodes?

Also note that this driver isn't for something internal to the DRM
driver. It can (and will) also be used by the V4L2 camera driver that
Bryan is working on, because the CSI pads need to be calibrated in the
same way.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2 04/13] ARM: tegra: Add MIPI calibration DT entries for Tegra114

[Stephen Warren]

On 10/16/2013 04:57 AM, Thierry Reding wrote:
> On Tue, Oct 15, 2013 at 02:41:44PM -0600, Stephen Warren wrote:
>> On 10/15/2013 09:27 AM, Thierry Reding wrote:
>>> Add a device node for the MIPI calibration block on Tegra114.
>>> There is no need to disable it by default because it only
>>> enables the clock while performing calibration and therefore
>>> shouldn't be consuming any power when unused.
>> 
>>> diff --git a/arch/arm/boot/dts/tegra114.dtsi
>>> b/arch/arm/boot/dts/tegra114.dtsi
>> 
>>> +	mipi: mipi { +		compatible = "nvidia,tegra114-mipi"; +		reg =
>>> <0x700e3000 0x100>; +		clocks = <&tegra_car
>>> TEGRA114_CLK_MIPI_CAL>; +		#calibrate-cells = <1>; +	};
>> 
>> Do you have a link to the binding documentation for this? I'm
>> still in the dark re: why there's a need for #calibrate-cells at
>> all. It seems like this should be some internal implementation
>> detail of the Tegra DC/..., or implicit based on the compatible
>> value (if cell count changes, just rev the compatible value; it's
>> not like this is a generic service for loosely coupled drivers).
> 
> Here's the commit that adds the device tree binding:
> 
> https://gitorious.org/thierryreding/linux/commit/43b798a54063156692e0fde2a9022c0ae44b862e

OK.
> 
That apparently hasn't been reviewed/acked by any DT maintainers
though?

> I was under the impression that we needed the #*-cells properties
> so that the device tree code could verify that the content is
> actually correct and so that it knows how to parse the specifier. I
> mean why else do we have the #gpio-cells property for GPIO
> controller nodes?

For GPIOs, there's no relationship between the provider and consumer;
any chip can provide any other chip with a GPIO. Hence, the format of
the GPIO property needs to be fully generic and flexible.

I would argue here that the MIPI module and its consumers are
completely coupled together, so the number of cells is known and
static. I suppose if you mixed/matched DSI and MIPI-CAL modules in
SoCs, perhaps this isn't the case though.

That said, even though I'm not convinced this property is needed, I
suppose it doesn't hurt. It might allow some strange future chip that
has multiple MIPI-CAL blocks each having a different number of
channels and hence needing a different number of cells, with some
lanes from one DSI controller routed to different MIPI-CAL blocks. I
guess it is best to be future-safe.

> Also note that this driver isn't for something internal to the DRM 
> driver. It can (and will) also be used by the V4L2 camera driver
> that Bryan is working on, because the CSI pads need to be
> calibrated in the same way.

Re: [PATCH v2 04/13] ARM: tegra: Add MIPI calibration DT entries for Tegra114

[Stephen Warren]

On 10/16/2013 04:57 AM, Thierry Reding wrote:
> On Tue, Oct 15, 2013 at 02:41:44PM -0600, Stephen Warren wrote:
>> On 10/15/2013 09:27 AM, Thierry Reding wrote:
>>> Add a device node for the MIPI calibration block on Tegra114.
>>> There is no need to disable it by default because it only
>>> enables the clock while performing calibration and therefore
>>> shouldn't be consuming any power when unused.
>> 
>>> diff --git a/arch/arm/boot/dts/tegra114.dtsi
>>> b/arch/arm/boot/dts/tegra114.dtsi
>> 
>>> +	mipi: mipi { +		compatible = "nvidia,tegra114-mipi"; +		reg =
>>> <0x700e3000 0x100>; +		clocks = <&tegra_car
>>> TEGRA114_CLK_MIPI_CAL>; +		#calibrate-cells = <1>;

Oh, one thing I wonder about: #gpio-cells is a generic property that
applies to any GPIO user, and hence has a generic name.
#calibrate-cells here doesn't fall into the same class. Do we need a
more unique property name, such as #nvidia,mipi-calibrate-cells, and
equally for the consumer to use nvidia,mipi-calibrate as the property
that references the MIPI device, rather than the generic-sounding
"calibrate"?

[PATCH v2 05/13] ARM: tegra: Add host1x, DC and HDMI to Tegra114 device tree

[Thierry Reding]

From: Mikko Perttunen <mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

Add host1x, DC (display controller) and HDMI devices to Tegra114
device tree.

Signed-off-by: Mikko Perttunen <mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 arch/arm/boot/dts/tegra114.dtsi | 49 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index e45e619..1ddf024 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -15,6 +15,55 @@
 		serial3 = &uartd;
 	};
 
+	host1x@50000000 {
+		compatible = "nvidia,tegra114-host1x", "simple-bus";
+		reg = <0x50000000 0x00028000>;
+		interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>, /* syncpt */
+			     <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>; /* general */
+		clocks = <&tegra_car TEGRA114_CLK_HOST1X>;
+
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		ranges = <0x54000000 0x54000000 0x01000000>;
+
+		dc@54200000 {
+			compatible = "nvidia,tegra114-dc", "nvidia,tegra20-dc";
+			reg = <0x54200000 0x00040000>;
+			interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&tegra_car TEGRA114_CLK_DISP1>,
+				 <&tegra_car TEGRA114_CLK_PLL_P>;
+			clock-names = "disp1", "parent";
+
+			rgb {
+				status = "disabled";
+			};
+		};
+
+		dc@54240000 {
+			compatible = "nvidia,tegra114-dc", "nvidia,tegra20-dc";
+			reg = <0x54240000 0x00040000>;
+			interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&tegra_car TEGRA114_CLK_DISP2>,
+				 <&tegra_car TEGRA114_CLK_PLL_P>;
+			clock-names = "disp2", "parent";
+
+			rgb {
+				status = "disabled";
+			};
+		};
+
+		hdmi@54280000 {
+			compatible = "nvidia,tegra114-hdmi";
+			reg = <0x54280000 0x00040000>;
+			interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&tegra_car TEGRA114_CLK_HDMI>,
+				 <&tegra_car TEGRA114_CLK_PLL_D2_OUT0>;
+			clock-names = "hdmi", "parent";
+			status = "disabled";
+		};
+	};
+
 	gic: interrupt-controller {
 		compatible = "arm,cortex-a15-gic";
 		#interrupt-cells = <3>;
-- 
1.8.4

[PATCH v2 06/13] ARM: tegra: Add Tegra114 DSI support

[Thierry Reding]

Add device tree nodes for the DSI controllers found on Tegra114 SoCs.

Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
Changes in v2:
- use a comment to describe which pads need calibration

 arch/arm/boot/dts/tegra114.dtsi | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 1ddf024..7905b2e 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -62,6 +62,26 @@
 			clock-names = "hdmi", "parent";
 			status = "disabled";
 		};
+
+		dsi@54300000 {
+			compatible = "nvidia,tegra114-dsi";
+			reg = <0x54300000 0x00040000>;
+			clocks = <&tegra_car TEGRA114_CLK_DSIA>,
+				 <&tegra_car TEGRA114_CLK_PLL_D_OUT0>;
+			clock-names = "dsi", "parent";
+			calibrate = <&mipi 0x060>; /* DSIA & DSIB pads */
+			status = "disabled";
+		};
+
+		dsi@54400000 {
+			compatible = "nvidia,tegra114-dsi";
+			reg = <0x54400000 0x00040000>;
+			clocks = <&tegra_car TEGRA114_CLK_DSIB>,
+				 <&tegra_car TEGRA114_CLK_PLL_D2_OUT0>;
+			clock-names = "dsi", "parent";
+			calibrate = <&mipi 0x180>; /* DSIC & DSID pads */
+			status = "disabled";
+		};
 	};
 
 	gic: interrupt-controller {
-- 
1.8.4

[PATCH v2 07/13] ARM: tegra: Add Tegra114 gr2d support

[Thierry Reding]

Add the device tree for the gr2d hardware found on Tegra114 SoCs.

Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
Changes in v2:
- mark as backwards-compatible with Tegra20

 arch/arm/boot/dts/tegra114.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 7905b2e..d8a3d61 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -27,6 +27,13 @@
 
 		ranges = <0x54000000 0x54000000 0x01000000>;
 
+		gr2d@54140000 {
+			compatible = "nvidia,tegra114-gr2d", "nvidia,tegra20-gr2d";
+			reg = <0x54140000 0x00040000>;
+			interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&tegra_car TEGRA114_CLK_GR2D>;
+		};
+
 		dc@54200000 {
 			compatible = "nvidia,tegra114-dc", "nvidia,tegra20-dc";
 			reg = <0x54200000 0x00040000>;
-- 
1.8.4

[PATCH v2 08/13] ARM: tegra: Enable DSI support on Dalmore

[Thierry Reding]

Dalmore has a 10.1" WUXGA panel connected to one of the DSI outputs of
the Tegra114.

Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
Changes in v2:
- remove backlight-boot-off property for now
- don't renumber all regulators

 arch/arm/boot/dts/tegra114-dalmore.dts | 43 ++++++++++++++++++++++++----------
 1 file changed, 31 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index cb5ec23..ad80ebd 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -11,6 +11,14 @@
 		reg = <0x80000000 0x40000000>;
 	};
 
+	host1x@50000000 {
+		dsi@54300000 {
+			status = "okay";
+
+			nvidia,panel = <&panel>;
+		};
+	};
+
 	pinmux {
 		pinctrl-names = "default";
 		pinctrl-0 = <&state_default>;
@@ -718,6 +726,10 @@
 		status = "okay";
 	};
 
+	pwm {
+		status = "okay";
+	};
+
 	i2c@7000c000 {
 		status = "okay";
 		clock-frequency = <100000>;
@@ -806,7 +818,7 @@
 					regulator-boot-on;
 				};
 
-				fet1 {
+				vdd_bl_reg: fet1 {
 					regulator-name = "vdd-lcd-bl";
 				};
 
@@ -814,7 +826,7 @@
 					regulator-name = "vdd-modem-3v3";
 				};
 
-				fet4 {
+				avdd_lcd_reg: fet4 {
 					regulator-name = "avdd-lcd";
 				};
 
@@ -1084,6 +1096,17 @@
 		vbus-supply = <&usb3_vbus_reg>;
 	};
 
+	backlight: backlight {
+		compatible = "pwm-backlight";
+
+		enable-gpios = <&gpio TEGRA_GPIO(H, 2) GPIO_ACTIVE_HIGH>;
+		power-supply = <&vdd_bl_reg>;
+		pwms = <&pwm 1 1000000>;
+
+		brightness-levels = <0 4 8 16 32 64 128 255>;
+		default-brightness-level = <6>;
+	};
+
 	clocks {
 		compatible = "simple-bus";
 		#address-cells = <1>;
@@ -1126,6 +1149,12 @@
 		};
 	};
 
+	panel: panel {
+		compatible = "panasonic,vvx10f004b00";
+		power-supply = <&avdd_lcd_reg>;
+		backlight = <&backlight>;
+	};
+
 	regulators {
 		compatible = "simple-bus";
 		#address-cells = <1>;
@@ -1150,16 +1179,6 @@
 			gpio = <&gpio TEGRA_GPIO(H, 5) GPIO_ACTIVE_HIGH>;
 		};
 
-		lcd_bl_en_reg: regulator@2 {
-			compatible = "regulator-fixed";
-			reg = <2>;
-			regulator-name = "lcd_bl_en";
-			regulator-min-microvolt = <5000000>;
-			regulator-max-microvolt = <5000000>;
-			enable-active-high;
-			gpio = <&gpio TEGRA_GPIO(H, 2) GPIO_ACTIVE_HIGH>;
-		};
-
 		usb1_vbus_reg: regulator@3 {
 			compatible = "regulator-fixed";
 			reg = <3>;
-- 
1.8.4

[PATCH v2 09/13] ARM: tegra: Enable HDMI support on Dalmore

[Thierry Reding]

From: Mikko Perttunen <mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

Add HDMI node to the Dalmore device tree and hook up the VDD and PLL
regulators as well as the I2C adapter used for DDC and the GPIO used
for hotplug detection.

Signed-off-by: Mikko Perttunen <mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 arch/arm/boot/dts/tegra114-dalmore.dts | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index ad80ebd..9da04d1 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -12,6 +12,17 @@
 	};
 
 	host1x@50000000 {
+		hdmi@54280000 {
+			status = "okay";
+
+			vdd-supply = <&vdd_hdmi_reg>;
+			pll-supply = <&palmas_smps3_reg>;
+
+			nvidia,ddc-i2c-bus = <&hdmi_ddc>;
+			nvidia,hpd-gpio =
+				<&gpio TEGRA_GPIO(N, 7) GPIO_ACTIVE_HIGH>;
+		};
+
 		dsi@54300000 {
 			status = "okay";
 
@@ -761,6 +772,10 @@
 		};
 	};
 
+	hdmi_ddc: i2c@7000c700 {
+		status = "okay";
+	};
+
 	i2c@7000d000 {
 		status = "okay";
 		clock-frequency = <400000>;
-- 
1.8.4

[PATCH v2 10/13] ARM: tegra: Enable DRM panel support

[Thierry Reding]

Enable DRM panel core support along with support for various simple
panels.

Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 arch/arm/configs/tegra_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index 4934295..17b22cc 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -164,6 +164,8 @@ CONFIG_MEDIA_CAMERA_SUPPORT=y
 CONFIG_MEDIA_USB_SUPPORT=y
 CONFIG_USB_VIDEO_CLASS=m
 CONFIG_DRM=y
+CONFIG_DRM_PANEL=y
+CONFIG_DRM_PANEL_SIMPLE=y
 CONFIG_TEGRA_HOST1X=y
 CONFIG_DRM_TEGRA=y
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
-- 
1.8.4

[PATCH v2 11/13] ARM: tegra: Add Tegra114 gr3d support

[Thierry Reding]

Add the gr3d device tree node. The gr3d block on Tegra114 is backwards-
compatible with the one on Tegra20.

Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 arch/arm/boot/dts/tegra114.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index d8a3d61..710c542 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -34,6 +34,12 @@
 			clocks = <&tegra_car TEGRA114_CLK_GR2D>;
 		};
 
+		gr3d@54180000 {
+			compatible = "nvidia,tegra114-gr3d", "nvidia,tegra20-gr3d";
+			reg = <0x54180000 0x00040000>;
+			clocks = <&tegra_car TEGRA114_CLK_GR3D>;
+		};
+
 		dc@54200000 {
 			compatible = "nvidia,tegra114-dc", "nvidia,tegra20-dc";
 			reg = <0x54200000 0x00040000>;
-- 
1.8.4

[PATCH v2 12/13] ARM: tegra: Use symbolic names for gr3d clocks

[Thierry Reding]

Commit 05849c9381354be4bd4a2a878b5ecb12d375a1a0 (ARM: tegra30: convert
device tree files to use CLK defines) updated the Tegra30 device tree to
use symbolic clock names but forgot to update this node.

Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 arch/arm/boot/dts/tegra30.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index d3d71ab..2bd55cf 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -136,7 +136,8 @@
 		gr3d {
 			compatible = "nvidia,tegra30-gr3d";
 			reg = <0x54180000 0x00040000>;
-			clocks = <&tegra_car 24 &tegra_car 98>;
+			clocks = <&tegra_car TEGRA30_CLK_GR3D
+				  &tegra_car TEGRA30_CLK_GR3D2>;
 			clock-names = "3d", "3d2";
 		};
 
-- 
1.8.4

[PATCH v2 13/13] WIP: ARM: tegra: Add Tegra114 powergate support

[Thierry Reding]

Extend the list of power gates found on Tegra114. Note that there are
now holes in the list, so perhaps a simple array is no longer the best
data structure to represent it. But perhaps this is good enough for now
and can be cleaned up in a follow up patch?

Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 arch/arm/mach-tegra/powergate.c | 41 +++++++++++++++++++++++++++++++++++++++++
 include/linux/tegra-powergate.h |  9 ++++++++-
 2 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/powergate.c b/arch/arm/mach-tegra/powergate.c
index f076f0f..8d9ab20 100644
--- a/arch/arm/mach-tegra/powergate.c
+++ b/arch/arm/mach-tegra/powergate.c
@@ -44,6 +44,13 @@ static int tegra_num_powerdomains;
 static int tegra_num_cpu_domains;
 static u8 *tegra_cpu_domains;
 static u8 tegra30_cpu_domains[] = {
+	TEGRA_POWERGATE_CPU,
+	TEGRA_POWERGATE_CPU1,
+	TEGRA_POWERGATE_CPU2,
+	TEGRA_POWERGATE_CPU3,
+};
+
+static u8 tegra114_cpu_domains[] = {
 	TEGRA_POWERGATE_CPU0,
 	TEGRA_POWERGATE_CPU1,
 	TEGRA_POWERGATE_CPU2,
@@ -189,6 +196,11 @@ int __init tegra_powergate_init(void)
 		tegra_num_cpu_domains = 4;
 		tegra_cpu_domains = tegra30_cpu_domains;
 		break;
+	case TEGRA114:
+		tegra_num_powerdomains = 23;
+		tegra_num_cpu_domains = 4;
+		tegra_cpu_domains = tegra114_cpu_domains;
+		break;
 	default:
 		/* Unknown Tegra variant. Disable powergating */
 		tegra_num_powerdomains = 0;
@@ -229,6 +241,32 @@ static const char * const powergate_name_t30[] = {
 	[TEGRA_POWERGATE_3D1]	= "3d1",
 };
 
+static const char * const powergate_name_t114[] = {
+	[TEGRA_POWERGATE_CPU]	= "cpu0",
+	[TEGRA_POWERGATE_3D]	= "3d",
+	[TEGRA_POWERGATE_VENC]	= "venc",
+	[TEGRA_POWERGATE_VDEC]	= "vdec",
+	[TEGRA_POWERGATE_PCIE]	= "n/a",
+	[TEGRA_POWERGATE_L2]	= "n/a",
+	[TEGRA_POWERGATE_MPE]	= "mpe",
+	[TEGRA_POWERGATE_HEG]	= "heg",
+	[TEGRA_POWERGATE_SATA]	= "n/a",
+	[TEGRA_POWERGATE_CPU1]	= "cpu1",
+	[TEGRA_POWERGATE_CPU2]	= "cpu2",
+	[TEGRA_POWERGATE_CPU3]	= "cpu3",
+	[TEGRA_POWERGATE_CELP]	= "celp",
+	[TEGRA_POWERGATE_3D1]	= "n/a",
+	[TEGRA_POWERGATE_CPU0]	= "cpu0",
+	[TEGRA_POWERGATE_C0NC]	= "c0nc",
+	[TEGRA_POWERGATE_C1NC]	= "c1nc",
+	[17]			= "n/a",
+	[TEGRA_POWERGATE_DISA]	= "disa",
+	[TEGRA_POWERGATE_DISB]	= "disb",
+	[TEGRA_POWERGATE_XUSBA]	= "xusba",
+	[TEGRA_POWERGATE_XUSBB]	= "xusbb",
+	[TEGRA_POWERGATE_XUSBC]	= "xusbc",
+};
+
 static int powergate_show(struct seq_file *s, void *data)
 {
 	int i;
@@ -265,6 +303,9 @@ int __init tegra_powergate_debugfs_init(void)
 	case TEGRA30:
 		powergate_name = powergate_name_t30;
 		break;
+	case TEGRA114:
+		powergate_name = powergate_name_t114;
+		break;
 	}
 
 	if (powergate_name) {
diff --git a/include/linux/tegra-powergate.h b/include/linux/tegra-powergate.h
index 55c29a8..b2df1c6 100644
--- a/include/linux/tegra-powergate.h
+++ b/include/linux/tegra-powergate.h
@@ -34,8 +34,15 @@ struct clk;
 #define TEGRA_POWERGATE_CPU3	11
 #define TEGRA_POWERGATE_CELP	12
 #define TEGRA_POWERGATE_3D1	13
+#define TEGRA_POWERGATE_CPU0	14
+#define TEGRA_POWERGATE_C0NC	15
+#define TEGRA_POWERGATE_C1NC	16
+#define TEGRA_POWERGATE_DISA	18
+#define TEGRA_POWERGATE_DISB	19
+#define TEGRA_POWERGATE_XUSBA	20
+#define TEGRA_POWERGATE_XUSBB	21
+#define TEGRA_POWERGATE_XUSBC	22
 
-#define TEGRA_POWERGATE_CPU0	TEGRA_POWERGATE_CPU
 #define TEGRA_POWERGATE_3D0	TEGRA_POWERGATE_3D
 
 int tegra_powergate_is_powered(int id);
-- 
1.8.4

Re: [PATCH v2 13/13] WIP: ARM: tegra: Add Tegra114 powergate support

[Stephen Warren]

On 10/15/2013 09:28 AM, Thierry Reding wrote:
> Extend the list of power gates found on Tegra114. Note that there are
> now holes in the list, so perhaps a simple array is no longer the best
> data structure to represent it. But perhaps this is good enough for now
> and can be cleaned up in a follow up patch?

Peter should probably comment on this, since I think he's touched the
powergate driver the most recently.

One idea might be to have the powergate IDs be "virtual", with a
virtual->HW ID mapping table per SoC. The virtual IDs need not have any
gaps. I'm not sure that having gaps is really much of a problem though,
except for the debugfs code in powergate.c...

> diff --git a/include/linux/tegra-powergate.h b/include/linux/tegra-powergate.h

> +#define TEGRA_POWERGATE_DISA	18
> +#define TEGRA_POWERGATE_DISB	19

s/DIS/DSI/ perhaps?

> -#define TEGRA_POWERGATE_CPU0	TEGRA_POWERGATE_CPU

I expect that was added deliberately. Perhaps Peter or Joseph can
comment? Admittedly, it's not used right now.

BTW, while you're fiddling with powergate.c, I note that
mach-tegra/pmc.c #defines some TEGRA_POWERGATE_xxx rather than including
tegra-powergate.h. Can you fix that?

Re: [PATCH v2 13/13] WIP: ARM: tegra: Add Tegra114 powergate support

[Joseph Lo]

On Wed, 2013-10-16 at 05:50 +0800, Stephen Warren wrote:
> On 10/15/2013 09:28 AM, Thierry Reding wrote:
> > Extend the list of power gates found on Tegra114. Note that there are
> > now holes in the list, so perhaps a simple array is no longer the best
> > data structure to represent it. But perhaps this is good enough for now
> > and can be cleaned up in a follow up patch?
> 
> Peter should probably comment on this, since I think he's touched the
> powergate driver the most recently.
> 
> One idea might be to have the powergate IDs be "virtual", with a
> virtual->HW ID mapping table per SoC. The virtual IDs need not have any
> gaps. I'm not sure that having gaps is really much of a problem though,
> except for the debugfs code in powergate.c...
> 
> > diff --git a/include/linux/tegra-powergate.h b/include/linux/tegra-powergate.h
> 
> > +#define TEGRA_POWERGATE_DISA	18
> > +#define TEGRA_POWERGATE_DISB	19
> 
> s/DIS/DSI/ perhaps?
> 
> > -#define TEGRA_POWERGATE_CPU0	TEGRA_POWERGATE_CPU
> 
> I expect that was added deliberately. Perhaps Peter or Joseph can
> comment? Admittedly, it's not used right now.
> 
> BTW, while you're fiddling with powergate.c, I note that
> mach-tegra/pmc.c #defines some TEGRA_POWERGATE_xxx rather than including
> tegra-powergate.h. Can you fix that?

The reason why we didn't keep updated this code and use this driver is
because we want it to convert to use generic power domain
infrastructure[1]. Not sure this makes sense to you. (Only PCIe uses
this powergate driver until now.)

[1]:
include/linux/pm_domain.h
drivers/base/power/domain.c
Documentation/power/devices.txt
Documentation/power/runtime_pm.txt

Re: [PATCH v2 13/13] WIP: ARM: tegra: Add Tegra114 powergate support

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2023 bytes --]

On Wed, Oct 16, 2013 at 10:31:11AM +0800, Joseph Lo wrote:
> On Wed, 2013-10-16 at 05:50 +0800, Stephen Warren wrote:
> > On 10/15/2013 09:28 AM, Thierry Reding wrote:
> > > Extend the list of power gates found on Tegra114. Note that there are
> > > now holes in the list, so perhaps a simple array is no longer the best
> > > data structure to represent it. But perhaps this is good enough for now
> > > and can be cleaned up in a follow up patch?
> > 
> > Peter should probably comment on this, since I think he's touched the
> > powergate driver the most recently.
> > 
> > One idea might be to have the powergate IDs be "virtual", with a
> > virtual->HW ID mapping table per SoC. The virtual IDs need not have any
> > gaps. I'm not sure that having gaps is really much of a problem though,
> > except for the debugfs code in powergate.c...
> > 
> > > diff --git a/include/linux/tegra-powergate.h b/include/linux/tegra-powergate.h
> > 
> > > +#define TEGRA_POWERGATE_DISA	18
> > > +#define TEGRA_POWERGATE_DISB	19
> > 
> > s/DIS/DSI/ perhaps?
> > 
> > > -#define TEGRA_POWERGATE_CPU0	TEGRA_POWERGATE_CPU
> > 
> > I expect that was added deliberately. Perhaps Peter or Joseph can
> > comment? Admittedly, it's not used right now.
> > 
> > BTW, while you're fiddling with powergate.c, I note that
> > mach-tegra/pmc.c #defines some TEGRA_POWERGATE_xxx rather than including
> > tegra-powergate.h. Can you fix that?
> 
> The reason why we didn't keep updated this code and use this driver is
> because we want it to convert to use generic power domain
> infrastructure[1]. Not sure this makes sense to you. (Only PCIe uses
> this powergate driver until now.)

We need it for gr3d as well and so far nobody's worked on the conversion
to the power domain infrastructure as far as I know. So in the meantime
we should still extend this driver to cover whatever functionality we
need. Hopefully any effort we invest now can be reused when moving to
the PM domain framework.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2 13/13] WIP: ARM: tegra: Add Tegra114 powergate support

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1858 bytes --]

On Wed, Oct 16, 2013 at 10:31:11AM +0800, Joseph Lo wrote:
> On Wed, 2013-10-16 at 05:50 +0800, Stephen Warren wrote:
> > On 10/15/2013 09:28 AM, Thierry Reding wrote:
> > > Extend the list of power gates found on Tegra114. Note that there are
> > > now holes in the list, so perhaps a simple array is no longer the best
> > > data structure to represent it. But perhaps this is good enough for now
> > > and can be cleaned up in a follow up patch?
> > 
> > Peter should probably comment on this, since I think he's touched the
> > powergate driver the most recently.
> > 
> > One idea might be to have the powergate IDs be "virtual", with a
> > virtual->HW ID mapping table per SoC. The virtual IDs need not have any
> > gaps. I'm not sure that having gaps is really much of a problem though,
> > except for the debugfs code in powergate.c...
> > 
> > > diff --git a/include/linux/tegra-powergate.h b/include/linux/tegra-powergate.h
> > 
> > > +#define TEGRA_POWERGATE_DISA	18
> > > +#define TEGRA_POWERGATE_DISB	19
> > 
> > s/DIS/DSI/ perhaps?
> > 
> > > -#define TEGRA_POWERGATE_CPU0	TEGRA_POWERGATE_CPU
> > 
> > I expect that was added deliberately. Perhaps Peter or Joseph can
> > comment? Admittedly, it's not used right now.
> > 
> > BTW, while you're fiddling with powergate.c, I note that
> > mach-tegra/pmc.c #defines some TEGRA_POWERGATE_xxx rather than including
> > tegra-powergate.h. Can you fix that?
> 
> The reason why we didn't keep updated this code and use this driver is
> because we want it to convert to use generic power domain
> infrastructure[1]. Not sure this makes sense to you. (Only PCIe uses
> this powergate driver until now.)

Hi Joseph,

Is this being tracked in an internal bug? Can you provide a bug number
for me? Also do you know if anyone's actively working on this?

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2 13/13] WIP: ARM: tegra: Add Tegra114 powergate support

[Joseph Lo]

On Thu, 2013-10-17 at 03:12 +0800, Thierry Reding wrote:
> On Wed, Oct 16, 2013 at 10:31:11AM +0800, Joseph Lo wrote:
> > On Wed, 2013-10-16 at 05:50 +0800, Stephen Warren wrote:
> > > On 10/15/2013 09:28 AM, Thierry Reding wrote:
> > > > Extend the list of power gates found on Tegra114. Note that there are
> > > > now holes in the list, so perhaps a simple array is no longer the best
> > > > data structure to represent it. But perhaps this is good enough for now
> > > > and can be cleaned up in a follow up patch?
> > > 
> > > Peter should probably comment on this, since I think he's touched the
> > > powergate driver the most recently.
> > > 
> > > One idea might be to have the powergate IDs be "virtual", with a
> > > virtual->HW ID mapping table per SoC. The virtual IDs need not have any
> > > gaps. I'm not sure that having gaps is really much of a problem though,
> > > except for the debugfs code in powergate.c...
> > > 
> > > > diff --git a/include/linux/tegra-powergate.h b/include/linux/tegra-powergate.h
> > > 
> > > > +#define TEGRA_POWERGATE_DISA	18
> > > > +#define TEGRA_POWERGATE_DISB	19
> > > 
> > > s/DIS/DSI/ perhaps?
> > > 
> > > > -#define TEGRA_POWERGATE_CPU0	TEGRA_POWERGATE_CPU
> > > 
> > > I expect that was added deliberately. Perhaps Peter or Joseph can
> > > comment? Admittedly, it's not used right now.
> > > 
> > > BTW, while you're fiddling with powergate.c, I note that
> > > mach-tegra/pmc.c #defines some TEGRA_POWERGATE_xxx rather than including
> > > tegra-powergate.h. Can you fix that?
> > 
> > The reason why we didn't keep updated this code and use this driver is
> > because we want it to convert to use generic power domain
> > infrastructure[1]. Not sure this makes sense to you. (Only PCIe uses
> > this powergate driver until now.)
> 
> Hi Joseph,
> 
> Is this being tracked in an internal bug? Can you provide a bug number
> for me? Also do you know if anyone's actively working on this?

Yes, it was 1264196. And I am the owner ...

As you know, except PCIe and XUSB(after Tegra114), only graphic and
video driver needs this driver to do PM domain control. And the power
sequence is pretty complicated here. It cannot be done by just toggling
the power bit in PMC. The other power client or memory client even need
to be considered if there are in the same domain. So I just finished
very initial part of them. And waiting for other drier that really need
them to continue.

We can discuss further internally before we decide how to do it.

Thanks,
Joseph

Re: [PATCH v2 13/13] WIP: ARM: tegra: Add Tegra114 powergate support

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1819 bytes --]

On Tue, Oct 15, 2013 at 03:50:42PM -0600, Stephen Warren wrote:
> On 10/15/2013 09:28 AM, Thierry Reding wrote:
> > Extend the list of power gates found on Tegra114. Note that there are
> > now holes in the list, so perhaps a simple array is no longer the best
> > data structure to represent it. But perhaps this is good enough for now
> > and can be cleaned up in a follow up patch?
> 
> Peter should probably comment on this, since I think he's touched the
> powergate driver the most recently.
> 
> One idea might be to have the powergate IDs be "virtual", with a
> virtual->HW ID mapping table per SoC. The virtual IDs need not have any
> gaps. I'm not sure that having gaps is really much of a problem though,
> except for the debugfs code in powergate.c...

That sounds like a good idea. I'll see what I can come up with.

> > diff --git a/include/linux/tegra-powergate.h b/include/linux/tegra-powergate.h
> 
> > +#define TEGRA_POWERGATE_DISA	18
> > +#define TEGRA_POWERGATE_DISB	19
> 
> s/DIS/DSI/ perhaps?

No, these are actually powergates for display A and display B.

> > -#define TEGRA_POWERGATE_CPU0	TEGRA_POWERGATE_CPU
> 
> I expect that was added deliberately. Perhaps Peter or Joseph can
> comment? Admittedly, it's not used right now.
> 
> BTW, while you're fiddling with powergate.c, I note that
> mach-tegra/pmc.c #defines some TEGRA_POWERGATE_xxx rather than including
> tegra-powergate.h. Can you fix that?

There's more: quite a bit of the powergate functionality seems to be
implemented in both powergate.c and pmc.c. I should probably unify both
while at it. Not sure if I can make it before the deadline on Thursday
though, so I'll focus on the refactoring of the power domain stuff first
because that's actually needed for Tegra114 support.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2 13/13] WIP: ARM: tegra: Add Tegra114 powergate support

[Stephen Warren]

On 10/16/2013 04:48 AM, Thierry Reding wrote:
> On Tue, Oct 15, 2013 at 03:50:42PM -0600, Stephen Warren wrote:
>> On 10/15/2013 09:28 AM, Thierry Reding wrote:
>>> Extend the list of power gates found on Tegra114. Note that
>>> there are now holes in the list, so perhaps a simple array is
>>> no longer the best data structure to represent it. But perhaps
>>> this is good enough for now and can be cleaned up in a follow
>>> up patch?
>> 
>> Peter should probably comment on this, since I think he's touched
>> the powergate driver the most recently.
>> 
>> One idea might be to have the powergate IDs be "virtual", with a 
>> virtual->HW ID mapping table per SoC. The virtual IDs need not
>> have any gaps. I'm not sure that having gaps is really much of a
>> problem though, except for the debugfs code in powergate.c...
> 
> That sounds like a good idea. I'll see what I can come up with.
> 
>>> diff --git a/include/linux/tegra-powergate.h
>>> b/include/linux/tegra-powergate.h
>> 
>>> +#define TEGRA_POWERGATE_DISA	18 +#define TEGRA_POWERGATE_DISB
>>> 19
>> 
>> s/DIS/DSI/ perhaps?
> 
> No, these are actually powergates for display A and display B.

Ah, OK. Those entries aren't called DCA, DCB then, DC==Display Controller?

>>> -#define TEGRA_POWERGATE_CPU0	TEGRA_POWERGATE_CPU
>> 
>> I expect that was added deliberately. Perhaps Peter or Joseph
>> can comment? Admittedly, it's not used right now.
>> 
>> BTW, while you're fiddling with powergate.c, I note that 
>> mach-tegra/pmc.c #defines some TEGRA_POWERGATE_xxx rather than
>> including tegra-powergate.h. Can you fix that?
> 
> There's more: quite a bit of the powergate functionality seems to
> be implemented in both powergate.c and pmc.c. I should probably
> unify both while at it. Not sure if I can make it before the
> deadline on Thursday though, so I'll focus on the refactoring of
> the power domain stuff first because that's actually needed for
> Tegra114 support.

I think it'd be better to just drop the gr3d support, which is all
that requires the powergate rework, so we can plan this out a little
better.

Re: [PATCH v2 13/13] WIP: ARM: tegra: Add Tegra114 powergate support

[Joseph Lo]

On Wed, 2013-10-16 at 18:48 +0800, Thierry Reding wrote:
> On Tue, Oct 15, 2013 at 03:50:42PM -0600, Stephen Warren wrote:
> > On 10/15/2013 09:28 AM, Thierry Reding wrote:
> > > -#define TEGRA_POWERGATE_CPU0	TEGRA_POWERGATE_CPU
> > 
> > I expect that was added deliberately. Perhaps Peter or Joseph can
> > comment? Admittedly, it's not used right now.
> > 
> > BTW, while you're fiddling with powergate.c, I note that
> > mach-tegra/pmc.c #defines some TEGRA_POWERGATE_xxx rather than including
> > tegra-powergate.h. Can you fix that?
> 
> There's more: quite a bit of the powergate functionality seems to be
> implemented in both powergate.c and pmc.c. I should probably unify both
> while at it. Not sure if I can make it before the deadline on Thursday
> though, so I'll focus on the refactoring of the power domain stuff first
> because that's actually needed for Tegra114 support.

The powergate driver should only touch the power function of devices not
CPU. Actually I had done the same thing you did here when Tegra114
brought up in March this year. But it was being rejected and asked for
using a generic framework if the kernel had one. I kept the driver but
moved all the CPU power control function to pmc.c.

So you may not need to unify them, just keep the devices power control
function in powergate.c and the CPU part in pmc.c. (The CPU part was
already there. You may just need to remove them in powergate.c.)

Thanks,
Joseph

Re: [PATCH v2 00/13] ARM: tegra: Enable DSI, panel and 3D support

[Stephen Warren]

On 10/15/2013 09:27 AM, Thierry Reding wrote:
> This series enables DSI, HDMI and gr2d support on Dalmore as well as
> panel support for Cardhu and Harmony. gr3d support is also enabled on
> Tegra20 through Tegra114.
> 
> I think I've addressed all comments from the initial version. A more
> notable addition was that of gr3d support and a WIP patch for Tegra114
> powergate support. I wanted to get some feedback on how to continue
> with the powergate patch (array vs. map, see patch for details) before
> finalizing it.

I have applied the following to Tegra's for-3.13/dt:

>   ARM: tegra: Mark Tegra30 display controller compatible with Tegra20
>   ARM: tegra: Add host1x, DC and HDMI to Tegra114 device tree
>   ARM: tegra: Enable HDMI support on Dalmore
>   ARM: tegra: Use symbolic names for gr3d clocks

I would have applied the following as well, but I can't since they
conflict with a patch in the clock tree that renames the GR2D and GR3D
clock #defines:

>   ARM: tegra: Add Tegra114 gr2d support
>   ARM: tegra: Add Tegra114 gr3d support

I didn't aply the following since they all rely on DT bindings thare
aren't yet approved, or enable functionality that doesn't yet work (HDMI
on Cardhu).

>   ARM: tegra: Enable LVDS and HDMI on Cardhu
>   ARM: tegra: Enable LVDS output on Harmony
>   ARM: tegra: Add MIPI calibration DT entries for Tegra114
>   ARM: tegra: Add Tegra114 DSI support
>   ARM: tegra: Enable DSI support on Dalmore
>   ARM: tegra: Enable DRM panel support

This one was replaced by another patch that's already applied:

>   WIP: ARM: tegra: Add Tegra114 powergate support

Re: [PATCH v2 00/13] ARM: tegra: Enable DSI, panel and 3D support

[Stephen Warren]

On 10/17/2013 11:37 AM, Stephen Warren wrote:
> On 10/15/2013 09:27 AM, Thierry Reding wrote:
>> This series enables DSI, HDMI and gr2d support on Dalmore as well as
>> panel support for Cardhu and Harmony. gr3d support is also enabled on
>> Tegra20 through Tegra114.
>>
>> I think I've addressed all comments from the initial version. A more
>> notable addition was that of gr3d support and a WIP patch for Tegra114
>> powergate support. I wanted to get some feedback on how to continue
>> with the powergate patch (array vs. map, see patch for details) before
>> finalizing it.
> 
> I have applied the following to Tegra's for-3.13/dt:
> 
>>   ARM: tegra: Mark Tegra30 display controller compatible with Tegra20
>>   ARM: tegra: Add host1x, DC and HDMI to Tegra114 device tree
>>   ARM: tegra: Enable HDMI support on Dalmore
>>   ARM: tegra: Use symbolic names for gr3d clocks

Actually, I just dropped the following two again:

ARM: tegra: Add host1x, DC and HDMI to Tegra114 device tree
ARM: tegra: Enable HDMI support on Dalmore

With those applied, I see a crash at boot when running Tegra's for-next
branch. Perhaps that's because the driver hasn't been updated to support
Tegra114 yet, and it would be fine once the Tegra and DRM trees were
merged, but I want the Tegra tree to be bisectable on its own.

Re: [PATCH v2 00/13] ARM: tegra: Enable DSI, panel and 3D support

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]

On Thu, Oct 17, 2013 at 11:45:51AM -0600, Stephen Warren wrote:
> On 10/17/2013 11:37 AM, Stephen Warren wrote:
> > On 10/15/2013 09:27 AM, Thierry Reding wrote:
> >> This series enables DSI, HDMI and gr2d support on Dalmore as well as
> >> panel support for Cardhu and Harmony. gr3d support is also enabled on
> >> Tegra20 through Tegra114.
> >>
> >> I think I've addressed all comments from the initial version. A more
> >> notable addition was that of gr3d support and a WIP patch for Tegra114
> >> powergate support. I wanted to get some feedback on how to continue
> >> with the powergate patch (array vs. map, see patch for details) before
> >> finalizing it.
> > 
> > I have applied the following to Tegra's for-3.13/dt:
> > 
> >>   ARM: tegra: Mark Tegra30 display controller compatible with Tegra20
> >>   ARM: tegra: Add host1x, DC and HDMI to Tegra114 device tree
> >>   ARM: tegra: Enable HDMI support on Dalmore
> >>   ARM: tegra: Use symbolic names for gr3d clocks
> 
> Actually, I just dropped the following two again:
> 
> ARM: tegra: Add host1x, DC and HDMI to Tegra114 device tree
> ARM: tegra: Enable HDMI support on Dalmore
> 
> With those applied, I see a crash at boot when running Tegra's for-next
> branch. Perhaps that's because the driver hasn't been updated to support
> Tegra114 yet, and it would be fine once the Tegra and DRM trees were
> merged, but I want the Tegra tree to be bisectable on its own.

You wouldn't have a saved copy of the crash around by any chance? Might
be useful to see if there's some problem with the host1x or DRM drivers
that needs to be fixed. Otherwise we might run into this again for
Tegra124 support.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]