Skip to contentSkip to conversation

add power-supply support to dw_hdmi

PATCH In review Heiko Stuebner 4 participants 10 messages Mar 9, 2015 – Mar 10, 2015

Subsystems (8)
lore
Share & tools
lore

Heiko Stuebner

author maintainer
#0 lore raw

cover add power-supply support to dw_hdmi

At least the Rockchip variant of the dw_hdmi should control its supplying regulators. A cursory glance at the imx manual didn't any equivalent there, so I'm not sure if there are similar controllable regulators present.

Patch1 is only a small fix to keep {devm_}regulator_bulk_get quiet in the deferring case and could go directly to the regulator tree, if ok.

Patch3 is the addition of the supplies to the rk3288 boards and I would take it into my dts branch if patch2 gets deemed acceptable.

Heiko Stuebner (3):
regulator: don't emit errors in {devm_}regulator_bulk_get when defering drm/bridge: dw-hdmi: support optional supply regulators
ARM: dts: rockchip: add hdmi analog power supplies to rk3288 boards

 .../devicetree/bindings/drm/bridge/dw_hdmi.txt     |  5 ++++
 arch/arm/boot/dts/rk3288-evb.dtsi                  |  2 ++
 arch/arm/boot/dts/rk3288-firefly.dtsi              |  2 ++
 drivers/gpu/drm/bridge/dw_hdmi.c                   | 27 +++++++++++++++++++++-
 drivers/gpu/drm/imx/dw_hdmi-imx.c                  |  3 ++-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c        | 15 +++++++++++-
 drivers/regulator/core.c                           |  5 ++--
 drivers/regulator/devres.c                         |  5 ++--
 include/drm/bridge/dw_hdmi.h                       |  3 ++-
 9 files changed, 59 insertions(+), 8 deletions(-)
Signature · 1 line
2.1.4
author maintainer
#1 lore raw

PATCH 1/3 regulator: don't emit errors in {devm_}regulator_bulk_get when defering

When {devm_}regulator_get returns -EPROBE_DEFER the driver in question will try probing again at a later time. So don't spam the log with failure messages as this is an expected result of probe ordering.

---
 drivers/regulator/core.c   | 5 +++--
 drivers/regulator/devres.c | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)
drivers/regulator/core.c +3 -2
index 52af1d7..07ca6cb 100644
@@ -3163,8 +3163,9 @@ int regulator_bulk_get(struct device *dev, int num_consumers,
 						      consumers[i].supply);
 		if (IS_ERR(consumers[i].consumer)) {
 			ret = PTR_ERR(consumers[i].consumer);
-			dev_err(dev, "Failed to get supply '%s': %d\n",
-				consumers[i].supply, ret);
+			if (ret != -EPROBE_DEFER)
+				dev_err(dev, "Failed to get supply '%s': %d\n",
+					consumers[i].supply, ret);
 			consumers[i].consumer = NULL;
 			goto err;
 		}
drivers/regulator/devres.c +3 -2
index 6ec1d40..78e460d 100644
@@ -168,8 +168,9 @@ int devm_regulator_bulk_get(struct device *dev, int num_consumers,
 							   consumers[i].supply);
 		if (IS_ERR(consumers[i].consumer)) {
 			ret = PTR_ERR(consumers[i].consumer);
-			dev_err(dev, "Failed to get supply '%s': %d\n",
-				consumers[i].supply, ret);
+			if (ret != -EPROBE_DEFER)
+				dev_err(dev, "Failed to get supply '%s': %d\n",
+					consumers[i].supply, ret);
 			consumers[i].consumer = NULL;
 			goto err;
 		}
Signature · 7 lines
2.1.4


_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel
maintainer
#2 lore raw

Re: [PATCH 1/3] regulator: don't emit errors in {devm_}regulator_bulk_get when defering

drivers/regulator/core.c int regulator_bulk_get(struct device *dev, int num_consumers, · line 3168

Quoted 9 lines · Heiko Stuebner

When {devm_}regulator_get returns -EPROBE_DEFER the driver in question will try probing again at a later time. So don't spam the log with failure messages as this is an expected result of probe ordering.

drivers/regulator/core.c +3 -2
-			dev_err(dev, "Failed to get supply '%s': %d\n",
-				consumers[i].supply, ret);
+			if (ret != -EPROBE_DEFER)
+				dev_err(dev, "Failed to get supply '%s': %d\n",
+					consumers[i].supply, ret);

No, this is not good - you get a nice quiet boot even if the regulator does not appear which means people have no idea why the driver isn't loading. That's not a good user experience, silent error handling is the main problem I see people running into trying to get their systems up and running these days.

Really deferred probe is just fundamentally noisy since it's intentionally tolerating errors like this and of course a lot of the noise comes from the deferral messages the core prints.

This is also not really connected to the series you're posting it in...

author maintainer
#3 lore raw

Re: [PATCH 1/3] regulator: don't emit errors in {devm_}regulator_bulk_get when defering

Am Dienstag, 10. M?rz 2015, 12:07:50 schrieb Mark Brown:

Quoted 18 lines · Heiko Stuebner

drivers/regulator/core.c int regulator_bulk_get(struct device *dev, int num_consumers, · line 3168

Quoted 10 lines

When {devm_}regulator_get returns -EPROBE_DEFER the driver in question will
try probing again at a later time. So don't spam the log with failure messages as this is an expected result of probe ordering.

drivers/regulator/core.c +3 -2
-			dev_err(dev, "Failed to get supply '%s': %d\n",
-				consumers[i].supply, ret);
+			if (ret != -EPROBE_DEFER)
+				dev_err(dev, "Failed to get supply '%s': %d\n",
+					consumers[i].supply, ret);

No, this is not good - you get a nice quiet boot even if the regulator does not appear which means people have no idea why the driver isn't loading. That's not a good user experience, silent error handling is the main problem I see people running into trying to get their systems up and running these days.

Quoted 3 lines

Really deferred probe is just fundamentally noisy since it's intentionally tolerating errors like this and of course a lot of the noise comes from the deferral messages the core prints.

ok, I'll drop this one then

author maintainer
#4 lore raw

PATCH 2/3 drm/bridge: dw-hdmi: support optional supply regulators

In reply to Heiko Stuebner

At least the Rockchip variant of the dw_hdmi can have controllable power supplies providing 1.0 and 1.8V. Therefore add the possibility for the generic bridge driver to enable supplies provided by the hw-specific drivers.

---
 .../devicetree/bindings/drm/bridge/dw_hdmi.txt     |  5 ++++
 drivers/gpu/drm/bridge/dw_hdmi.c                   | 27 +++++++++++++++++++++-
 drivers/gpu/drm/imx/dw_hdmi-imx.c                  |  3 ++-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c        | 15 +++++++++++-
 include/drm/bridge/dw_hdmi.h                       |  3 ++-
 5 files changed, 49 insertions(+), 4 deletions(-)
Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt +5 -0
index a905c14..bb74640 100644
@@ -22,6 +22,11 @@ Optional properties
 - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
 - clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec"
 
+Supplies:
+rockchip,rk3288-dw-hdmi handles two optional power supplies:
+- avdd1v0-supply: 1.0V power supply
+- avdd1v8-supply: 1.8V power supply
+
 Example:
 	hdmi: hdmi@0120000 {
 		compatible = "fsl,imx6q-hdmi";
drivers/gpu/drm/bridge/dw_hdmi.c +26 -1
index cd6a706..9f8999d 100644
@@ -17,6 +17,7 @@
 #include <linux/clk.h>
 #include <linux/hdmi.h>
 #include <linux/of_device.h>
+#include <linux/regulator/consumer.h>
 
 #include <drm/drm_of.h>
 #include <drm/drmP.h>
@@ -114,6 +115,9 @@ struct dw_hdmi {
 	struct hdmi_data_info hdmi_data;
 	const struct dw_hdmi_plat_data *plat_data;
 
+	struct regulator_bulk_data *supplies;
+	int nsupplies;
+
 	int vic;
 
 	u8 edid[HDMI_EDID_LEN];
@@ -879,6 +883,12 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
 	int i, ret;
 	bool cscon = false;
 
+	if (hdmi->nsupplies > 0) {
+		ret = regulator_bulk_enable(hdmi->nsupplies, hdmi->supplies);
+		if (ret)
+			return ret;
+	}
+
 	/*check csc whether needed activated in HDMI mode */
 	cscon = (is_color_space_conversion(hdmi) &&
 			!hdmi->hdmi_data.video_mode.mdvi);
@@ -1105,6 +1115,9 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi)
 	dw_hdmi_phy_enable_tmds(hdmi, 0);
 	dw_hdmi_phy_enable_power(hdmi, 0);
 
+	if (hdmi->nsupplies > 0)
+		regulator_bulk_disable(hdmi->nsupplies, hdmi->supplies);
+
 	hdmi->phy_enabled = false;
 }
 
@@ -1549,7 +1562,8 @@ static int dw_hdmi_register(struct drm_device *drm, struct dw_hdmi *hdmi)
 int dw_hdmi_bind(struct device *dev, struct device *master,
 		 void *data, struct drm_encoder *encoder,
 		 struct resource *iores, int irq,
-		 const struct dw_hdmi_plat_data *plat_data)
+		 const struct dw_hdmi_plat_data *plat_data,
+		 struct regulator_bulk_data *supplies, int nsupplies)
 {
 	struct drm_device *drm = data;
 	struct device_node *np = dev->of_node;
@@ -1602,6 +1616,17 @@ int dw_hdmi_bind(struct device *dev, struct device *master,
 	if (IS_ERR(hdmi->regs))
 		return PTR_ERR(hdmi->regs);
 
+	if (nsupplies > 0) {
+		ret = devm_regulator_bulk_get(hdmi->dev, nsupplies, supplies);
+		if (ret == -EPROBE_DEFER)
+			return ret;
+		if (ret)
+			nsupplies = 0;
+	}
+
+	hdmi->supplies = supplies;
+	hdmi->nsupplies = nsupplies;
+
 	hdmi->isfr_clk = devm_clk_get(hdmi->dev, "isfr");
 	if (IS_ERR(hdmi->isfr_clk)) {
 		ret = PTR_ERR(hdmi->isfr_clk);
drivers/gpu/drm/imx/dw_hdmi-imx.c +2 -1
index 121d30c..153e259 100644
@@ -214,7 +214,8 @@ static int dw_hdmi_imx_bind(struct device *dev, struct device *master,
 	drm_encoder_init(drm, encoder, &dw_hdmi_imx_encoder_funcs,
 			 DRM_MODE_ENCODER_TMDS);
 
-	return dw_hdmi_bind(dev, master, data, encoder, iores, irq, plat_data);
+	return dw_hdmi_bind(dev, master, data, encoder, iores, irq, plat_data,
+			    NULL, 0);
 }
 
 static void dw_hdmi_imx_unbind(struct device *dev, struct device *master,
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c +14 -1
index d236faa..c085e88 100644
@@ -11,6 +11,7 @@
 #include <linux/platform_device.h>
 #include <linux/mfd/syscon.h>
 #include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
 #include <drm/drm_of.h>
 #include <drm/drmP.h>
 #include <drm/drm_crtc_helper.h>
@@ -24,6 +25,8 @@
 #define GRF_SOC_CON6                    0x025c
 #define HDMI_SEL_VOP_LIT                (1 << 4)
 
+#define HDMI_NUM_REGULATORS             2
+
 struct rockchip_hdmi {
 	struct device *dev;
 	struct regmap *regmap;
@@ -248,6 +251,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
 	struct platform_device *pdev = to_platform_device(dev);
 	const struct dw_hdmi_plat_data *plat_data;
 	const struct of_device_id *match;
+	struct regulator_bulk_data *supplies;
 	struct drm_device *drm = data;
 	struct drm_encoder *encoder;
 	struct rockchip_hdmi *hdmi;
@@ -275,6 +279,14 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
 	if (!iores)
 		return -ENXIO;
 
+	supplies = devm_kcalloc(&pdev->dev, HDMI_NUM_REGULATORS,
+				sizeof(*supplies), GFP_KERNEL);
+	if (!supplies)
+		return -ENOMEM;
+
+	supplies[0].supply = "avdd1v0";
+	supplies[1].supply = "avdd1v8";
+
 	platform_set_drvdata(pdev, hdmi);
 
 	encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
@@ -297,7 +309,8 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
 	drm_encoder_init(drm, encoder, &dw_hdmi_rockchip_encoder_funcs,
 			 DRM_MODE_ENCODER_TMDS);
 
-	return dw_hdmi_bind(dev, master, data, encoder, iores, irq, plat_data);
+	return dw_hdmi_bind(dev, master, data, encoder, iores, irq, plat_data,
+			    supplies, HDMI_NUM_REGULATORS);
 }
 
 static void dw_hdmi_rockchip_unbind(struct device *dev, struct device *master,
include/drm/bridge/dw_hdmi.h +2 -1
index 5a4f490..7b0fac5 100644
@@ -57,5 +57,6 @@ void dw_hdmi_unbind(struct device *dev, struct device *master, void *data);
 int dw_hdmi_bind(struct device *dev, struct device *master,
 		 void *data, struct drm_encoder *encoder,
 		 struct resource *iores, int irq,
-		 const struct dw_hdmi_plat_data *plat_data);
+		 const struct dw_hdmi_plat_data *plat_data,
+		 struct regulator_bulk_data *supplies, int nsupplies);
 #endif /* __IMX_HDMI_H__ */
Signature · 7 lines
2.1.4


_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel
#5 lore raw

Re: [PATCH 2/3] drm/bridge: dw-hdmi: support optional supply regulators

Hi Heiko,

Am Dienstag, den 10.03.2015, 00:22 +0100 schrieb Heiko Stuebner:

Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt Optional properties · line 25

Quoted 9 lines
Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt +1 -0
index a905c14..bb74640 100644
@@ -22,6 +22,11 @@ Optional properties
 - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
 - clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec"
 
+Supplies:

"Optional supplies:" ? It seems to be common to always state optional or required for the properties.

Quoted 20 lines
Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt +4 -0
+rockchip,rk3288-dw-hdmi handles two optional power supplies:
+- avdd1v0-supply: 1.0V power supply
+- avdd1v8-supply: 1.8V power supply
+
 Example:
 	hdmi: hdmi at 0120000 {
 		compatible = "fsl,imx6q-hdmi";
drivers/gpu/drm/bridge/dw_hdmi.c +1 -0
index cd6a706..9f8999d 100644
@@ -17,6 +17,7 @@
 #include <linux/clk.h>
 #include <linux/hdmi.h>
 #include <linux/of_device.h>
+#include <linux/regulator/consumer.h>
 
 #include <drm/drm_of.h>
 #include <drm/drmP.h>

drivers/gpu/drm/bridge/dw_hdmi.c struct dw_hdmi { · line 117

Quoted 3 lines
drivers/gpu/drm/bridge/dw_hdmi.c +0 -0
@@ -114,6 +115,9 @@ struct dw_hdmi {
 	struct hdmi_data_info hdmi_data;
 	const struct dw_hdmi_plat_data *plat_data;
 

Superfluous empty line.

Quoted 7 lines
drivers/gpu/drm/bridge/dw_hdmi.c +3 -0
+	struct regulator_bulk_data *supplies;
+	int nsupplies;
+
 	int vic;
 
 	u8 edid[HDMI_EDID_LEN];

drivers/gpu/drm/bridge/dw_hdmi.c static int dw_hdmi_phy_init(struct dw_hdmi *hdmi) · line 891

Quoted 9 lines
drivers/gpu/drm/bridge/dw_hdmi.c +6 -0
@@ -879,6 +883,12 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
 	int i, ret;
 	bool cscon = false;
 
+	if (hdmi->nsupplies > 0) {
+		ret = regulator_bulk_enable(hdmi->nsupplies, hdmi->supplies);
+		if (ret)
+			return ret;
+	}
+

Are these really supplies to the PHY or is this just a convenient place to enable them? Looking at the i.MX6 docs, I suppose yes.

Quoted 14 lines
drivers/gpu/drm/bridge/dw_hdmi.c +3 -0
 	/*check csc whether needed activated in HDMI mode */
 	cscon = (is_color_space_conversion(hdmi) &&
 			!hdmi->hdmi_data.video_mode.mdvi);
@@ -1105,6 +1115,9 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi)
 	dw_hdmi_phy_enable_tmds(hdmi, 0);
 	dw_hdmi_phy_enable_power(hdmi, 0);
 
+	if (hdmi->nsupplies > 0)
+		regulator_bulk_disable(hdmi->nsupplies, hdmi->supplies);
+
 	hdmi->phy_enabled = false;
 }
 

drivers/gpu/drm/bridge/dw_hdmi.c static int dw_hdmi_register(struct drm_device *drm, struct dw_hdmi *hdmi) · line 1566

Quoted 6 lines
drivers/gpu/drm/bridge/dw_hdmi.c +2 -1
@@ -1549,7 +1562,8 @@ static int dw_hdmi_register(struct drm_device *drm, struct dw_hdmi *hdmi)
 int dw_hdmi_bind(struct device *dev, struct device *master,
 		 void *data, struct drm_encoder *encoder,
 		 struct resource *iores, int irq,
-		 const struct dw_hdmi_plat_data *plat_data)
+		 const struct dw_hdmi_plat_data *plat_data,
+		 struct regulator_bulk_data *supplies, int nsupplies)

I'm not sure I like this function sprouting so many parameters. Is there a good reason not to add this to struct dw_hdmi_plat_data?

Quoted 94 lines
drivers/gpu/drm/bridge/dw_hdmi.c +11 -0
 {
 	struct drm_device *drm = data;
 	struct device_node *np = dev->of_node;
@@ -1602,6 +1616,17 @@ int dw_hdmi_bind(struct device *dev, struct device *master,
 	if (IS_ERR(hdmi->regs))
 		return PTR_ERR(hdmi->regs);
 
+	if (nsupplies > 0) {
+		ret = devm_regulator_bulk_get(hdmi->dev, nsupplies, supplies);
+		if (ret == -EPROBE_DEFER)
+			return ret;
+		if (ret)
+			nsupplies = 0;
+	}
+
+	hdmi->supplies = supplies;
+	hdmi->nsupplies = nsupplies;
+
 	hdmi->isfr_clk = devm_clk_get(hdmi->dev, "isfr");
 	if (IS_ERR(hdmi->isfr_clk)) {
 		ret = PTR_ERR(hdmi->isfr_clk);
drivers/gpu/drm/imx/dw_hdmi-imx.c +2 -1
index 121d30c..153e259 100644
@@ -214,7 +214,8 @@ static int dw_hdmi_imx_bind(struct device *dev, struct device *master,
 	drm_encoder_init(drm, encoder, &dw_hdmi_imx_encoder_funcs,
 			 DRM_MODE_ENCODER_TMDS);
 
-	return dw_hdmi_bind(dev, master, data, encoder, iores, irq, plat_data);
+	return dw_hdmi_bind(dev, master, data, encoder, iores, irq, plat_data,
+			    NULL, 0);
 }
 
 static void dw_hdmi_imx_unbind(struct device *dev, struct device *master,
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c +14 -1
index d236faa..c085e88 100644
@@ -11,6 +11,7 @@
 #include <linux/platform_device.h>
 #include <linux/mfd/syscon.h>
 #include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
 #include <drm/drm_of.h>
 #include <drm/drmP.h>
 #include <drm/drm_crtc_helper.h>
@@ -24,6 +25,8 @@
 #define GRF_SOC_CON6                    0x025c
 #define HDMI_SEL_VOP_LIT                (1 << 4)
 
+#define HDMI_NUM_REGULATORS             2
+
 struct rockchip_hdmi {
 	struct device *dev;
 	struct regmap *regmap;
@@ -248,6 +251,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
 	struct platform_device *pdev = to_platform_device(dev);
 	const struct dw_hdmi_plat_data *plat_data;
 	const struct of_device_id *match;
+	struct regulator_bulk_data *supplies;
 	struct drm_device *drm = data;
 	struct drm_encoder *encoder;
 	struct rockchip_hdmi *hdmi;
@@ -275,6 +279,14 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
 	if (!iores)
 		return -ENXIO;
 
+	supplies = devm_kcalloc(&pdev->dev, HDMI_NUM_REGULATORS,
+				sizeof(*supplies), GFP_KERNEL);
+	if (!supplies)
+		return -ENOMEM;
+
+	supplies[0].supply = "avdd1v0";
+	supplies[1].supply = "avdd1v8";
+
 	platform_set_drvdata(pdev, hdmi);
 
 	encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
@@ -297,7 +309,8 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
 	drm_encoder_init(drm, encoder, &dw_hdmi_rockchip_encoder_funcs,
 			 DRM_MODE_ENCODER_TMDS);
 
-	return dw_hdmi_bind(dev, master, data, encoder, iores, irq, plat_data);
+	return dw_hdmi_bind(dev, master, data, encoder, iores, irq, plat_data,
+			    supplies, HDMI_NUM_REGULATORS);
 }
 
 static void dw_hdmi_rockchip_unbind(struct device *dev, struct device *master,
include/drm/bridge/dw_hdmi.h +0 -0
index 5a4f490..7b0fac5 100644

include/drm/bridge/dw_hdmi.h void dw_hdmi_unbind(struct device *dev, struct device *master, void *data); · line 62

Quoted 7 lines
include/drm/bridge/dw_hdmi.h +2 -1
@@ -57,5 +57,6 @@ void dw_hdmi_unbind(struct device *dev, struct device *master, void *data);
 int dw_hdmi_bind(struct device *dev, struct device *master,
 		 void *data, struct drm_encoder *encoder,
 		 struct resource *iores, int irq,
-		 const struct dw_hdmi_plat_data *plat_data);
+		 const struct dw_hdmi_plat_data *plat_data,
+		 struct regulator_bulk_data *supplies, int nsupplies);
 #endif /* __IMX_HDMI_H__ */

regards
Philipp

author maintainer
#6 lore raw

Re: [PATCH 2/3] drm/bridge: dw-hdmi: support optional supply regulators

Hi Philipp,

Am Dienstag, 10. M?rz 2015, 10:16:53 schrieb Philipp Zabel:

[cut the obvious stuff I need to fix]

Quoted 6 lines

Am Dienstag, den 10.03.2015, 00:22 +0100 schrieb Heiko Stuebner:

Quoted 5 lines
drivers/gpu/drm/bridge/dw_hdmi.c +0 -0
@@ -879,6 +883,12 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
 
 	int i, ret;
 	bool cscon = false;
 
Quoted 9 lines

drivers/gpu/drm/bridge/dw_hdmi.c static int dw_hdmi_phy_init(struct dw_hdmi *hdmi) · line 891

Quoted 6 lines
drivers/gpu/drm/bridge/dw_hdmi.c +6 -0
+	if (hdmi->nsupplies > 0) {
+		ret = regulator_bulk_enable(hdmi->nsupplies, hdmi->supplies);
+		if (ret)
+			return ret;
+	}
+

Are these really supplies to the PHY or is this just a convenient place to enable them? Looking at the i.MX6 docs, I suppose yes.

According to the TRM, the supplies are "DC supply voltage for Analog part of HDMI", so I'd think phy supplies.

Quoted 27 lines
Quoted 27 lines
drivers/gpu/drm/bridge/dw_hdmi.c +0 -0
 	/*check csc whether needed activated in HDMI mode */
 	cscon = (is_color_space_conversion(hdmi) &&
drivers/gpu/drm/bridge/dw_hdmi.c +3 -0
 			!hdmi->hdmi_data.video_mode.mdvi);
@@ -1105,6 +1115,9 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
 *hdmi)
 
 	dw_hdmi_phy_enable_tmds(hdmi, 0);
 	dw_hdmi_phy_enable_power(hdmi, 0);
 
+	if (hdmi->nsupplies > 0)
+		regulator_bulk_disable(hdmi->nsupplies, hdmi->supplies);
+
 
drivers/gpu/drm/bridge/dw_hdmi.c +0 -0
 	hdmi->phy_enabled = false;
 
 }
@@ -1549,7 +1562,8 @@ static int dw_hdmi_register(struct drm_device *drm,

struct dw_hdmi *hdmi)>
int dw_hdmi_bind(struct device *dev, struct device *master,

(quoted diff) +0 -0
 		 void *data, struct drm_encoder *encoder,
 		 struct resource *iores, int irq,
Quoted 6 lines

drivers/gpu/drm/bridge/dw_hdmi.c static int dw_hdmi_register(struct drm_device *drm, struct dw_hdmi *hdmi) · line 1566

Quoted 3 lines
drivers/gpu/drm/bridge/dw_hdmi.c +2 -1
-		 const struct dw_hdmi_plat_data *plat_data)
+		 const struct dw_hdmi_plat_data *plat_data,
+		 struct regulator_bulk_data *supplies, int nsupplies)

I'm not sure I like this function sprouting so many parameters. Is there a good reason not to add this to struct dw_hdmi_plat_data?

Nope, moving this to platdata sound sensible and I'll give this a try :-)

Heiko

author maintainer
#7 lore raw

PATCH 3/3 ARM: dts: rockchip: add hdmi analog power supplies to rk3288 boards

In reply to Heiko Stuebner

Add the recently added hdmi power supplies to evb and firefly boards.

---
 arch/arm/boot/dts/rk3288-evb.dtsi     | 2 ++
 arch/arm/boot/dts/rk3288-firefly.dtsi | 2 ++
 2 files changed, 4 insertions(+)
arch/arm/boot/dts/rk3288-evb.dtsi +2 -0
index 5e895a5..edd45a0 100644
@@ -118,6 +118,8 @@
 };
 
 &hdmi {
+	avdd1v0-supply = <&vdd10_lcd>;
+	avdd1v8-supply = <&vcc18_lcd>;
 	ddc-i2c-bus = <&i2c5>;
 	status = "okay";
 };
arch/arm/boot/dts/rk3288-firefly.dtsi +2 -0
index e6f873a..09fcded 100644
@@ -180,6 +180,8 @@
 };
 
 &hdmi {
+	avdd1v0-supply = <&vdd10_lcd>;
+	avdd1v8-supply = <&vcc18_lcd>;
 	ddc-i2c-bus = <&i2c5>;
 	status = "okay";
 };
Signature · 7 lines
2.1.4


_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel
#8 lore raw
In reply to Heiko Stuebner

Am Dienstag, den 10.03.2015, 00:21 +0100 schrieb Heiko Stuebner:

Quoted 3 lines

At least the Rockchip variant of the dw_hdmi should control its supplying regulators. A cursory glance at the imx manual didn't any equivalent there, so I'm not sure if there are similar controllable regulators present.

On i.MX6 the HDMI_VP (1.1 V) and HDMI_VPH (2.5 V) are usually supplied by the internal LDO_SoC via VDD_SOC_CAP (also used for ARM cache, SATA, and PCIe) and the LDO_2P5 via VDDHIGH_CAP (also used for PLLs, MIPI, SATA, PCIe, USB, and LVDS), respectively.
While I haven't seen anyone ever do this, it should be possible to supply them from an external regulator.

regards
Philipp

#9 lore raw
In reply to Heiko Stuebner
Quoted 9 lines · Heiko Stuebner

At least the Rockchip variant of the dw_hdmi should control its supplying regulators. A cursory glance at the imx manual didn't any equivalent there, so I'm not sure if there are similar controllable regulators present.

Patch1 is only a small fix to keep {devm_}regulator_bulk_get quiet in the deferring case and could go directly to the regulator tree, if ok.

Patch3 is the addition of the supplies to the rk3288 boards and I would take it into my dts branch if patch2 gets deemed acceptable.

I have a problem with this approach.

Rather than trying to shove everything into the generic part of the driver, what we should be doing is ensuring that the generic part stays generic, and the specific implementation details end up in the appropriate place.

As Rockchip needs these external regulators, they should be in that part of the driver, and controlled appropriately from the encoder callbacks. The encoder has sufficient callbacks to be able to turn on/off regulators both before and after the bridge has been disabled/enabled.

When we see more implementations with regulators, then we can think about moving it into the core dw_hdmi driver code.

Signature · 6 lines
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html