* Re: [PATCH 1/1] backlight: lm3630a_bl: Fix incorrect variable type
From: Jingoo Han @ 2013-09-27 0:14 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1380196776-27909-1-git-send-email-sachin.kamat@linaro.org>
On Thursday, September 26, 2013 9:00 PM, Sachin Kamat wrote:
>
> 'lm3630a_read' returns a negative error code upon failure. This
> will never get detected by unsigned 'rval'. Make it signed.
Hi Sachin Kamat,
The same patch was already sent by Dan Carpenter two days ago.
Also, it was merged to mm tree by Andrew Morton with my Acked-by.
Thank you for caring. :-)
Best regards,
Jingoo Han
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> Cc: Daniel Jeong <gshark.jeong@gmail.com>
> ---
> drivers/video/backlight/lm3630a_bl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/backlight/lm3630a_bl.c b/drivers/video/backlight/lm3630a_bl.c
> index c63f918..65392f9 100644
> --- a/drivers/video/backlight/lm3630a_bl.c
> +++ b/drivers/video/backlight/lm3630a_bl.c
> @@ -105,7 +105,7 @@ static int lm3630a_chip_init(struct lm3630a_chip *pchip)
> /* interrupt handling */
> static void lm3630a_delayed_func(struct work_struct *work)
> {
> - unsigned int rval;
> + int rval;
> struct lm3630a_chip *pchip;
>
> pchip = container_of(work, struct lm3630a_chip, work.work);
> --
> 1.7.9.5
^ permalink raw reply
* Re: [PATCH 1/2] backlight: l4f00242t03: Remove redundant spi_set_drvdata
From: Jingoo Han @ 2013-09-27 0:08 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1379659133-18799-1-git-send-email-sachin.kamat@linaro.org>
On Thursday, September 26, 2013 5:48 PM, Tomi Valkeinen wrote:
> On 20/09/13 09:38, Sachin Kamat wrote:
> > Driver core sets driver data to NULL upon failure or remove.
> >
> > Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> > ---
> > drivers/video/backlight/l4f00242t03.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/video/backlight/l4f00242t03.c b/drivers/video/backlight/l4f00242t03.c
> > index a35a38c..59eebe0 100644
> > --- a/drivers/video/backlight/l4f00242t03.c
> > +++ b/drivers/video/backlight/l4f00242t03.c
> > @@ -244,7 +244,6 @@ static int l4f00242t03_remove(struct spi_device *spi)
> >
> > l4f00242t03_lcd_power_set(priv->ld, FB_BLANK_POWERDOWN);
> > lcd_device_unregister(priv->ld);
> > - spi_set_drvdata(spi, NULL);
> >
> > return 0;
> > }
> >
>
> Thanks, queuing this and the second patch for 3.13.
>
Hi Tomi Valkeinen,
Andrew Morton already merged these patches to mm-tree with my Acked-by.
So, you don't need to queue these patches.
Thank you for caring. :-)
Best regards,
Jingoo Han
^ permalink raw reply
* Re: [PATCH 00/51] DMA mask changes
From: Rafał Miłecki @ 2013-09-26 20:23 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: alsa-devel, b43-dev, devel@driverdev.osuosl.org, devicetree,
dri-devel, e1000-devel, linux-arm-kernel@lists.infradead.org,
linux-crypto, linux-doc, linux-fbdev, linux-ide, linux-media,
linux-mmc, linux-nvme, linux-omap, linux ppc dev,
linux-samsung-soc, Linux SCSI List, linux-tegra, linux-usb,
linux-wireless@vger.kernel.org, Network Development,
Solarflare linux maintainers <linux-ne>
In-Reply-To: <20130919212235.GD12758@n2100.arm.linux.org.uk>
2013/9/19 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> This email is only being sent to the mailing lists in question, not to
> anyone personally. The list of individuals is far to great to do that.
> I'm hoping no mailing lists reject the patches based on the number of
> recipients.
Huh, I think it was enough to send only 3 patches to the b43-dev@. Like:
[PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks
[PATCH 14/51] DMA-API: net: b43: (...)
[PATCH 15/51] DMA-API: net: b43legacy: (...)
;)
I believe Joe has some nice script for doing it that way. When fixing
some coding style / formatting, he sends only related patches to the
given ML.
--
Rafał
^ permalink raw reply
* Re: [PATCH v11 2/8] usb: phy: omap-usb2: use the new generic PHY framework
From: Greg KH @ 2013-09-26 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1377063973-22044-3-git-send-email-kishon@ti.com>
On Wed, Aug 21, 2013 at 11:16:07AM +0530, Kishon Vijay Abraham I wrote:
> Used the generic PHY framework API to create the PHY. Now the power off and
> power on are done in omap_usb_power_off and omap_usb_power_on respectively.
> The omap-usb2 driver is also moved to driver/phy.
>
> However using the old USB PHY library cannot be completely removed
> because OTG is intertwined with PHY and moving to the new framework
> will break OTG. Once we have a separate OTG state machine, we
> can get rid of the USB PHY library.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Acked-by: Felipe Balbi <balbi@ti.com>
> ---
> drivers/phy/Kconfig | 12 +++++++++
> drivers/phy/Makefile | 1 +
> drivers/{usb => }/phy/phy-omap-usb2.c | 45 ++++++++++++++++++++++++++++++---
> drivers/usb/phy/Kconfig | 10 --------
> drivers/usb/phy/Makefile | 1 -
> 5 files changed, 54 insertions(+), 15 deletions(-)
> rename drivers/{usb => }/phy/phy-omap-usb2.c (88%)
I tried to apply this to my USB branch, but it fails.
Kishon, you were going to refresh this patch series, right? Please do,
because as-is, I can't take it.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] video: mxsfb: Add missing break
From: Marek Vasut @ 2013-09-26 13:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <524429C0.2020907@ti.com>
Hi Tomi,
> On 26/09/13 14:13, Marek Vasut wrote:
> > Add missing break into the restore function.
> >
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > Cc: Fabio Estevam <fabio.estevam@freescale.com>
> > Cc: Shawn Guo <shawn.guo@linaro.org>
> > Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > ---
> >
> > drivers/video/mxsfb.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
> > index d250ed0..27197a8 100644
> > --- a/drivers/video/mxsfb.c
> > +++ b/drivers/video/mxsfb.c
> > @@ -620,6 +620,7 @@ static int mxsfb_restore_mode(struct mxsfb_info
> > *host)
> >
> > break;
> >
> > case 3:
> > bits_per_pixel = 32;
> >
> > + break;
> >
> > case 1:
> >
> > default:
> > return -EINVAL;
>
> Thanks, queued for 3.12 fixes.
Can you please also queue this for stable 3.10? It's broken there too.
Thanks!
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH v2] pwm-backlight: allow for non-increasing brightness levels
From: Thierry Reding @ 2013-09-26 12:59 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jingoo Han, Mike Dunn, Richard Purdie,
Jean-Christophe Plagniol-Villard, Grant Likely, Rob Herring,
linux-pwm-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Robert Jarzmik, Marek Vasut
In-Reply-To: <524423B6.4070609-l0cyMroinI0@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2809 bytes --]
On Thu, Sep 26, 2013 at 03:08:22PM +0300, Tomi Valkeinen wrote:
> On 26/09/13 14:51, Thierry Reding wrote:
> > On Thu, Sep 26, 2013 at 01:03:06PM +0300, Tomi Valkeinen wrote:
> > [...]
> >> But if you and Thierry think this version is good, I'll take it.
> >
> > That sounds like you want to take it through the fbdev tree. Jingoo is
> > listed (along with Richard, but he hasn't been responsive to email for
> > years) as maintainer for the backlight subsystem. Furthermore back at
>
> Ah, so they are. I just thought it falls under fbdev, as it's under
> drivers/video/ =).
>
> I don't have any particular "want" to take it through fbdev tree. But I
> can take it.
>
> > the time when I began working on the PWM subsystem, the backlight sub-
> > system was pretty much orphaned, and pwm-backlight was by far the
> > biggest user of the PWM subsystem. I adopted the driver at the time
> > because it needed to be updated for PWM subsystem changes.
> >
> > What's the plan going forward? Given the coupling between the PWM
> > subsystem and the pwm-backlight driver it might be useful to keep
> > maintaining it as part of the PWM subsystem. On the other hand, there's
> > some coupling between the driver and the backlight subsystem too.
>
> And backlight is coupled with fbdev... Which is something I don't like.
>
> > I have a couple of patches queued up for 3.13 that rework parts of the
> > driver, so it'd be good to know how you guys want to handle this.
>
> Well. I'm happy if somebody wants to maintain the backlight side. In
> fact, I'd be happy if somebody would start restructuring it totally,
> it's rather messy. The link with fbdev should be removed, and some
> backlight drivers are actually panel drivers. However, perhaps Common
> Display Framework is required until it can be fully cleaned.
>
> So... For the time being, I'm fine with merging pwm-backlight via any
> tree that works best. I'm presuming here that backlight framework and
> fbdev (for the parts that are relevant for backlight) are not really
> being changed, so there shouldn't be conflicts.
In that case I'll just take it through the PWM tree as I've done for the
past year. I have some other changes planned for the PWM framework for
the near future that'll create dependencies between the PWM tree and the
pwm-backlight driver, so keeping them in one tree will make it easier to
merge them.
Longer term it probably makes sense, as you say, for someone to take
over the backlight subsystem completely and give it the love it could
really use. If Jingoo can do that, it'd be great. Perhaps it'd be a good
idea to remove Richard as maintainer since he's obviously no longer
responding to emails. Keeping him Cc'ed on all patches is just
pointless.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] pwm-backlight: add support for device tree gpio control
From: Thierry Reding @ 2013-09-26 12:50 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Mike Dunn, Richard Purdie, Jingoo Han,
Jean-Christophe Plagniol-Villard, Grant Likely, Rob Herring,
linux-pwm, linux-fbdev, linux-kernel, devicetree, Robert Jarzmik,
Marek Vasut
In-Reply-To: <524427E5.50403@ti.com>
[-- Attachment #1: Type: text/plain, Size: 5799 bytes --]
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 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.
> >>>>
> >>>> Looking at the Palm Treo code it seems like the reason why multiple
> >>>> GPIOs are needed is because one is to enable the backlight, while the
> >>>> other is in fact used to enable the LCD panel.
> >>>
> >>>
> >>> There are actually four GPIOs involved! (There is an embarrasingly horrible
> >>> hack in arch/arm/mach-pxa/palmtreo.c that handles the others.) One is almost
> >>> certainly simply backlight power. The other three are probably LCD related.
> >>
> >> When you say "power", do you mean the gpio enables a regulator to feed
> >> power to the backlight? If so, wouldn't that be a regulator, not gpio,
> >> from the bl driver's point of view?
> >>
> >> Generally speaking, this same problem appears in many places, but for
> >> some reason especially in display. I'm a bit hesitant in adding "free
> >> form" gpio/regulator support for drivers, as, as Thierry pointed out,
> >> there are often timing requirements, or sometimes the gpios are
> >> inverted, or sometimes the gpio is, in fact, a reset gpio, where you'll
> >> assert the gpio for a short moment only.
> >
> > I sent out another series a few days ago that somewhat obsoletes this
> > patch. What it does is basically add a single enable GPIO that can be
> > used to turn the backlight on and off. In a separate patch, support is
> > added for a power regulator. The combination of both should be able to
> > cover the majority of use-cases.
>
> But Mike's case required 4 GPIOs? Or can that be reduced to one gpio and
> one regulator?
Well, at least for the backlight it only seemed to involve a single
GPIO. The other three were probably related to LCD and therefore not
really suitable for a backlight driver. Traditionally it has been that
the backlight driver handled these things as well (via the callbacks
installed by board setup code). While really they should be handled by a
separate driver (for the LCD).
> > That series doesn't handle any timing requirements, but again, for the
> > majority of the setups supported by a power supply and enable GPIO the
> > timing doesn't matter.
> >
> >> I haven't seen new versions for the power sequences framework (without
> >> DT support), I think it could help us here a bit by simplifying how we
> >> present the sequences inside the driver. But we still need multiple
> >> drivers or the same driver supporting multiple devices.
> >
> > I'm not sure if power sequences will be very helpful here. There was an
> > attempt to get those merged, but the patches were NAKed in the end. I'm
> > not aware of any work currently being done on them.
>
> 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 first place. Without DT we can just use the existing hooks to do the
sequencing. There is not much to be gained from power sequences.
> >> And I also think that the model where we have just one driver for, say,
> >> backlight may not be enough. There may be multiple hardware components,
> >> that used together will generate the backlight. And each component
> >> requires specific management.
> >
> > I'm not sure what other components you are talking about here. Can you
> > elaborate?
>
> I don't have any specific case in mind, and maybe these are quite rare.
> But there could be some kind of mix of muxes, regulators, gpios and
> whatnot that need to be managed in certain way to make backlight (or
> display) work.
>
> I'm making this up, so I'm not sure if this is sensible, but consider a
> board where there's a mux to select where a backlight gets its PWM
> input, and the mux is controlled via i2c. And maybe insert some kind of
> level shifter in between, enabled with a GPIO. And some third component,
> as this hypothetical board is a development board, and hardware people
> seem to love to make bizarre designs, that work in theory but the SW is
> almost impossible to design...
>
> So to enable the backlight, we might need to do multiple different
> things, depending on which components this particular board has.
> Especially for a mux controlled via i2c it would make sense to have a
> separate driver. Having just a single backlight driver might not be enough.
>
> Sometimes, or hopefully often, that kind of complexity can be hidden
> behind common frameworks. For example, enabling a gpio could result in
> the gpio driver enabling a regulator, sending i2c messages, or whatever.
> But I don't think that's possible in all cases.
>
> Anyway, this was really more of "thinking out loud" than any suggestion.
There is unfortunately always the next crazy setup that one can think
of. I personally prefer to support what we have (or at least the
majority of that) with something generic and tackle the more exotic
setups later on (or when they appear, as the case may be).
As things stand right now, there's no way to get the simplest panel
setup to work properly if you use DT. By adding both an enable GPIO and
a power supply regulator we can at least cover the sane use-cases with
some sane and pretty simple code.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] video: mxsfb: Add missing break
From: Tomi Valkeinen @ 2013-09-26 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1380194038-5148-1-git-send-email-marex@denx.de>
[-- Attachment #1: Type: text/plain, Size: 753 bytes --]
On 26/09/13 14:13, Marek Vasut wrote:
> Add missing break into the restore function.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Fabio Estevam <fabio.estevam@freescale.com>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/mxsfb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
> index d250ed0..27197a8 100644
> --- a/drivers/video/mxsfb.c
> +++ b/drivers/video/mxsfb.c
> @@ -620,6 +620,7 @@ static int mxsfb_restore_mode(struct mxsfb_info *host)
> break;
> case 3:
> bits_per_pixel = 32;
> + break;
> case 1:
> default:
> return -EINVAL;
>
Thanks, queued for 3.12 fixes.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] pwm-backlight: add support for device tree gpio control
From: Tomi Valkeinen @ 2013-09-26 12:26 UTC (permalink / raw)
To: Thierry Reding
Cc: Mike Dunn, Richard Purdie, Jingoo Han,
Jean-Christophe Plagniol-Villard, Grant Likely, Rob Herring,
linux-pwm-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Robert Jarzmik, Marek Vasut
In-Reply-To: <20130926120248.GB1680@ulmo>
[-- Attachment #1: Type: text/plain, Size: 4586 bytes --]
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 some kind of timing or other additional constraint
>>>> which can't be represented by this simple binding.
>>>>
>>>> Looking at the Palm Treo code it seems like the reason why multiple
>>>> GPIOs are needed is because one is to enable the backlight, while the
>>>> other is in fact used to enable the LCD panel.
>>>
>>>
>>> There are actually four GPIOs involved! (There is an embarrasingly horrible
>>> hack in arch/arm/mach-pxa/palmtreo.c that handles the others.) One is almost
>>> certainly simply backlight power. The other three are probably LCD related.
>>
>> When you say "power", do you mean the gpio enables a regulator to feed
>> power to the backlight? If so, wouldn't that be a regulator, not gpio,
>> from the bl driver's point of view?
>>
>> Generally speaking, this same problem appears in many places, but for
>> some reason especially in display. I'm a bit hesitant in adding "free
>> form" gpio/regulator support for drivers, as, as Thierry pointed out,
>> there are often timing requirements, or sometimes the gpios are
>> inverted, or sometimes the gpio is, in fact, a reset gpio, where you'll
>> assert the gpio for a short moment only.
>
> I sent out another series a few days ago that somewhat obsoletes this
> patch. What it does is basically add a single enable GPIO that can be
> used to turn the backlight on and off. In a separate patch, support is
> added for a power regulator. The combination of both should be able to
> cover the majority of use-cases.
But Mike's case required 4 GPIOs? Or can that be reduced to one gpio and
one regulator?
> That series doesn't handle any timing requirements, but again, for the
> majority of the setups supported by a power supply and enable GPIO the
> timing doesn't matter.
>
>> I haven't seen new versions for the power sequences framework (without
>> DT support), I think it could help us here a bit by simplifying how we
>> present the sequences inside the driver. But we still need multiple
>> drivers or the same driver supporting multiple devices.
>
> I'm not sure if power sequences will be very helpful here. There was an
> attempt to get those merged, but the patches were NAKed in the end. I'm
> not aware of any work currently being done on them.
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.
> But as I said above, the combination of an enable GPIO and power supply
> should be enough to get a lot of use-cases supported.
Yep.
>> And I also think that the model where we have just one driver for, say,
>> backlight may not be enough. There may be multiple hardware components,
>> that used together will generate the backlight. And each component
>> requires specific management.
>
> I'm not sure what other components you are talking about here. Can you
> elaborate?
I don't have any specific case in mind, and maybe these are quite rare.
But there could be some kind of mix of muxes, regulators, gpios and
whatnot that need to be managed in certain way to make backlight (or
display) work.
I'm making this up, so I'm not sure if this is sensible, but consider a
board where there's a mux to select where a backlight gets its PWM
input, and the mux is controlled via i2c. And maybe insert some kind of
level shifter in between, enabled with a GPIO. And some third component,
as this hypothetical board is a development board, and hardware people
seem to love to make bizarre designs, that work in theory but the SW is
almost impossible to design...
So to enable the backlight, we might need to do multiple different
things, depending on which components this particular board has.
Especially for a mux controlled via i2c it would make sense to have a
separate driver. Having just a single backlight driver might not be enough.
Sometimes, or hopefully often, that kind of complexity can be hidden
behind common frameworks. For example, enabling a gpio could result in
the gpio driver enabling a regulator, sending i2c messages, or whatever.
But I don't think that's possible in all cases.
Anyway, this was really more of "thinking out loud" than any suggestion.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH v2] pwm-backlight: allow for non-increasing brightness levels
From: Tomi Valkeinen @ 2013-09-26 12:08 UTC (permalink / raw)
To: Thierry Reding, Jingoo Han
Cc: Mike Dunn, Richard Purdie, Jean-Christophe Plagniol-Villard,
Grant Likely, Rob Herring, linux-pwm-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Robert Jarzmik, Marek Vasut
In-Reply-To: <20130926115108.GA1680@ulmo>
[-- Attachment #1: Type: text/plain, Size: 1995 bytes --]
On 26/09/13 14:51, Thierry Reding wrote:
> On Thu, Sep 26, 2013 at 01:03:06PM +0300, Tomi Valkeinen wrote:
> [...]
>> But if you and Thierry think this version is good, I'll take it.
>
> That sounds like you want to take it through the fbdev tree. Jingoo is
> listed (along with Richard, but he hasn't been responsive to email for
> years) as maintainer for the backlight subsystem. Furthermore back at
Ah, so they are. I just thought it falls under fbdev, as it's under
drivers/video/ =).
I don't have any particular "want" to take it through fbdev tree. But I
can take it.
> the time when I began working on the PWM subsystem, the backlight sub-
> system was pretty much orphaned, and pwm-backlight was by far the
> biggest user of the PWM subsystem. I adopted the driver at the time
> because it needed to be updated for PWM subsystem changes.
>
> What's the plan going forward? Given the coupling between the PWM
> subsystem and the pwm-backlight driver it might be useful to keep
> maintaining it as part of the PWM subsystem. On the other hand, there's
> some coupling between the driver and the backlight subsystem too.
And backlight is coupled with fbdev... Which is something I don't like.
> I have a couple of patches queued up for 3.13 that rework parts of the
> driver, so it'd be good to know how you guys want to handle this.
Well. I'm happy if somebody wants to maintain the backlight side. In
fact, I'd be happy if somebody would start restructuring it totally,
it's rather messy. The link with fbdev should be removed, and some
backlight drivers are actually panel drivers. However, perhaps Common
Display Framework is required until it can be fully cleaned.
So... For the time being, I'm fine with merging pwm-backlight via any
tree that works best. I'm presuming here that backlight framework and
fbdev (for the parts that are relevant for backlight) are not really
being changed, so there shouldn't be conflicts.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] pwm-backlight: add support for device tree gpio control
From: Thierry Reding @ 2013-09-26 12:02 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Mike Dunn, Richard Purdie, Jingoo Han,
Jean-Christophe Plagniol-Villard, Grant Likely, Rob Herring,
linux-pwm, linux-fbdev, linux-kernel, devicetree, Robert Jarzmik,
Marek Vasut
In-Reply-To: <524408BE.40402@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2894 bytes --]
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 constraint
> >> which can't be represented by this simple binding.
> >>
> >> Looking at the Palm Treo code it seems like the reason why multiple
> >> GPIOs are needed is because one is to enable the backlight, while the
> >> other is in fact used to enable the LCD panel.
> >
> >
> > There are actually four GPIOs involved! (There is an embarrasingly horrible
> > hack in arch/arm/mach-pxa/palmtreo.c that handles the others.) One is almost
> > certainly simply backlight power. The other three are probably LCD related.
>
> When you say "power", do you mean the gpio enables a regulator to feed
> power to the backlight? If so, wouldn't that be a regulator, not gpio,
> from the bl driver's point of view?
>
> Generally speaking, this same problem appears in many places, but for
> some reason especially in display. I'm a bit hesitant in adding "free
> form" gpio/regulator support for drivers, as, as Thierry pointed out,
> there are often timing requirements, or sometimes the gpios are
> inverted, or sometimes the gpio is, in fact, a reset gpio, where you'll
> assert the gpio for a short moment only.
I sent out another series a few days ago that somewhat obsoletes this
patch. What it does is basically add a single enable GPIO that can be
used to turn the backlight on and off. In a separate patch, support is
added for a power regulator. The combination of both should be able to
cover the majority of use-cases.
That series doesn't handle any timing requirements, but again, for the
majority of the setups supported by a power supply and enable GPIO the
timing doesn't matter.
> I haven't seen new versions for the power sequences framework (without
> DT support), I think it could help us here a bit by simplifying how we
> present the sequences inside the driver. But we still need multiple
> drivers or the same driver supporting multiple devices.
I'm not sure if power sequences will be very helpful here. There was an
attempt to get those merged, but the patches were NAKed in the end. I'm
not aware of any work currently being done on them.
But as I said above, the combination of an enable GPIO and power supply
should be enough to get a lot of use-cases supported.
> And I also think that the model where we have just one driver for, say,
> backlight may not be enough. There may be multiple hardware components,
> that used together will generate the backlight. And each component
> requires specific management.
I'm not sure what other components you are talking about here. Can you
elaborate?
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH 1/1] backlight: lm3630a_bl: Fix incorrect variable type
From: Sachin Kamat @ 2013-09-26 11:59 UTC (permalink / raw)
To: linux-fbdev
'lm3630a_read' returns a negative error code upon failure. This
will never get detected by unsigned 'rval'. Make it signed.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Daniel Jeong <gshark.jeong@gmail.com>
---
drivers/video/backlight/lm3630a_bl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/lm3630a_bl.c b/drivers/video/backlight/lm3630a_bl.c
index c63f918..65392f9 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -105,7 +105,7 @@ static int lm3630a_chip_init(struct lm3630a_chip *pchip)
/* interrupt handling */
static void lm3630a_delayed_func(struct work_struct *work)
{
- unsigned int rval;
+ int rval;
struct lm3630a_chip *pchip;
pchip = container_of(work, struct lm3630a_chip, work.work);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v2] pwm-backlight: allow for non-increasing brightness levels
From: Thierry Reding @ 2013-09-26 11:51 UTC (permalink / raw)
To: Tomi Valkeinen, Jingoo Han
Cc: Mike Dunn, Richard Purdie, Jean-Christophe Plagniol-Villard,
Grant Likely, Rob Herring, linux-pwm-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Robert Jarzmik, Marek Vasut
In-Reply-To: <5244065A.8010408-l0cyMroinI0@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]
On Thu, Sep 26, 2013 at 01:03:06PM +0300, Tomi Valkeinen wrote:
[...]
> But if you and Thierry think this version is good, I'll take it.
That sounds like you want to take it through the fbdev tree. Jingoo is
listed (along with Richard, but he hasn't been responsive to email for
years) as maintainer for the backlight subsystem. Furthermore back at
the time when I began working on the PWM subsystem, the backlight sub-
system was pretty much orphaned, and pwm-backlight was by far the
biggest user of the PWM subsystem. I adopted the driver at the time
because it needed to be updated for PWM subsystem changes.
What's the plan going forward? Given the coupling between the PWM
subsystem and the pwm-backlight driver it might be useful to keep
maintaining it as part of the PWM subsystem. On the other hand, there's
some coupling between the driver and the backlight subsystem too.
I have a couple of patches queued up for 3.13 that rework parts of the
driver, so it'd be good to know how you guys want to handle this.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 01/15] video: atmel_lcdfb: Remove redundant dev_set_drvdata
From: Sachin Kamat @ 2013-09-26 11:48 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1379658744-17113-2-git-send-email-sachin.kamat@linaro.org>
On 26 September 2013 16:05, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 20/09/13 09:32, Sachin Kamat wrote:
> I had to modify this one as follows. Are you fine with it?
Looks good to me. Thanks Tomi.
--
With warm regards,
Sachin
^ permalink raw reply
* [PATCH] video: mxsfb: Add missing break
From: Marek Vasut @ 2013-09-26 11:13 UTC (permalink / raw)
To: linux-arm-kernel
Add missing break into the restore function.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/mxsfb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index d250ed0..27197a8 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -620,6 +620,7 @@ static int mxsfb_restore_mode(struct mxsfb_info *host)
break;
case 3:
bits_per_pixel = 32;
+ break;
case 1:
default:
return -EINVAL;
--
1.8.4.rc3
^ permalink raw reply related
* Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()
From: Archit Taneja @ 2013-09-26 10:57 UTC (permalink / raw)
To: Russell King, alsa-devel, b43-dev, devel, devicetree, dri-devel,
e1000-devel, linux-arm-kernel, linux-crypto, linux-doc,
linux-fbdev, linux-ide, linux-media, linux-mmc, linux-nvme,
linux-omap, linuxppc-dev, linux-samsung-soc, linux-scsi,
linux-tegra, linux-usb, linux-wireless, netdev,
Solarflare linux maintainers, uclinux-dist-devel
Cc: Kukjin Kim, Joonyoung Shim, David Airlie, Seung-Woo Kim,
Rob Clark, Inki Dae, Kyungmin Park, Valkeinen, Tomi, Tejun Heo
In-Reply-To: <E1VMnNq-0007s4-HN@rmk-PC.arm.linux.org.uk>
Hi,
On Friday 20 September 2013 04:41 AM, Russell King wrote:
> The correct way for a driver to specify the coherent DMA mask is
> not to directly access the field in the struct device, but to use
> dma_set_coherent_mask(). Only arch and bus code should access this
> member directly.
>
> Convert all direct write accesses to using the correct API.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/ata/pata_ixp4xx_cf.c | 5 ++++-
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 6 +++++-
> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 5 +++--
> 3 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/ata/pata_ixp4xx_cf.c b/drivers/ata/pata_ixp4xx_cf.c
> index 1ec53f8..ddf470c 100644
> --- a/drivers/ata/pata_ixp4xx_cf.c
> +++ b/drivers/ata/pata_ixp4xx_cf.c
> @@ -144,6 +144,7 @@ static int ixp4xx_pata_probe(struct platform_device *pdev)
> struct ata_host *host;
> struct ata_port *ap;
> struct ixp4xx_pata_data *data = dev_get_platdata(&pdev->dev);
> + int ret;
>
> cs0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> cs1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> @@ -157,7 +158,9 @@ static int ixp4xx_pata_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> /* acquire resources and fill host */
> - pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> + ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
> + if (ret)
> + return ret;
>
> data->cs0 = devm_ioremap(&pdev->dev, cs0->start, 0x1000);
> data->cs1 = devm_ioremap(&pdev->dev, cs1->start, 0x1000);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index bb82ef7..81192d0 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -286,7 +286,11 @@ static struct drm_driver exynos_drm_driver = {
>
> static int exynos_drm_platform_probe(struct platform_device *pdev)
> {
> - pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> + int ret;
> +
> + ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
> + if (ret)
> + return ret;
>
> return drm_platform_init(&exynos_drm_driver, pdev);
> }
> diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> index acf6678..701c4c1 100644
> --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> @@ -664,8 +664,9 @@ static int omap_dmm_probe(struct platform_device *dev)
> }
>
> /* set dma mask for device */
> - /* NOTE: this is a workaround for the hwmod not initializing properly */
> - dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> + ret = dma_set_coherent_mask(&dev->dev, DMA_BIT_MASK(32));
> + if (ret)
> + goto fail;
Tested with omapdrm on omap4 panda es board.
Thanks,
Archit
^ permalink raw reply
* Re: [PATCH 01/15] video: atmel_lcdfb: Remove redundant dev_set_drvdata
From: Tomi Valkeinen @ 2013-09-26 10:35 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1379658744-17113-2-git-send-email-sachin.kamat@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 2407 bytes --]
On 20/09/13 09:32, Sachin Kamat wrote:
> Driver core sets driver data to NULL upon failure or remove.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> drivers/video/atmel_lcdfb.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> index 34e934d..70052e7 100644
> --- a/drivers/video/atmel_lcdfb.c
> +++ b/drivers/video/atmel_lcdfb.c
> @@ -1318,7 +1318,6 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
> return 0;
>
> reset_drvdata:
> - dev_set_drvdata(dev, NULL);
> fb_dealloc_cmap(&info->cmap);
> unregister_irqs:
> cancel_work_sync(&sinfo->task);
> @@ -1379,7 +1378,6 @@ static int __exit atmel_lcdfb_remove(struct platform_device *pdev)
> atmel_lcdfb_free_video_memory(sinfo);
> }
>
> - dev_set_drvdata(dev, NULL);
> framebuffer_release(info);
>
> return 0;
>
I had to modify this one as follows. Are you fine with it?
commit 8d84d1223dbbaceb5cbf25b597e48a59c36b8c91
Author: Sachin Kamat <sachin.kamat@linaro.org>
Date: Fri Sep 20 12:02:10 2013 +0530
video: atmel_lcdfb: Remove redundant dev_set_drvdata
Driver core sets driver data to NULL upon failure or remove.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index df05550..3f7d6dc 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -1089,7 +1089,7 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
ret = register_framebuffer(info);
if (ret < 0) {
dev_err(dev, "failed to register framebuffer device: %d\n", ret);
- goto reset_drvdata;
+ goto free_cmap;
}
/* add selected videomode to modelist */
@@ -1105,8 +1105,6 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
return 0;
-reset_drvdata:
- dev_set_drvdata(dev, NULL);
free_cmap:
fb_dealloc_cmap(&info->cmap);
unregister_irqs:
@@ -1167,7 +1165,6 @@ static int __exit atmel_lcdfb_remove(struct platform_device *pdev)
atmel_lcdfb_free_video_memory(sinfo);
}
- dev_set_drvdata(dev, NULL);
framebuffer_release(info);
return 0;
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply related
* Re: [PATCH 1/2] video: jz4740-fb: Fix LCD_CMD bit definitions
From: Tomi Valkeinen @ 2013-09-26 10:24 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1379844109-10513-1-git-send-email-lars@metafoo.de>
[-- Attachment #1: Type: text/plain, Size: 953 bytes --]
On 22/09/13 13:01, Lars-Peter Clausen wrote:
> Fix the bit offsets for the LCD_CMD definitions.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
> ---
> drivers/video/jz4740_fb.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/jz4740_fb.c b/drivers/video/jz4740_fb.c
> index 2c49112..23aa475 100644
> --- a/drivers/video/jz4740_fb.c
> +++ b/drivers/video/jz4740_fb.c
> @@ -99,9 +99,9 @@
> #define JZ_LCD_CTRL_BPP_15_16 0x4
> #define JZ_LCD_CTRL_BPP_18_24 0x5
>
> -#define JZ_LCD_CMD_SOF_IRQ BIT(15)
> -#define JZ_LCD_CMD_EOF_IRQ BIT(16)
> -#define JZ_LCD_CMD_ENABLE_PAL BIT(12)
> +#define JZ_LCD_CMD_SOF_IRQ BIT(31)
> +#define JZ_LCD_CMD_EOF_IRQ BIT(30)
> +#define JZ_LCD_CMD_ENABLE_PAL BIT(28)
>
> #define JZ_LCD_SYNC_MASK 0x3ff
>
>
Thanks, queuing this and the second patch for 3.13.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] OMAPDSS: Add missing dependency on backlight for DSI-CM panel drier
From: Tomi Valkeinen @ 2013-09-26 10:21 UTC (permalink / raw)
To: Mark Brown
Cc: Jean-Christophe Plagniol-Villard, linux-fbdev, linux-omap,
linaro-kernel
In-Reply-To: <20130926101247.GB19304@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 827 bytes --]
On 26/09/13 13:12, Mark Brown wrote:
> On Thu, Sep 26, 2013 at 11:36:26AM +0300, Tomi Valkeinen wrote:
>
>> I wish we could "select" instead of "depends on"...
>
> We probably could.
I'm not so sure.
If we select BACKLIGHT_CLASS_DEVICE, we could end up compiling
backlight.c without fbdev, and backlight.c uses fb's funcs.
The funny thing is, there is FB_BACKLIGHT, which seems to be designed to
be selectable (and is selected). That one depends on FB, but if I'm not
mistaken, that dependency does not do anything if FB_BACKLIGHT is selected.
FB_BACKLIGHT in turn selects both BACKLIGHT_LCD_SUPPORT and
BACKLIGHT_CLASS_DEVICE, neither of which seem to be designed to be
selectable.
I think that's a bit broken. Anyway, I guess it's better to "depend on"
here, to be on the safe side.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] pwm-backlight: add support for device tree gpio control
From: Tomi Valkeinen @ 2013-09-26 10:13 UTC (permalink / raw)
To: Mike Dunn, Thierry Reding
Cc: Richard Purdie, Jingoo Han, Jean-Christophe Plagniol-Villard,
Grant Likely, Rob Herring, linux-pwm-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Robert Jarzmik, Marek Vasut
In-Reply-To: <523056A6.5060000-kFrNdAxtuftBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1854 bytes --]
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.
>>
>> Looking at the Palm Treo code it seems like the reason why multiple
>> GPIOs are needed is because one is to enable the backlight, while the
>> other is in fact used to enable the LCD panel.
>
>
> There are actually four GPIOs involved! (There is an embarrasingly horrible
> hack in arch/arm/mach-pxa/palmtreo.c that handles the others.) One is almost
> certainly simply backlight power. The other three are probably LCD related.
When you say "power", do you mean the gpio enables a regulator to feed
power to the backlight? If so, wouldn't that be a regulator, not gpio,
from the bl driver's point of view?
Generally speaking, this same problem appears in many places, but for
some reason especially in display. I'm a bit hesitant in adding "free
form" gpio/regulator support for drivers, as, as Thierry pointed out,
there are often timing requirements, or sometimes the gpios are
inverted, or sometimes the gpio is, in fact, a reset gpio, where you'll
assert the gpio for a short moment only.
I haven't seen new versions for the power sequences framework (without
DT support), I think it could help us here a bit by simplifying how we
present the sequences inside the driver. But we still need multiple
drivers or the same driver supporting multiple devices.
And I also think that the model where we have just one driver for, say,
backlight may not be enough. There may be multiple hardware components,
that used together will generate the backlight. And each component
requires specific management.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] OMAPDSS: Add missing dependency on backlight for DSI-CM panel drier
From: Mark Brown @ 2013-09-26 10:12 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jean-Christophe Plagniol-Villard, linux-fbdev, linux-omap,
linaro-kernel
In-Reply-To: <5243F20A.9000707@ti.com>
[-- Attachment #1: Type: text/plain, Size: 139 bytes --]
On Thu, Sep 26, 2013 at 11:36:26AM +0300, Tomi Valkeinen wrote:
> I wish we could "select" instead of "depends on"...
We probably could.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] framebuffer: arkfb: Fix framebugger typo
From: Joe Perches @ 2013-09-26 10:10 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jean-Christophe Plagniol-Villard, linux-fbdev, linux-kernel
In-Reply-To: <524402A6.1040709@ti.com>
On Thu, 2013-09-26 at 12:47 +0300, Tomi Valkeinen wrote:
> On 20/09/13 04:53, Joe Perches wrote:
> > s/framebugger/framebuffer/
[]
> Thanks, queued for 3.13. Although I have to say I kinda like the sound
> of framebugger.
I wondered if I should even change it
because it _is_ kind of funny.
Maybe you should just leave it in.
^ permalink raw reply
* Re: [PATCH v2] pwm-backlight: allow for non-increasing brightness levels
From: Tomi Valkeinen @ 2013-09-26 10:03 UTC (permalink / raw)
To: Mike Dunn, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w
Cc: Richard Purdie, Jingoo Han, Jean-Christophe Plagniol-Villard,
Grant Likely, Rob Herring, linux-pwm-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Robert Jarzmik, Marek Vasut
In-Reply-To: <1379869196-19377-1-git-send-email-mikedunn-kFrNdAxtuftBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]
On 22/09/13 19:59, 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 will need to specify decreasing brightness-levels.
> This patch removes the assumption that the last element of the array is
> the maximum value, and instead searches the array for the maximum value
> and uses that in the duty cycle calculation.
>
> Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
> ---
> Changelog:
> v2:
> - commit message reworded; correct line wrap used
> - 'max_level' variable renamed to 'scale'
> - loop counter variable type changed to unsigned int
> - value held in scale changed from array index to actual maximum level
> - blank lines added around loop for readability
As you said in a previous mail, the code is rather confusing. And, at
least to me, "scale" sounds an odd name there, especially as it's then
assigned to "max" local var. But if you and Thierry think this version
is good, I'll take it.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [patch 1/2] backlight: lm3630: signedness bug in lm3630a_chip_init()
From: Dan Carpenter @ 2013-09-26 9:53 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20130925085451.GA6661@elgon.mountain>
On Thu, Sep 26, 2013 at 12:43:43PM +0300, Tomi Valkeinen wrote:
> On 25/09/13 11:54, Dan Carpenter wrote:
> > "rval" needs to be signed for the error handling to work.
> >
> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> >
> > diff --git a/drivers/video/backlight/lm3630a_bl.c b/drivers/video/backlight/lm3630a_bl.c
> > index c63f918..65392f9 100644
> > --- a/drivers/video/backlight/lm3630a_bl.c
> > +++ b/drivers/video/backlight/lm3630a_bl.c
> > @@ -105,7 +105,7 @@ static int lm3630a_chip_init(struct lm3630a_chip *pchip)
> > /* interrupt handling */
> > static void lm3630a_delayed_func(struct work_struct *work)
> > {
> > - unsigned int rval;
> > + int rval;
> > struct lm3630a_chip *pchip;
> >
> > pchip = container_of(work, struct lm3630a_chip, work.work);
> >
>
> There's no drivers/video/backlight/lm3630a_bl.c in v3.12. Which kernel
> is this for?
>
The story is that this driver wasn't submitted to you or to linux-fbdev
but only to lkml.
Andrew Morton (the only person who reads LKML) picked it up in his tree.
Probably at some point he will prod you into taking it through your
tree. Anyway, I resent the patches so they're in -mm now.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 1/2] framebuffer: arkfb: Fix framebugger typo
From: Tomi Valkeinen @ 2013-09-26 9:47 UTC (permalink / raw)
To: Joe Perches; +Cc: Jean-Christophe Plagniol-Villard, linux-fbdev, linux-kernel
In-Reply-To: <c94f3e342947923f20d4c12932f382aa5200511b.1379641901.git.joe@perches.com>
[-- Attachment #1: Type: text/plain, Size: 803 bytes --]
On 20/09/13 04:53, Joe Perches wrote:
> s/framebugger/framebuffer/
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> drivers/video/arkfb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/arkfb.c b/drivers/video/arkfb.c
> index ee0f1a1..b13f3f2 100644
> --- a/drivers/video/arkfb.c
> +++ b/drivers/video/arkfb.c
> @@ -1048,7 +1048,7 @@ static int ark_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
>
> rc = register_framebuffer(info);
> if (rc < 0) {
> - dev_err(info->device, "cannot register framebugger\n");
> + dev_err(info->device, "cannot register framebuffer\n");
> goto err_reg_fb;
> }
>
>
Thanks, queued for 3.13. Although I have to say I kinda like the sound
of framebugger.
Tom
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox