[PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep

[PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep

[Russ Dill]

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.Dill@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

[PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep

[Russ Dill]

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.Dill@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

Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep

[Tony Lindgren]

* Russ Dill <Russ.Dill@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.Dill@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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep

[Tony Lindgren]

* Russ Dill <Russ.Dill@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.Dill@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 majordomo@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]

On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Russ Dill <Russ.Dill@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.Dill@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 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

Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep

[Russ Dill]

On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Russ Dill <Russ.Dill@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.Dill@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 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
--
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

Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep

[Tony Lindgren]

* Russ Dill <Russ.Dill@ti.com> [120509 15:53]:
> On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Russ Dill <Russ.Dill@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

Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep

[Tony Lindgren]

* Russ Dill <Russ.Dill@ti.com> [120509 15:53]:
> On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Russ Dill <Russ.Dill@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

Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep

[Tomi Valkeinen]

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

On Wed, 2012-05-09 at 16:37 -0700, Tony Lindgren wrote:
> * Russ Dill <Russ.Dill@ti.com> [120509 15:53]:
> > On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren <tony@atomide.com> wrote:
> > > * Russ Dill <Russ.Dill@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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep

[Tomi Valkeinen]

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

On Wed, 2012-05-09 at 16:37 -0700, Tony Lindgren wrote:
> * Russ Dill <Russ.Dill@ti.com> [120509 15:53]:
> > On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren <tony@atomide.com> wrote:
> > > * Russ Dill <Russ.Dill@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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [120509 23:56]:
> On Wed, 2012-05-09 at 16:37 -0700, Tony Lindgren wrote:
> > * Russ Dill <Russ.Dill@ti.com> [120509 15:53]:
> > > On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren <tony@atomide.com> wrote:
> > > > * Russ Dill <Russ.Dill@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

Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [120509 23:56]:
> On Wed, 2012-05-09 at 16:37 -0700, Tony Lindgren wrote:
> > * Russ Dill <Russ.Dill@ti.com> [120509 15:53]:
> > > On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren <tony@atomide.com> wrote:
> > > > * Russ Dill <Russ.Dill@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

Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep

[Tomi Valkeinen]

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

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.Dill@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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep

[Tomi Valkeinen]

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

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.Dill@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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]