All of lore.kernel.org
 help / color / mirror / Atom feed
From: Raphael Assenat <raph@8d.com>
To: linux-omap@vger.kernel.org
Cc: tomi.valkeinen@ti.com, linux-fbdev@vger.kernel.org
Subject: [PATCH] OMAPDSS: Do not require a VDDS_DSI regulator on am35xx
Date: Thu, 19 Jul 2012 20:04:29 +0000	[thread overview]
Message-ID: <20120719200429.GD3850@renkinjitsu.usine.8d.com> (raw)

On our AM3505 based board, dpi.c complains that there is no VDSS_DSI regulator
and the framebuffer cannot be enabled. However, this check does not seem to
apply to AM3505/17 chips.

I am not the first facing this issue, see this thread from Nov. 2011:
http://marc.info/?l=linux-omap&m\x132147745930213&w=2

The string 'vdds_dsi' does appear once in the technical reference manual[1]
but there is no corresponding power pin on the package[2]. I failed to 
locate any signal that could be an equivalent. I am trying to obtain some
clarifications on TI's forum[3]...

In any case, I am currently running with the patch below. In order to keep
cpu_is_xx uses to a minimum, I check for am35xx once at init time and allow
dpi.vdds_dsi_reg to be NULL from then on, getting rid of all the other
cpu_is_omap34xx uses in the process.

Your comments would be appreciated. Please also consider for merging.

[1] http://www.ti.com/litv/pdf/sprugr0b
[2] http://www.ti.com/lit/gpn/am3505
[3] http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/416/t/202586.aspx

Signed-off-by: Raphael Assenat <raph@8d.com>

diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 8c2056c..d3b428d 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -180,11 +180,6 @@ int omapdss_dpi_display_enable(struct omap_dss_device *dssdev)
 {
 	int r;
 
-	if (cpu_is_omap34xx() && !dpi.vdds_dsi_reg) {
-		DSSERR("no VDSS_DSI regulator\n");
-		return -ENODEV;
-	}
-
 	if (dssdev->manager = NULL) {
 		DSSERR("failed to enable display: no manager\n");
 		return -ENODEV;
@@ -196,7 +191,7 @@ int omapdss_dpi_display_enable(struct omap_dss_device *dssdev)
 		goto err_start_dev;
 	}
 
-	if (cpu_is_omap34xx()) {
+	if (dpi.vdds_dsi_reg) {
 		r = regulator_enable(dpi.vdds_dsi_reg);
 		if (r)
 			goto err_reg_enable;
@@ -240,7 +235,7 @@ err_dsi_pll_init:
 err_get_dsi:
 	dispc_runtime_put();
 err_get_dispc:
-	if (cpu_is_omap34xx())
+	if (dpi.vdds_dsi_reg)
 		regulator_disable(dpi.vdds_dsi_reg);
 err_reg_enable:
 	omap_dss_stop_device(dssdev);
@@ -261,7 +256,7 @@ void omapdss_dpi_display_disable(struct omap_dss_device *dssdev)
 
 	dispc_runtime_put();
 
-	if (cpu_is_omap34xx())
+	if (dpi.vdds_dsi_reg)
 		regulator_disable(dpi.vdds_dsi_reg);
 
 	omap_dss_stop_device(dssdev);
@@ -343,7 +338,7 @@ static int __init dpi_init_display(struct omap_dss_device *dssdev)
 {
 	DSSDBG("init_display\n");
 
-	if (cpu_is_omap34xx() && dpi.vdds_dsi_reg = NULL) {
+	if (cpu_is_omap34xx() && dpi.vdds_dsi_reg = NULL && !soc_is_am35xx()) {
 		struct regulator *vdds_dsi;
 
 		vdds_dsi = dss_get_vdds_dsi();

WARNING: multiple messages have this Message-ID (diff)
From: Raphael Assenat <raph@8d.com>
To: linux-omap@vger.kernel.org
Cc: tomi.valkeinen@ti.com, linux-fbdev@vger.kernel.org
Subject: [PATCH] OMAPDSS: Do not require a VDDS_DSI regulator on am35xx
Date: Thu, 19 Jul 2012 16:04:29 -0400	[thread overview]
Message-ID: <20120719200429.GD3850@renkinjitsu.usine.8d.com> (raw)

On our AM3505 based board, dpi.c complains that there is no VDSS_DSI regulator
and the framebuffer cannot be enabled. However, this check does not seem to
apply to AM3505/17 chips.

I am not the first facing this issue, see this thread from Nov. 2011:
http://marc.info/?l=linux-omap&m=132147745930213&w=2

The string 'vdds_dsi' does appear once in the technical reference manual[1]
but there is no corresponding power pin on the package[2]. I failed to 
locate any signal that could be an equivalent. I am trying to obtain some
clarifications on TI's forum[3]...

In any case, I am currently running with the patch below. In order to keep
cpu_is_xx uses to a minimum, I check for am35xx once at init time and allow
dpi.vdds_dsi_reg to be NULL from then on, getting rid of all the other
cpu_is_omap34xx uses in the process.

Your comments would be appreciated. Please also consider for merging.

[1] http://www.ti.com/litv/pdf/sprugr0b
[2] http://www.ti.com/lit/gpn/am3505
[3] http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/416/t/202586.aspx

Signed-off-by: Raphael Assenat <raph@8d.com>

diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 8c2056c..d3b428d 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -180,11 +180,6 @@ int omapdss_dpi_display_enable(struct omap_dss_device *dssdev)
 {
 	int r;
 
-	if (cpu_is_omap34xx() && !dpi.vdds_dsi_reg) {
-		DSSERR("no VDSS_DSI regulator\n");
-		return -ENODEV;
-	}
-
 	if (dssdev->manager == NULL) {
 		DSSERR("failed to enable display: no manager\n");
 		return -ENODEV;
@@ -196,7 +191,7 @@ int omapdss_dpi_display_enable(struct omap_dss_device *dssdev)
 		goto err_start_dev;
 	}
 
-	if (cpu_is_omap34xx()) {
+	if (dpi.vdds_dsi_reg) {
 		r = regulator_enable(dpi.vdds_dsi_reg);
 		if (r)
 			goto err_reg_enable;
@@ -240,7 +235,7 @@ err_dsi_pll_init:
 err_get_dsi:
 	dispc_runtime_put();
 err_get_dispc:
-	if (cpu_is_omap34xx())
+	if (dpi.vdds_dsi_reg)
 		regulator_disable(dpi.vdds_dsi_reg);
 err_reg_enable:
 	omap_dss_stop_device(dssdev);
@@ -261,7 +256,7 @@ void omapdss_dpi_display_disable(struct omap_dss_device *dssdev)
 
 	dispc_runtime_put();
 
-	if (cpu_is_omap34xx())
+	if (dpi.vdds_dsi_reg)
 		regulator_disable(dpi.vdds_dsi_reg);
 
 	omap_dss_stop_device(dssdev);
@@ -343,7 +338,7 @@ static int __init dpi_init_display(struct omap_dss_device *dssdev)
 {
 	DSSDBG("init_display\n");
 
-	if (cpu_is_omap34xx() && dpi.vdds_dsi_reg == NULL) {
+	if (cpu_is_omap34xx() && dpi.vdds_dsi_reg == NULL && !soc_is_am35xx()) {
 		struct regulator *vdds_dsi;
 
 		vdds_dsi = dss_get_vdds_dsi();

             reply	other threads:[~2012-07-19 20:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-19 20:04 Raphael Assenat [this message]
2012-07-19 20:04 ` [PATCH] OMAPDSS: Do not require a VDDS_DSI regulator on am35xx Raphael Assenat
2012-07-31  8:45 ` Tomi Valkeinen
2012-07-31  8:45   ` Tomi Valkeinen
2012-07-31 20:46   ` Raphaël Assénat
2012-07-31 20:46     ` Raphaël Assénat

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120719200429.GD3850@renkinjitsu.usine.8d.com \
    --to=raph@8d.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=tomi.valkeinen@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.