* Re: [PATCH v2 1/3] video: clps711x: Add new C =?UTF-8?B?aXJydXMgTG9naWMgQ
From: Alexander Shiyan @ 2014-05-18 12:01 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1398327006.501536964@f133.i.mail.ru>
RnJpLCAxNiBNYXkgMjAxNCAxNTo1NjoyNiAtMDcwMCDQvtGCIE9sb2YgSm9oYW5zc29uIDxvbG9m
QGxpeG9tLm5ldD46Cj4gT24gVGh1LCBNYXkgMDgsIDIwMTQgYXQgMDE6MTQ6NDBQTSArMDMwMCwg
VG9taSBWYWxrZWluZW4gd3JvdGU6Cj4gPiBPbiAwOC8wNS8xNCAxMToyNywgQWxleGFuZGVyIFNo
aXlhbiB3cm90ZToKPiA+IAo+ID4gPj4+IEF0IHRoaXMgdGltZSB0aGUgZHJpdmVyIGhhcyB0aHJl
ZSB1c2VyLgo+ID4gPj4+IE9ubHkgb25lIG9mIHRoZW0gc2hvdWxkIHRoZW9yZXRpY2FsbHkgd29y
ay4KPiA+ID4+PiBjbHBzNzExeC1hdXRjcHUxMiBzaG91bGQgbm90IHdvcmsgaW4gdGhlIGFic2Vu
Y2Ugb2YgbWVtYmxvY2tfcmVzZXJ2ZSgpLgo+ID4gPj4+IGNscHM3MTF4LXA3MjB0IHNob3VsZCBu
b3Qgd29yayBkdWUgdG8gcGh5c2ljYWwgYWRkcmVzcyBsaW1pdGF0aW9uIGFzIGkKPiA+ID4+PiBu
b3RpY2VkIGJlZm9yZS4gQm9hcmQgbWVhbnMgdG8gdXNlIFNSQU0gaW5zdGVhZCBvZiBTRFJBTS4K
PiA+ID4+PiBPbmx5IGNscHM3MTF4LWVkYjcyMTEgc2hvdWxkIHdvcmsgZmluZSAoaW4gdGhlb3J5
KS4KPiA+ID4+PiBJcyB0aGlzIGEgZ29vZCByZWFzb24gdG8gcmVwbGFjZSB0aGUgZHJpdmVyPyBJ
IHRoaW5rIHllcy4KPiA+ID4+Cj4gPiA+PiBPaywgaWYgdGhlIHNpdHVhdGlvbiBpcyB0aGF0IGJh
ZCwgbWF5YmUgd2UgY2FuIGp1c3Qgc3dpdGNoIHRvIHRoZSBuZXcKPiA+ID4+IGRyaXZlci4gSGF2
ZSB5b3UgdmVyaWZpZWQgdGhhdCB0aG9zZSBib2FyZHMgZG8gbm90IHdvcmsgZnJvbSBhbnlvbmU/
IE9yCj4gPiA+PiBhc2tlZCBzb21lb25lIHRvIHRlc3QgdGhlIG5ldyBkcml2ZXIgd2l0aCB0aG9z
ZSBib2FyZHM/Cj4gPiA+IAo+ID4gPiBJJ20gbm90IGZhbWlsaWFyIHdpdGggb3RoZXIgdXNlcnMg
b2YgdGhpcyBwbGF0Zm9ybSAuCj4gPiA+IEkgYW0gZG8gbm90IGhhdmUgdGhlc2UgYm9hcmRzLCBh
bGwgdGhhdCBJIGhhdmUgd3JpdHRlbiBiZWZvcmUgdGhhdCBpdCdzIGp1c3QgYSB0aGVvcnkuCj4g
PiA+IEZpcm0gaW4gd2hpY2ggSSB3b3JrLCB1c2VzIGl0cyBvd24gYm9hcmQgd2l0aCBDTFBTNzEx
WCBDUFUgLCB0aGlzIGJvYXJkIGlzIHRoZQo+ID4gPiBvbmx5IHdheSB0byBjaGVjayBmb3IgY2hh
bmdlcyBvbiByZWFsIGhhcmR3YXJlIC4KPiA+IAo+ID4gT2suIFRoYXQgbWFrZXMgbWUgYSBiaXQg
bmVydm91cy4uLiBZb3UncmUgcmVtb3ZpbmcgYSBkcml2ZXIsIHdoaWNoIG1heQo+ID4gKG9yIG1h
eSBub3QpIGhhdmUgYmVlbiB3b3JraW5nIGZvciBvdGhlciB1c2Vycy4gQW5kIGFkZGluZyBhIG5l
dyBvbmUsCj4gPiB3aGljaCBtYXkgbm90IChvciBtYXkpIHdvcmsgZm9yIHRoZSBvdGhlciB1c2Vy
cy4KPiAKPiBLZWVwIHRoZSBvbGQgb25lIGFyb3VuZCB1bmRlciBhbm90aGVyIEtjb25maWcgbmFt
ZSwgbWFyayBpdCBCUk9LRU4sCj4gYW5kIGlmIG5vYm9keSBzcGVha3MgdXAgaW4gYSBjb3VwbGUg
b2YgcmVsZWFzZXMsIHJlbW92ZSBpdD8KCkkgbGlrZSB0aGlzIHZhcmlhbnQsIFRvbWkgYXJlIHlv
dSBhZ3JlZSB3aXRoIHRoaXM/CgotLS0KCg=
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tomi Valkeinen @ 2014-05-19 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140516180154.GG22031@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1699 bytes --]
On 16/05/14 21:01, Tony Lindgren wrote:
>> IMHO appending -omap-dss to a random device is an even bigger hack,
>> since its adding lots of bloat to the API. Let's assume there is
>> another OS using DT for ARM, but has no proper API for SPI
>> controllers and it introduces your hack to SPI devices. That would
>> mean each SPI device has -omap-spi appended (or -exynos-spi,
>> -foo-spi, ...). At least I would blame them for creating a huge
>> unmaintainable mess.
>
> I think you're misunderstanding. I do not want the naming to
> be Linux specific. The naming should naturally be as hardware
> specific as possible. In this case something like:
>
> compatible = "sharp,ls037v7dw01-dss", "sharp,ls037v7dw01";
>
> Or we should probably use:
>
> compatible = "sharp,ls037v7dw01-dpi", "sharp,ls037v7dw01";
>
> As dpi here reflects the hardware it's connected to. The dss
> is probably a Linux name.
Well, "dss" or "omapdss" is as much a hardware term as "dpi". And "dpi"
wouldn't really be a good extension, as what we want is an omapdss
driver specific compatible string. So I think "-omapdss" is the best
extension if that method is used.
But I don't think that's really the point. The point is that the panel's
compatible string should be "sharp,ls037v7dw01", nothing else.
All the variations of "sharp,ls037v7dw01-dss" are not correct, and are
only made for Linux SW reasons. So I would say they are Linux specific
SW names, even if the words themselves are also HW terms.
> Not use what you're after with the SPI example though, but sounds
> like that's something different.
I think Sebastien's example is just like the issue here.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tomi Valkeinen @ 2014-05-19 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140516213907.GL12881@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 3592 bytes --]
On 17/05/14 00:39, Tony Lindgren wrote:
>> AFAIK that remapping not needed at all. All that is already
>> available with the compatible flags.
>
> And alternatively we can also just use the sharp,ls037v7dw01
> in the panel driver(s). We can have the panels bail out in driver
> probe based on of_machine_is_compatible if nothing else is available.
I don't think that would work. Then we could have two panel drivers,
both loaded into the kernel and both having the same driver name and the
same compatible-string.
I'm not sure if it's even possible to load both of those drivers at the
same time, but if it was, and the first one would get probe() called for
a device, and the driver would return an error, I'm quite sure the
driver framework won't continue trying with the other driver, as the
first driver already matched for the device.
> Also, currently the remapping code also probably keeps prepending
> more and more omapdss,omapdss,omapdss,... on each kexec reboot? And
I don't think so. The code looks for, say, "ti,tfp410", and it wouldn't
match for "omapdss,ti,tfp410".
> it would be quite silly for each display controller to have to do
> their own remapping for shared panels?
It would, but wouldn't it be just as silly (well, even more silly in my
opinion) to have each display controller require driver specific
compatible strings for the panels used?
Until we have a common display framework, we need _some_ way to handle
this problem. Either we mess up the .dts files as you suggest, or we
have a driver internal hack.
> If we still still despite all these reasons decide to go with
> the remapping of the compatible strings, it should really be a
> Linux generic (or drivers/video generic function), not implemented
> for each display controller.
Well, I sure hope nobody else has to implement similar thing.
The reason why we have this code, and others do not, is mainly that
omapdss is maybe the first driver to implement the display components
properly, both in the SW side and in the .dts side, and that I wanted
omapdss to behave correctly even if there are other display
subsystems/panels compiled into the same kernel.
To open that up a bit, traditionally other display driver architectures
have not had drivers for each display "entity", like the panels. So you
would really just have the display subsystem in the .dts, and some raw
data there (panel timings) to get the panel running.
Now, with omapdss, we have separate drivers for each display entity.
Unfortunately those drivers are all tied to the omapdss driver's API
(and cannot thus be used on anything else than OMAP), as there's not yet
a driver framework for display entities (DRM is a bit different thing,
in my opinion).
Everything with that was simple with platform data, as the omap board
files created the panel devices, and there were no name clashing
problems with other platforms.
With DT that changed, as the bindings are common, and thus the
compatible strings are common also. But we still have omapdss specific
panel drivers. This is the reason we do the compatible-string conversion
hack. As soon as we can create platform agnostic panel drivers, we can
remove the hack.
And, I want to remind, it's an omapdss internal hack (after the patch I
sent), not visible to anyone else. The .dts files, the arch/arm files,
they are all not touched. So I don't quite understand why you see it as
such a bad thing. It's ugly, sure, but what harm does it do (except some
maintainer burden, for me)?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] video: delete unneeded call to platform_get_drvdata
From: Tomi Valkeinen @ 2014-05-19 13:04 UTC (permalink / raw)
To: Julia Lawall, Jean-Christophe Plagniol-Villard
Cc: kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1400308369-24375-2-git-send-email-Julia.Lawall@lip6.fr>
[-- Attachment #1: Type: text/plain, Size: 605 bytes --]
On 17/05/14 09:32, Julia Lawall wrote:
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Platform_get_drvdata is an accessor function, and has no purpose if its
> result is not used.
>
> The semantic patch that fixes this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> identifier x;
> type T;
> @@
> - T x = platform_get_drvdata(...);
> ... when != x
> // </smpl>
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>
> ---
> drivers/video/fbdev/bf54x-lq043fb.c | 2 --
> 1 file changed, 2 deletions(-)
Thanks, queued for 3.16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] backlight: gpio-backlight: Fix warning when the GPIO is on a I2C chip
From: Lee Jones @ 2014-05-19 13:50 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-kernel, linux-fbdev, linux-omap, Bryan Wu, Jingoo Han,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen
In-Reply-To: <20140509012454.GL2198@atomide.com>
> If the GPIO for the backlight is on an I2C chip, we currently
> get nasty warnings like this during the boot:
>
> WARNING: CPU: 0 PID: 6 at drivers/gpio/gpiolib.c:2364 gpiod_set_raw_value+0x40/0x4c()
> Modules linked in:
> CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.15.0-rc4-12393-gcde9f4e #400
> Workqueue: deferwq deferred_probe_work_func
> [<c0014cbc>] (unwind_backtrace) from [<c001191c>] (show_stack+0x10/0x14)
> [<c001191c>] (show_stack) from [<c0566ae0>] (dump_stack+0x80/0x9c)
> [<c0566ae0>] (dump_stack) from [<c003f61c>] (warn_slowpath_common+0x68/0x8c)
> [<c003f61c>] (warn_slowpath_common) from [<c003f65c>] (warn_slowpath_null+0x1c/0x24)
> [<c003f65c>] (warn_slowpath_null) from [<c02f7e10>] (gpiod_set_raw_value+0x40/0x4c)
> [<c02f7e10>] (gpiod_set_raw_value) from [<c0308fbc>] (gpio_backlight_update_status+0x4c/0x74)
> [<c0308fbc>] (gpio_backlight_update_status) from [<c030914c>] (gpio_backlight_probe+0x168/0x254)
> [<c030914c>] (gpio_backlight_probe) from [<c0378fa8>] (platform_drv_probe+0x18/0x48)
> [<c0378fa8>] (platform_drv_probe) from [<c0377c40>] (driver_probe_device+0x10c/0x238)
> [<c0377c40>] (driver_probe_device) from [<c0376330>] (bus_for_each_drv+0x44/0x8c)
> [<c0376330>] (bus_for_each_drv) from [<c0377afc>] (device_attach+0x74/0x8c)
> [<c0377afc>] (device_attach) from [<c03771c4>] (bus_probe_device+0x88/0xb0)
> [<c03771c4>] (bus_probe_device) from [<c03775c8>] (deferred_probe_work_func+0x64/0x94)
> [<c03775c8>] (deferred_probe_work_func) from [<c00572e8>] (process_one_work+0x1b4/0x4bc)
> [<c00572e8>] (process_one_work) from [<c00579d0>] (worker_thread+0x11c/0x398)
> [<c00579d0>] (worker_thread) from [<c005dfd8>] (kthread+0xc8/0xe4)
> [<c005dfd8>] (kthread) from [<c000e768>] (ret_from_fork+0x14/0x2c)
>
> Fix this by using gpio_set_value_cansleep() as suggested in
> drivers/gpio/gpiolib.c:2364. This is what the other backlight drivers
> are also doing.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
Applied, thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [alsa-devel] [PATCH 00/19] Rework OMAP4+ HDMI audio support
From: Jyri Sarha @ 2014-05-19 14:44 UTC (permalink / raw)
To: Joachim Eastwood
Cc: alsa-devel, linux-fbdev, devicetree, linux-omap, liam.r.girdwood,
detheridge, broonie, peter.ujfalusi, Tomi Valkeinen,
Benoit Cousson
In-Reply-To: <CAGhQ9VyxKWZ9KSWoYkhf8KeUJnMKJO=b0kG=upC7uojNLHVObw@mail.gmail.com>
On 05/17/2014 12:16 PM, Joachim Eastwood wrote:
> On 17 May 2014 10:51, Joachim Eastwood <manabian@gmail.com> wrote:
>> On 14 May 2014 18:25, Joachim Eastwood <manabian@gmail.com> wrote:
...
>>
>> I did some more testing over here.
>>
>> My HTPC (nVidia ION2 based) works good with speaker-test and all
>> channels are where they are suppose to be.
>>
>> On the OMAP4 board I tried doing: "while true; do speaker-test -c 4 -s
>> 1; done" and this had an interesting effect.
>> Most of the time FL (Front Left) is swapped with BL (Back Left) but
>> about every 10th time the sound comes out in the FL speaker... So
>> there something weird going on here. Same story for the right channel.
>>
>> I also noticed that HDMI doesn't always work on boot up, it sometimes fail with:
>> [ 193.985565] omapdss_hdmi 58006000.encoder: audio not supported
>> [ 193.985565] omapdss_hdmi 58006000.encoder: ASoC: can't open
>> interface 58006000.encoder: -19
>>
>> But after replugging the HDMI connector a couple of times it starts to work.
>>
That is weird I can not reproduce this problem. I rebooted my panda
several times and the audio device was always there. Could it be that
the connector is in DVI mode or something?
>> I'll see if I can try with an old TI OMAP4 kernel (3.4) and see how that works.
>
> On the 3.4 Variscite kernel:
> Linux version 3.4.0-1489-omap4 (uri@pluto) (gcc version 4.6.3
> (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #27 SMP PREEMPT Sun Apr 7 13:27:10
> IDT 2013
> git://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git +
> Variscite vendor patches
>
> Both speaker-test -c 4 and -c 8 works. All channels are where they are
> suppose to be.
>
> Hot plugging is broken, though. So the HDMI must be connected on boot,
> but that might be the Variscite board setup.
>
I checked the ubuntu branch implementation and found that it is quite
different in many places, but the one place that affects the i2s channel
mapping to HDMI looks exactly the same. So there must be a bug some
where else and there is no point trying to fix it by changing the
mapping (it would be impossible anyway). I'll compare the
implementations further when I have time.
Thanks for your testing. Now I at least now where the bug is not.
Best regards,
Jyri
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-19 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5379D35F.8040207@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140519 02:49]:
> On 17/05/14 00:39, Tony Lindgren wrote:
>
> >> AFAIK that remapping not needed at all. All that is already
> >> available with the compatible flags.
> >
> > And alternatively we can also just use the sharp,ls037v7dw01
> > in the panel driver(s). We can have the panels bail out in driver
> > probe based on of_machine_is_compatible if nothing else is available.
>
> I don't think that would work. Then we could have two panel drivers,
> both loaded into the kernel and both having the same driver name and the
> same compatible-string.
>
> I'm not sure if it's even possible to load both of those drivers at the
> same time, but if it was, and the first one would get probe() called for
> a device, and the driver would return an error, I'm quite sure the
> driver framework won't continue trying with the other driver, as the
> first driver already matched for the device.
No need to load multiple drivers at this point. That's why I'm saying
you can bail out on the undesired display controller probes using
of_machine_is_compatible test. It's not that uncommon for drivers to do:
$ git grep of_machine_is_compatible drivers/ | wc -l
116
> > Also, currently the remapping code also probably keeps prepending
> > more and more omapdss,omapdss,omapdss,... on each kexec reboot? And
>
> I don't think so. The code looks for, say, "ti,tfp410", and it wouldn't
> match for "omapdss,ti,tfp410".
OK
> > it would be quite silly for each display controller to have to do
> > their own remapping for shared panels?
>
> It would, but wouldn't it be just as silly (well, even more silly in my
> opinion) to have each display controller require driver specific
> compatible strings for the panels used?
Not driver specific, but hardware package specific. That's being done
all the time. For example, compatible strings like "nvidia,tegra124",
"ti,omap5" describe a package of an ARM core and various devices.
But by using of_machine_is_compatible in the display drivers, you
can use the right compatible flags from the start if you want to go
that way.
> Until we have a common display framework, we need _some_ way to handle
> this problem. Either we mess up the .dts files as you suggest, or we
> have a driver internal hack.
It seems that there's no need to mess up the .dts files here by
using the of_machine_is_compatible check in the drivers.
> > If we still still despite all these reasons decide to go with
> > the remapping of the compatible strings, it should really be a
> > Linux generic (or drivers/video generic function), not implemented
> > for each display controller.
>
> Well, I sure hope nobody else has to implement similar thing.
Suuuure.. I've heard that about 20 times before and guess what
happenened? Things never got fixed until some poor maintainer
had to start fixing it all over the place about three years later.
> The reason why we have this code, and others do not, is mainly that
> omapdss is maybe the first driver to implement the display components
> properly, both in the SW side and in the .dts side, and that I wanted
> omapdss to behave correctly even if there are other display
> subsystems/panels compiled into the same kernel.
>
> To open that up a bit, traditionally other display driver architectures
> have not had drivers for each display "entity", like the panels. So you
> would really just have the display subsystem in the .dts, and some raw
> data there (panel timings) to get the panel running.
Right, I believe that is the way to go, no doubt about it.
> Now, with omapdss, we have separate drivers for each display entity.
> Unfortunately those drivers are all tied to the omapdss driver's API
> (and cannot thus be used on anything else than OMAP), as there's not yet
> a driver framework for display entities (DRM is a bit different thing,
> in my opinion).
>
> Everything with that was simple with platform data, as the omap board
> files created the panel devices, and there were no name clashing
> problems with other platforms.
>
> With DT that changed, as the bindings are common, and thus the
> compatible strings are common also. But we still have omapdss specific
> panel drivers. This is the reason we do the compatible-string conversion
> hack. As soon as we can create platform agnostic panel drivers, we can
> remove the hack.
>
> And, I want to remind, it's an omapdss internal hack (after the patch I
> sent), not visible to anyone else. The .dts files, the arch/arm files,
> they are all not touched. So I don't quite understand why you see it as
> such a bad thing. It's ugly, sure, but what harm does it do (except some
> maintainer burden, for me)?
Here's a list of things that bothers me:
1. Searching through the dtb from a driver instead of relying on the
driver probe mechanism for the components in question. If the parsing
of the dtb needs to be done it should be done in a Linux generic way
from some framework instead.
2. Having to do this all early before we even have any debug console
available. We are trying to move everything to happen later on to avoid
all the issues related to initializing things early.
3. Having to maintain a database in kernel of display mappings separately
in addition to the .dts files.
4. Having this hack limited to device tree based booting while we are
trying to unify the functions for drivers to use to get their
resources.
5. Seeing the possibility of this spreading to other drivers.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-19 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5379CD24.6040508@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140519 02:22]:
> On 16/05/14 21:01, Tony Lindgren wrote:
>
> >> IMHO appending -omap-dss to a random device is an even bigger hack,
> >> since its adding lots of bloat to the API. Let's assume there is
> >> another OS using DT for ARM, but has no proper API for SPI
> >> controllers and it introduces your hack to SPI devices. That would
> >> mean each SPI device has -omap-spi appended (or -exynos-spi,
> >> -foo-spi, ...). At least I would blame them for creating a huge
> >> unmaintainable mess.
> >
> > I think you're misunderstanding. I do not want the naming to
> > be Linux specific. The naming should naturally be as hardware
> > specific as possible. In this case something like:
> >
> > compatible = "sharp,ls037v7dw01-dss", "sharp,ls037v7dw01";
> >
> > Or we should probably use:
> >
> > compatible = "sharp,ls037v7dw01-dpi", "sharp,ls037v7dw01";
> >
> > As dpi here reflects the hardware it's connected to. The dss
> > is probably a Linux name.
>
> Well, "dss" or "omapdss" is as much a hardware term as "dpi". And "dpi"
> wouldn't really be a good extension, as what we want is an omapdss
> driver specific compatible string. So I think "-omapdss" is the best
> extension if that method is used.
>
> But I don't think that's really the point. The point is that the panel's
> compatible string should be "sharp,ls037v7dw01", nothing else.
>
> All the variations of "sharp,ls037v7dw01-dss" are not correct, and are
> only made for Linux SW reasons. So I would say they are Linux specific
> SW names, even if the words themselves are also HW terms.
If you really want to use only "sharp,ls037v7dw01" as the compatible
string, then you can still do that and bail out from the undesired
drivers by using of_machine_is_compatible check.
In many cases however we do have multiple compatible strings that
describe how the device is wired. See drivers/tty/serial/of_serial.c
for example. It has "ns16550" but then it also has additional
"nvidia,tegra20-uart", "nxp,lpc3220-uart" and "ibm,qpace-nwp-serial".
> > Not use what you're after with the SPI example though, but sounds
> > like that's something different.
>
> I think Sebastien's example is just like the issue here.
Hmm is there some existing example in the kernel like that?
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Arnd Bergmann @ 2014-05-19 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140519155732.GA4849@atomide.com>
On Monday 19 May 2014 08:57:33 Tony Lindgren wrote:
> No need to load multiple drivers at this point. That's why I'm saying
> you can bail out on the undesired display controller probes using
> of_machine_is_compatible test. It's not that uncommon for drivers to do:
>
> $ git grep of_machine_is_compatible drivers/ | wc -l
> 116
I think this is widely seen as bad style, and most of the examples are
testing for Power Mac specific workarounds for stuff that Apple didn't
put in DT elsewhere.
Arnd
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tomi Valkeinen @ 2014-05-19 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140519155732.GA4849@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 5571 bytes --]
On 19/05/14 18:57, Tony Lindgren wrote:
>> I'm not sure if it's even possible to load both of those drivers at the
>> same time, but if it was, and the first one would get probe() called for
>> a device, and the driver would return an error, I'm quite sure the
>> driver framework won't continue trying with the other driver, as the
>> first driver already matched for the device.
>
> No need to load multiple drivers at this point. That's why I'm saying
> you can bail out on the undesired display controller probes using
> of_machine_is_compatible test. It's not that uncommon for drivers to do:
Hmm, I don't follow. If both, say, omap and exynos have a panel driver
for the same sharp panel, both need a driver for it (presuming exynos
has a proper display component driver system, which may not be true).
Both drivers would be loaded at boot time for the probe to be even to be
possible. Even if the other one bails out from a device probe using
of_machine_is_compatible, afaik the driver framework will stop probing
at that point, as that driver reports being compatible with the device
in question.
...
Ah, ok, now I see. I think you mean module init, not probe? For some
reason I was just thinking about the probe stage.
Maybe that would work. I need to test tomorrow.
>>> it would be quite silly for each display controller to have to do
>>> their own remapping for shared panels?
>>
>> It would, but wouldn't it be just as silly (well, even more silly in my
>> opinion) to have each display controller require driver specific
>> compatible strings for the panels used?
>
> Not driver specific, but hardware package specific. That's being done
> all the time. For example, compatible strings like "nvidia,tegra124",
> "ti,omap5" describe a package of an ARM core and various devices.
It feels to me rather wrong if I'd specify the compatible string for an
external piece of hardware based on the SoC it's connected to.
> But by using of_machine_is_compatible in the display drivers, you
> can use the right compatible flags from the start if you want to go
> that way.
Yes, with that we could have right compatible flags in the .dts.
>> Well, I sure hope nobody else has to implement similar thing.
>
> Suuuure.. I've heard that about 20 times before and guess what
> happenened? Things never got fixed until some poor maintainer
> had to start fixing it all over the place about three years later.
The poor maintainer here being me =). And it's still a case of
pick-your-poison. We need to hack around the issue, in some form or
another. So in any case the poor maintainer has to fix it at some point
in the future.
But all this is fixed when we have a common display framework. And
that's something that is really badly needed in some form or another,
the sooner the better.
So the "fix" here is not just some internal thing that could be left at
that and forgotten.
>> To open that up a bit, traditionally other display driver architectures
>> have not had drivers for each display "entity", like the panels. So you
>> would really just have the display subsystem in the .dts, and some raw
>> data there (panel timings) to get the panel running.
>
> Right, I believe that is the way to go, no doubt about it.
No, that's exactly _not_ the way to go =). We need proper drivers for
display components, instead of trying to avoid that and embed panel data
into the display controller's data.
> Here's a list of things that bothers me:
>
> 1. Searching through the dtb from a driver instead of relying on the
> driver probe mechanism for the components in question. If the parsing
> of the dtb needs to be done it should be done in a Linux generic way
> from some framework instead.
The reason I haven't made the conversion code available for others to
use is that there are no other users at the moment. And I hope there
will be no other user until we get the common display framework. If
there is, we'll need to move the code to a generic place.
> 2. Having to do this all early before we even have any debug console
> available. We are trying to move everything to happen later on to avoid
> all the issues related to initializing things early.
It worked fine for me when doing it as subsys_init level. Why do you say
it'd be early, before debug console?
All the drivers with converted compatible strings are normal drivers, so
afaik things work fine if we just convert the strings before the module
init level.
> 3. Having to maintain a database in kernel of display mappings separately
> in addition to the .dts files.
Yes, that's slightly annoying. Not really a big burden, though, as it's
quite rare to get a new encoder or panel driver.
> 4. Having this hack limited to device tree based booting while we are
> trying to unify the functions for drivers to use to get their
> resources.
I don't understand this one. With non-DT boot we don't have the issue at
all, there's no need for hacks.
> 5. Seeing the possibility of this spreading to other drivers.
Well, until we have a common display framework, one of the hacky options
we've discussed will spread to other drivers if they need to have their
own drivers for the same hardware devices.
Which is not nice, but not something we can escape. And using the
of_machine_is_compatible or having the compatible strings in .dts
appended with "dss" or such doesn't change that, it just changes which
hack may spread.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tomi Valkeinen @ 2014-05-19 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140519160447.GB4849@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]
On 19/05/14 19:04, Tony Lindgren wrote:
> In many cases however we do have multiple compatible strings that
> describe how the device is wired. See drivers/tty/serial/of_serial.c
> for example. It has "ns16550" but then it also has additional
> "nvidia,tegra20-uart", "nxp,lpc3220-uart" and "ibm,qpace-nwp-serial".
All those sound like SoC components. In that case it sounds fine to have
the device compatible contain the SoC name. We're talking here about
external, detachable devices.
>>> Not use what you're after with the SPI example though, but sounds
>>> like that's something different.
>>
>> I think Sebastien's example is just like the issue here.
>
> Hmm is there some existing example in the kernel like that?
No, Sebastien's example was just a hypothetical case. Here, using your
way of having SoC specific data in the .dts, we would have
"sharp,ls037v7dw01-omap-dss", and in Sebastien's example with a touch
sensor we'd have, say, "synaptics,xyz123-omap-spi".
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-19 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <537A540E.8070302@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140519 11:58]:
> On 19/05/14 18:57, Tony Lindgren wrote:
>
> >> I'm not sure if it's even possible to load both of those drivers at the
> >> same time, but if it was, and the first one would get probe() called for
> >> a device, and the driver would return an error, I'm quite sure the
> >> driver framework won't continue trying with the other driver, as the
> >> first driver already matched for the device.
> >
> > No need to load multiple drivers at this point. That's why I'm saying
> > you can bail out on the undesired display controller probes using
> > of_machine_is_compatible test. It's not that uncommon for drivers to do:
>
> Hmm, I don't follow. If both, say, omap and exynos have a panel driver
> for the same sharp panel, both need a driver for it (presuming exynos
> has a proper display component driver system, which may not be true).
>
> Both drivers would be loaded at boot time for the probe to be even to be
> possible. Even if the other one bails out from a device probe using
> of_machine_is_compatible, afaik the driver framework will stop probing
> at that point, as that driver reports being compatible with the device
> in question.
>
> ...
>
> Ah, ok, now I see. I think you mean module init, not probe? For some
> reason I was just thinking about the probe stage.
>
> Maybe that would work. I need to test tomorrow.
Ah right probe is too late as the match has been made already by then :)
> >>> it would be quite silly for each display controller to have to do
> >>> their own remapping for shared panels?
> >>
> >> It would, but wouldn't it be just as silly (well, even more silly in my
> >> opinion) to have each display controller require driver specific
> >> compatible strings for the panels used?
> >
> > Not driver specific, but hardware package specific. That's being done
> > all the time. For example, compatible strings like "nvidia,tegra124",
> > "ti,omap5" describe a package of an ARM core and various devices.
>
> It feels to me rather wrong if I'd specify the compatible string for an
> external piece of hardware based on the SoC it's connected to.
>
> > But by using of_machine_is_compatible in the display drivers, you
> > can use the right compatible flags from the start if you want to go
> > that way.
>
> Yes, with that we could have right compatible flags in the .dts.
>
> >> Well, I sure hope nobody else has to implement similar thing.
> >
> > Suuuure.. I've heard that about 20 times before and guess what
> > happenened? Things never got fixed until some poor maintainer
> > had to start fixing it all over the place about three years later.
>
> The poor maintainer here being me =). And it's still a case of
> pick-your-poison. We need to hack around the issue, in some form or
> another. So in any case the poor maintainer has to fix it at some point
> in the future.
Yeah I agree none of the options so far have been very nice.
> But all this is fixed when we have a common display framework. And
> that's something that is really badly needed in some form or another,
> the sooner the better.
>
> So the "fix" here is not just some internal thing that could be left at
> that and forgotten.
Yes..
> >> To open that up a bit, traditionally other display driver architectures
> >> have not had drivers for each display "entity", like the panels. So you
> >> would really just have the display subsystem in the .dts, and some raw
> >> data there (panel timings) to get the panel running.
> >
> > Right, I believe that is the way to go, no doubt about it.
>
> No, that's exactly _not_ the way to go =). We need proper drivers for
> display components, instead of trying to avoid that and embed panel data
> into the display controller's data.
Right, sorry I misread it :)
> > Here's a list of things that bothers me:
> >
> > 1. Searching through the dtb from a driver instead of relying on the
> > driver probe mechanism for the components in question. If the parsing
> > of the dtb needs to be done it should be done in a Linux generic way
> > from some framework instead.
>
> The reason I haven't made the conversion code available for others to
> use is that there are no other users at the moment. And I hope there
> will be no other user until we get the common display framework. If
> there is, we'll need to move the code to a generic place.
>
> > 2. Having to do this all early before we even have any debug console
> > available. We are trying to move everything to happen later on to avoid
> > all the issues related to initializing things early.
>
> It worked fine for me when doing it as subsys_init level. Why do you say
> it'd be early, before debug console?
The debug console should not be needed for debugging drivers.. Just
the serial console. This is because it's hard for users to produce
decent error information when the system does not boot if DEBUG_LL
and earlyprintk need to be enabled.
> All the drivers with converted compatible strings are normal drivers, so
> afaik things work fine if we just convert the strings before the module
> init level.
Yes that seems like the right place to do the workarounds.
> > 3. Having to maintain a database in kernel of display mappings separately
> > in addition to the .dts files.
>
> Yes, that's slightly annoying. Not really a big burden, though, as it's
> quite rare to get a new encoder or panel driver.
>
> > 4. Having this hack limited to device tree based booting while we are
> > trying to unify the functions for drivers to use to get their
> > resources.
>
> I don't understand this one. With non-DT boot we don't have the issue at
> all, there's no need for hacks.
Hmm can't we still have multiarch booting happening with the same
panel name being used by two different display drivers?
> > 5. Seeing the possibility of this spreading to other drivers.
>
> Well, until we have a common display framework, one of the hacky options
> we've discussed will spread to other drivers if they need to have their
> own drivers for the same hardware devices.
>
> Which is not nice, but not something we can escape. And using the
> of_machine_is_compatible or having the compatible strings in .dts
> appended with "dss" or such doesn't change that, it just changes which
> hack may spread.
Yes I agree they are all hacks, but your version seems to carry some
extra early init baggage with it as I noted above :)
Regards,
Tony
^ permalink raw reply
* [PATCHv2 resend 00/11] improve PWM lookup support without device tree
From: Alexandre Belloni @ 2014-05-19 20:42 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Originally sent on Apr 14th, note that this series is blocking another 16
patches series, I would like it to be taken in 3.16 if we can agree on this
implementation.
A patch set as suggested by Thierry to make lookup with the lookup table
instead of device tree behave more like when using device tree.
The first patch adds a period and a polarity member to the lookup table and use
those to set period and polarity.
Patch 2, 4 and 5 are making use of those new members from the board files.
Patch 3 removes useless code since setting the polarity is now handled by the
PWM core.
I couldn't decide on a good name for the extended PWM_LOOKUP macro and I believe
we won't have to add members to that structure soon so:
Patch 6 modifies the PWM_LOOKUP macro to also initialize period and polarity
and
Patch 7-9 are making use of the new PWM_LOOKUP macro in the board files
Patch 10 and 11 are making the leds-pwm and pwm_bl drivers get the period from
the PWM before using pwm_period_ns if it is not already set.
Patch 10 will obviously conflict with the series of Russell reworking the
leds-pwm probing. I can rebase if necessary
The final goal would be to get rid of .pwm_period_ns in leds-pwm and pwm_bl
after moving all the remaining users (still around 25) to pwm_lookup.
Changes in v2:
- correctly unlock the pwm_lookup_lock mutex before returning.
- don't change PWM_LOOKUP atomically
- remove tpu_pwm_platform_data and the associated header file
- make the leds-pwm and pwm_bl drivers get the period from the PWM
Alexandre Belloni (11):
pwm: add period and polarity to struct pwm_lookup
ARM: shmobile: Armadillo 800 EVA: initialize all struct pwm_lookup
members
pwm: renesas-tpu: remove useless struct tpu_pwm_platform_data
ARM: OMAP3: Beagle: initialize all the struct pwm_lookup members
ARM: pxa: hx4700: initialize all the struct pwm_lookup members
pwm: modify PWM_LOOKUP to initialize all struct pwm_lookup members
ARM: OMAP3: Beagle: use PWM_LOOKUP to initialize struct pwm_lookup
ARM: shmobile: Armadillo 800 EVA: use PWM_LOOKUP to initialize struct
pwm_lookup
ARM: pxa: hx4700: use PWM_LOOKUP to initialize struct pwm_lookup
leds: leds-pwm: retrieve configured pwm period
backlight: pwm_bl: retrieve configured pwm period
Documentation/pwm.txt | 3 ++-
arch/arm/mach-omap2/board-omap3beagle.c | 3 ++-
arch/arm/mach-pxa/hx4700.c | 3 ++-
arch/arm/mach-shmobile/board-armadillo800eva.c | 14 +++-----------
drivers/leds/leds-pwm.c | 5 ++++-
drivers/pwm/core.c | 8 +++++++-
drivers/pwm/pwm-renesas-tpu.c | 19 +++----------------
drivers/video/backlight/pwm_bl.c | 8 +++++---
include/linux/platform_data/pwm-renesas-tpu.h | 16 ----------------
include/linux/pwm.h | 6 +++++-
10 files changed, 33 insertions(+), 52 deletions(-)
delete mode 100644 include/linux/platform_data/pwm-renesas-tpu.h
--
1.9.1
^ permalink raw reply
* [PATCHv2 resend 01/11] pwm: add period and polarity to struct pwm_lookup
From: Alexandre Belloni @ 2014-05-19 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1400532162-29483-1-git-send-email-alexandre.belloni@free-electrons.com>
Adds a period and a polarity member to struct pwm_lookup so that when performing
a lookup using the lookup table instead of device tree, we are able to set the
period and the polarity accordingly like what is done in
of_pwm_xlate_with_flags.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
drivers/pwm/core.c | 8 +++++++-
include/linux/pwm.h | 2 ++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index a80471399c20..4b66bf09ee55 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -661,10 +661,16 @@ struct pwm_device *pwm_get(struct device *dev, const char *con_id)
}
}
+ mutex_unlock(&pwm_lookup_lock);
+
if (chip)
pwm = pwm_request_from_chip(chip, index, con_id ?: dev_id);
+ if (IS_ERR(pwm))
+ return pwm;
+
+ pwm_set_period(pwm, p->period);
+ pwm_set_polarity(pwm, p->polarity);
- mutex_unlock(&pwm_lookup_lock);
return pwm;
}
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 4717f54051cb..2f45e2fe5b93 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -274,6 +274,8 @@ struct pwm_lookup {
unsigned int index;
const char *dev_id;
const char *con_id;
+ unsigned int period;
+ enum pwm_polarity polarity;
};
#define PWM_LOOKUP(_provider, _index, _dev_id, _con_id) \
--
1.9.1
^ permalink raw reply related
* [PATCHv2 resend 02/11] ARM: shmobile: Armadillo 800 EVA: initialize all struct pwm_lookup members
From: Alexandre Belloni @ 2014-05-19 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1400532162-29483-1-git-send-email-alexandre.belloni@free-electrons.com>
Initializing all the struc pwm_lookup members allows to get rid of the struct
tpu_pwm_platform_data as the polarity initialization will be taken care of by
the PWM core.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Simon Horman <horms@verge.net.au>
---
arch/arm/mach-shmobile/board-armadillo800eva.c | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c b/arch/arm/mach-shmobile/board-armadillo800eva.c
index 2858f380beae..1bf61dad9a35 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -31,7 +31,7 @@
#include <linux/gpio_keys.h>
#include <linux/regulator/driver.h>
#include <linux/pinctrl/machine.h>
-#include <linux/platform_data/pwm-renesas-tpu.h>
+#include <linux/pwm.h>
#include <linux/pwm_backlight.h>
#include <linux/regulator/fixed.h>
#include <linux/regulator/gpio-regulator.h>
@@ -399,24 +399,22 @@ static struct resource pwm_resources[] = {
},
};
-static struct tpu_pwm_platform_data pwm_device_data = {
- .channels[2] = {
- .polarity = PWM_POLARITY_INVERSED,
- }
-};
-
static struct platform_device pwm_device = {
.name = "renesas-tpu-pwm",
.id = -1,
- .dev = {
- .platform_data = &pwm_device_data,
- },
.num_resources = ARRAY_SIZE(pwm_resources),
.resource = pwm_resources,
};
static struct pwm_lookup pwm_lookup[] = {
- PWM_LOOKUP("renesas-tpu-pwm", 2, "pwm-backlight.0", NULL),
+ {
+ .provider = "renesas-tpu-pwm",
+ .index = 2,
+ .dev_id = "pwm-backlight.0",
+ .con_id = NULL,
+ .period = 33333,
+ .polarity = PWM_POLARITY_INVERSED,
+ },
};
/* LCDC and backlight */
--
1.9.1
^ permalink raw reply related
* [PATCHv2 resend 03/11] pwm: renesas-tpu: remove useless struct tpu_pwm_platform_data
From: Alexandre Belloni @ 2014-05-19 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1400532162-29483-1-git-send-email-alexandre.belloni@free-electrons.com>
The struct is not used anymore and the polarity initialization will be taken
care of by the PWM core.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
drivers/pwm/pwm-renesas-tpu.c | 19 +++----------------
include/linux/platform_data/pwm-renesas-tpu.h | 16 ----------------
2 files changed, 3 insertions(+), 32 deletions(-)
delete mode 100644 include/linux/platform_data/pwm-renesas-tpu.h
diff --git a/drivers/pwm/pwm-renesas-tpu.c b/drivers/pwm/pwm-renesas-tpu.c
index aff6ba9b49e7..9dbcf82b3e6c 100644
--- a/drivers/pwm/pwm-renesas-tpu.c
+++ b/drivers/pwm/pwm-renesas-tpu.c
@@ -21,13 +21,14 @@
#include <linux/module.h>
#include <linux/mutex.h>
#include <linux/of.h>
-#include <linux/platform_data/pwm-renesas-tpu.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/pwm.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
+#define TPU_CHANNEL_MAX 4
+
#define TPU_TSTR 0x00 /* Timer start register (shared) */
#define TPU_TCRn 0x00 /* Timer control register */
@@ -87,7 +88,6 @@ struct tpu_pwm_device {
struct tpu_device {
struct platform_device *pdev;
- enum pwm_polarity polarities[TPU_CHANNEL_MAX];
struct pwm_chip chip;
spinlock_t lock;
@@ -229,7 +229,7 @@ static int tpu_pwm_request(struct pwm_chip *chip, struct pwm_device *_pwm)
pwm->tpu = tpu;
pwm->channel = _pwm->hwpwm;
- pwm->polarity = tpu->polarities[pwm->channel];
+ pwm->polarity = PWM_POLARITY_NORMAL;
pwm->prescaler = 0;
pwm->period = 0;
pwm->duty = 0;
@@ -388,16 +388,6 @@ static const struct pwm_ops tpu_pwm_ops = {
* Probe and remove
*/
-static void tpu_parse_pdata(struct tpu_device *tpu)
-{
- struct tpu_pwm_platform_data *pdata = tpu->pdev->dev.platform_data;
- unsigned int i;
-
- for (i = 0; i < ARRAY_SIZE(tpu->polarities); ++i)
- tpu->polarities[i] = pdata ? pdata->channels[i].polarity
- : PWM_POLARITY_NORMAL;
-}
-
static int tpu_probe(struct platform_device *pdev)
{
struct tpu_device *tpu;
@@ -413,9 +403,6 @@ static int tpu_probe(struct platform_device *pdev)
spin_lock_init(&tpu->lock);
tpu->pdev = pdev;
- /* Initialize device configuration from platform data. */
- tpu_parse_pdata(tpu);
-
/* Map memory, get clock and pin control. */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
tpu->base = devm_ioremap_resource(&pdev->dev, res);
diff --git a/include/linux/platform_data/pwm-renesas-tpu.h b/include/linux/platform_data/pwm-renesas-tpu.h
deleted file mode 100644
index a7220b10ddab..000000000000
--- a/include/linux/platform_data/pwm-renesas-tpu.h
+++ /dev/null
@@ -1,16 +0,0 @@
-#ifndef __PWM_RENESAS_TPU_H__
-#define __PWM_RENESAS_TPU_H__
-
-#include <linux/pwm.h>
-
-#define TPU_CHANNEL_MAX 4
-
-struct tpu_pwm_channel_data {
- enum pwm_polarity polarity;
-};
-
-struct tpu_pwm_platform_data {
- struct tpu_pwm_channel_data channels[TPU_CHANNEL_MAX];
-};
-
-#endif /* __PWM_RENESAS_TPU_H__ */
--
1.9.1
^ permalink raw reply related
* [PATCHv2 resend 04/11] ARM: OMAP3: Beagle: initialize all the struct pwm_lookup members
From: Alexandre Belloni @ 2014-05-19 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1400532162-29483-1-git-send-email-alexandre.belloni@free-electrons.com>
This will allow to get rid of the .pwm_period_ns member of struct led_pwm as the
period will be set by the PWM core.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
arch/arm/mach-omap2/board-omap3beagle.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index d6ed819ff15c..f27e1ec90b5e 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -61,7 +61,14 @@
static struct pwm_lookup pwm_lookup[] = {
/* LEDB -> PMU_STAT */
- PWM_LOOKUP("twl-pwmled", 1, "leds_pwm", "beagleboard::pmu_stat"),
+ {
+ .provider = "twl-pwmled",
+ .index = 1,
+ .dev_id = "leds_pwm",
+ .con_id = "beagleboard::pmu_stat",
+ .period = 7812500,
+ .polarity = PWM_POLARITY_NORMAL,
+ },
};
static struct led_pwm pwm_leds[] = {
--
1.9.1
^ permalink raw reply related
* [PATCHv2 resend 05/11] ARM: pxa: hx4700: initialize all the struct pwm_lookup members
From: Alexandre Belloni @ 2014-05-19 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1400532162-29483-1-git-send-email-alexandre.belloni@free-electrons.com>
This will allow to get rid of the .pwm_period_ns member of struct
platform_pwm_backlight_data as the period will be set by the PWM core.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
arch/arm/mach-pxa/hx4700.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-pxa/hx4700.c b/arch/arm/mach-pxa/hx4700.c
index a7c30eb0c8db..0788a1f171fe 100644
--- a/arch/arm/mach-pxa/hx4700.c
+++ b/arch/arm/mach-pxa/hx4700.c
@@ -574,7 +574,14 @@ static struct platform_device backlight = {
};
static struct pwm_lookup hx4700_pwm_lookup[] = {
- PWM_LOOKUP("pxa27x-pwm.1", 0, "pwm-backlight", NULL),
+ {
+ .provider = "pxa27x-pwm.1",
+ .index = 0,
+ .dev_id = "pwm-backlight",
+ .con_id = NULL,
+ .period = 30923,
+ .polarity = PWM_POLARITY_NORMAL,
+ },
};
/*
--
1.9.1
^ permalink raw reply related
* [PATCHv2 resend 06/11] pwm: modify PWM_LOOKUP to initialize all struct pwm_lookup members
From: Alexandre Belloni @ 2014-05-19 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1400532162-29483-1-git-send-email-alexandre.belloni@free-electrons.com>
Now that PWM_LOOKUP is not used anymore, modify it to initialize all the
members of struct pwm_lookup.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
Documentation/pwm.txt | 3 ++-
include/linux/pwm.h | 4 +++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt
index 93cb97974986..f38f99cda64f 100644
--- a/Documentation/pwm.txt
+++ b/Documentation/pwm.txt
@@ -19,7 +19,8 @@ should instead register a static mapping that can be used to match PWM
consumers to providers, as given in the following example:
static struct pwm_lookup board_pwm_lookup[] = {
- PWM_LOOKUP("tegra-pwm", 0, "pwm-backlight", NULL),
+ PWM_LOOKUP("tegra-pwm", 0, "pwm-backlight", NULL,
+ 50000, PWM_POLARITY_NORMAL),
};
static void __init board_init(void)
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 2f45e2fe5b93..e90628cac8fa 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -278,12 +278,14 @@ struct pwm_lookup {
enum pwm_polarity polarity;
};
-#define PWM_LOOKUP(_provider, _index, _dev_id, _con_id) \
+#define PWM_LOOKUP(_provider, _index, _dev_id, _con_id, _period, _polarity) \
{ \
.provider = _provider, \
.index = _index, \
.dev_id = _dev_id, \
.con_id = _con_id, \
+ .period = _period, \
+ .polarity = _polarity \
}
#if IS_ENABLED(CONFIG_PWM)
--
1.9.1
^ permalink raw reply related
* [PATCHv2 resend 07/11] ARM: OMAP3: Beagle: use PWM_LOOKUP to initialize struct pwm_lookup
From: Alexandre Belloni @ 2014-05-19 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1400532162-29483-1-git-send-email-alexandre.belloni@free-electrons.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
arch/arm/mach-omap2/board-omap3beagle.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index f27e1ec90b5e..54c135a5b4f7 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -61,14 +61,8 @@
static struct pwm_lookup pwm_lookup[] = {
/* LEDB -> PMU_STAT */
- {
- .provider = "twl-pwmled",
- .index = 1,
- .dev_id = "leds_pwm",
- .con_id = "beagleboard::pmu_stat",
- .period = 7812500,
- .polarity = PWM_POLARITY_NORMAL,
- },
+ PWM_LOOKUP("twl-pwmled", 1, "leds_pwm", "beagleboard::pmu_stat",
+ 7812500, PWM_POLARITY_NORMAL),
};
static struct led_pwm pwm_leds[] = {
--
1.9.1
^ permalink raw reply related
* [PATCHv2 resend 08/11] ARM: shmobile: Armadillo 800 EVA: use PWM_LOOKUP to initialize struct pwm_loo
From: Alexandre Belloni @ 2014-05-19 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1400532162-29483-1-git-send-email-alexandre.belloni@free-electrons.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Simon Horman <horms@verge.net.au>
---
arch/arm/mach-shmobile/board-armadillo800eva.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c b/arch/arm/mach-shmobile/board-armadillo800eva.c
index 1bf61dad9a35..ca82b1e2ebab 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -407,14 +407,8 @@ static struct platform_device pwm_device = {
};
static struct pwm_lookup pwm_lookup[] = {
- {
- .provider = "renesas-tpu-pwm",
- .index = 2,
- .dev_id = "pwm-backlight.0",
- .con_id = NULL,
- .period = 33333,
- .polarity = PWM_POLARITY_INVERSED,
- },
+ PWM_LOOKUP("renesas-tpu-pwm", 2, "pwm-backlight.0", NULL,
+ 33333, PWM_POLARITY_INVERSED),
};
/* LCDC and backlight */
--
1.9.1
^ permalink raw reply related
* [PATCHv2 resend 09/11] ARM: pxa: hx4700: use PWM_LOOKUP to initialize struct pwm_lookup
From: Alexandre Belloni @ 2014-05-19 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1400532162-29483-1-git-send-email-alexandre.belloni@free-electrons.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
arch/arm/mach-pxa/hx4700.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-pxa/hx4700.c b/arch/arm/mach-pxa/hx4700.c
index 0788a1f171fe..c66ad4edc5e3 100644
--- a/arch/arm/mach-pxa/hx4700.c
+++ b/arch/arm/mach-pxa/hx4700.c
@@ -574,14 +574,8 @@ static struct platform_device backlight = {
};
static struct pwm_lookup hx4700_pwm_lookup[] = {
- {
- .provider = "pxa27x-pwm.1",
- .index = 0,
- .dev_id = "pwm-backlight",
- .con_id = NULL,
- .period = 30923,
- .polarity = PWM_POLARITY_NORMAL,
- },
+ PWM_LOOKUP("pxa27x-pwm.1", 0, "pwm-backlight", NULL,
+ 30923, PWM_POLARITY_NORMAL),
};
/*
--
1.9.1
^ permalink raw reply related
* [PATCHv2 resend 10/11] leds: leds-pwm: retrieve configured pwm period
From: Alexandre Belloni @ 2014-05-19 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1400532162-29483-1-git-send-email-alexandre.belloni@free-electrons.com>
The PWM core is now able to initialize the PWM period. Use it and if it is not
configured, use the supplied pwm_period_ns.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
drivers/leds/leds-pwm.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index 7d0aaed1e23a..aa770ec1e892 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -181,7 +181,6 @@ static int led_pwm_probe(struct platform_device *pdev)
led_dat->cdev.name = cur_led->name;
led_dat->cdev.default_trigger = cur_led->default_trigger;
led_dat->active_low = cur_led->active_low;
- led_dat->period = cur_led->pwm_period_ns;
led_dat->cdev.brightness_set = led_pwm_set;
led_dat->cdev.brightness = LED_OFF;
led_dat->cdev.max_brightness = cur_led->max_brightness;
@@ -191,6 +190,10 @@ static int led_pwm_probe(struct platform_device *pdev)
if (led_dat->can_sleep)
INIT_WORK(&led_dat->work, led_pwm_work);
+ led_dat->period = pwm_get_period(led_dat->pwm);
+ if (!led_dat->period && (cur_led->pwm_period_ns > 0))
+ led_dat->period = cur_led->pwm_period_ns;
+
ret = led_classdev_register(&pdev->dev, &led_dat->cdev);
if (ret < 0)
goto err;
--
1.9.1
^ permalink raw reply related
* [PATCHv2 resend 11/11] backlight: pwm_bl: retrieve configured pwm period
From: Alexandre Belloni @ 2014-05-19 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1400532162-29483-1-git-send-email-alexandre.belloni@free-electrons.com>
The PWM core is now able to initialize the PWM period from platform_data. Use it
and if it is not configured, use the supplied pwm_period_ns.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
drivers/video/backlight/pwm_bl.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index b75201ff46f6..1bb8a69062c5 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -304,12 +304,14 @@ static int pwm_backlight_probe(struct platform_device *pdev)
/*
* The DT case will set the pwm_period_ns field to 0 and store the
* period, parsed from the DT, in the PWM device. For the non-DT case,
- * set the period from platform data.
+ * set the period from platform data if it is not already set.
*/
- if (data->pwm_period_ns > 0)
+ pb->period = pwm_get_period(pb->pwm);
+ if (!pb->period && (data->pwm_period_ns > 0)) {
+ pb->period = data->pwm_period_ns;
pwm_set_period(pb->pwm, data->pwm_period_ns);
+ }
- pb->period = pwm_get_period(pb->pwm);
pb->lth_brightness = data->lth_brightness * (pb->period / pb->scale);
memset(&props, 0, sizeof(struct backlight_properties));
--
1.9.1
^ permalink raw reply related
* Re: [PATCHv2 resend 04/11] ARM: OMAP3: Beagle: initialize all the struct pwm_lookup members
From: Tony Lindgren @ 2014-05-19 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1400532162-29483-5-git-send-email-alexandre.belloni@free-electrons.com>
* Alexandre Belloni <alexandre.belloni@free-electrons.com> [140519 13:44]:
> This will allow to get rid of the .pwm_period_ns member of struct led_pwm as the
> period will be set by the PWM core.
This should not conflict with anything I have:
Acked-by: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
> arch/arm/mach-omap2/board-omap3beagle.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
> index d6ed819ff15c..f27e1ec90b5e 100644
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> @@ -61,7 +61,14 @@
>
> static struct pwm_lookup pwm_lookup[] = {
> /* LEDB -> PMU_STAT */
> - PWM_LOOKUP("twl-pwmled", 1, "leds_pwm", "beagleboard::pmu_stat"),
> + {
> + .provider = "twl-pwmled",
> + .index = 1,
> + .dev_id = "leds_pwm",
> + .con_id = "beagleboard::pmu_stat",
> + .period = 7812500,
> + .polarity = PWM_POLARITY_NORMAL,
> + },
> };
>
> static struct led_pwm pwm_leds[] = {
> --
> 1.9.1
>
^ 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