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
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
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
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
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
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
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
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
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
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
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
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 |
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
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
>
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
40 matches
Mail list logo
