The Beagleboard xM gpio used for TFP410 powerdown is connected through
an I2C attached chip which means setting the GPIO can sleep. Code that
calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
Signed-off-by: Russ Dill <redacted>
---
drivers/video/omap2/displays/panel-tfp410.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Tony Lindgren <tony@atomide.com> Date: 2012-05-09 22:14:48
* Russ Dill [off-list ref] [120509 15:12]:
The Beagleboard xM gpio used for TFP410 powerdown is connected through
an I2C attached chip which means setting the GPIO can sleep. Code that
calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
What's the error without this patch? Or just no display?
Just wondering if it's safe to merge Tomi's clean up series to
arm-soc tree..
Tony
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren [off-list ref] wrote:
* Russ Dill [off-list ref] [120509 15:12]:
quoted
The Beagleboard xM gpio used for TFP410 powerdown is connected through
an I2C attached chip which means setting the GPIO can sleep. Code that
calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
What's the error without this patch? Or just no display?
Just wondering if it's safe to merge Tomi's clean up series to
arm-soc tree..
The only platform that has a problem is Beagleboard xM, and that is
only after 'ARM: OMAP: Cleanup Beagleboard DVI reset gpio' is applied.
Since the context actually can sleep, the only consequence is a
WARN_ON statement.
So yes, it should be safe.
return;
if (gpio_is_valid(ddata->pd_gpio))
- gpio_set_value(ddata->pd_gpio, 0);
+ gpio_set_value_cansleep(ddata->pd_gpio, 0);
omapdss_dpi_display_disable(dssdev);
}
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Tony Lindgren <tony@atomide.com> Date: 2012-05-09 23:37:46
* Russ Dill [off-list ref] [120509 15:53]:
On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren [off-list ref] wrote:
quoted
* Russ Dill [off-list ref] [120509 15:12]:
quoted
The Beagleboard xM gpio used for TFP410 powerdown is connected through
an I2C attached chip which means setting the GPIO can sleep. Code that
calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
What's the error without this patch? Or just no display?
Just wondering if it's safe to merge Tomi's clean up series to
arm-soc tree..
The only platform that has a problem is Beagleboard xM, and that is
only after 'ARM: OMAP: Cleanup Beagleboard DVI reset gpio' is applied.
Since the context actually can sleep, the only consequence is a
WARN_ON statement.
So yes, it should be safe.
Well since I have not actually merged it with other branches yet, I'll wait
for Tomi to apply that and repull his for-l-o-3.5 branch.
Tony
From: Tomi Valkeinen <hidden> Date: 2012-05-10 06:53:10
On Wed, 2012-05-09 at 16:37 -0700, Tony Lindgren wrote:
* Russ Dill [off-list ref] [120509 15:53]:
quoted
On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren [off-list ref] wrote:
quoted
* Russ Dill [off-list ref] [120509 15:12]:
quoted
The Beagleboard xM gpio used for TFP410 powerdown is connected through
an I2C attached chip which means setting the GPIO can sleep. Code that
calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
What's the error without this patch? Or just no display?
Just wondering if it's safe to merge Tomi's clean up series to
arm-soc tree..
The only platform that has a problem is Beagleboard xM, and that is
only after 'ARM: OMAP: Cleanup Beagleboard DVI reset gpio' is applied.
Since the context actually can sleep, the only consequence is a
WARN_ON statement.
So yes, it should be safe.
Well since I have not actually merged it with other branches yet, I'll wait
for Tomi to apply that and repull his for-l-o-3.5 branch.
You can pull for-l-o-3.5 as it is now, there's no need to change it.
This _cansleep change is a separate dss specific change.
So to summarize:
Currently the powerdown GPIO for tfp410 is handled in the board files
(and called reset gpio), with gpio_set_value(). My cleanup series moves
this to the tfp410 driver.
BB-xM needs to use gpio_set_value_cansleep() in tfp410 to function
properly, so the tfp410 driver needs to be changed, as this patch does.
I will take this patch to the dss tree.
So it's safe to pull my cleanup series, but if I understood correctly,
applying Russ's "[PATCH v4] ARM: OMAP: Cleanup Beagleboard DVI reset
gpio" will cause WARN_ONs on BB-xM until this patch to tfp410 is also
applied.
But it doesn't sound too serious, so I think it's safe to apply the
"cleanup beagleboard dvi" patch also. The warning will go away when both
l-o and dss trees are pulled in the merge window.
Tomi
From: Tomi Valkeinen <hidden> Date: 2012-05-10 06:54:50
On Wed, 2012-05-09 at 15:08 -0700, Russ Dill wrote:
The Beagleboard xM gpio used for TFP410 powerdown is connected through
an I2C attached chip which means setting the GPIO can sleep. Code that
calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
Signed-off-by: Russ Dill <redacted>
---
drivers/video/omap2/displays/panel-tfp410.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Tony Lindgren <tony@atomide.com> Date: 2012-05-10 16:16:04
* Tomi Valkeinen [off-list ref] [120509 23:56]:
On Wed, 2012-05-09 at 16:37 -0700, Tony Lindgren wrote:
quoted
* Russ Dill [off-list ref] [120509 15:53]:
quoted
On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren [off-list ref] wrote:
quoted
* Russ Dill [off-list ref] [120509 15:12]:
quoted
The Beagleboard xM gpio used for TFP410 powerdown is connected through
an I2C attached chip which means setting the GPIO can sleep. Code that
calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
What's the error without this patch? Or just no display?
Just wondering if it's safe to merge Tomi's clean up series to
arm-soc tree..
The only platform that has a problem is Beagleboard xM, and that is
only after 'ARM: OMAP: Cleanup Beagleboard DVI reset gpio' is applied.
Since the context actually can sleep, the only consequence is a
WARN_ON statement.
So yes, it should be safe.
Well since I have not actually merged it with other branches yet, I'll wait
for Tomi to apply that and repull his for-l-o-3.5 branch.
You can pull for-l-o-3.5 as it is now, there's no need to change it.
This _cansleep change is a separate dss specific change.
So to summarize:
Currently the powerdown GPIO for tfp410 is handled in the board files
(and called reset gpio), with gpio_set_value(). My cleanup series moves
this to the tfp410 driver.
BB-xM needs to use gpio_set_value_cansleep() in tfp410 to function
properly, so the tfp410 driver needs to be changed, as this patch does.
I will take this patch to the dss tree.
So it's safe to pull my cleanup series, but if I understood correctly,
applying Russ's "[PATCH v4] ARM: OMAP: Cleanup Beagleboard DVI reset
gpio" will cause WARN_ONs on BB-xM until this patch to tfp410 is also
applied.
But it doesn't sound too serious, so I think it's safe to apply the
"cleanup beagleboard dvi" patch also. The warning will go away when both
l-o and dss trees are pulled in the merge window.
OK thanks will use for-l-o-3.5 as it is now then.
Tony