* Re: [PATCH 2/3] OMAPDSS: panel-lgphilips-lb035q02: Add DT support
From: Florian Vaussard @ 2014-05-20 10:58 UTC (permalink / raw)
To: Tomi Valkeinen, linux-fbdev, linux-omap; +Cc: Archit Taneja
In-Reply-To: <1400148637-17726-3-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
On 05/15/2014 12:10 PM, Tomi Valkeinen wrote:
> Add DT support for panel-lgphilips-lb035q02.
>
> We disable the use of the backlight_gpio as it should be handled via
> backlight framework with DT boots.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> .../omap2/displays-new/panel-lgphilips-lb035q02.c | 44 +++++++++++++++++++++-
> 1 file changed, 43 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c b/drivers/video/fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c
> index 6e6acd696a70..76c4fdc51c31 100644
> --- a/drivers/video/fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c
> +++ b/drivers/video/fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c
> @@ -159,7 +159,8 @@ static int lb035q02_enable(struct omap_dss_device *dssdev)
> if (omapdss_device_is_enabled(dssdev))
> return 0;
>
> - in->ops.dpi->set_data_lines(in, ddata->data_lines);
> + if (ddata->data_lines)
> + in->ops.dpi->set_data_lines(in, ddata->data_lines);
> in->ops.dpi->set_timings(in, &ddata->videomode);
>
> r = in->ops.dpi->enable(in);
> @@ -277,6 +278,35 @@ err_gpio:
> return r;
> }
>
> +static int lb035q02_probe_of(struct spi_device *spi)
> +{
> + struct device_node *node = spi->dev.of_node;
> + struct panel_drv_data *ddata = dev_get_drvdata(&spi->dev);
> + struct omap_dss_device *in;
> + struct gpio_desc *gpio;
> +
> + gpio = devm_gpiod_get(&spi->dev, "enable");
> + if (IS_ERR(gpio)) {
> + dev_err(&spi->dev, "failed to parse enable gpio\n");
> + return PTR_ERR(gpio);
> + } else {
> + gpiod_direction_output(gpio, 0);
> + ddata->enable_gpio = gpio;
> + }
> +
> + ddata->backlight_gpio = -ENOENT;
> +
> + in = omapdss_of_find_source_for_first_ep(node);
> + if (IS_ERR(in)) {
> + dev_err(&spi->dev, "failed to find video source\n");
> + return PTR_ERR(in);
> + }
> +
> + ddata->in = in;
> +
> + return 0;
> +}
> +
> static int lb035q02_panel_spi_probe(struct spi_device *spi)
> {
> struct panel_drv_data *ddata;
> @@ -295,6 +325,10 @@ static int lb035q02_panel_spi_probe(struct spi_device *spi)
> r = lb035q02_probe_pdata(spi);
> if (r)
> return r;
> + } else if (spi->dev.of_node) {
> + r = lb035q02_probe_of(spi);
> + if (r)
> + return r;
> } else {
> return -ENODEV;
> }
> @@ -346,6 +380,13 @@ static int lb035q02_panel_spi_remove(struct spi_device *spi)
> return 0;
> }
>
> +static const struct of_device_id lb035q02_of_match[] = {
> + { .compatible = "omapdss,lgphilips,lb035q02", },
> + {},
> +};
> +
> +MODULE_DEVICE_TABLE(of, lb035q02_of_match);
> +
> static struct spi_driver lb035q02_spi_driver = {
> .probe = lb035q02_panel_spi_probe,
> .remove = lb035q02_panel_spi_remove,
> @@ -357,6 +398,7 @@ static struct spi_driver lb035q02_spi_driver = {
>
.of_match_table = lb035q02_of_match,
is missing.
> module_spi_driver(lb035q02_spi_driver);
>
> +MODULE_ALIAS("spi:lgphilips,lb035q02");
> MODULE_AUTHOR("Tomi Valkeinen <tomi.valkeinen@ti.com>");
> MODULE_DESCRIPTION("LG.Philips LB035Q02 LCD Panel driver");
> MODULE_LICENSE("GPL");
>
Regards,
Florian
^ permalink raw reply
* Re: [RFC 2/6] omapdss: add init port functions for different omap revs
From: Archit Taneja @ 2014-05-20 9:43 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap
In-Reply-To: <537B0CA1.5060100@ti.com>
On Tuesday 20 May 2014 01:34 PM, Tomi Valkeinen wrote:
> On 08/05/14 12:15, Archit Taneja wrote:
>> The init/uninit port functions are used to set up the DPI and SDI outputs under
>> the dss platform device. A 'reg' property is used to determine whether the node
>> is DPI or SDI for OMAP34xx DSS revision. For other DSS revisions, only DPI
>> output exists.
>>
>> For multiple DPI output instances(introduced in DRA7xx DSS), we would use the
>> 'reg' property to specify the DPI output number.
>>
>> The current functions work fine if there is only one DPI output instance in
>> DSS. For multiple DPI instances, it would get complicated to figure out whether
>> 'reg' is used to specify whether the output is SDI, or a later DPI instance.
>>
>> Create DSS revision specific init/uninit_port functions such that we have a
>> separate functions for OMAP34xx, this helps us deal with the SDI case
>> separately.
>
> Could we instead have an array of the ports for the said DSS version,
> assigned to dss_features? Maybe just something like:
>
> static enum omap_display_type omap34xx_ports[] = {
> OMAP_DISPLAY_TYPE_DPI,
> OMAP_DISPLAY_TYPE_SDI,
> };
>
> The index on the array tells the matching 'reg' value.
Oh yeah! That should prevent us creating ops. It would require us to
create a ports pointer in dss_features, but it's certainly much better
than having 2 very similar functions.
Archit
^ permalink raw reply
* Re: [RFC 2/6] omapdss: add init port functions for different omap revs
From: Tomi Valkeinen @ 2014-05-20 8:04 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1399540517-17883-2-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]
On 08/05/14 12:15, Archit Taneja wrote:
> The init/uninit port functions are used to set up the DPI and SDI outputs under
> the dss platform device. A 'reg' property is used to determine whether the node
> is DPI or SDI for OMAP34xx DSS revision. For other DSS revisions, only DPI
> output exists.
>
> For multiple DPI output instances(introduced in DRA7xx DSS), we would use the
> 'reg' property to specify the DPI output number.
>
> The current functions work fine if there is only one DPI output instance in
> DSS. For multiple DPI instances, it would get complicated to figure out whether
> 'reg' is used to specify whether the output is SDI, or a later DPI instance.
>
> Create DSS revision specific init/uninit_port functions such that we have a
> separate functions for OMAP34xx, this helps us deal with the SDI case
> separately.
Could we instead have an array of the ports for the said DSS version,
assigned to dss_features? Maybe just something like:
static enum omap_display_type omap34xx_ports[] = {
OMAP_DISPLAY_TYPE_DPI,
OMAP_DISPLAY_TYPE_SDI,
};
The index on the array tells the matching 'reg' value.
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-20 5:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140520051203.GB28812@earth.universe>
* Sebastian Reichel <sre@kernel.org> [140519 22:13]:
> On Mon, May 19, 2014 at 10:05:15PM +0300, Tomi Valkeinen wrote:
> > 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.
Yes I agree it's also hackish. But playing with the compatible flags
avoids adding other custom workarounds.
> > >>> 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".
>
> Yes, that's what I wanted to say :)
Hmm I think we need to add few things to the hypothetical SPI case
to get it even close to the panel example. Like assume that no SPI bus
exists, and that potentially multiple different Synaptics drivers are
trying to share the same compatible flag for a non-existing generic
binding.. I think then it's getting close to the panel example :)
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tomi Valkeinen @ 2014-05-20 5:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140520045748.GA28812@earth.universe>
[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]
On 20/05/14 07:57, Sebastian Reichel wrote:
> Hi,
>
> On Mon, May 19, 2014 at 09:57:18PM +0300, Tomi Valkeinen wrote:
>>> 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.
>
> I wonder if the "omapdss," prefix could be added to *all* remote
> endpoints seen by omapdss. Pseudocode:
>
> for each port in dss {
> for each endpoint in port {
> panel = get_phandle(endpoint, "remote-endpoint");
>
> /* only add prefix if it's not already there (kexec) */
> if (panel.compatible != "omapdss,.*")
> panel.compatible = "omapdss," + panel.compatible;
> }
> }
Hmm, yes, I think that would work. It would remove the need for the
database, but the code would be slightly more complex as we'd need to
travel through the graph, not just the nodes that are directly connected
to omapdss. I need to try this approach also.
Tomi
Ps. Sorry for misspelling your name, twice. If I recall right, I even
checked if your name is written with an 'a' or an 'e', but somehow still
managed to get it wrong.
[-- 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: Sebastian Reichel @ 2014-05-20 5:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <537A55EB.1080507@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]
On Mon, May 19, 2014 at 10:05:15PM +0300, Tomi Valkeinen wrote:
> 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".
Yes, that's what I wanted to say :)
My name is spelled Sebastian, though. Sebastien is the French
variant as far as i know.
-- Sebastian
[-- Attachment #2: 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: Sebastian Reichel @ 2014-05-20 4:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <537A540E.8070302@ti.com>
[-- Attachment #1: Type: text/plain, Size: 750 bytes --]
Hi,
On Mon, May 19, 2014 at 09:57:18PM +0300, Tomi Valkeinen wrote:
> > 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.
I wonder if the "omapdss," prefix could be added to *all* remote
endpoints seen by omapdss. Pseudocode:
for each port in dss {
for each endpoint in port {
panel = get_phandle(endpoint, "remote-endpoint");
/* only add prefix if it's not already there (kexec) */
if (panel.compatible != "omapdss,.*")
panel.compatible = "omapdss," + panel.compatible;
}
}
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCHv2 resend 00/11] improve PWM lookup support without device tree
From: Laurent Pinchart @ 2014-05-20 0:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140519223913.GE20590@verge.net.au>
Hi Alexandre and Simon,
On Tuesday 20 May 2014 07:39:13 Simon Horman wrote:
> [ CCed Laurent Pinchart ]
>
> The renesas and shmobile portions of this seem reasonable to me
> and I have checked that there do not seem to be any conflicts
> with changes I already have queued up for v3.16 (and v3.17).
>
> I have CCed Laurent Pinchart as I believe he most recently
> did work on the renesas and shmobile code in question.
The series look sane to me. For the three patches that Simon has acked below,
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> On Mon, May 19, 2014 at 10:42:31PM +0200, Alexandre Belloni wrote:
> > 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
>
> The above two patches:
> Acked-by: Simon Horman <horms+renesas@verge.net.au>
>
> > 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
>
> The above patch:
> Acked-by: Simon Horman <horms+renesas@verge.net.au>
>
> > 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
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCHv2 resend 00/11] improve PWM lookup support without device tree
From: Simon Horman @ 2014-05-19 22:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1400532162-29483-1-git-send-email-alexandre.belloni@free-electrons.com>
[ CCed Laurent Pinchart ]
The renesas and shmobile portions of this seem reasonable to me
and I have checked that there do not seem to be any conflicts
with changes I already have queued up for v3.16 (and v3.17).
I have CCed Laurent Pinchart as I believe he most recently
did work on the renesas and shmobile code in question.
On Mon, May 19, 2014 at 10:42:31PM +0200, Alexandre Belloni wrote:
> 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
The above two patches:
Acked-by: Simon Horman <horms+renesas@verge.net.au>
> 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
The above patch:
Acked-by: Simon Horman <horms+renesas@verge.net.au>
> 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
^ permalink raw reply
* Re: [PATCHv2 resend 00/11] improve PWM lookup support without device tree
From: Thierry Reding @ 2014-05-19 21:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1400532162-29483-1-git-send-email-alexandre.belloni@free-electrons.com>
[-- Attachment #1: Type: text/plain, Size: 483 bytes --]
On Mon, May 19, 2014 at 10:42:31PM +0200, Alexandre Belloni wrote:
> 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.
It's kind of late for 3.16 now, but it doesn't look very risky from a
quick look. I'll sleep on it and if I don't feel too uncomfortable about
it in the morning I'll apply it for linux-next and see how that goes.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCHv2 resend 07/11] ARM: OMAP3: Beagle: use PWM_LOOKUP to initialize struct pwm_lookup
From: Tony Lindgren @ 2014-05-19 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1400532162-29483-8-git-send-email-alexandre.belloni@free-electrons.com>
* Alexandre Belloni <alexandre.belloni@free-electrons.com> [140519 13:44]:
Missing description?
Presumably you'll fix that so:
Acked-by: Tony Lindgren <tony@atomide.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
* 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
* [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
* [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 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 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 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 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 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 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 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 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 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 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
* 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
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