Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep
On Wed, 2012-05-09 at 16:37 -0700, Tony Lindgren wrote: * Russ Dill russ.d...@ti.com [120509 15:53]: On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren t...@atomide.com wrote: * Russ Dill russ.d...@ti.com [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.. 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 signature.asc Description: This is a digitally signed message part
Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep
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 russ.d...@ti.com --- drivers/video/omap2/displays/panel-tfp410.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) I'll apply this to dss tree, thanks. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep
* Tomi Valkeinen tomi.valkei...@ti.com [120509 23:56]: On Wed, 2012-05-09 at 16:37 -0700, Tony Lindgren wrote: * Russ Dill russ.d...@ti.com [120509 15:53]: On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren t...@atomide.com wrote: * Russ Dill russ.d...@ti.com [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.. 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep
* Russ Dill russ.d...@ti.com [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 Signed-off-by: Russ Dill russ.d...@ti.com --- drivers/video/omap2/displays/panel-tfp410.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/omap2/displays/panel-tfp410.c b/drivers/video/omap2/displays/panel-tfp410.c index 52637fa..1266520 100644 --- a/drivers/video/omap2/displays/panel-tfp410.c +++ b/drivers/video/omap2/displays/panel-tfp410.c @@ -68,7 +68,7 @@ static int tfp410_power_on(struct omap_dss_device *dssdev) goto err0; if (gpio_is_valid(ddata-pd_gpio)) - gpio_set_value(ddata-pd_gpio, 1); + gpio_set_value_cansleep(ddata-pd_gpio, 1); return 0; err0: @@ -83,7 +83,7 @@ static void tfp410_power_off(struct omap_dss_device *dssdev) 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 majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep
On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren t...@atomide.com wrote: * Russ Dill russ.d...@ti.com [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.. 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. Signed-off-by: Russ Dill russ.d...@ti.com --- drivers/video/omap2/displays/panel-tfp410.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/omap2/displays/panel-tfp410.c b/drivers/video/omap2/displays/panel-tfp410.c index 52637fa..1266520 100644 --- a/drivers/video/omap2/displays/panel-tfp410.c +++ b/drivers/video/omap2/displays/panel-tfp410.c @@ -68,7 +68,7 @@ static int tfp410_power_on(struct omap_dss_device *dssdev) goto err0; if (gpio_is_valid(ddata-pd_gpio)) - gpio_set_value(ddata-pd_gpio, 1); + gpio_set_value_cansleep(ddata-pd_gpio, 1); return 0; err0: @@ -83,7 +83,7 @@ static void tfp410_power_off(struct omap_dss_device *dssdev) 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 majord...@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 majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep
* Russ Dill russ.d...@ti.com [120509 15:53]: On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren t...@atomide.com wrote: * Russ Dill russ.d...@ti.com [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.. 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
