* [GIT PULL] fbdev fixes for 3.12
From: Tomi Valkeinen @ 2013-09-27 9:07 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-fbdev, linux-kernel, Jean-Christophe PLAGNIOL-VILLARD
[-- Attachment #1: Type: text/plain, Size: 1923 bytes --]
Hi Linus,
The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f:
Linux 3.12-rc1 (2013-09-16 16:17:51 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git tags/fbdev-fixes-3.12
for you to fetch changes up to 6d0bb818041a02be682abadb3ba35ff608f7d60a:
video: mxsfb: Add missing break (2013-09-26 15:33:23 +0300)
----------------------------------------------------------------
Small fbdev fixes for various fb drivers
----------------------------------------------------------------
Andrzej Hajda (1):
video: of: display_timing: correct display-timings node finding
Marek Vasut (1):
video: mxsfb: Add missing break
Mark Brown (1):
OMAPDSS: Add missing dependency on backlight for DSI-CM panel drier
Sathya Prakash M R (1):
OMAPDSS: Return right error during connector probe
Tomi Valkeinen (1):
OMAPDSS: DISPC: set irq_safe for runtime PM
Uwe Kleine-König (1):
video: mmp: drop needless devm cleanup
Wei Yongjun (2):
s3fb: fix error return code in s3_pci_probe()
neofb: fix error return code in neofb_probe()
drivers/video/mmp/hw/mmp_ctrl.c | 17 ++---------------
drivers/video/mxsfb.c | 1 +
drivers/video/neofb.c | 4 +++-
drivers/video/of_display_timing.c | 6 +++---
drivers/video/omap2/displays-new/Kconfig | 1 +
drivers/video/omap2/displays-new/connector-analog-tv.c | 2 +-
drivers/video/omap2/displays-new/connector-dvi.c | 2 +-
drivers/video/omap2/displays-new/connector-hdmi.c | 2 +-
drivers/video/omap2/dss/dispc.c | 1 +
drivers/video/s3fb.c | 9 +--------
10 files changed, 15 insertions(+), 30 deletions(-)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 00/51] DMA mask changes
From: Russell King - ARM Linux @ 2013-09-27 8:27 UTC (permalink / raw)
To: Rafał Miłecki
Cc: alsa-devel, linux-doc, linux-mmc, linux-fbdev, linux-nvme,
linux-ide, devel@driverdev.osuosl.org, linux-samsung-soc,
Linux SCSI List, e1000-devel, b43-dev, linux-media, devicetree,
dri-devel, linux-tegra, linux-omap,
linux-arm-kernel@lists.infradead.org,
Solarflare linux maintainers, Network Development, linux-usb,
linux-wireless@vger.kernel.org, linux-crypto, uclinux-dist-devel
In-Reply-To: <CACna6rxkpYzdD8_Jfi22vA2suUa3k-JM65_gCySQpp4crVCoPg@mail.gmail.com>
On Thu, Sep 26, 2013 at 10:23:08PM +0200, Rafał Miłecki wrote:
> 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.
If I did that, then the mailing lists would not get the first patch,
because almost none of the lists would be referred to by patch 1.
Moreover, people complain when they don't have access to the full
patch series - they assume patches are missing for some reason, and
they ask for the rest of the series.
^ permalink raw reply
* Re: [PATCH] fbcon: fix deadlock in fbcon_generic_blank()
From: Tomi Valkeinen @ 2013-09-27 7:15 UTC (permalink / raw)
To: John Tapsell
Cc: Jean-Christophe Plagniol-Villard, Peter Hurley, Dave Airlie,
linux-fbdev, linux-kernel
In-Reply-To: <CAHQ6N+q13YeM60S_QfRF8Bh+Vc_7yHhCMSABQ=GOtOe5V0EXow@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]
Hi,
On 18/09/13 01:29, John Tapsell wrote:
> Do not lock fb_info when calling sending the FB_EVENT_CONBLANK
> event.
>
> In fbmem.c, the semantics are that we acquire the lock_fb_info first,
> and then console_lock. However when fbcon.c fbcon_generic_blank() is
> called, the console lock could already be held. Locking fb_info can
> thus cause a deadlock.
So has this happened for you? Or is it just theoretical?
> fbmem.c sends the FB_EVENT_BLANK without locking lock_fb_info first, so
> this change introduces similar behaviour.
I don't think this is true. FB_EVENT_BLANK is sent in fb_blank(). That
one is called when FBIOBLANK ioctl is called, and it does lock_fb_info().
I'm not familiar with the console code, but removing a lock makes me
feel rather uneasy... But looking at the code, I can also see that
console_lock could already be held, so something here definitely looks
broken.
The only place using FB_EVENT_CONBLANK seems to be backlight, and if I'm
not mistaken, it has its own lock, and doesn't depend on the fb_info
being locked.
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-27 6:55 UTC (permalink / raw)
To: Thierry Reding
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: <20130926125020.GA2141@ulmo>
[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]
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 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.
Board hooks? Those cannot be used with DT boot.
But yes, the power sequences without DT (or platform data) parts cannot
handle with board-specific-things. I still think it'd be a very nice
thing to have inside the drivers. A single driver could more easily
handle bunch of somewhat similar devices, by specifying power sequences
in a table, one sequence for each device.
> 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.
Sure, no disagreement there.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH v11 2/8] usb: phy: omap-usb2: use the new generic PHY framework
From: Kishon Vijay Abraham I @ 2013-09-27 6:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130926185151.GA8689@kroah.com>
Hi Greg,
On Friday 27 September 2013 12:21 AM, Greg KH wrote:
> 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.
Just sent.
Thanks
Kishon
^ permalink raw reply
* linux-next: manual merge of the omap_dss2 tree with the fbdev tree
From: Stephen Rothwell @ 2013-09-27 5:49 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-next, linux-kernel, Sachin Kamat,
Jean-Christophe PLAGNIOL-VILLARD, Florian Tobias Schandinat,
linux-fbdev
In-Reply-To: <523FEE23.3010503@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2968 bytes --]
Hi Tomi,
Today's linux-next merge of the omap_dss2 tree got a conflict in
drivers/video/atmel_lcdfb.c between commit 5e8be022fb5b ("video:
atmel_lcdfb: add device tree suport") from the fbdev tree and commit
a36bf1925539 ("video: atmel_lcdfb: Remove redundant dev_set_drvdata")
from the omap_dss2 tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/video/atmel_lcdfb.c
index bf9c5d0,3f7d6dc..0000000
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@@ -1157,30 -934,19 +1157,30 @@@ static int __init atmel_lcdfb_probe(str
}
sinfo = info->par;
+ sinfo->pdev = pdev;
+ sinfo->info = info;
+
+ INIT_LIST_HEAD(&info->modelist);
- if (dev_get_platdata(dev)) {
- pdata_sinfo = dev_get_platdata(dev);
- sinfo->default_bpp = pdata_sinfo->default_bpp;
- sinfo->default_dmacon = pdata_sinfo->default_dmacon;
- sinfo->default_lcdcon2 = pdata_sinfo->default_lcdcon2;
- sinfo->default_monspecs = pdata_sinfo->default_monspecs;
- sinfo->atmel_lcdfb_power_control = pdata_sinfo->atmel_lcdfb_power_control;
- sinfo->guard_time = pdata_sinfo->guard_time;
- sinfo->smem_len = pdata_sinfo->smem_len;
- sinfo->lcdcon_is_backlight = pdata_sinfo->lcdcon_is_backlight;
- sinfo->lcdcon_pol_negative = pdata_sinfo->lcdcon_pol_negative;
- sinfo->lcd_wiring_mode = pdata_sinfo->lcd_wiring_mode;
+ if (pdev->dev.of_node) {
+ ret = atmel_lcdfb_of_init(sinfo);
+ if (ret)
+ goto free_info;
- } else if (dev->platform_data) {
++ } else if (dev_get_platdata(dev)) {
+ struct fb_monspecs *monspecs;
+ int i;
+
- pdata = dev->platform_data;
++ pdata = dev_get_platdata(dev);
+ monspecs = pdata->default_monspecs;
+ sinfo->pdata = *pdata;
+
+ for (i = 0; i < monspecs->modedb_len; i++)
+ fb_add_videomode(&monspecs->modedb[i], &info->modelist);
+
+ sinfo->config = atmel_lcdfb_get_config(pdev);
+
+ info->var.bits_per_pixel = pdata->default_bpp ? pdata->default_bpp : 16;
+ memcpy(&info->monspecs, pdata->default_monspecs, sizeof(info->monspecs));
} else {
dev_err(dev, "cannot get default configuration\n");
goto free_info;
@@@ -1305,11 -1089,16 +1305,11 @@@
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 */
- fb_var_to_videomode(&fbmode, &info->var);
- fb_add_videomode(&fbmode, &info->modelist);
-
/* Power up the LCDC screen */
- if (sinfo->atmel_lcdfb_power_control)
- sinfo->atmel_lcdfb_power_control(1);
+ atmel_lcdfb_power_control(sinfo, 1);
dev_info(dev, "fb%d: Atmel LCDC at 0x%08lx (mapped at %p), irq %d\n",
info->node, info->fix.mmio_start, sinfo->mmio, sinfo->irq_base);
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: [PATCH v3 0/5] ARM: vf610: Add DCU framebuffer driver for Vybrid VF610 platform
From: Wang Huan-B18965 @ 2013-09-27 5:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <523C1DAB.60808@ti.com>
PiA+PiBPbiAwMy8wOS8xMyAxMToyMSwgV2FuZyBIdWFuLUIxODk2NSB3cm90ZToNCj4gPj4+IEhp
LCBKZWFuLUNocmlzdG9waGUsIFRvbWksDQo+ID4+Pg0KPiA+Pj4gQ291bGQgeW91IHBsZWFzZSBo
ZWxwIHRvIHJldmlldyB0aGVzZSBwYXRjaGVzPyBUaGFua3MhDQo+ID4+DQo+ID4+IFRoZXJlIHNl
ZW1lZCB0byBiZSBzb21lIHN0cm9uZyBvcGluaW9ucyB0aGF0IHRoZXJlIHNob3VsZCBiZSBhIGRy
bQ0KPiA+PiBkcml2ZXIgZm9yIHRoaXMgaGFyZHdhcmUsIGluc3RlYWQgb2YgYW4gZmIgZHJpdmVy
LiBTbyBhcyB0aGVyZSBzZWVtcw0KPiA+PiB0byBiZSBkaXNhZ3JlZW1lbnRzIGFib3V0IHRoaXMs
IEknbGwgbGVhdmUgdGhpcyBzZXJpZXMgdG8NCj4gPj4gSmVhbi1DaHJpc3RvcGhlLCB3aG8ncyB0
aGUgcHJpbWFyeSBtYWludGFpbmVyLg0KPiA+IFtBbGlzb24gV2FuZ10NCj4gPg0KPiA+IFRoYW5r
cyBmb3IgVG9taSdzIGNvbW1lbnRzLg0KPiA+DQo+ID4gSSBhZ3JlZSB0aGF0IHdlIGNhbiBpbXBs
ZW1lbnQgdGhlIERSTSBkcml2ZXIgZm9yIHRoZSBEQ1UuIEFzIHRoZQ0KPiA+IGJhbmR3aWR0aCBs
aW1pdGF0aW9uLCBJIHN1Z2dlc3Qgd2UgdXNlIHRoZSBmYiBkcml2ZXIgZmlyc3RseS4gT24gdGhl
DQo+ID4gb3RoZXIgaGFuZCwgdGhlIGZiIGRyaXZlciBjYW4gbWVldCB0aGUgYXBwbGljYXRpb24g
cmVxdWlyZW1lbnQgYmFzZWQNCj4gPiBvbiB0aGlzIFNvQy4gV2UnbGwgdHJ5IHRvIHByb3ZpZGUg
dGhlIERSTSBkcml2ZXIgd2hlbiB0aGlzIElQDQo+ID4gaW50ZWdyYXRlZCBpbnRvIG90aGVyIFNv
Qy4NCj4gDQo+IElmIHlvdSBwbGFuIHRvIG1vdmUgdG8gRFJNIGRyaXZlciBhbnl3YXksIEkgd291
bGQgc3Ryb25nbHkgc3VnZ2VzdA0KPiBtZXJnaW5nIG9ubHkgdGhlIERSTSBkcml2ZXIuIElmIHdl
IG1lcmdlIHRoZSBmYiBkcml2ZXIsIGFuZCBhIGJpdCBsYXRlcg0KPiB0aGUgRFJNIGRyaXZlciBm
b3IgdGhlIHNhbWUgaGFyZHdhcmUsIHdlJ2xsIGhhdmUgdHdvIGRyaXZlcnMgb2Ygd2hpY2gNCj4g
dGhlIG90aGVyIGlzIGFscmVhZHkgZGVwcmVjYXRlZC4NCj4gDQpbQWxpc29uIFdhbmddIFdlIHdp
bGwgbm90IGhhdmUgYmFuZHdpZHRoIGFuZCBkZXZlbG9wIHRoZSBEUk0gZHJpdmVyIGluIHRoZSBu
ZWFyIGZ1dHVyZS4gT24gdGhlIG90aGVyIGhhbmQsIHRoaXMgSVAgaXMgbm90IGludGVncmF0ZWQg
aW50byBvdGhlciBoaWdoLWVuZCBTT0MuIFNvIHRoaXMgZmIgZHJpdmVyIHdpbGwgYmUgdXNlZCBm
b3Igc29tZSBraW5kIG9mIGxvbmcgdGltZSBmb3IgY3VycmVudCBTb0MuIFdlIGNhbiB0cnkgdG8g
cmVtb3ZlIHRoZSBmYiBkcml2ZXIgd2hlbiB3ZSBkZXZlbG9wZWQgdGhlIERSTSBkcml2ZXIgZm9y
IG90aGVyIFNvQy4NCg0KSmVhbi1DaHJpc3RvcGhlLCBEbyB5b3UgaGF2ZSBhbnkgY29tbWVudHM/
IFRoYW5rcy4NCg0KDQpCZXN0IFJlZ2FyZHMsDQpBbGlzb24gV2FuZw0K
^ permalink raw reply
* [PATCH] MAINTAINERS: remove Richard Purdie as backlight maintainer
From: Jingoo Han @ 2013-09-27 3:59 UTC (permalink / raw)
To: 'Andrew Morton'
Cc: linux-kernel, linux-fbdev, 'Richard Purdie',
'Jingoo Han', 'Thierry Reding',
'Tomi Valkeinen', 'Laurent Pinchart',
'Michael Hennerich', 'Milo Kim',
'Daniel Jeong'
Remove Richard Purdie as backlight subsystem maintainer, since he
is not responding for a few years.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 146ade4..398819c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1645,7 +1645,6 @@ S: Maintained
F: drivers/net/wireless/b43legacy/
BACKLIGHT CLASS/SUBSYSTEM
-M: Richard Purdie <rpurdie@rpsys.net>
M: Jingoo Han <jg1.han@samsung.com>
S: Maintained
F: drivers/video/backlight/
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] video: mxsfb: Add missing break
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-09-27 3:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201309261504.45088.marex@denx.de>
On 15:04 Thu 26 Sep , Marek Vasut wrote:
> 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.
this you have to do it by yourself by cc stable
Greg will take it not us
Best Regards,
J.
>
> Thanks!
>
> Best regards,
> Marek Vasut
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] pwm-backlight: allow for non-increasing brightness levels
From: Jingoo Han @ 2013-09-27 3:28 UTC (permalink / raw)
To: 'Tomi Valkeinen', 'Thierry Reding'
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', 'Laurent Pinchart',
'Jingoo Han'
In-Reply-To: <524423B6.4070609-l0cyMroinI0@public.gmane.org>
On Thursday, September 26, 2013 9:08 PM, 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.
+cc Laurent Pinchart,
Yes, right.
The backlight should be de-coupled with fbdev.
I remember that Laurent Pinchart was doing this patch.
Laurent Pinchart,
Would you let us know your plan about this? :-)
>
> > 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.
I think that some backlight drivers can be moved to 'Common Display Framework',
after 'Common Display Framework' is merged.
But, I am not sure, when it will be completed.
Best regards,
Jingoo Han
>
> 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
>
^ permalink raw reply
* Re: [PATCH 1/1] backlight: lm3630a_bl: Fix incorrect variable type
From: Sachin Kamat @ 2013-09-27 3:20 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1380196776-27909-1-git-send-email-sachin.kamat@linaro.org>
On 27 September 2013 05:44, Jingoo Han <jg1.han@samsung.com> wrote:
> On Thursday, September 26, 2013 9:00 PM, Sachin Kamat wrote:
>
> 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. :-)
Sounds great, Thanks for letting me know.
--
With warm regards,
Sachin
^ permalink raw reply
* Re: [PATCH v2] pwm-backlight: allow for non-increasing brightness levels
From: Jingoo Han @ 2013-09-27 3:19 UTC (permalink / raw)
To: 'Thierry Reding', 'Tomi Valkeinen'
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', 'Jingoo Han'
In-Reply-To: <20130926125953.GB2141@ulmo>
On Thursday, September 26, 2013 10:00 PM, Thierry Reding wrote:
> 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.
Yes, I think so.
I want you to take the patches for pwm-backlight through the PWM tree,
as you have done.
>
> 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.
OK, I will send the patch to remove Richard as maintainer.
I will make a git tree and mailing-list for the backlight subsystem later.
However, I am not certain when it will be done. :-(
Best regards,
Jingoo Han
^ permalink raw reply
* Re: [PATCH 31/51] DMA-API: media: omap3isp: use dma_coerce_mask_and_coherent()
From: Laurent Pinchart @ 2013-09-27 1:56 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
devicetree-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
e1000-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-ide-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Solarflare linux maintainers,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b,
Mauro Carvalho Chehab
In-Reply-To: <E1VMmCg-0007j1-Pi-eh5Bv4kxaXIANfyc6IWni62ZND6+EDdj@public.gmane.org>
Hi Russell,
Thank you for the patch.
On Thursday 19 September 2013 22:56:02 Russell King wrote:
> The code sequence:
> isp->raw_dmamask = DMA_BIT_MASK(32);
> isp->dev->dma_mask = &isp->raw_dmamask;
> isp->dev->coherent_dma_mask = DMA_BIT_MASK(32);
> bypasses the architectures check on the DMA mask. It can be replaced
> with dma_coerce_mask_and_coherent(), avoiding the direct initialization
> of this mask.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/media/platform/omap3isp/isp.c | 6 +++---
> drivers/media/platform/omap3isp/isp.h | 3 ---
> 2 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c index df3a0ec..1c36080 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -2182,9 +2182,9 @@ static int isp_probe(struct platform_device *pdev)
> isp->pdata = pdata;
> isp->ref_count = 0;
>
> - isp->raw_dmamask = DMA_BIT_MASK(32);
> - isp->dev->dma_mask = &isp->raw_dmamask;
> - isp->dev->coherent_dma_mask = DMA_BIT_MASK(32);
> + ret = dma_coerce_mask_and_coherent(isp->dev, DMA_BIT_MASK(32));
> + if (ret)
> + return ret;
>
> platform_set_drvdata(pdev, isp);
>
> diff --git a/drivers/media/platform/omap3isp/isp.h
> b/drivers/media/platform/omap3isp/isp.h index cd3eff4..ce65d3a 100644
> --- a/drivers/media/platform/omap3isp/isp.h
> +++ b/drivers/media/platform/omap3isp/isp.h
> @@ -152,7 +152,6 @@ struct isp_xclk {
> * @mmio_base_phys: Array with physical L4 bus addresses for ISP register
> * regions.
> * @mmio_size: Array with ISP register regions size in bytes.
> - * @raw_dmamask: Raw DMA mask
> * @stat_lock: Spinlock for handling statistics
> * @isp_mutex: Mutex for serializing requests to ISP.
> * @crashed: Bitmask of crashed entities (indexed by entity ID)
> @@ -190,8 +189,6 @@ struct isp_device {
> unsigned long mmio_base_phys[OMAP3_ISP_IOMEM_LAST];
> resource_size_t mmio_size[OMAP3_ISP_IOMEM_LAST];
>
> - u64 raw_dmamask;
> -
> /* ISP Obj */
> spinlock_t stat_lock; /* common lock for statistic drivers */
> struct mutex isp_mutex; /* For handling ref_count field */
--
Regards,
Laurent Pinchart
^ permalink raw reply
* 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
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