Re: [rtc-linux] [PATCH] rtc: ds1307: fix kernel splat due to wakeup irq handling
On 11/11/2015 at 10:11:01 -0600, Felipe Balbi wrote :
> Since commit 3fffd1283927 ("i2c: allow specifying
> separate wakeup interrupt in device tree") we have
> automatic wakeup irq support for i2c devices. That
> commit missed the fact that rtc-1307 had its own
> wakeup irq handling and ended up introducing a
> kernel splat for at least Beagle x15 boards.
>
> Fix that by reverting original commit _and_ passing
> correct interrupt names on DTS so i2c-core can
> choose correct IRQ as wakeup.
>
> Now that we have automatic wakeirq support, we can
> revert the original commit which did it manually.
>
> Fixes the following warning:
>
> [ 10.346582] WARNING: CPU: 1 PID: 263 at
> linux/drivers/base/power/wakeirq.c:43 dev_pm_attach_wake_irq+0xbc/0xd4()
> [ 10.359244] rtc-ds1307 2-006f: wake irq already initialized
>
> Cc: Tony Lindgren
> Cc: Nishanth Menon
> Signed-off-by: Felipe Balbi
> ---
> arch/arm/boot/dts/am57xx-beagle-x15.dts | 1 +
> drivers/rtc/rtc-ds1307.c| 36
> +++------
> 2 files changed, 4 insertions(+), 33 deletions(-)
>
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rtc: ds1307: Fix alarm programming for mcp794xx
On 23/10/2015 at 09:29:57 +0300, Tero Kristo wrote :
> mcp794xx alarm registers must be written in BCD format. However, the
> alarm programming logic neglected this by adding one to the value
> after bin2bcd conversion has been already done, writing bad values
> to month register in case the alarm being set is in October. In this
> case, the alarm month value becomes 0x0a instead of the expected 0x10.
>
> Fix by moving the +1 addition within the bin2bcd call also.
>
> Fixes: 1d1945d261a2 ("drivers/rtc/rtc-ds1307.c: add alarm support for
> mcp7941x chips")
>
> Signed-off-by: Tero Kristo
> ---
> drivers/rtc/rtc-ds1307.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/3] ARM: AM437X: Add rtc clock handling
On 26/08/2015 at 11:01:27 -0700, Tony Lindgren wrote : > * Keerthy [150826 09:54]: > > Tony, > > > > On Saturday 22 August 2015 02:48 AM, Alexandre Belloni wrote: > > >Tony, > > > > > >On 18/08/2015 at 15:11:13 +0530, Keerthy wrote : > > >>The series is applicable for all am437x series of processors. > > >>It adds clock handling support. Boot tested on am437x-gp-evm. > > >> > > >>Keerthy (3): > > >> ARM: dts: AM437x: Add the internal and external clock nodes for rtc > > >> rtc: omap: Add internal clock enabling support > > >> rtc: omap: Add external clock enabling support > > >> > > > > > >I'm wondering how you want to get those patches merged. I can let you > > >take 2 and 3 through arm-soc but you will miss 4.3. Or I can take 2 and > > >3 for 4.3 but the documentation will be missing. > > > > A gentle ping on this series. > > Alexandre, it's probably best that you take them all. The dts changes > apply against Linux next with fuzz so there should not be any merge > conflict. Feel free to add: > > Acked-by: Tony Lindgren > So, I've rebased 1/3 on rtc-next to avoid depending on arm-soc. I've pushed everything and hopefully there won't be any issues in linux-next. We are quite close to the merge window so I would be much more confident sending them to Linus if you could test linux-next once the patches land there. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/3] rtc: omap: Add internal clock enabling support
Hi, On 18/08/2015 at 15:11:15 +0530, Keerthy wrote : > @@ -681,6 +688,9 @@ static int __exit omap_rtc_remove(struct platform_device > *pdev) > > device_init_wakeup(&pdev->dev, 0); > > + if (!IS_ERR(rtc->clk)) > + clk_disable_unprepare(rtc->clk); > + > rtc->type->unlock(rtc); > /* leave rtc running, but disable irqs */ Is it actually still running once the clock is disabled? > rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, 0); -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/3] ARM: AM437X: Add rtc clock handling
Tony, On 18/08/2015 at 15:11:13 +0530, Keerthy wrote : > The series is applicable for all am437x series of processors. > It adds clock handling support. Boot tested on am437x-gp-evm. > > Keerthy (3): > ARM: dts: AM437x: Add the internal and external clock nodes for rtc > rtc: omap: Add internal clock enabling support > rtc: omap: Add external clock enabling support > I'm wondering how you want to get those patches merged. I can let you take 2 and 3 through arm-soc but you will miss 4.3. Or I can take 2 and 3 for 4.3 but the documentation will be missing. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] rtc: omap: Add external clock enabling support
On 13/08/2015 at 12:37:48 +0530, Keerthy wrote :
> Configure the clock source to either internal clock
> or external clock based on the availability of the clocks.
> External clock is preferred as it can be ticking during suspend.
>
> Signed-off-by: Keerthy
> ---
> drivers/rtc/rtc-omap.c | 44
> 1 file changed, 44 insertions(+)
>
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index 8b6355f..479f730 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * The OMAP RTC is a year/month/day/hours/minutes/seconds BCD clock
> @@ -107,6 +108,7 @@
>
> /* OMAP_RTC_OSC_REG bit fields: */
> #define OMAP_RTC_OSC_32KCLK_EN BIT(6)
> +#define OMAP_RTC_OSC_SEL_32KCLK_SRC BIT(3)
>
> /* OMAP_RTC_IRQWAKEEN bit fields: */
> #define OMAP_RTC_IRQWAKEEN_ALARM_WAKEEN BIT(1)
> @@ -136,6 +138,7 @@ struct omap_rtc {
> int irq_timer;
> u8 interrupts_reg;
> bool is_pmic_controller;
> + bool has_ext_clk;
> const struct omap_rtc_device_type *type;
> };
>
> @@ -525,6 +528,7 @@ static int omap_rtc_probe(struct platform_device *pdev)
> {
> struct omap_rtc *rtc;
> struct resource *res;
> + struct clk *ext_clk, *int_clk;
> u8 reg, mask, new_ctrl;
> const struct platform_device_id *id_entry;
> const struct of_device_id *of_id;
> @@ -553,6 +557,17 @@ static int omap_rtc_probe(struct platform_device *pdev)
> if (rtc->irq_alarm <= 0)
> return -ENOENT;
>
> + ext_clk = devm_clk_get(&pdev->dev, "ext-clk");
> + if (!IS_ERR(ext_clk)) {
> + rtc->has_ext_clk = true;
> + clk_prepare(ext_clk);
I'd say this has to be prepare_enable because you are not enabling those
clocks anywhere
> + } else {
> + int_clk = devm_clk_get(&pdev->dev, "int-clk");
> +
> + if (!IS_ERR(int_clk))
> + clk_prepare(int_clk);
> + }
> +
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> rtc->base = devm_ioremap_resource(&pdev->dev, res);
> if (IS_ERR(rtc->base))
> @@ -627,6 +642,17 @@ static int omap_rtc_probe(struct platform_device *pdev)
> if (reg != new_ctrl)
> rtc_write(rtc, OMAP_RTC_CTRL_REG, new_ctrl);
>
> + /*
> + * If we have the external clock then
> + * Switch to external clock so we can keep ticking
> + * acorss suspend
> + */
> + if (rtc->has_ext_clk) {
> + reg = rtc_read(rtc, OMAP_RTC_OSC_REG);
> + rtc_write(rtc, OMAP_RTC_OSC_REG, reg |
> + OMAP_RTC_OSC_SEL_32KCLK_SRC);
> + }
> +
> rtc->type->lock(rtc);
>
> device_init_wakeup(&pdev->dev, true);
> @@ -672,6 +698,8 @@ err:
> static int __exit omap_rtc_remove(struct platform_device *pdev)
> {
> struct omap_rtc *rtc = platform_get_drvdata(pdev);
> + struct clk *ext_clk, *int_clk;
> + u8 reg;
>
> if (pm_power_off == omap_rtc_power_off &&
> omap_rtc_power_off_rtc == rtc) {
> @@ -681,10 +709,26 @@ static int __exit omap_rtc_remove(struct
> platform_device *pdev)
>
> device_init_wakeup(&pdev->dev, 0);
>
> + ext_clk = devm_clk_get(&pdev->dev, "ext-clk");
> + if (!IS_ERR(ext_clk)) {
> + clk_unprepare(ext_clk);
> + } else {
> + int_clk = devm_clk_get(&pdev->dev, "int-clk");
> +
> + if (!IS_ERR(int_clk))
> + clk_unprepare(int_clk);
> + }
> +
You can probably add ext_clk and int_clk to struct omap_rtc and avoid
those devm_clk_get.
> rtc->type->unlock(rtc);
> /* leave rtc running, but disable irqs */
> rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, 0);
>
> + if (rtc->has_ext_clk) {
Then you could also avoid has_ext_clk and simply test rtc->ext_clk.
> + reg = rtc_read(rtc, OMAP_RTC_OSC_REG);
> + reg &= ~OMAP_RTC_OSC_SEL_32KCLK_SRC;
> + rtc_write(rtc, OMAP_RTC_OSC_REG, reg);
> + }
> +
> rtc->type->lock(rtc);
>
> /* Disable the clock/module */
> --
> 1.9.1
>
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/6] rtc: omap: Add external clock enabling support
On 13/08/2015 at 20:17:23 +, Paul Walmsley wrote : > > I'd say that I don't really care. I'd say the best would be to make a > > decision based on clock-accuracy but maybe that is an information you > > don't have yet. Anyway, this could be added at a later date. > > Either the clock mux logic is glitchless, in which case the RTC is likely > to lose at least 31 microseconds per switch; or it's not glitchless, in > which case it's unsafe to switch the RTC clock source while the clock > isn't gated. Keerthy, before submitting this patch for merging, I'd > suggest consulting your hardware folks to figure out which case it is. > Don't take me wrong, your point is perfectly valid. I was just saying that I didn't care what was done in the driver. Obviously, this has to match what is best from a hardware point of view. But since we agreed on the DT bindings, I'd say that we can still adjust the driver later. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/6] rtc: omap: Add external clock enabling support
Hi, On 13/08/2015 at 00:38:50 +0530, Keerthy wrote : > The intent here is to switch to a higher precision clock which is the > internal clock when available. > > Alexandre, > > Is dynamic switching preferred over sticking to external clock always if > present? > I'd say that I don't really care. I'd say the best would be to make a decision based on clock-accuracy but maybe that is an information you don't have yet. Anyway, this could be added at a later date. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/6] rtc: omap: Add external clock enabling support
Hi,
This seems better but:
On 10/08/2015 at 14:58:22 +0530, Keerthy wrote :
> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> index d99b2ee..756819f 100644
> --- a/arch/arm/boot/dts/am4372.dtsi
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -336,6 +336,8 @@
> interrupts = GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
> ti,hwmods = "rtc";
> + clocks = <&clk_32768_ck>, <&clk_32k_rtc>;
> + clock-names = "int-clk", "ext-clk";
> status = "disabled";
> };
>
This change has to be part of another patch.
> @@ -698,6 +706,7 @@ static int __exit omap_rtc_remove(struct platform_device
> *pdev)
> static int omap_rtc_suspend(struct device *dev)
> {
> struct omap_rtc *rtc = dev_get_drvdata(dev);
> + u8 reg;
>
> rtc->interrupts_reg = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
>
> @@ -711,6 +720,18 @@ static int omap_rtc_suspend(struct device *dev)
> enable_irq_wake(rtc->irq_alarm);
> else
> rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, 0);
> +
> + /*
> + * If we have the luxury of external clock then
> + * Switch to external clock so we can keep ticking
> + * acorss suspend
> + */
> + if (rtc->has_ext_clk) {
> + reg = rtc_read(rtc, OMAP_RTC_OSC_REG);
> + rtc_write(rtc, OMAP_RTC_OSC_REG, reg |
> + OMAP_RTC_OSC_SEL_32KCLK_SRC);
> + }
> +
You should probably prepare/enable the clock before switching to it. I
know it doesn't matter right now but that may not be the case on other
boards.
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] rtc: omap: Add external clock enabling support
On 06/08/2015 at 12:36:54 +0300, Grygorii Strashko wrote :
> Pls, correct me if I'm not right. Is below what you propose?
>
> Doard dts:
> / {
> rtc_32k_ext_clk: rtc_osc_xi_clkin32_ext {
> #clock-cells = <0>;
> compatible = "fixed-clock";
> clock-frequency = <32000>;
> clock-output-names = "rtc_osc_xi_clkin32";
> };
> }
>
> &rtc {
> status = "okay";
> clocks = <&sys_32k_ck>, <&rtc_32k_ext_clk>;
> [optional] clock-names = "int-clk", "ext-clk";
> };
>
> Driver:
> 1) clk0 is mandatory, internal clock source
> 2) clk1 is optional, external clock source, so
> if present - RTC driver can switch to use ext clock source
>
Absolutely!
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] rtc: omap: Add external clock enabling support
On 06/08/2015 at 07:39:52 +0530, Keerthy wrote : > On Wednesday 05 August 2015 06:05 PM, Alexandre Belloni wrote: > >On 05/08/2015 at 17:31:22 +0530, Keerthy wrote : > >>This is a special one where in the enable bit is present in the rtc register > >>space and not in the prcm register space. Since there was a concern on the > >>external clock not being present i added a board dts flag. > >> > > > >So you mean this external clock is coming internally from the SoC? > > No what i meant is external clock is coming from Oscillator OSC1 @32.768KHz > but the controlling bits are part of rtc register space. > > TRM: http://www.ti.com/lit/ug/spruhl7c/spruhl7c.pdf > > Section: 19.4.3.2 Clock Source Page 2836 > > Also register details: > 19.4.5.19 RTCSS_OSC_REG Register (offset = 54h) [reset = 10h] > > Page 2865. > This confirms what I'm saying. Your issue here is that the driver is not properly taking the clocks so when the PRCM is disabling CLK_32KHZ, you end up without any clock. You can use the clocks property in the device tree and pass two clocks, the prcm one and the external crystal/external oscillator. In the driver, you get both clock, clk_get_rate on the external one will help you know whether it is populated or not (this will be 0 or 32768). It is is populated, use it by writing 32KCLK_SEL. Bonus points if you use the clock-accuracy and decide to switch between PRCM and the external clock when going to suspend and resuming. I guess an external RC oscillator is quite bad versus the PRCM. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] rtc: omap: Add external clock enabling support
On 05/08/2015 at 17:31:22 +0530, Keerthy wrote : > This is a special one where in the enable bit is present in the rtc register > space and not in the prcm register space. Since there was a concern on the > external clock not being present i added a board dts flag. > So you mean this external clock is coming internally from the SoC? Do you have a link to the datasheet? -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] rtc: omap: Add external clock enabling support
On 05/08/2015 at 13:41:19 +0200, Alexandre Belloni wrote : > Hi, > > On 05/08/2015 at 04:13:17 -0700, Tony Lindgren wrote : > > * Keerthy [150805 03:53]: > > > Based on the board property switch the source from internal > > > to external clock. Switching to external source is needed for > > > rtcwake to work in low power modes. > > > > I think this is better handled based on the compatible string > > in the device driver rather than introducing a custom dts > > property for it. You can just set the quirk flag in the driver > > probe based on the compatible. > > > > Why not use the clocks property? Then you can pass an external clock. If > it is present you can even get its rate if this is needed at some point > in the future. You could also disable it when going to suspend. > Actually, that was already my suggestion back in april: http://patchwork.ozlabs.org/patch/445631/ (Please Cc: the rtc mailing list for RTC related patches so that they get picked up by patchwork). -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] rtc: omap: Add external clock enabling support
Hi, On 05/08/2015 at 04:13:17 -0700, Tony Lindgren wrote : > * Keerthy [150805 03:53]: > > Based on the board property switch the source from internal > > to external clock. Switching to external source is needed for > > rtcwake to work in low power modes. > > I think this is better handled based on the compatible string > in the device driver rather than introducing a custom dts > property for it. You can just set the quirk flag in the driver > probe based on the compatible. > Why not use the clocks property? Then you can pass an external clock. If it is present you can even get its rate if this is needed at some point in the future. You could also disable it when going to suspend. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 0/5] drivers/rtc/rtc-ds1307.c: Basic cleanups and support for wakeupirq
Hi, On 23/06/2015 at 11:15:09 -0500, Nishanth Menon wrote : > NOTE1: I have only tested in mcp79410 device, and not on other > ds1307-rtc driver compatbile devices as I dont have any other. > additional testing might be nice to have. Patchwork picked up V3 of 4/5 correctly so I have applied the series and pushed it in rtc-next. It will land in linux-next tomorrow so hopefully, this will see more testing. > NOTE2: there are additional fixes that linux-next seems to need but > those are in omap-rtc, cpufreq etc, but those are not related by the > ds-1307. > > V1: https://patchwork.kernel.org/patch/4759171/ > > NOTE: Patch 5/5 of the series is meant to indicate the usage, and will > be reposted along with other wakeup sources to be enabled once the > driver changes are accepted. > I've left that one out so you can send it to the omap maintainers when ready. Thanks! -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 4/5] drivers/rtc/rtc-ds1307.c: Support optional wakeup interrupt source
Hi,
On 24/06/2015 at 11:26:54 -0500, Nishanth Menon wrote :
> I am wrong here - code just returns 0 and ignores err. So, how about
> the following patch instead: (Alexandre, please do let me know if the
> entire series needs to be reposted):
Can you resend just that one as v3? I'll take it right away. Thanks!
> - improvement as suggested
> - Picked up previous acks
> - cleanup in probe does not need dev_pm_clear_wake_irq.
> -->8<---
> From 12367f8edffc25613f6f920d9bd7b69dfed57ce1 Mon Sep 17 00:00:00 2001
> From: Nishanth Menon
> Date: Mon, 22 Jun 2015 14:13:19 -0500
> Subject: [PATCH V3] drivers/rtc/rtc-ds1307.c: Support optional wakeup
> interrupt
> source
>
> With the recent pinctrl-single changes, SoCs such as Texas
> Instrument's OMAP processors can treat wake-up events from deeper idle
> states as interrupts.
>
> Let's add support for the optional second interrupt for wake-up using
> the generic wakeirq support added in commit 4990d4fe327b ("PM /
> Wakeirq: Add automated device wake IRQ handling")
>
> Finally, to pass the wake-up interrupt in the dts file,
> interrupts-extended property needs to be passed.
>
> This is similar in approach to commit 2a0b965cfb6e ("serial: omap: Add
> support for optional wake-up") + ee83bd3b6483 ("serial: omap: Switch
> wake-up interrupt to generic wakeirq")
>
> Acked-by: Tony Lindgren
> Acked-by: Felipe Balbi
> Signed-off-by: Nishanth Menon
> ---
> drivers/rtc/rtc-ds1307.c | 36 +---
> 1 file changed, 33 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
> index b03880fc32b5..e16989c48a90 100644
> --- a/drivers/rtc/rtc-ds1307.c
> +++ b/drivers/rtc/rtc-ds1307.c
> @@ -15,6 +15,9 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> #include
> #include
> #include
> @@ -114,6 +117,7 @@ struct ds1307 {
> #define HAS_ALARM1 /* bit 1 == irq claimed */
> struct i2c_client *client;
> struct rtc_device *rtc;
> + int wakeirq;
> s32 (*read_block_data)(const struct i2c_client *client, u8 command,
> u8 length, u8 *values);
> s32 (*write_block_data)(const struct i2c_client *client, u8 command,
> @@ -1156,6 +1160,8 @@ read_rtc:
> }
>
> if (want_irq) {
> + struct device_node *node = client->dev.of_node;
> +
> err = devm_request_threaded_irq(&client->dev,
> client->irq, NULL, irq_handler,
> IRQF_SHARED | IRQF_ONESHOT,
> @@ -1163,13 +1169,34 @@ read_rtc:
> if (err) {
> client->irq = 0;
> dev_err(&client->dev, "unable to request IRQ!\n");
> - } else {
> + goto no_irq;
> + }
>
> - set_bit(HAS_ALARM, &ds1307->flags);
> - dev_dbg(&client->dev, "got IRQ %d\n", client->irq);
> + set_bit(HAS_ALARM, &ds1307->flags);
> + dev_dbg(&client->dev, "got IRQ %d\n", client->irq);
> +
> + /* Currently supported by OF code only! */
> + if (!node)
> + goto no_irq;
> +
> + err = of_irq_get(node, 1);
> + if (err <= 0) {
> + if (err == -EPROBE_DEFER)
> + goto exit;
> + goto no_irq;
> + }
> + ds1307->wakeirq = err;
> +
> + err = dev_pm_set_dedicated_wake_irq(&client->dev,
> + ds1307->wakeirq);
> + if (err) {
> + dev_err(&client->dev, "unable to setup wakeIRQ %d!\n",
> + err);
> + goto exit;
> }
> }
>
> +no_irq:
> if (chip->nvram_size) {
>
> ds1307->nvram = devm_kzalloc(&client->dev,
> @@ -1213,6 +1240,9 @@ static int ds1307_remove(struct i2c_client *client)
> {
> struct ds1307 *ds1307 = i2c_get_clientdata(client);
>
> + if (ds1307->wakeirq)
> + dev_pm_clear_wake_irq(&client->dev);
> +
> if (test_and_clear_bit(HAS_NVRAM, &ds1307->flags))
> sysfs_remove_bin_file(&client->dev.kobj, ds1307->nvram);
>
> --
> 1.7.9.5
>
> --
> Regards,
> Nishanth Menon
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: drivers/rtc/rtc-ds1307.c: Support optional wakeup interrupt source
Hi Nishanth,
Do you mind rebasing that one so I can apply it?
On 21/08/2014 at 11:12:01 -0500, Nishanth Menon wrote :
> With the recent pinctrl-single changes, SoCs such as Texas
> Instrument's OMAP processors can treat wake-up events from deeper idle
> states as interrupts.
>
> Let's add support for the optional second interrupt for wake-up
> events. And then SoC can wakeup and handle the event using it's
> regular handler.
>
> Finally, to pass the wake-up interrupt in the dts file,
> interrupts-extended property needs to be passed.
>
> This is similar in approach to commit 2a0b965cfb6e ("serial: omap: Add
> support for optional wake-up")
>
> Signed-off-by: Nishanth Menon
> ---
> drivers/rtc/rtc-ds1307.c | 57
> ++
> 1 file changed, 57 insertions(+)
>
> diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
> index f03d5ba..5feedfc 100644
> --- a/drivers/rtc/rtc-ds1307.c
> +++ b/drivers/rtc/rtc-ds1307.c
> @@ -15,6 +15,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -115,6 +117,7 @@ struct ds1307 {
> struct i2c_client *client;
> struct rtc_device *rtc;
> struct work_struct work;
> + int wakeirq;
> s32 (*read_block_data)(const struct i2c_client *client, u8 command,
> u8 length, u8 *values);
> s32 (*write_block_data)(const struct i2c_client *client, u8 command,
> @@ -835,6 +838,34 @@ ds1307_nvram_write(struct file *filp, struct kobject
> *kobj,
>
> /*--*/
>
> +static int ds1307_i2c_suspend(struct i2c_client *client, pm_message_t mesg)
> +{
> + struct ds1307 *ds1307 = i2c_get_clientdata(client);
> + struct device *dev = &client->dev;
> +
> + if (!ds1307->wakeirq)
> + return 0;
> +
> + if (device_may_wakeup(dev))
> + enable_irq(ds1307->wakeirq);
> +
> + return 0;
> +}
> +
> +static int ds1307_i2c_resume(struct i2c_client *client)
> +{
> + struct ds1307 *ds1307 = i2c_get_clientdata(client);
> + struct device *dev = &client->dev;
> +
> + if (!ds1307->wakeirq)
> + return 0;
> +
> + if (device_may_wakeup(dev))
> + disable_irq_nosync(ds1307->wakeirq);
> +
> + return 0;
> +}
> +
> static int ds1307_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> @@ -1116,6 +1147,8 @@ read_rtc:
> }
>
> if (want_irq) {
> + struct device_node *node = client->dev.of_node;
> +
> err = request_irq(client->irq, ds1307_irq, IRQF_SHARED,
> ds1307->rtc->name, client);
> if (err) {
> @@ -1125,6 +1158,28 @@ read_rtc:
>
> set_bit(HAS_ALARM, &ds1307->flags);
> dev_dbg(&client->dev, "got IRQ %d\n", client->irq);
> + if (node)
> + ds1307->wakeirq = irq_of_parse_and_map(node, 1);
> +
> + if (ds1307->wakeirq <= 0)
> + ds1307->wakeirq = 0;
> + else
> + err = devm_request_irq(&client->dev,
> +ds1307->wakeirq,
> +ds1307_irq,
> +IRQF_ONESHOT,
> +ds1307->rtc->name,
> +client);
> + if (err) {
> + dev_err(&client->dev, "unable to get wakeIRQ
> %d\n",
> + err);
> + free_irq(client->irq, client);
> + goto exit;
> + }
> +
> + /* We enable the interrupt only during suspend path */
> + if (ds1307->wakeirq)
> + disable_irq_nosync(ds1307->wakeirq);
> }
> }
>
> @@ -1189,6 +1244,8 @@ static struct i2c_driver ds1307_driver = {
> },
> .probe = ds1307_probe,
> .remove = ds1307_remove,
> + .suspend= ds1307_i2c_suspend,
> + .resume = ds1307_i2c_resume,
> .id_table = ds1307_id,
> };
>
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
On 22/04/2015 at 19:04:52 -0500, Nishanth Menon wrote : > > I fully agree that your patch doesn't change the behaviour for the other > > cases you presented and further clean up is to be done in a separate set > > of patches. > > > Sure, Acked-by: Alexandre Belloni -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
On 21/04/2015 at 20:59:15 -0500, Nishanth Menon wrote : > >> Why is that so? when set alarm is requested for time X, you want > >> interrupt at time X, not an interrupt for previous configured RTC > >> alarm time! > >> > > > > You expect at least an interrupt. > > And you will get an interrupt if the event occurs before the i2c burst > starts. Once the i2cburst does start, you are committing to the new time. > You mean that even if ALM0EN is set after ALM0IF was set to 1, it will trigger the interrupt? I had a look at the MFP output block diagram would let me think that this is the case. I was thinking otherwise before. If that is so, then indeed, your patch is OK. My concern was about the time between ds1307->write_block_data() and i2c_smbus_write_byte_data() which actually calls cond_sched(). I fully agree that your patch doesn't change the behaviour for the other cases you presented and further clean up is to be done in a separate set of patches. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
On 21/04/2015 at 18:58:43 -0500, Nishanth Menon wrote : > > > > Consider the following use case: a platform is setting the RTC alarm > > before going to suspend to ram. Before your patch, it may be woken up > ^^ precisely what I am trying to solve. > > > quite quickly, before expected. After your patch, it may never wake at > > all. > > Why is that so? when set alarm is requested for time X, you want > interrupt at time X, not an interrupt for previous configured RTC > alarm time! > You expect at least an interrupt. > If the time X is > the point when ALM0 is programmed, then you will > get an interrupt. > You are eluding my point. What happens if the alarm expires before ALM0 is programmed? Your system is probably dead because it will never wake up. > If you get an interrupt (like my screenshot shows) because the new > value has not yet been programmed (just because we enabled interrupt > before programming time), it is unexpected event and wrong! > > Another scenario: Take the following time points A < B < C < D > we program at time (A), an interrupt for time (C). > but at time B, we intiate a new time request for time (D). > if we happen to send the first ALM0EN at time C (before programming > D), you will generate an interrupt, but before the irq handler can > handle (since we are doing burst i2c), we program D which clears the > irq status (as can be seen in waveform). > > This does not make sense for a predictable behavior! Yeah, it will > wakeup quickly, but when we go and read irqstatus (ALM0IF), it will be > 0 and nothing will get reported to rtc subsystem. So: > a) we woke up at a time not requested - this is wrong > b) our irq handler has nothing to handle! - this is wrong as well. > > in short, the behavior you are asking for is quiet the wrong behavior! > I agree that an unexpected event is wrong but it is still better than a dead system. I'm not asking to keep the current behaviour. I'm just wanting to try to not introduce another race condition. What about setting ALM0MTH to 0x1F before reading the control registers? You could also read only the first 3 registers as all the others are overwritten. And finally, you only need to write 9 bytes instead of 10 (register 0x10 is reserved). While not eliminating it completely, this will definitively reduce the race condition window. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
Hi, On 20/04/2015 at 19:51:34 -0500, Nishanth Menon wrote : > Alarm interrupt enable register is at offset 0x7, while the time > registers for the alarm follow that. When we program Alarm interrupt > enable prior to programming the time, it is possible that previous > time value could be close or match at the time of alarm enable > resulting in interrupt trigger which is unexpected (and does not match > the time we expect it to trigger). > > To prevent this scenario from occuring, program the ALM0_EN bit only > after the alarm time is appropriately programmed. > > Ofcourse, I2C programming is non-atomic, so there are loopholes where > the interrupt wont trigger if the time requested is in the past at > the time of programming the ALM0_EN bit. However, we will not have > unexpected interrupts while the time is programmed after the interrupt > are enabled. > Do you have more details about the issue you are trying to solve? Consider the following use case: a platform is setting the RTC alarm before going to suspend to ram. Before your patch, it may be woken up quite quickly, before expected. After your patch, it may never wake at all. > Signed-off-by: Nishanth Menon > --- > Changes in v2: > - minor typo fix in comments > - merged up code that I missed committing in > > V1: https://patchwork.kernel.org/patch/6245041/ > > drivers/rtc/rtc-ds1307.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c > index 4ffabb322a9a..3cd4783375a5 100644 > --- a/drivers/rtc/rtc-ds1307.c > +++ b/drivers/rtc/rtc-ds1307.c > @@ -742,17 +742,17 @@ static int mcp794xx_set_alarm(struct device *dev, > struct rtc_wkalrm *t) > regs[6] &= ~MCP794XX_BIT_ALMX_IF; > /* Set alarm match: second, minute, hour, day, date, month. */ > regs[6] |= MCP794XX_MSK_ALMX_MATCH; > - > - if (t->enabled) > - regs[0] |= MCP794XX_BIT_ALM0_EN; > - else > - regs[0] &= ~MCP794XX_BIT_ALM0_EN; > + /* Disable interrupt. We will not enable until completely programmed */ > + regs[0] &= ~MCP794XX_BIT_ALM0_EN; > > ret = ds1307->write_block_data(client, MCP794XX_REG_CONTROL, 10, regs); > if (ret < 0) > return ret; > > - return 0; > + if (!t->enabled) > + return 0; > + regs[0] |= MCP794XX_BIT_ALM0_EN; > + return i2c_smbus_write_byte_data(client, MCP794XX_REG_CONTROL, regs[0]); > } > > static int mcp794xx_alarm_irq_enable(struct device *dev, unsigned int > enabled) > -- > 1.7.9.5 > -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rtc-linux] [PATCH] rtc: OMAP: Add external 32k clock feature
On 10/04/2015 at 13:37:30 -0700, Andrew Morton wrote : > Is there any way in which we can get all systems working properly? If > there's no way of auto-detecting an external oscillator then perhaps a > module parameter is needed. If so, it would be better if the driver > were to default to internal oscillator (ie: current behaviour), and the > module parameter selects the external oscillator. This way, existing > systems are unaffected by the kernel upgrade. > Actually, I would use the common clock framework, allowing to chose between the internal and an external clock source by using the "clocks" property. This would also allow to have the correct reference count on that 32k internal clock. It may not matter now but for example, not doing so became a problem on at91. As a fallback, if no clocks property is available, I would use the internal 32k to keep DT ABI backward compatibility. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] rtc: omap: Unlock and Lock rtc registers before and after register writes
Hi, On 02/04/2015 at 18:14:11 +0530, Lokesh Vutla wrote : > Here is the updated patch. > You should probably send it properly using git send-email, have a look at the --in-reply-to parameter, else, I'm not sure Andrew will be able to pick it up. Thanks! -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] rtc: omap: Unlock and Lock rtc registers before and after register writes
_REG, alm->time.tm_mday);
> @@ -362,6 +392,7 @@ static int omap_rtc_set_alarm(struct device *dev, struct
> rtc_wkalrm *alm)
> rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, reg);
> if (rtc->type->has_irqwakeen)
> rtc_write(rtc, OMAP_RTC_IRQWAKEEN, irqwake_reg);
> + rtc->type->lock(rtc);
>
> local_irq_enable();
>
> @@ -391,6 +422,7 @@ static void omap_rtc_power_off(void)
> unsigned long now;
> u32 val;
>
> + rtc->type->unlock(rtc);
> /* enable pmic_power_en control */
> val = rtc_readl(rtc, OMAP_RTC_PMIC_REG);
> rtc_writel(rtc, OMAP_RTC_PMIC_REG, val | OMAP_RTC_PMIC_POWER_EN_EN);
> @@ -423,6 +455,7 @@ static void omap_rtc_power_off(void)
> val = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
> rtc_writel(rtc, OMAP_RTC_INTERRUPTS_REG,
> val | OMAP_RTC_INTERRUPTS_IT_ALARM2);
> + rtc->type->lock(rtc);
>
> /*
>* Wait for alarm to trigger (within two seconds) and external PMIC to
> @@ -442,17 +475,21 @@ static struct rtc_class_ops omap_rtc_ops = {
>
> static const struct omap_rtc_device_type omap_rtc_default_type = {
> .has_power_up_reset = true,
> + .lock = default_rtc_lock,
> + .unlock = default_rtc_unlock,
> };
>
> static const struct omap_rtc_device_type omap_rtc_am3352_type = {
> .has_32kclk_en = true,
> - .has_kicker = true,
> .has_irqwakeen = true,
> .has_pmic_mode = true,
> + .lock = am3352_rtc_lock,
> + .unlock = am3352_rtc_unlock,
> };
>
> static const struct omap_rtc_device_type omap_rtc_da830_type = {
> - .has_kicker = true,
> + .lock = am3352_rtc_lock,
> + .unlock = am3352_rtc_unlock,
> };
>
> static const struct platform_device_id omap_rtc_id_table[] = {
> @@ -527,10 +564,7 @@ static int __init omap_rtc_probe(struct platform_device
> *pdev)
> pm_runtime_enable(&pdev->dev);
> pm_runtime_get_sync(&pdev->dev);
>
> - if (rtc->type->has_kicker) {
> - rtc_writel(rtc, OMAP_RTC_KICK0_REG, KICK0_VALUE);
> - rtc_writel(rtc, OMAP_RTC_KICK1_REG, KICK1_VALUE);
> - }
> + rtc->type->unlock(rtc);
>
> /*
>* disable interrupts
> @@ -593,6 +627,8 @@ static int __init omap_rtc_probe(struct platform_device
> *pdev)
> if (reg != new_ctrl)
> rtc_write(rtc, OMAP_RTC_CTRL_REG, new_ctrl);
>
> + rtc->type->lock(rtc);
> +
> device_init_wakeup(&pdev->dev, true);
>
> rtc->rtc = devm_rtc_device_register(&pdev->dev, pdev->name,
> @@ -626,8 +662,7 @@ static int __init omap_rtc_probe(struct platform_device
> *pdev)
>
> err:
> device_init_wakeup(&pdev->dev, false);
> - if (rtc->type->has_kicker)
> - rtc_writel(rtc, OMAP_RTC_KICK0_REG, 0);
> + rtc->type->lock(rtc);
> pm_runtime_put_sync(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
>
> @@ -646,11 +681,11 @@ static int __exit omap_rtc_remove(struct
> platform_device *pdev)
>
> device_init_wakeup(&pdev->dev, 0);
>
> + rtc->type->unlock(rtc);
> /* leave rtc running, but disable irqs */
> rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, 0);
>
> - if (rtc->type->has_kicker)
> - rtc_writel(rtc, OMAP_RTC_KICK0_REG, 0);
> + rtc->type->lock(rtc);
>
> /* Disable the clock/module */
> pm_runtime_put_sync(&pdev->dev);
> @@ -666,6 +701,7 @@ static int omap_rtc_suspend(struct device *dev)
>
> rtc->interrupts_reg = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
>
> + rtc->type->unlock(rtc);
> /*
>* FIXME: the RTC alarm is not currently acting as a wakeup event
>* source on some platforms, and in fact this enable() call is just
> @@ -675,6 +711,7 @@ static int omap_rtc_suspend(struct device *dev)
> enable_irq_wake(rtc->irq_alarm);
> else
> rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, 0);
> + rtc->type->lock(rtc);
>
> /* Disable the clock/module */
> pm_runtime_put_sync(dev);
> @@ -689,10 +726,12 @@ static int omap_rtc_resume(struct device *dev)
> /* Enable the clock/module so that we can access the registers */
> pm_runtime_get_sync(dev);
>
> + rtc->type->unlock(rtc);
> if (device_may_wakeup(dev))
> disable_irq_wake(rtc->irq_alarm);
> else
> rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, rtc->interrupts_reg);
> + rtc->type->lock(rtc);
>
> return 0;
> }
> @@ -709,9 +748,11 @@ static void omap_rtc_shutdown(struct platform_device
> *pdev)
>* Keep the ALARM interrupt enabled to allow the system to power up on
>* alarm events.
>*/
> + rtc->type->unlock(rtc);
> mask = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
> mask &= OMAP_RTC_INTERRUPTS_IT_ALARM;
> rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, mask);
> + rtc->type->lock(rtc);
> }
>
> static struct platform_driver omap_rtc_driver = {
> --
> 1.9.1
>
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rtc-linux] [PATCH 3/3] rtc: omap: use module_platform_driver
On 01/04/2015 at 11:24:58 +0530, Lokesh Vutla wrote :
> module_platform_driver_probe() prevents driver from requesting probe deferral.
> So using module_platform_drive() to support probe deferral.
>
> Signed-off-by: Lokesh Vutla
Acked-by: Alexandre Belloni
> ---
> drivers/rtc/rtc-omap.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index 96cc613..a4965a0 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -510,7 +510,7 @@ static const struct of_device_id omap_rtc_of_match[] = {
> };
> MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
>
> -static int __init omap_rtc_probe(struct platform_device *pdev)
> +static int omap_rtc_probe(struct platform_device *pdev)
> {
> struct omap_rtc *rtc;
> struct resource *res;
> @@ -745,6 +745,7 @@ static void omap_rtc_shutdown(struct platform_device
> *pdev)
> }
>
> static struct platform_driver omap_rtc_driver = {
> + .probe = omap_rtc_probe,
> .remove = __exit_p(omap_rtc_remove),
> .shutdown = omap_rtc_shutdown,
> .driver = {
> @@ -755,7 +756,7 @@ static struct platform_driver omap_rtc_driver = {
> .id_table = omap_rtc_id_table,
> };
>
> -module_platform_driver_probe(omap_rtc_driver, omap_rtc_probe);
> +module_platform_driver(omap_rtc_driver);
>
> MODULE_ALIAS("platform:omap_rtc");
> MODULE_AUTHOR("George G. Davis (and others)");
> --
> 1.9.1
>
> --
> --
> You received this message because you are subscribed to "rtc-linux".
> Membership options at http://groups.google.com/group/rtc-linux .
> Please read http://groups.google.com/group/rtc-linux/web/checklist
> before submitting a driver.
> ---
> You received this message because you are subscribed to the Google Groups
> "rtc-linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rtc-linux+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rtc-linux] [PATCH 1/3] rtc: omap: Unlock and Lock rtc registers before and after register writes
Hi,
On 01/04/2015 at 11:24:56 +0530, Lokesh Vutla wrote :
> RTC module contains a kicker mechanism to prevent any spurious writes
> from changing the register values. This mechanism requires two MMR
> writes to the KICK0 and KICK1 registers with exact data values
> before the kicker lock mechanism is released.
>
> Currently the driver release the lock in the probe and leaves it enabled
> until the rtc driver removal. This eliminates the idea of preventing
> spurious writes when RTC driver is loaded.
> So implement rtc lock and unlock functions before and after register writes.
>
> Signed-off-by: Lokesh Vutla
> ---
> - This is as advised by Paul to implement lock and unlock functions in
> the driver and not to unlock and leave it in probe.
> The same discussion can be seen here:
> http://www.mail-archive.com/linux-omap%40vger.kernel.org/msg111588.html
>
> drivers/rtc/rtc-omap.c | 46 ++
> 1 file changed, 38 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index 8e5851a..96cc613 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -156,6 +156,22 @@ static inline void rtc_writel(struct omap_rtc *rtc,
> unsigned int reg, u32 val)
> writel(val, rtc->base + reg);
> }
>
> +static void rtc_unlock(struct omap_rtc *rtc)
> +{
> + if (rtc->type->has_kicker) {
Instead of testing for has_kicker each time, I would add .lock and
.unlock to omap_rtc_device_type and directly use rtc->type->lock and
rtc->type->unlock.
> + rtc_writel(rtc, OMAP_RTC_KICK0_REG, KICK0_VALUE);
> + rtc_writel(rtc, OMAP_RTC_KICK1_REG, KICK1_VALUE);
> + }
> +}
> +
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rtc-linux] [PATCH 2/3] rtc: omap: Update Kconfig for OMAP RTC
On 01/04/2015 at 11:24:57 +0530, Lokesh Vutla wrote : > RTC is present in AM43xx and DRA7xx also. Updating the Kconfig > to depend on ARCH_OMAP or ARCH_DAVINCI > > Signed-off-by: Lokesh Vutla Acked-by: Alexandre Belloni > --- > drivers/rtc/Kconfig | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig > index b5b5c3d..40faf56 100644 > --- a/drivers/rtc/Kconfig > +++ b/drivers/rtc/Kconfig > @@ -1121,11 +1121,11 @@ config RTC_DRV_IMXDI > will be called "rtc-imxdi". > > config RTC_DRV_OMAP > - tristate "TI OMAP1" > - depends on ARCH_OMAP15XX || ARCH_OMAP16XX || ARCH_OMAP730 || > ARCH_DAVINCI_DA8XX || SOC_AM33XX > + tristate "TI OMAP Real Time Clock" > + depends on ARCH_OMAP || ARCH_DAVINCI > help > Say "yes" here to support the on chip real time clock > - present on TI OMAP1, AM33xx and DA8xx/OMAP-L13x. > + present on TI OMAP1, AM33xx, DA8xx/OMAP-L13x, AM43xx and DRA7xx. > > This driver can also be built as a module, if so, module > will be called rtc-omap. > -- > 1.9.1 > > -- > -- > You received this message because you are subscribed to "rtc-linux". > Membership options at http://groups.google.com/group/rtc-linux . > Please read http://groups.google.com/group/rtc-linux/web/checklist > before submitting a driver. > --- > You received this message because you are subscribed to the Google Groups > "rtc-linux" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rtc-linux+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/7] Enable L2 cache support on Exynos4210/4x12 SoCs
Hi, On 14/01/2015 at 16:21:50 +, Russell King - ARM Linux wrote : > On Wed, Jan 14, 2015 at 04:46:03PM +0100, Alexandre Belloni wrote: > > Hi, > > > > This patch set hasn't moved since while. We actually need patch 4 to > > properly configure prefetch on sama5d4. What would be needed to come to > > an agreement ? > > What do you mean "hasn't moved since a while" - there has been movement. > It was discovered that it breaks OMAP4 platforms. > > Since then, work has been done to resolve that breakage, and I've merged > the recent patch set into my tree for further regression testing, and > I'm going to push it out to linux-next later this week. > Indeed, my searching skills are not great. I was actually looking for mails from Tomasz but he is not taking care of it now... Thanks for the info! -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/7] Enable L2 cache support on Exynos4210/4x12 SoCs
| 14 ++ > arch/arm/include/asm/outercache.h | 3 + > arch/arm/kernel/irq.c | 3 +- > arch/arm/mach-exynos/firmware.c| 50 + > arch/arm/mach-exynos/sleep.S | 46 + > arch/arm/mm/cache-l2x0.c | 255 > - > 8 files changed, 294 insertions(+), 96 deletions(-) > > -- > 1.9.2 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/7] ARM: l2c: Add support for overriding prefetch settings
On 19/09/2014 at 17:39:32 +0100, Russell King - ARM Linux wrote : > On Fri, Sep 19, 2014 at 11:50:01AM +0200, Alexandre Belloni wrote: > > On 26/08/2014 at 16:17:57 +0200, Tomasz Figa wrote : > > > Firmware on certain boards (e.g. ODROID-U3) can leave incorrect L2C > > > prefetch > > > settings configured in registers leading to crashes if L2C is enabled > > > without overriding them. This patch introduces bindings to enable > > > prefetch settings to be specified from DT and necessary support in the > > > driver. > > > > > > Signed-off-by: Tomasz Figa > > > > Tested-by: Alexandre Belloni > > > > It is working and useful on Atmel's sama5d4 were the bootloader is not > > configuring the L2C prefetch. However, I'm wondering whether we should > > add support for setting L310_PREFETCH_CTRL_DATA_PREFETCH and > > L310_PREFETCH_CTRL_INSTR_PREFETCH. I'm currently doing it by using > > ".l2c_aux_val= L310_AUX_CTRL_DATA_PREFETCH | > > L310_AUX_CTRL_INSTR_PREFETCH" (those are the same bits) but this has the > > disadvantage of displaying the "L2C: platform modifies aux control > > register:" twice. > > The L2C documentation, freely available from the ARM infocentre website, > has the answer to this for you. > > The two bits in the prefetch control register which control the data > and instruction prefetching are aliases of the aux control register. > If you set them to a value in one register, they are reflected in the > other. > > The reason for that is that once the L2 cache is enabled, writes to > the aux control register are no longer permitted, but it's safe to > enable and disable the prefetching with the cache already enabled. > This reason is even stated in the documentation. > Yeah, so my question still holds, should we have an other way to enable/disable I/D prefetch by adding two other DT bindings ? -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/7] ARM: l2c: Add support for overriding prefetch settings
On 26/08/2014 at 16:17:57 +0200, Tomasz Figa wrote :
> Firmware on certain boards (e.g. ODROID-U3) can leave incorrect L2C prefetch
> settings configured in registers leading to crashes if L2C is enabled
> without overriding them. This patch introduces bindings to enable
> prefetch settings to be specified from DT and necessary support in the
> driver.
>
> Signed-off-by: Tomasz Figa
Tested-by: Alexandre Belloni
It is working and useful on Atmel's sama5d4 were the bootloader is not
configuring the L2C prefetch. However, I'm wondering whether we should
add support for setting L310_PREFETCH_CTRL_DATA_PREFETCH and
L310_PREFETCH_CTRL_INSTR_PREFETCH. I'm currently doing it by using
".l2c_aux_val= L310_AUX_CTRL_DATA_PREFETCH |
L310_AUX_CTRL_INSTR_PREFETCH" (those are the same bits) but this has the
disadvantage of displaying the "L2C: platform modifies aux control
register:" twice.
> + if (!of_property_read_u32(np, "arm,prefetch-offset", &val)) {
> + prefetch &= ~L310_PREFETCH_CTRL_OFFSET_MASK;
> + prefetch |= val & L310_PREFETCH_CTRL_OFFSET_MASK;
> + }
> +
While you use val directly here, later, while printing the offset, val +
1 is used. Maybe it would be better to have the same number in both
places, else you end up with having "arm,prefetch-offset = <1>" in your
DT and the kernel printing "L2C-310 ID prefetch enabled, offset 2
lines".
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 resend 00/11] improve PWM lookup support without device tree
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 resend 01/11] pwm: add period and polarity to struct pwm_lookup
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
---
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 resend 11/11] backlight: pwm_bl: retrieve configured pwm period
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
---
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 resend 04/11] ARM: OMAP3: Beagle: initialize all the struct pwm_lookup members
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
---
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 resend 08/11] ARM: shmobile: Armadillo 800 EVA: use PWM_LOOKUP to initialize struct pwm_lookup
Signed-off-by: Alexandre Belloni
Acked-by: Simon Horman
---
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 = 3,
- .polarity = PWM_POLARITY_INVERSED,
- },
+ PWM_LOOKUP("renesas-tpu-pwm", 2, "pwm-backlight.0", NULL,
+ 3, PWM_POLARITY_INVERSED),
};
/* LCDC and backlight */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 resend 10/11] leds: leds-pwm: retrieve configured pwm period
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 --- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 resend 09/11] ARM: pxa: hx4700: use PWM_LOOKUP to initialize struct pwm_lookup
Signed-off-by: Alexandre Belloni
---
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 resend 02/11] ARM: shmobile: Armadillo 800 EVA: initialize all struct pwm_lookup members
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
Acked-by: Simon Horman
---
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
#include
#include
-#include
+#include
#include
#include
#include
@@ -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 = 3,
+ .polarity = PWM_POLARITY_INVERSED,
+ },
};
/* LCDC and backlight */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 resend 06/11] pwm: modify PWM_LOOKUP to initialize all struct pwm_lookup members
Now that PWM_LOOKUP is not used anymore, modify it to initialize all the
members of struct pwm_lookup.
Signed-off-by: Alexandre Belloni
---
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,
+ 5, 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 resend 03/11] pwm: renesas-tpu: remove useless struct tpu_pwm_platform_data
The struct is not used anymore and the polarity initialization will be taken
care of by the PWM core.
Signed-off-by: Alexandre Belloni
---
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
#include
#include
-#include
#include
#include
#include
#include
#include
+#define TPU_CHANNEL_MAX4
+
#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..
--- 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
-
-#define TPU_CHANNEL_MAX4
-
-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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 resend 05/11] ARM: pxa: hx4700: initialize all the struct pwm_lookup members
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
---
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 resend 07/11] ARM: OMAP3: Beagle: use PWM_LOOKUP to initialize struct pwm_lookup
Signed-off-by: Alexandre Belloni
---
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 00/11] improve PWM lookup support without device tree
Hello Thierry, Do you know when you will have some time to review that patch series ? On 14/04/2014 at 23:59:42 +0200, Alexandre Belloni wrote : > Hi, > > 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.8.3.2 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-leds" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 02/11] ARM: shmobile: Armadillo 800 EVA: initialize all struct pwm_lookup members
Initializing all the struct 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
---
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
#include
#include
-#include
+#include
#include
#include
#include
@@ -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 = 3,
+ .polarity = PWM_POLARITY_INVERSED,
+ },
};
/* LCDC and backlight */
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 04/11] ARM: OMAP3: Beagle: initialize all the struct pwm_lookup members
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
---
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.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 00/11] improve PWM lookup support without device tree
Hi, 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.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 03/11] pwm: renesas-tpu: remove useless struct tpu_pwm_platform_data
The struct tpu_pwm_platform_data is not used anymore and the polarity
initialization will be taken care of by the PWM core.
Signed-off-by: Alexandre Belloni
---
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
#include
#include
-#include
#include
#include
#include
#include
#include
+#define TPU_CHANNEL_MAX4
+
#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..
--- 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
-
-#define TPU_CHANNEL_MAX4
-
-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.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 01/11] pwm: add period and polarity to struct pwm_lookup
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.
The period and polarity can be set unconditionally as the default is 0 anyway.
Signed-off-by: Alexandre Belloni
---
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.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 10/11] leds: leds-pwm: retrieve configured pwm period
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 --- 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.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 06/11] pwm: modify PWM_LOOKUP to initialize all struct pwm_lookup members
Now that PWM_LOOKUP is not used anymore, modify it to initialize all the
members of struct pwm_lookup.
Signed-off-by: Alexandre Belloni
---
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,
+ 5, 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.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 08/11] ARM: shmobile: Armadillo 800 EVA: use PWM_LOOKUP to initialize struct pwm_lookup
Signed-off-by: Alexandre Belloni
---
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 = 3,
- .polarity = PWM_POLARITY_INVERSED,
- },
+ PWM_LOOKUP("renesas-tpu-pwm", 2, "pwm-backlight.0", NULL,
+ 3, PWM_POLARITY_INVERSED),
};
/* LCDC and backlight */
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 09/11] ARM: pxa: hx4700: use PWM_LOOKUP to initialize struct pwm_lookup
Signed-off-by: Alexandre Belloni
---
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.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 07/11] ARM: OMAP3: Beagle: use PWM_LOOKUP to initialize struct pwm_lookup
Signed-off-by: Alexandre Belloni
---
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.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 05/11] ARM: pxa: hx4700: initialize all the struct pwm_lookup members
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
---
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.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 11/11] backlight: pwm_bl: retrieve configured pwm period
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
---
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.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] pwm: use PWM_LOOKUP to set the period and polarity
On 10/04/2014 at 08:15:49 +0900, Simon Horman wrote : > On Wed, Apr 09, 2014 at 08:04:09PM +0200, Alexandre Belloni wrote: > > Now that the PWM core is able to set the period and polarity based on > > the lookup table, add those to PWM_LOOKUP to ease their usage. > > I would prefer if this change was made in a non-atomic manner. > > 1. Add new infrastructure > 2. Update users individually > 3. Remove old infrastructure > I agree this would be better but I'm not sure how you can modify a macro without renaming it or changing it everywhere at once. Like said, I'm open to creating a new macro. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] pwm: add period and polarity to struct pwm_lookup
On 09/04/2014 at 20:37:06 +0100, Russell King - ARM Linux wrote : > On Wed, Apr 09, 2014 at 08:04:08PM +0200, Alexandre Belloni wrote: > > 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 > > --- > > drivers/pwm/core.c | 5 + > > include/linux/pwm.h | 2 ++ > > 2 files changed, 7 insertions(+) > > > > diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c > > index a80471399c20..206e5996359c 100644 > > --- a/drivers/pwm/core.c > > +++ b/drivers/pwm/core.c > > @@ -663,6 +663,11 @@ struct pwm_device *pwm_get(struct device *dev, const > > char *con_id) > > > > 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); > > Clearly, this is not right. Returning while leaving the mutex locked? > No. > Sure, I will fix that crap, sorry about that and thanks for pointing it out. > The second issue is... with _just_ this patch applied, we end up with > "period" and "polarity" presumably initialised to zero, which means we > now end up with the above explicitly setting the period and polarity as > such. Isn't that going to change the behaviour of this? > I actually checked that. For the polarity, for now, it is assumed that it is normal unless specified otherwise. The only driver that was supporting inverting it using platform_data is pwm-renesas-tpu. It is used by board-armadillo800eva.c that I am modifying now (and I just now realise that I forgot to invert it). The only PWM controller that I know of that by default has its polarity inversed is the allwinner one and in the driver I submitted, I actually switch it to normal polarity in the probe instead of e.g. doing pwm->polarity = PWM_POLARITY_INVERSED; For the period, all the driver are assuming 0 after initialization. I think this is not specified. If you think that may be a concern then I suggest creating another macro and using a bitfield to know which value is set. I would also argue that when using device tree, of_pwm_xlate_with_flags() will set the period and the polarity unconditionally, this is replicating that behaviour. However, I could agree that we may need to test for pwm->chip->ops->set_polarity before calling pwm_set_polarity as we will get an error if it is NULL (but we actually discard that return value). -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] improve pwm lookup support without device tree
Hi, a small patch set as suggested byt Thierry to make lokkup with the lookup table instead of device tree bahve more like when using device tree. The first patch adds a period annd a polarity member to the lookup table and use those to set period and polarity. The second patch changes PWM_LOOKUP to set period an polarity. I was wondering about adding a new macro to d that but the number of boards using it is limited (only 3) so I guess it is ok to do that now. The final goal would be to get rid of .pwm_period_ns in leds-pwm and pwm_bl. Alexandre Belloni (2): pwm: add period and polarity to struct pwm_lookup pwm: use PWM_LOOKUP to set the period and polarity 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 | 3 ++- drivers/pwm/core.c | 5 + include/linux/pwm.h| 6 +- 6 files changed, 18 insertions(+), 5 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] pwm: use PWM_LOOKUP to set the period and polarity
Now that the PWM core is able to set the period and polarity based on
the lookup table, add those to PWM_LOOKUP to ease their usage.
Signed-off-by: Alexandre Belloni
---
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 | 3 ++-
include/linux/pwm.h| 4 +++-
5 files changed, 11 insertions(+), 5 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,
+ 5, PWM_POLARITY_NORMAL),
};
static void __init board_init(void)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index d6ed819ff15c..54c135a5b4f7 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -61,7 +61,8 @@
static struct pwm_lookup pwm_lookup[] = {
/* LEDB -> PMU_STAT */
- PWM_LOOKUP("twl-pwmled", 1, "leds_pwm", "beagleboard::pmu_stat"),
+ PWM_LOOKUP("twl-pwmled", 1, "leds_pwm", "beagleboard::pmu_stat",
+ 7812500, PWM_POLARITY_NORMAL),
};
static struct led_pwm pwm_leds[] = {
diff --git a/arch/arm/mach-pxa/hx4700.c b/arch/arm/mach-pxa/hx4700.c
index a7c30eb0c8db..c66ad4edc5e3 100644
--- a/arch/arm/mach-pxa/hx4700.c
+++ b/arch/arm/mach-pxa/hx4700.c
@@ -574,7 +574,8 @@ static struct platform_device backlight = {
};
static struct pwm_lookup hx4700_pwm_lookup[] = {
- PWM_LOOKUP("pxa27x-pwm.1", 0, "pwm-backlight", NULL),
+ PWM_LOOKUP("pxa27x-pwm.1", 0, "pwm-backlight", NULL,
+ 30923, PWM_POLARITY_NORMAL),
};
/*
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c
b/arch/arm/mach-shmobile/board-armadillo800eva.c
index 2858f380beae..e2c4c5010f19 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -416,7 +416,8 @@ static struct platform_device pwm_device = {
};
static struct pwm_lookup pwm_lookup[] = {
- PWM_LOOKUP("renesas-tpu-pwm", 2, "pwm-backlight.0", NULL),
+ PWM_LOOKUP("renesas-tpu-pwm", 2, "pwm-backlight.0", NULL,
+ 3, PWM_POLARITY_NORMAL),
};
/* LCDC and backlight */
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.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] pwm: add period and polarity to struct pwm_lookup
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
---
drivers/pwm/core.c | 5 +
include/linux/pwm.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index a80471399c20..206e5996359c 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -663,6 +663,11 @@ struct pwm_device *pwm_get(struct device *dev, const char
*con_id)
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);
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.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/8] wilink: add device tree support
On 28/02/2014 at 08:26:46 +0100, Yegor Yefremov wrote : > > What is the state of the series? Who is now responsible for the > patches? What issues were still not handled? > We probably want to end that discussion before taking those bindings in: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-February/232185.html I've hit the issue, precisely using those bindings. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: DTS: SAMA5: Add PMU support
ARM Performance Monitor Units are available on the sama5d3, add the support in
the dtsi.
Tested with perf and oprofile on the sama5d31ek.
Signed-off-by: Alexandre Belloni
---
arch/arm/boot/dts/sama5d3.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index a1d5e25..afa68ac 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -48,6 +48,11 @@
};
};
+ pmu {
+ compatible = "arm,cortex-a5-pmu";
+ interrupts = <46 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
memory {
reg = <0x2000 0x800>;
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: DTS: AM33XX: Add PMU support
ARM Performance Monitor Units are available on the am33xx, add the support in
the dtsi.
Tested with perf and oprofile on a regular beaglebone.
Signed-off-by: Alexandre Belloni
---
arch/arm/boot/dts/am33xx.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..cfeac96 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -53,6 +53,11 @@
};
};
+ pmu {
+ compatible = "arm,cortex-a8-pmu";
+ interrupts = <3>;
+ };
+
/*
* The soc node represents the soc top level view. It is uses for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
