* 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
* 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 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 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: 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: [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: [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: 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: 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: [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: [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: [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: [PATCH 3/3] Doc/DT: Add binding doc for lgphilips,lb035q02.txt
From: Florian Vaussard @ 2014-05-20 11:01 UTC (permalink / raw)
To: Tomi Valkeinen, linux-fbdev, linux-omap; +Cc: Archit Taneja, devicetree
In-Reply-To: <1400148637-17726-4-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
On 05/15/2014 12:10 PM, Tomi Valkeinen wrote:
> Add DT bindings documentation for LG.Philips LB035Q02 LCD panel.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: devicetree@vger.kernel.org
> ---
> .../bindings/video/lgphilips,lb035q02.txt | 33 ++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/lgphilips,lb035q02.txt
>
> diff --git a/Documentation/devicetree/bindings/video/lgphilips,lb035q02.txt b/Documentation/devicetree/bindings/video/lgphilips,lb035q02.txt
> new file mode 100644
> index 000000000000..1a1e653e5407
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/lgphilips,lb035q02.txt
> @@ -0,0 +1,33 @@
> +LG.Philips LB035Q02 Panel
> +============> +
> +Required properties:
> +- compatible: "lgphilips,lb035q02"
> +- enable-gpios: panel enable gpio
> +
> +Optional properties:
> +- label: a symbolic name for the panel
> +
> +Required nodes:
> +- Video port for DPI input
> +
> +Example
> +-------
> +
> +lcd-panel: panel@0 {
> + compatible = "lgphilips,lb035q02";
> + reg = <0>;
> + spi-max-frequency = <100000>;
> + spi-cpol;
> + spi-cpha;
> +
> + label = "lcd";
> +
> + enable-gpios = <&gpio7 7 0>;
> +
> + port {
> + lcd_in: endpoint {
> + remote-endpoint = <&dpi_out>;
> + };
> + };
> +};
>
The lcd-panel should be a child node of a SPI controller. Maybe this
could be mentioned? Or the example could be more explicit, like:
&mcspi1 {
lcd-panel: panel@0 {
....
};
};
Regards,
Florian
^ permalink raw reply
* Re: [PATCH 0/3] OMAPDSS: DT support for panel-lgphilips-lb035q02
From: Florian Vaussard @ 2014-05-20 11:04 UTC (permalink / raw)
To: Tomi Valkeinen, linux-fbdev, linux-omap; +Cc: Archit Taneja
In-Reply-To: <1400148637-17726-1-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
On 05/15/2014 12:10 PM, Tomi Valkeinen wrote:
> Hi,
>
> This adds DT support to panel-lgphilips-lb035q02. Compile tested only.
>
> This panel is used on some Overo boards (alto35, if I'm not mistaken).
>
I tested with the Alto35. Using the small fix for patch 2, I was able to
use the panel. I will post the related DTS changes soon.
Tested-by: Florian Vaussard <florian.vaussard@epfl.ch>
> Tomi
>
> Tomi Valkeinen (3):
> OMAPDSS: panel-lgphilips-lb035q02: use gpiod for enable gpio
> OMAPDSS: panel-lgphilips-lb035q02: Add DT support
> Doc/DT: Add binding doc for lgphilips,lb035q02.txt
>
> .../bindings/video/lgphilips,lb035q02.txt | 33 ++++++++++
> .../omap2/displays-new/panel-lgphilips-lb035q02.c | 76 +++++++++++++++++-----
> 2 files changed, 94 insertions(+), 15 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/video/lgphilips,lb035q02.txt
>
^ permalink raw reply
* Re: [PATCH 2/3] OMAPDSS: panel-lgphilips-lb035q02: Add DT support
From: Tomi Valkeinen @ 2014-05-20 11:36 UTC (permalink / raw)
To: florian.vaussard, linux-fbdev, linux-omap; +Cc: Archit Taneja
In-Reply-To: <537B3543.2040906@epfl.ch>
[-- Attachment #1: Type: text/plain, Size: 440 bytes --]
On 20/05/14 13:58, Florian Vaussard wrote:
>> 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.
Thanks. I seem to have missed it with the other panels also in the
patches I sent last week.
Tomi
[-- Attachment #2: OpenPGP 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: Philipp Zabel @ 2014-05-20 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1400532162-29483-1-git-send-email-alexandre.belloni@free-electrons.com>
Hi Alexandre,
On Mon, May 19, 2014 at 10:42 PM, Alexandre Belloni
<alexandre.belloni@free-electrons.com> 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
> 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
For the hx4700 patches (5 an 9),
Acked-by: Philipp Zabel <philipp.zabel@gmail.com>
regards
Philipp
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Sebastian Reichel @ 2014-05-20 21:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140520054852.GA12384@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 3156 bytes --]
On Mon, May 19, 2014 at 10:48:52PM -0700, Tony Lindgren wrote:
> * 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, [...]
The important thing is not, that there is an SPI bus (hardware), but
that there is a common SPI client framework (software). That's one
of the problem's I see with the modified compatible value.
Basically I see the following problem with the appended -omapdss in
the compatible string:
* You can read the -omapdss as "to be used with omapdss driver". In
this case the compatible string is just needed for driver loading,
which is frowned upon DT binding maintainers AFAIK.
* Alternatively one can read it as "connected to omapdss". In this
case we add unneeded redundancy to the DT. This does not belong
into a compatible string, since its encoded in the DT hierarchy.
And btw. Tomi's rewrite hack basically works exactly like this, just
without adding the redundancy explicitly into the DT. Instead of
prefixing the comaptible string he could also add a -omapdss sufix.
That's basically a proof, that the suffix adds useless redudancy.
> [...] and that potentially multiple different Synaptics drivers are
> trying to share the same compatible flag for a non-existing generic
> binding.
If there was no common SPI client framework you would need two
different SPI client drivers for two different SPI host controllers.
Obviously its a bad idea to have no SPI framework, but that's not
important for the example (except that there should obviously be a
common panel framework) :)
> I think then it's getting close to the panel example :)
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] video: fbdev: grvga.c: Fix for possible null pointer dereference
From: Rickard Strandqvist @ 2014-05-20 21:35 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: Rickard Strandqvist, Grant Likely, Rob Herring, Sachin Kamat,
Jingoo Han, Daniel Vetter, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
There is otherwise a risk of a possible null pointer dereference.
Was largely found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
---
drivers/video/fbdev/grvga.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/grvga.c b/drivers/video/fbdev/grvga.c
index c078701..2db5bb1 100644
--- a/drivers/video/fbdev/grvga.c
+++ b/drivers/video/fbdev/grvga.c
@@ -514,9 +514,10 @@ free_fb:
static int grvga_remove(struct platform_device *device)
{
struct fb_info *info = dev_get_drvdata(&device->dev);
- struct grvga_par *par = info->par;
+ struct grvga_par *par;
if (info) {
+ par = info->par;
unregister_framebuffer(info);
fb_dealloc_cmap(&info->cmap);
--
1.7.10.4
^ permalink raw reply related
* [PATCH] video: fbdev: s3fb.c: Fix for possible null pointer dereference
From: Rickard Strandqvist @ 2014-05-20 21:37 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: Rickard Strandqvist, Jingoo Han, Daniel Vetter, Wei Yongjun,
Bjorn Helgaas, Joe Perches, linux-fbdev, linux-kernel
There is otherwise a risk of a possible null pointer dereference.
Was largely found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
---
drivers/video/fbdev/s3fb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/s3fb.c b/drivers/video/fbdev/s3fb.c
index 9a3f8f1..c43b969 100644
--- a/drivers/video/fbdev/s3fb.c
+++ b/drivers/video/fbdev/s3fb.c
@@ -1401,9 +1401,10 @@ err_enable_device:
static void s3_pci_remove(struct pci_dev *dev)
{
struct fb_info *info = pci_get_drvdata(dev);
- struct s3fb_info __maybe_unused *par = info->par;
+ struct s3fb_info __maybe_unused *par;
if (info) {
+ par = info->par;
#ifdef CONFIG_MTRR
if (par->mtrr_reg >= 0) {
--
1.7.10.4
^ permalink raw reply related
* [PATCH] drivers/video/fbdev/fb-puv3.c: Add header files for function unifb_mmap
From: sunzc522 @ 2014-05-21 6:13 UTC (permalink / raw)
To: linux-kernel
Cc: gxt, gang.chen.5i5j, Zhichuang SUN,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Jingoo Han,
Daniel Vetter, Joe Perches, Laurent Pinchart, linux-fbdev
From: Zhichuang SUN <sunzc522@gmail.com>
Function unifb_mmap calls functions which are defined in linux/mm.h
and asm/pgtable.h
The related error (for unicore32 with unicore32_defconfig):
CC drivers/video/fbdev/fb-puv3.o
drivers/video/fbdev/fb-puv3.c: In function 'unifb_mmap':
drivers/video/fbdev/fb-puv3.c:646: error: implicit declaration of
function 'vm_iomap_memory'
drivers/video/fbdev/fb-puv3.c:646: error: implicit declaration of
function 'pgprot_noncached'
Signed-off-by: Zhichuang Sun <sunzc522@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Joe Perches <joe@perches.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: linux-fbdev@vger.kernel.org
---
drivers/video/fbdev/fb-puv3.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/video/fbdev/fb-puv3.c b/drivers/video/fbdev/fb-puv3.c
index 6db9ebd..88fa2e7 100644
--- a/drivers/video/fbdev/fb-puv3.c
+++ b/drivers/video/fbdev/fb-puv3.c
@@ -18,8 +18,10 @@
#include <linux/fb.h>
#include <linux/init.h>
#include <linux/console.h>
+#include <linux/mm.h>
#include <asm/sizes.h>
+#include <asm/pgtable.h>
#include <mach/hardware.h>
/* Platform_data reserved for unifb registers. */
--
1.7.0.4
^ permalink raw reply related
* =?gbk?B?UmU6IFtQQVRDSF0gZHJpdmVycy92aWRlby9mYmRldi9mYi1wdXYzLmM6IEFkZCBoZWFkZXIgZmlsZXMgZm9yDQogZnVu
From: 管雪涛 @ 2014-05-21 7:04 UTC (permalink / raw)
To: sunzc522
Cc: linux-kernel, gxt, gang chen 5i5j,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Jingoo Han,
Daniel Vetter, Joe Perches, Laurent Pinchart, linux-fbdev
In-Reply-To: <1400652811-5206-1-git-send-email-sunzc522@gmail.com>
Thanks.
Acked-by: Xuetao Guan <gxt@mprc.pku.edu.cn>
----- sunzc522@gmail.com 写道：
> From: Zhichuang SUN <sunzc522@gmail.com>
>
> Function unifb_mmap calls functions which are defined in linux/mm.h
> and asm/pgtable.h
>
> The related error (for unicore32 with unicore32_defconfig):
> CC drivers/video/fbdev/fb-puv3.o
> drivers/video/fbdev/fb-puv3.c: In function 'unifb_mmap':
> drivers/video/fbdev/fb-puv3.c:646: error: implicit declaration of
> function 'vm_iomap_memory'
> drivers/video/fbdev/fb-puv3.c:646: error: implicit declaration of
> function 'pgprot_noncached'
>
> Signed-off-by: Zhichuang Sun <sunzc522@gmail.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Joe Perches <joe@perches.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: linux-fbdev@vger.kernel.org
> ---
> drivers/video/fbdev/fb-puv3.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/fbdev/fb-puv3.c b/drivers/video/fbdev/fb-puv3.c
> index 6db9ebd..88fa2e7 100644
> --- a/drivers/video/fbdev/fb-puv3.c
> +++ b/drivers/video/fbdev/fb-puv3.c
> @@ -18,8 +18,10 @@
> #include <linux/fb.h>
> #include <linux/init.h>
> #include <linux/console.h>
> +#include <linux/mm.h>
>
> #include <asm/sizes.h>
> +#include <asm/pgtable.h>
> #include <mach/hardware.h>
>
> /* Platform_data reserved for unifb registers. */
> --
> 1.7.0.4
>
^ permalink raw reply
* Re: [PATCHv2 resend 00/11] improve PWM lookup support without device tree
From: Thierry Reding @ 2014-05-21 9:16 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: 3483 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.
>
> 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
I've applied this whole series with some minor fixups (mostly adding
detail to commit messages). Test builds show no breakage, so I've pushed
this to the for-next branch.
Thanks,
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
From: Tomi Valkeinen @ 2014-05-21 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140513213205.GB18001@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 640 bytes --]
On 14/05/14 00:32, Tony Lindgren wrote:
> +&dss {
> + status = "ok";
> + vdds_dsi-supply = <&vpll2>;
> + port {
> + dpi_out: endpoint {
> + remote-endpoint = <&lcd_in>;
> + data-lines = <18>;
> + };
> + };
> +};
I just noticed the vdds_dsi-supply there. While the driver currently
uses that if available, I think it should be removed, and done the same
way Florian did with his overo patches:
/* Needed to power the DPI pins */
&vpll2 {
regulator-always-on;
};
That supply is not DSS's supply, but it's used to power up the pins. If
the pins were used as GPIOs, that power should be enabled.
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-21 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140519195100.GB11945@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 2423 bytes --]
On 19/05/14 22:51, Tony Lindgren wrote:
>>> 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?
Yes, but in that case the driver names are internal to kernel. You can
append "omapdss" or such to the driver name, and have that name used in
the board file and in the driver. It's not visible outside the kernel,
and when there's a common display framework, it can be changed without
anyone knowing.
With DT we have the old, stable .dts files that need to be supported...
>>> 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 :)
True, but it doesn't feel very big baggage to me. We can bail out
immediately if the machine is not omap, so for non-omap's the effect
should be negligible.
For omap there is some extra stuff being done. I don't really know heavy
it is, performance wise, but the operation itself is quite small.
I'll try and see how the other options work, which are:
- Bailing out from module_init in each display driver. The reason I
don't like this (although I haven't tried it) is that all the display
drivers need the modification, and because I need to catch the
module_init, I cannot use the helpers like module_platform_driver(), so
it adds multiple lines to every driver.
- Traveling the video graph, starting from omapdss. This one is possibly
better performance-wise than my original version, as we only need to
search for the omapdss node and can then follow the links. But the code
will be more complex.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH resend 0/4] Make video.use_native_backlight=1 work properly with nouveau
From: Hans de Goede @ 2014-05-21 13:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Aaron Lu, Jingoo Han, Bryan Wu, Lee Jones,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Ben Skeggs,
David Airlie
Cc: Zhang Rui, Len Brown, linux-acpi, linux-fbdev, dri-devel
Hi All,
I know it has not been that long since the last send of this series, but
it has been very quiet, and I would like to see some discussion on it
(or it being applied at once, that is fine too :)
This patch-set adds backlight device (un)registration notification and
makes acpi-video listen to it, so that video.use_native_backlight=1 still
works if a raw interface gets loaded *after* acpi-video has been initialized.
It also changes nouveau to always register its raw interface, as all the other
kms drivers do, acpi_video_backlight_support() is only intended to avoid the
loading of multiple (possibly conflicting) firmware drivers, not to avoid
loading raw drivers.
In the mean time I've gotten feedback from a user with a laptop which needs
video.use_native_backlight=1 and uses nouveau, and he has confirmed that this
patch-set works as advertised, see:
https://bugzilla.redhat.com/show_bug.cgi?id\x1093171
Regards,
Hans
^ 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