Hi Lee,
Am Freitag, den 30.10.2015, 18:21 + schrieb Lee Jones:
> > @@ -264,12 +266,32 @@ static int pwm_backlight_probe(struct platform_device
> > *pdev)
> > pb->enable_gpio = gpio_to_desc(data->enable_gpio);
> > }
> >
> > + phandle = of_find_property(pdev->dev.of_node, "p
On Thu, 29 Oct 2015, Philipp Zabel wrote:
> If the driver is probed from the device tree, and there is a phandle
> property set on it, and the enable GPIO is already configured as output,
> and the backlight is currently disabled, keep it disabled.
> If all these conditions are met, assume there w
If the driver is probed from the device tree, and there is a phandle
property set on it, and the enable GPIO is already configured as output,
and the backlight is currently disabled, keep it disabled.
If all these conditions are met, assume there will be some other driver
that can enable the backli
On Fri, 2015-10-16 at 10:31 +0200, Lucas Stach wrote:
> Am Freitag, den 16.10.2015, 09:37 +0800 schrieb YH Huang:
> > In order to match the panel power sequence, disable the enable_gpio
> > in the probe function. Also, reorder the code in the power_on and
> > power_off function to match the timing.
On Fri, 2015-10-16 at 10:36 +0200, Sascha Hauer wrote:
> On Fri, Oct 16, 2015 at 09:37:34AM +0800, YH Huang wrote:
> > In order to match the panel power sequence, disable the enable_gpio
> > in the probe function. Also, reorder the code in the power_on and
> > power_off function to match the timing
On Fri, 2015-10-16 at 10:42 +0800, kbuild test robot wrote:
> Hi YH,
>
> [auto build test ERROR on pwm/for-next -- if it's inappropriate base, please
> suggest rules for selecting the more suitable base]
>
> url:
> https://github.com/0day-ci/linux/commits/YH-Huang/pwm-backlight-fix-the-panel
On Fri, Oct 16, 2015 at 09:37:34AM +0800, YH Huang wrote:
> In order to match the panel power sequence, disable the enable_gpio
> in the probe function. Also, reorder the code in the power_on and
> power_off function to match the timing.
> @@ -241,8 +242,7 @@ static int pwm_backlight_probe(struct p
Am Freitag, den 16.10.2015, 09:37 +0800 schrieb YH Huang:
> In order to match the panel power sequence, disable the enable_gpio
> in the probe function. Also, reorder the code in the power_on and
> power_off function to match the timing.
>
You aren't specifying which panels power sequence you are
Hi YH,
[auto build test ERROR on pwm/for-next -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/YH-Huang/pwm-backlight-fix-the-panel-power-sequence/20151016-093957
config: i386-allmodconfig (attached as .co
In order to match the panel power sequence, disable the enable_gpio
in the probe function. Also, reorder the code in the power_on and
power_off function to match the timing.
Signed-off-by: YH Huang
---
drivers/video/backlight/pwm_bl.c | 15 +--
1 file changed, 9 insertions(+), 6 de
On Wed, 14 Oct 2015, YH Huang wrote:
> Hi all,
>
> If you have any suggestion, please let me know.
> Thanks.
Please don't do that.
If you think the patch has fallen through the gaps, please just RESEND
it, like [RESEND vX] $subject.
> On Wed, 2015-09-16 at 22:42 +0800, YH Huang wrote:
> > In o
Hi all,
If you have any suggestion, please let me know.
Thanks.
Regards,
YH Huang
On Wed, 2015-09-16 at 22:42 +0800, YH Huang wrote:
> In order to match the panel power sequence, disable the enable_gpio
> in the probe function. Also, reorder the code in the power_on and
> power_off function to m
In order to match the panel power sequence, disable the enable_gpio
in the probe function. Also, reorder the code in the power_on and
power_off function to match the timing.
Signed-off-by: YH Huang
---
drivers/video/backlight/pwm_bl.c | 15 +--
1 file changed, 9 insertions(+), 6 de
Hi,
Am Freitag, den 12.06.2015, 18:26 +0200 schrieb Philipp Zabel:
> If the driver is probed from the device tree, and there is a phandle
> property set on it, and the enable GPIO is already configured as output,
> and the backlight is currently disabled, keep it disabled.
> If all these condition
If the driver is probed from the device tree, and there is a phandle
property set on it, and the enable GPIO is already configured as output,
and the backlight is currently disabled, keep it disabled.
If all these conditions are met, assume there will be some other driver
that can enable the backli
On Wed, 20 Aug 2014, Lothar Waßmann wrote:
> commit 257462dbf3ed ("pwm-backlight: switch to gpiod interface")
> introduced a regression leading to acquiring a bogus GPIO-0 when
> configured from DT without an 'enable-gpios' property.
> The driver will happily accept the 0 initialized 'enable_gpio'
On Wed, Aug 20, 2014 at 08:38:36AM +0200, Lothar Waßmann wrote:
> commit 257462dbf3ed ("pwm-backlight: switch to gpiod interface")
> introduced a regression leading to acquiring a bogus GPIO-0 when
> configured from DT without an 'enable-gpios' property.
> The driver will happily accept the 0 initi
commit 257462dbf3ed ("pwm-backlight: switch to gpiod interface")
introduced a regression leading to acquiring a bogus GPIO-0 when
configured from DT without an 'enable-gpios' property.
The driver will happily accept the 0 initialized 'enable_gpio' member
of the struct platform_pwm_backlight_data as
Since 257462dbf3ed ("pwm-backlight: switch to gpiod interface")
enable_gpio is no longer set and remains 0 when probing from
device-tree. This is a valid gpio number. With no enable-gpios
specified in the device-tree this is used and probing fails
with:
pwm-backlight lcd-backlight.3: failed to req
On Wed, Jun 25, 2014 at 01:03:31PM +0100, Lee Jones wrote:
> On Wed, 25 Jun 2014, Thierry Reding wrote:
> > On Wed, Jun 25, 2014 at 10:54:47AM +0100, Lee Jones wrote:
> > > > Make use of the new devm_gpiod_get_optional() to simplify the probe
> > > > code.
> > > >
> > > > Signed-off-by: Alexandre
On Wed, 25 Jun 2014, Thierry Reding wrote:
> On Wed, Jun 25, 2014 at 10:54:47AM +0100, Lee Jones wrote:
> > > Make use of the new devm_gpiod_get_optional() to simplify the probe
> > > code.
> > >
> > > Signed-off-by: Alexandre Courbot
> > > ---
> > > drivers/video/backlight/pwm_bl.c | 7 ++-
On Wed, Jun 25, 2014 at 10:54:47AM +0100, Lee Jones wrote:
> > Make use of the new devm_gpiod_get_optional() to simplify the probe
> > code.
> >
> > Signed-off-by: Alexandre Courbot
> > ---
> > drivers/video/backlight/pwm_bl.c | 7 ++-
> > 1 file changed, 2 insertions(+), 5 deletions(-)
>
>
> Make use of the new devm_gpiod_get_optional() to simplify the probe
> code.
>
> Signed-off-by: Alexandre Courbot
> ---
> drivers/video/backlight/pwm_bl.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
Looks good. Applied, thanks.
> diff --git a/drivers/video/backlight/pwm_bl
Make use of the new devm_gpiod_get_optional() to simplify the probe
code.
Signed-off-by: Alexandre Courbot
---
drivers/video/backlight/pwm_bl.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 38c
On Fri, 06 Jun 2014, Lothar Waßmann wrote:
> commit 257462dbf3ed pwm-backlight: switch to gpiod interface
> introduced a regression leading to acquiring a bogus GPIO-0 when
> configured from DT without an 'enable-gpios' property.
> The driver will happily accept the 0 initialized 'enable_gpio' mem
commit 257462dbf3ed pwm-backlight: switch to gpiod interface
introduced a regression leading to acquiring a bogus GPIO-0 when
configured from DT without an 'enable-gpios' property.
The driver will happily accept the 0 initialized 'enable_gpio' member
of the struct platform_pwm_backlight_data as val
On Fri, Sep 27, 2013 at 06:35:31AM -0700, Mike Dunn wrote:
> On 09/26/2013 05:50 AM, Thierry Reding wrote:
> > On Thu, Sep 26, 2013 at 03:26:13PM +0300, Tomi Valkeinen wrote:
> >> On 26/09/13 15:02, Thierry Reding wrote:
> >>> On Thu, Sep 26, 2013 at 01:13:18PM +0300, Tomi Valkeinen wrote:
> O
On 09/26/2013 05:50 AM, Thierry Reding wrote:
> On Thu, Sep 26, 2013 at 03:26:13PM +0300, Tomi Valkeinen wrote:
>> On 26/09/13 15:02, Thierry Reding wrote:
>>> On Thu, Sep 26, 2013 at 01:13:18PM +0300, Tomi Valkeinen wrote:
On 11/09/13 14:40, Mike Dunn wrote:
> On 09/10/2013 10:21 AM, Thie
On 26/09/13 15:50, Thierry Reding wrote:
>> I thought the NAK was for the DT parts, not for the sequences as such. I
>> don't remember anyone shooting down the idea of defining power sequences
>> inside a driver.
>
> Yes, but the DT parts were the primary reason why they were written in
> the fir
On Thu, Sep 26, 2013 at 03:26:13PM +0300, Tomi Valkeinen wrote:
> On 26/09/13 15:02, Thierry Reding wrote:
> > On Thu, Sep 26, 2013 at 01:13:18PM +0300, Tomi Valkeinen wrote:
> >> On 11/09/13 14:40, Mike Dunn wrote:
> >>> On 09/10/2013 10:21 AM, Thierry Reding wrote:
> >>
> Do you have a real
On 26/09/13 15:02, Thierry Reding wrote:
> On Thu, Sep 26, 2013 at 01:13:18PM +0300, Tomi Valkeinen wrote:
>> On 11/09/13 14:40, Mike Dunn wrote:
>>> On 09/10/2013 10:21 AM, Thierry Reding wrote:
>>
Do you have a real setup that actually needs multiple GPIOs? Usually
such a setup requires
On Thu, Sep 26, 2013 at 01:13:18PM +0300, Tomi Valkeinen wrote:
> On 11/09/13 14:40, Mike Dunn wrote:
> > On 09/10/2013 10:21 AM, Thierry Reding wrote:
>
> >> Do you have a real setup that actually needs multiple GPIOs? Usually
> >> such a setup requires some kind of timing or other additional con
On 11/09/13 14:40, Mike Dunn wrote:
> On 09/10/2013 10:21 AM, Thierry Reding wrote:
>> Do you have a real setup that actually needs multiple GPIOs? Usually
>> such a setup requires some kind of timing or other additional constraint
>> which can't be represented by this simple binding.
>>
>> Lookin
On 09/19/2013 04:56 AM, Thierry Reding wrote:
> On Thu, Sep 12, 2013 at 11:35:52AM -0700, Mike Dunn wrote:
>> Currently the driver assumes that the values specified in the
>> brightness-levels
>> device tree property increase as they are parsed from left to right. But
>> boards
>> that invert th
On Thu, Sep 12, 2013 at 11:35:52AM -0700, Mike Dunn wrote:
> Currently the driver assumes that the values specified in the
> brightness-levels
> device tree property increase as they are parsed from left to right. But
> boards
> that invert the signal between the PWM output and the backlight wil
On 09/17/2013 02:36 AM, Sascha Hauer wrote:
> Hi Mike,
>
> On Thu, Sep 12, 2013 at 11:35:52AM -0700, Mike Dunn wrote:
>> Currently the driver assumes that the values specified in the
>> brightness-levels
>> device tree property increase as they are parsed from left to right. But
>> boards
>> th
Hi Mike,
On Thu, Sep 12, 2013 at 11:35:52AM -0700, Mike Dunn wrote:
> Currently the driver assumes that the values specified in the
> brightness-levels
> device tree property increase as they are parsed from left to right. But
> boards
> that invert the signal between the PWM output and the bac
Currently the driver assumes that the values specified in the brightness-levels
device tree property increase as they are parsed from left to right. But boards
that invert the signal between the PWM output and the backlight will need to
specify decreasing brightness-levels. This patch removes the
On 09/10/2013 10:21 AM, Thierry Reding wrote:
> On Tue, Sep 03, 2013 at 12:26:12PM -0700, Mike Dunn wrote:
>> This patch adds support for controlling an arbitrary number of gpios to the
>> pwm-backlight driver. This was left as a TODO when initial device tree
>> support
>> was added by Thierry a
On Tue, Sep 03, 2013 at 12:26:12PM -0700, Mike Dunn wrote:
> This patch adds support for controlling an arbitrary number of gpios to the
> pwm-backlight driver. This was left as a TODO when initial device tree
> support
> was added by Thierry a while back. This functionality replaces the callbac
This patch adds support for controlling an arbitrary number of gpios to the
pwm-backlight driver. This was left as a TODO when initial device tree support
was added by Thierry a while back. This functionality replaces the callbacks
that are passed in the platform data for non-DT cases. Users can
On Mon, Aug 12, 2013 at 03:04:17PM -0700, Andrew Bresticker wrote:
> Specifying each individual brightness value via the "brightness-levels"
> property can be a pain if we want to use a large continuous range of
> brightness values. Add the property "max-brightness", which can be
> given in place
On 08/12/2013 04:04 PM, Andrew Bresticker wrote:
> Specifying each individual brightness value via the "brightness-levels"
> property can be a pain if we want to use a large continuous range of
> brightness values. Add the property "max-brightness", which can be
> given in place of "brightness-lev
Specifying each individual brightness value via the "brightness-levels"
property can be a pain if we want to use a large continuous range of
brightness values. Add the property "max-brightness", which can be
given in place of "brightness-levels", that specifies that all values
between 0 and the gi
On Wed, Jan 30, 2013 at 03:19:15PM +0900, Alexandre Courbot wrote:
> According to include/linux/backlight.h, the fb_blank field is to be
> removed and blank status should preferably be set by setting the
> BL_CORE_FBBLANK bit of the state field. This patch ensures this
> condition is also taken int
According to include/linux/backlight.h, the fb_blank field is to be
removed and blank status should preferably be set by setting the
BL_CORE_FBBLANK bit of the state field. This patch ensures this
condition is also taken into account when updating the backlight state.
Signed-off-by: Alexandre Cour
Hi Linus,
On Nov 11, 2012, at 7:26 PM, Linus Walleij wrote:
> On Fri, Nov 9, 2012 at 9:06 AM, Thierry Reding
> wrote:
>> On Wed, Oct 31, 2012 at 05:57:27PM +0200, Pantelis Antoniou wrote:
>
>>> + pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
>>> + if (IS_ERR(pinctrl))
>>> +
On Fri, Nov 9, 2012 at 9:06 AM, Thierry Reding
wrote:
> On Wed, Oct 31, 2012 at 05:57:27PM +0200, Pantelis Antoniou wrote:
>> + pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
>> + if (IS_ERR(pinctrl))
>> + dev_warn(&pdev->dev, "unable to select pin group\n");
>> +
>
>
On Wed, Oct 31, 2012 at 05:57:27PM +0200, Pantelis Antoniou wrote:
> Enable pinctrl for pwm-backlight.
>
> Signed-off-by: Pantelis Antoniou
> ---
> drivers/video/backlight/pwm_bl.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/video/backlight/pwm_bl.c
> b/drivers/vide
The brightness curve assume that the first level always have a duty
cycle of 0% and the last level 100%. However it is desirable to allow
any kind of curve to handle low-active devices, or devices that need
to clamp the curve to some range.
To allow defining any kind of curve the brightness levels
On Tue, 6 Nov 2012 07:44:06 +0100
Thierry Reding wrote:
> > --- a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
> > +++ b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
> > @@ -14,6 +14,7 @@ Required properties:
> > Optional properties:
> >- pwm-nam
On Mon, Nov 05, 2012 at 04:49:01PM +0100, Alban Bedel wrote:
> Signed-off-by: Alban Bedel
> ---
> .../bindings/video/backlight/pwm-backlight.txt |1 +
> drivers/video/backlight/pwm_bl.c | 22 ++-
> include/linux/pwm_backlight.h |
Signed-off-by: Alban Bedel
---
.../bindings/video/backlight/pwm-backlight.txt |1 +
drivers/video/backlight/pwm_bl.c | 22 ++-
include/linux/pwm_backlight.h |1 +
3 files changed, 18 insertions(+), 6 deletions(-)
diff --git
a/
On Wed, Oct 31, 2012 at 05:57:27PM +0200, Pantelis Antoniou wrote:
[...]
> diff --git a/drivers/video/backlight/pwm_bl.c
> b/drivers/video/backlight/pwm_bl.c
[...]
> @@ -20,6 +20,8 @@
> #include
> #include
> #include
> +#include
> +#include
linux/err.h is already included earlier.
Thierr
Enable pinctrl for pwm-backlight.
Signed-off-by: Pantelis Antoniou
---
drivers/video/backlight/pwm_bl.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 0c91023..f3b6194 100644
--- a/drivers/video/backlight/pwm_b
On Thursday 20 September 2012 18:50:35 Thierry Reding wrote:
> Since the pwm-backlight driver is lacking a proper maintainer and is the
> heaviest user of the PWM framework I'm taking over maintenance.
>
> Signed-off-by: Thierry Reding
> Cc: Arun Murthy
> Cc: Matthew Garrett
> Cc: Robert Morell
> Signed-off-by: Thierry Reding
> Cc: Arun Murthy
> Cc: Matthew Garrett
> Cc: Robert Morell
> Cc: Dilan Lee
> Cc: Axel Lin
> Cc: Mark Brown
> Cc: Alexandre Courbot
> Cc: Sachin Kamat
> Cc: Andrew Morton
> ---
> Andrew: As previously discussed this patch makes me the new maintainer
> for t
On 20 September 2012 16:20, Thierry Reding
wrote:
> Since the pwm-backlight driver is lacking a proper maintainer and is the
> heaviest user of the PWM framework I'm taking over maintenance.
>
> Signed-off-by: Thierry Reding
> Cc: Arun Murthy
> Cc: Matthew Garrett
> Cc: Robert Morell
> Cc: Dil
On Thu, Sep 20, 2012 at 12:50 PM, Thierry Reding
wrote:
> Since the pwm-backlight driver is lacking a proper maintainer and is the
> heaviest user of the PWM framework I'm taking over maintenance.
>
> Signed-off-by: Thierry Reding
> Cc: Arun Murthy
> Cc: Matthew Garrett
> Cc: Robert Morell
>
Since the pwm-backlight driver is lacking a proper maintainer and is the
heaviest user of the PWM framework I'm taking over maintenance.
Signed-off-by: Thierry Reding
Cc: Arun Murthy
Cc: Matthew Garrett
Cc: Robert Morell
Cc: Dilan Lee
Cc: Axel Lin
Cc: Mark Brown
Cc: Alexandre Courbot
Cc: S
On 07/09/2012 02:19 PM, Jingoo Han wrote:
I couldn't agree with Stephen Warren more.
Could you support DT and non-DT case for backwards compatibility?
Both cases are handled in the new version I just sent. I hope all other
concerns have also been addressed properly. If I forgot something pleas
.org;
> linux-kernel@vger.kernel.org;
> linux-fb...@vger.kernel.org
> Subject: Re: [PATCH] pwm-backlight: add regulator and GPIO support
>
> On 07/05/2012 02:12 AM, Alex Courbot wrote:
> > On 07/05/2012 04:57 PM, Thierry Reding wrote:
> >> I agree. Non-DT platf
62 matches
Mail list logo
