Re: New build warnings
On Mon, Sep 10, 2012 at 02:42:37PM +0800, Mark Brown wrote: > On Mon, Sep 10, 2012 at 08:40:02AM +0200, Uwe Kleine-König wrote: > > > Message-id: 201208141241.51379.a...@arndb.de > > This is illegible, did the message have a subject line or other content > that a human might understand? Just as with commit IDs you should > *always* provide a human readable version, message IDs are even worse > than commit IDs in this respect. The full headers are: Date: Tue, 14 Aug 2012 12:41:50 + From: Arnd Bergmann To: Axel Lin Cc: Mark Brown , Rajendra Nayak , Tero Kristo , Uwe Kleine-König Subject: [PATCH] regulator: twl: make twl_info tables const Message-Id: <201208141241.51379.a...@arndb.de> It used to be possible to get a posting by message id via: http://mid.gmane.org/201208141241.51379.a...@arndb.de but as this message was not send to a mailing list this doesn't work here and even for public mails this failed most of the time for me in the past. Other than that in Mutt you can search using ~i 201208141241.51379.a...@arndb.de as search string, for notmuch it's id:201208141241.51379.a...@arndb.de . Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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] pinctrl: pinctrl-single: Make sure we do not change bits outside of mask
On Wed, Sep 5, 2012 at 11:01 AM, Peter Ujfalusi wrote: > Signed-off-by: Peter Ujfalusi Applied with Tony's ACK. Yours, Linus Walleij -- 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] pinctrl: pinctrl-single: Add pinctrl-single,bits type of mux
On Wed, Sep 5, 2012 at 11:01 AM, Peter Ujfalusi wrote: > With pinctrl-single,bits it is possible to update just part of the register > within the pinctrl-single,function-mask area. > This is useful when one register configures mmore than one pin's mux. > > pinctrl-single,bits takes three parameters: > > > Signed-off-by: Peter Ujfalusi Do we have a conclusion on this patch 2/2? I'm holding it back until Tony explicitly ACKs it for now. Yours, Linus Walleij -- 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: New build warnings
On Mon, Sep 10, 2012 at 09:05:47AM +0200, Uwe Kleine-König wrote: > Subject: [PATCH] regulator: twl: make twl_info tables const This is in my drivers branch and in -next, according to git it was applied on Tuesday, so I'm not sure what you're querying here? > It used to be possible to get a posting by message id via: > Other than that in Mutt you can search using > as search string, for notmuch it's All of which rely on some combination of live internet access or a copy of the message and don't work terribly well if those are missing due to using a mailing list archive or whatever (and even when they do work they require people to go away and fire up something to do a search). Making things directly readable by humans really is much better. -- 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 RESEND] arm/dts: AM33XX: Add SPI device tree data
On Fri, Sep 07, 2012 at 18:29:36, Porter, Matt wrote:
> On Thu, Sep 06, 2012 at 12:30:15PM +0530, Philip, Avinash wrote:
> > Add McSPI data node to AM33XX device tree file. The McSPI module (and so
> > as the driver) is reused from OMAP4.
> >
> > Signed-off-by: Philip, Avinash
> > ---
> > Resenting patch because ARM & OMAP mailing list was not copied.
> >
> > :100644 100644 bb31bff... 6b469bd... M arch/arm/boot/dts/am33xx.dtsi
> > arch/arm/boot/dts/am33xx.dtsi | 25 +
> > 1 files changed, 25 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> > index bb31bff..6b469bd 100644
> > --- a/arch/arm/boot/dts/am33xx.dtsi
> > +++ b/arch/arm/boot/dts/am33xx.dtsi
> > @@ -210,5 +210,30 @@
> > interrupt-parent = <&intc>;
> > interrupts = <91>;
> > };
> > +
> > + spi0: spi@4803 {
> > + compatible = "ti,omap4-mcspi";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0x483 0x400>;
>
> Please fix this typo, should be 0x4803.
>
> With the typo fixed, it's working on bone for me:
Thanks for review and testing.
I didn't notice the issue as currently hwmod fills up reg
resource data & hence I missed it.
I will correct & re-send.
Thanks
Avinash
>
> Tested-by: Matt Porter
>
> -Matt
>
--
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: [RFC PATCH v2] OMAPDSS: Fix IRQ unregister race
On Sat, 2012-09-08 at 18:05 +0300, Dimitar Dimitrov wrote:
> Very rare kernel crashes are reported on a custom OMAP4 board. Kernel
> panics due to corrupted completion structure while executing
> dispc_irq_wait_handler(). Excerpt from kernel log:
>
> Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP
> Unable to handle kernel paging request at virtual address 00400130
> ...
> PC is at 0xebf205bc
> LR is at __wake_up_common+0x54/0x94
> ...
> (__wake_up_common+0x0/0x94)
> (complete+0x0/0x60)
> (dispc_irq_wait_handler.36902+0x0/0x14)
> (omap_dispc_irq_handler+0x0/0x354)
> (handle_irq_event_percpu+0x0/0x188)
> (handle_irq_event+0x0/0x64)
> (handle_fasteoi_irq+0x0/0x10c)
> (generic_handle_irq+0x0/0x48)
> (asm_do_IRQ+0x0/0xc0)
>
> DISPC IRQ executes callbacks with dispc.irq_lock released. Hence
> unregister_isr() and DISPC IRQ might be running in parallel on different
> CPUs. So there is a chance that a callback is executed even though it
> has been unregistered. As omap_dispc_wait_for_irq_timeout() declares a
> completion on stack, the dispc_irq_wait_handler() callback might try to
> access a completion structure that is invalid. This leads to crashes and
> hangs.
>
> Solution is to divide unregister calls into two sets:
> 1. Non-strict unregistering of callbacks. Callbacks could safely be
> executed after unregistering them. This is the case with unregister
> calls from the IRQ handler itself.
> 2. Strict (synchronized) unregistering. Callbacks are not allowed
> after unregistering. This is the case with completion waiting.
>
> The above solution should satisfy one of the original intentions of the
> driver: callbacks should be able to unregister themselves.
>
> Also fix DSI IRQ unregister which has similar logic to DISPC IRQ handling.
>
> Signed-off-by: Dimitar Dimitrov
> ---
>
> WARNING: This bug is quite old. The patch has been tested on v3.0. No testing
> has been done after rebasing to v3.6. Hence the RFC tag. Hopefully someone
> will beat me in testing with latest linux-omap/master.
>
> Changes since v1 per Tomi Valkeinen's comments:
> - Don't rename omap_dispc_unregister_isr, just introduce nosync variant.
> - Apply the same fix for DSI IRQ which suffers from the same race condition.
I made a quick test and works for me, although I haven't encountered the
problem itself.
Some mostly cosmetic comments below.
This seems to apply cleanly to v3.4+ kernels, but not earlier ones. Do
you want to make the needed modifications and mail this and the modified
patches for stable kernels also? I can do that also if you don't want
to.
> drivers/staging/omapdrm/omap_plane.c |2 +-
> drivers/video/omap2/dss/apply.c |2 +-
> drivers/video/omap2/dss/dispc.c | 45
> +-
> drivers/video/omap2/dss/dsi.c| 19 ++
> include/video/omapdss.h |1 +
> 5 files changed, 61 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/staging/omapdrm/omap_plane.c
> b/drivers/staging/omapdrm/omap_plane.c
> index 7997be7..8d8aa5b 100644
> --- a/drivers/staging/omapdrm/omap_plane.c
> +++ b/drivers/staging/omapdrm/omap_plane.c
> @@ -82,7 +82,7 @@ static void dispc_isr(void *arg, uint32_t mask)
> struct omap_plane *omap_plane = to_omap_plane(plane);
> struct omap_drm_private *priv = plane->dev->dev_private;
>
> - omap_dispc_unregister_isr(dispc_isr, plane,
> + omap_dispc_unregister_isr_nosync(dispc_isr, plane,
> id2irq[omap_plane->ovl->id]);
>
> queue_work(priv->wq, &omap_plane->work);
> diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
> index 0fefc68..9386834 100644
> --- a/drivers/video/omap2/dss/apply.c
> +++ b/drivers/video/omap2/dss/apply.c
> @@ -847,7 +847,7 @@ static void dss_unregister_vsync_isr(void)
> for (i = 0; i < num_mgrs; ++i)
> mask |= dispc_mgr_get_framedone_irq(i);
>
> - r = omap_dispc_unregister_isr(dss_apply_irq_handler, NULL, mask);
> + r = omap_dispc_unregister_isr_nosync(dss_apply_irq_handler, NULL, mask);
> WARN_ON(r);
>
> dss_data.irq_enabled = false;
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index ee9e296..a67d92c 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -2421,8 +2421,8 @@ static void dispc_mgr_enable_digit_out(bool enable)
> enable ? "start" : "stop");
> }
>
> - r = omap_dispc_unregister_isr(dispc_disable_isr, &frame_done_completion,
> - irq_mask);
> + r = omap_dispc_unregister_isr(dispc_disable_isr,
> + &frame_done_completion, irq_mask);
This change is not needed.
> if (r)
> DSSERR("failed to unregister %x isr\n", irq_mask);
>
> @@ -3320,7 +3320,8 @@ err:
> }
> EXPORT_SYMBOL(omap_dispc_register_isr);
>
> -int omap
Re: [PATCH v3 1/8] ARM/dts: omap2: Add McBSP entries for OMAP2420 and OMAP2430 SoC
Hi Tony,
On 09/08/2012 12:29 AM, Tony Lindgren wrote:
> * Peter Ujfalusi [120905 04:59]:
>> +
>> +ocp {
>> +mcbsp1: mcbsp@48074000 {
>> +compatible = "ti,omap2420-mcbsp";
>> +reg = <0x48074000 0xff>;
>> +reg-names = "mpu";
>> +interrupts = <59>, /* TX interrupt */
>> + <60>; /* RX interrupt */
>> +interrupt-names = "tx", "rx";
>> +interrupt-parent = <&intc>;
>> +ti,hwmods = "mcbsp1";
>> +};
>> +
>> +mcbsp2: mcbsp@48076000 {
>> +compatible = "ti,omap2420-mcbsp";
>> +reg = <0x48076000 0xff>;
>> +reg-names = "mpu";
>> +interrupts = <62>, /* TX interrupt */
>> + <63>; /* RX interrupt */
>> +interrupt-names = "tx", "rx";
>> +interrupt-parent = <&intc>;
>> +ti,hwmods = "mcbsp2";
>> +};
>> +};
>
> Hmm don't you need to specify the interrupt chip and offset for
> the interrupts here?
Mmm, I'm not sure to get your question, there is the link to the
interrupt-parent.
The interrupt number is relative to the parent interrupt domain. So even
if the INTC IRQ offset start at 32 instead of 0, DT IRQ mechanism will
convert that to the proper hwirq thanks to irqdomain.
In that case we should always provide interrupt number relative to the
interrupt controller HW number and not assuming any Linux IRQ number
offset like before.
And in fact the interrupt-parent is not even needed, by default if will
look to the parent to get the interrupt-controller.
Extract from [1]
interrupt-parent:
"Because the hierarchy of the nodes in the interrupt tree might not
match the device tree, the interrupt-parent property is available to
make the definition of an interrupt parent explicit.
The value is the phandle to the interrupt parent. If this property is
missing from a device, its interrupt parent is assumed to be its device
tree parent."
[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf
Regards,
Benoit
--
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] gpio/twl4030: get platform data from device tree
Hello Benoit, Le 07/09/2012 19:33, Benoit Cousson a écrit : Hi Florian, I've just noticed that this patch is reporting some CHECK issues. d1f5052 - gpio/twl4030: get platform data from device tree CHECK: Alignment should match open parenthesis #66: FILE: drivers/gpio/gpio-twl4030.c:412: + of_property_read_u32(dev->of_node, "ti,debounce", + &omap_twl_info->debounce); CHECK: Alignment should match open parenthesis #68: FILE: drivers/gpio/gpio-twl4030.c:414: + of_property_read_u32(dev->of_node, "ti,mmc-cd", + (u32 *)&omap_twl_info->mmc_cd); CHECK: Alignment should match open parenthesis #70: FILE: drivers/gpio/gpio-twl4030.c:416: + of_property_read_u32(dev->of_node, "ti,pullups", + &omap_twl_info->pullups); CHECK: Alignment should match open parenthesis #72: FILE: drivers/gpio/gpio-twl4030.c:418: + of_property_read_u32(dev->of_node, "ti,pulldowns", + &omap_twl_info->pulldowns); CHECK: Alignment should match open parenthesis + pdata->pullups, pdata->pulldowns, CHECK: Alignment should match open parenthesis #139: FILE: drivers/gpio/gpio-twl4030.c:479: + dev_dbg(&pdev->dev, "debounce %.03x %.01x --> %d\n", + pdata->debounce, pdata->mmc_cd, total: 0 errors, 0 warnings, 6 checks, 118 lines checked I fixed them since it was trivial, but next time you should ensure that the patch pass checkpatch before posting. Sorry for these errors. I however checked my patches before submitting, and had no such warnings. I redone, and remarked that these warnings appear only with the "--strict" option, which is not enabled by default. Is this the recommended guideline? Thus why not enabling it by default? Just let me know if you have any issue with the following update. I will test, but should not have any issue with your fix. Thank you very much for fixing my patch, I send you a virtual chocolate from Switzerland! Regards, Florian -- 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: [alsa-devel] [RFC update 0/2] dmaengine/ASoC: omap: Enable element mode in cyclic DMA
Hi Janusz, On 09/09/2012 10:57 PM, Janusz Krzysztofik wrote: > On Tue, 4 Sep 2012 15:08:00 Peter Ujfalusi wrote: >> >> Enable the element mode (thus allowing mono playback and probably > unblocking >> OMAP1, OMAP2420) in OMAP dmaengine and omap-pcm. >> >> Janusz: would it be possible for you to test Russell's series plus > this on >> OMAP1 to make sure that we do not broke it? > > Hi, > I can confirm that sound works for me as before, both capture and > playback, on my OMAP1 Amstrad Delta with Russell's and Peter's patches > applied on top of linux-3.6-rc3, with the OMAP DMA engine driver built > in. I was not able make audible tests with applications other than a > soft phone as I didn't get back home for this weekend, but I think that > the asterisk soft phone is quite a demanding use case. Thank you very much for taking time to test this! This is indeed a good news. > The only thing I'm not sure about is why the sysfs provided > bytes_transferred values never change from their initial zeros. I have not looked at those files in sysfs, but if the same applies for OMAP3/4/5 I can look at it and fix it which should correct OMAP1 at the same time. > > For OMAP1: > Tested-by: Janusz Krzysztofik Again, thanks for the testing, Péter -- 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] gpio/twl4030: get platform data from device tree
Hi Florian, On 09/10/2012 10:17 AM, Florian Vaussard wrote: > Hello Benoit, > > Le 07/09/2012 19:33, Benoit Cousson a écrit : >> Hi Florian, >> >> I've just noticed that this patch is reporting some CHECK issues. >> >> d1f5052 - gpio/twl4030: get platform data from device tree >> CHECK: Alignment should match open parenthesis >> #66: FILE: drivers/gpio/gpio-twl4030.c:412: >> +of_property_read_u32(dev->of_node, "ti,debounce", >> +&omap_twl_info->debounce); >> >> CHECK: Alignment should match open parenthesis >> #68: FILE: drivers/gpio/gpio-twl4030.c:414: >> +of_property_read_u32(dev->of_node, "ti,mmc-cd", >> +(u32 *)&omap_twl_info->mmc_cd); >> >> CHECK: Alignment should match open parenthesis >> #70: FILE: drivers/gpio/gpio-twl4030.c:416: >> +of_property_read_u32(dev->of_node, "ti,pullups", >> +&omap_twl_info->pullups); >> >> CHECK: Alignment should match open parenthesis >> #72: FILE: drivers/gpio/gpio-twl4030.c:418: >> +of_property_read_u32(dev->of_node, "ti,pulldowns", >> +&omap_twl_info->pulldowns); >> >> CHECK: Alignment should match open parenthesis >> +pdata->pullups, pdata->pulldowns, >> >> CHECK: Alignment should match open parenthesis >> #139: FILE: drivers/gpio/gpio-twl4030.c:479: >> +dev_dbg(&pdev->dev, "debounce %.03x %.01x --> %d\n", >> +pdata->debounce, pdata->mmc_cd, >> >> total: 0 errors, 0 warnings, 6 checks, 118 lines checked >> >> >> I fixed them since it was trivial, but next time you should ensure >> that the patch pass checkpatch before posting. > > Sorry for these errors. I however checked my patches before submitting, > and had no such warnings. I redone, and remarked that these warnings > appear only with the "--strict" option, which is not enabled by default. > Is this the recommended guideline? Thus why not enabling it by default? That's a pretty good question :-) Maybe the --strict is more a nice to have than a strong requirement? Anyway, we'd better run checkpatch with --strict and thus fix any cosmetic details that might be in the patch. >> Just let me know if you have any issue with the following update. > > I will test, but should not have any issue with your fix. > > Thank you very much for fixing my patch, I send you a virtual chocolate > from Switzerland! Cool, I love chocolate. That being said, I'm not sure how tasteful will be the *virtual* chocolate. Regards, Benoit -- 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 v8 0/3] GPMC driver conversion
Hello, Le 08/09/2012 00:10, Tony Lindgren a écrit : * Afzal Mohammed [120905 05:37]: Hi, Basic gpmc driver conversion series. Driver that is now created out of gpmc code is a simple one, it handles tasks that were earlier executed by gpmc_init. Now instead of relying on cpu_is_* checks, it obtains resources and clk handle in the standard Linux way. The existing gpmc interface works as was without this series. HWMOD patch also has been brought into this series back with v7 series As this creates only a basic driver, further gpmc driver work can be based over this, while having a driver first in place. This series is based on l-o/testing-cleanup as on 5-Sep-12, i.e. over commit, e3a5c14 ARM: OMAP1: Move SoC specific headers from plat to mach for omap1 per Tony's suggestion. It is available @git://gitorious.org/x0148406-public/linux-kernel.git gpmc-drv-v8 Great, this all looks good to me. I suggest that on top of this we add minimal devicetree binding that does not even attempt to deal with the timings yet. Then once the minimal devicetree binding is in place, we can call the current GPMC timing functions using the compatible flags and auxdata in the gpmc.c driver. That way we get all the legacy boards booting with GPMC support for smsc911x etc, and can even remove some less used board-*.c files. This would be great. If you happen to have DT bindings for GPMC, I would be happy to test them with my Overo board, as well as with my CAN chips on a custom board. Regards, Florian -- 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] gpio/twl4030: get platform data from device tree
Hello Benoit, I fixed them since it was trivial, but next time you should ensure that the patch pass checkpatch before posting. Sorry for these errors. I however checked my patches before submitting, and had no such warnings. I redone, and remarked that these warnings appear only with the "--strict" option, which is not enabled by default. Is this the recommended guideline? Thus why not enabling it by default? That's a pretty good question :-) Maybe the --strict is more a nice to have than a strong requirement? Anyway, we'd better run checkpatch with --strict and thus fix any cosmetic details that might be in the patch. Good to know, I will use --strict for the next submissions. Cool, I love chocolate. That being said, I'm not sure how tasteful will be the *virtual* chocolate. Regards, Benoit Even *virtual*, Swiss chocolate will be the most tasteful (hope no Belgium friends will see this thread) :-) Regards, Florian -- 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 0/2] ARM: omap/dts: Add support for Gumstix Overo with Tobi expansion
Le 06/09/2012 22:52, Tony Lindgren a écrit : * Florian Vaussard [120831 09:07]: The Gumstix Overo is a computer on module using an OMAP3 processor. This module must be plugged into an expansion board. This patchset adds a first device tree support for the Overo, using the Tobi expansion board. The current support is able to boot and mount the rootfs from MMC, with a few extra features. The first patch creates the device tree for both the Overo and the Tobi expansion board, and updates the dtb build target. The second patch updates the omap/dts documentation. This patchset applies on tony's tree [1], devel-dt branch. Great, I'm assuming Benoit will pick this up as well. What is the status Benoit? Thank you, Florian -- 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] watchdog: omap_wdt: convert to new watchdog core
On Sat, Sep 8, 2012 at 11:34 PM, Aaro Koskinen wrote:
> Convert omap_wdt to new watchdog core. On OMAP boards, there are usually
> multiple watchdogs. Since the new watchdog core supports multiple
> watchdogs, all watchdog drivers used on OMAP should be converted.
>
> The legacy watchdog device node is still created, so this should not
> break existing users.
>
> Signed-off-by: Aaro Koskinen
> ---
>
> v2: Fix a bug in the first version of the patch: __omap_wdt_disable()
> in probe was mistakenly moved outside PM runtime calls. This caused a
> crash as device was probably accessed with some clocks off. Thanks to
> Jarkko Nikula for reporting this.
Tested with various watchdog testcases. Seems to work fine.
Tested-by: Lokesh Vutla
>
> drivers/watchdog/Kconfig|1 +
> drivers/watchdog/omap_wdt.c | 266
> ++-
> 2 files changed, 114 insertions(+), 153 deletions(-)
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 0526c7a..212b566 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -232,6 +232,7 @@ config EP93XX_WATCHDOG
> config OMAP_WATCHDOG
> tristate "OMAP Watchdog"
> depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS
> + select WATCHDOG_CORE
> help
> Support for TI OMAP1610/OMAP1710/OMAP2420/OMAP3430/OMAP4430
> watchdog. Say 'Y'
> here to enable the OMAP1610/OMAP1710/OMAP2420/OMAP3430/OMAP4430
> watchdog timer.
> diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
> index fceec4f..1636f2c 100644
> --- a/drivers/watchdog/omap_wdt.c
> +++ b/drivers/watchdog/omap_wdt.c
> @@ -31,18 +31,14 @@
> #include
> #include
> #include
> -#include
> #include
> -#include
> #include
> #include
> #include
> #include
> #include
> #include
> -#include
> #include
> -#include
> #include
> #include
> #include
> @@ -50,24 +46,20 @@
>
> #include "omap_wdt.h"
>
> -static struct platform_device *omap_wdt_dev;
> -
> static unsigned timer_margin;
> module_param(timer_margin, uint, 0);
> MODULE_PARM_DESC(timer_margin, "initial watchdog timeout (in seconds)");
>
> -static unsigned int wdt_trgr_pattern = 0x1234;
> -static DEFINE_SPINLOCK(wdt_lock);
> -
> struct omap_wdt_dev {
> void __iomem*base; /* physical */
> struct device *dev;
> - int omap_wdt_users;
> + boolomap_wdt_users;
> struct resource *mem;
> - struct miscdevice omap_wdt_miscdev;
> + int wdt_trgr_pattern;
> + struct mutexlock; /* to avoid races with PM */
> };
>
> -static void omap_wdt_ping(struct omap_wdt_dev *wdev)
> +static void __omap_wdt_ping(struct omap_wdt_dev *wdev)
> {
> void __iomem*base = wdev->base;
>
> @@ -75,8 +67,8 @@ static void omap_wdt_ping(struct omap_wdt_dev *wdev)
> while ((__raw_readl(base + OMAP_WATCHDOG_WPS)) & 0x08)
> cpu_relax();
>
> - wdt_trgr_pattern = ~wdt_trgr_pattern;
> - __raw_writel(wdt_trgr_pattern, (base + OMAP_WATCHDOG_TGR));
> + wdev->wdt_trgr_pattern = ~wdev->wdt_trgr_pattern;
> + __raw_writel(wdev->wdt_trgr_pattern, (base + OMAP_WATCHDOG_TGR));
>
> /* wait for posted write to complete */
> while ((__raw_readl(base + OMAP_WATCHDOG_WPS)) & 0x08)
> @@ -84,7 +76,7 @@ static void omap_wdt_ping(struct omap_wdt_dev *wdev)
> /* reloaded WCRR from WLDR */
> }
>
> -static void omap_wdt_enable(struct omap_wdt_dev *wdev)
> +static void __omap_wdt_enable(struct omap_wdt_dev *wdev)
> {
> void __iomem *base = wdev->base;
>
> @@ -98,7 +90,7 @@ static void omap_wdt_enable(struct omap_wdt_dev *wdev)
> cpu_relax();
> }
>
> -static void omap_wdt_disable(struct omap_wdt_dev *wdev)
> +static void __omap_wdt_disable(struct omap_wdt_dev *wdev)
> {
> void __iomem *base = wdev->base;
>
> @@ -112,18 +104,10 @@ static void omap_wdt_disable(struct omap_wdt_dev *wdev)
> cpu_relax();
> }
>
> -static void omap_wdt_adjust_timeout(unsigned new_timeout)
> -{
> - if (new_timeout < TIMER_MARGIN_MIN)
> - new_timeout = TIMER_MARGIN_DEFAULT;
> - if (new_timeout > TIMER_MARGIN_MAX)
> - new_timeout = TIMER_MARGIN_MAX;
> - timer_margin = new_timeout;
> -}
> -
> -static void omap_wdt_set_timeout(struct omap_wdt_dev *wdev)
> +static void __omap_wdt_set_timeout(struct omap_wdt_dev *wdev,
> + unsigned int timeout)
> {
> - u32 pre_margin = GET_WLDR_VAL(timer_margin);
> + u32 pre_margin = GET_WLDR_VAL(timeout);
> void __iomem *base = wdev->base;
>
> /* just count up at 32 KHz */
> @@ -135,16 +119,14 @@ static void omap_wdt_set_timeout(struct omap_wdt_dev
> *wdev)
> cpu_relax();
> }
>
> -/*
> - * Allow only one task to hold it open
> - */
> -static int omap_wdt_open(struct inode *inode, struct file *
Re: [PATCH v4 1/2] ARM: new cache maintenance api for iommu
Hi Russell, On Sat, Sep 8, 2012 at 3:44 PM, Russell King - ARM Linux wrote: > On Thu, Jul 05, 2012 at 10:50:17AM +0530, Gupta, Ramesh wrote: >> + * flush_iommu_mem(start, end) >> + * >> + * Clean and invalidate the specified virtual address range. >> + * This is to support the non coherent iommu drivers. >> + * The iommu driver need to call this api with the page >> + * table memory address range to ensure the data held in >> + * the cache is visible to the slave processor MMU. >> + * - start - virtual start address >> + * - end- virtual end address > > I think: > iommu_flush_range(start, end) > or > iommu_flush_area(start, size) > Perform CPU specific cache operations are required to > ensure that the IOMMU page table mappings covering the > specified block of memory are visiable to the IOMMU. I prefer iommu_flush_area(start, size). > > Notice that it's defined by purpose, not by implementation. Also notice > the distinction between _range taking two addresses, and _area taking > a start plus size. > Also notice that it is defined just for IOMMU page tables, not for general > data for other processors. Agree with your comments, may be I can add an explicit comment for not using these apis other than IOMMU page tables. > Note that iommu_flush_area is safer if your virt_to_phys() are non-linear. Agree, I will send an updated patch series with iommu_flush_area. thank you for the review comments. Best regards Ramesh Gupta G -- 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 2/2] OMAP:IOMMU:flush L1 and L2 caches
Hi Russell,
On Sat, Sep 8, 2012 at 3:47 PM, Russell King - ARM Linux
wrote:
> On Thu, Jul 05, 2012 at 10:50:24AM +0530, Gupta, Ramesh wrote:
>> static void flush_iopgd_range(u32 *first, u32 *last)
>> {
>> - /* FIXME: L2 cache should be taken care of if it exists */
>> - do {
>> - asm("mcrp15, 0, %0, c7, c10, 1 @ flush_pgd"
>> - : : "r" (first));
>> - first += L1_CACHE_BYTES / sizeof(*first);
>> - } while (first <= last);
>> + flush_iommu_mem(first, last);
>> + outer_flush_range(virt_to_phys(first), virt_to_phys(last));
>
> I think this would be safer if these operated on an area rather than a
> range - which means taking a start plus size.
>
> phys_addr_t phys = virt_to_phys(start);
>
> iommu_flush_area(start, size);
> outer_flush_range(phys, phys + size);
>
> is safer than the above if virt_to_phys() is non-linear.
Agree, I will use the area.
>
>> *iopgd = virt_to_phys(iopte) | IOPGD_TABLE;
>> - flush_iopgd_range(iopgd, iopgd);
>> + flush_iopgd_range(iopgd, iopgd + 1);
>
> And operating on a start + size also makes this kind of stuff clearer.
Sure, I will cleanup this and send an updated patch series.
Thank you for the inputs.
Best regards
Ramesh Gupta G
--
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: Seeking clarity on IRQCHIP_MASK_ON_SUSPEND
On Mon, 10 Sep 2012, NeilBrown wrote: > > The IRQCHIP_MASK_ON_SUSPEND flag seems to be hard to use correctly, so either > I'm understanding it wrongly, or it could be made easier to use. > If the first case, I'm hoping that some improvement to documentation might > result. If the second, then maybe we can fix the code. ... > Is anyone able to give a definitive answer on this? Should > IRQCHIP_MASK_ON_SUSPEND be removed? The whole point of IRQCHIP_MASK_ON_SUSPEND is to deal with hardware designed by geniuses. Most SoCs have a way to mark the interrupts which serve as a wake up source as such. All other interrupts are magically "masked" on entry to suspend. Now there is hardware which is missing such a control, so we need to mask the non wakeup interrupts right before going into suspend. That's what IRQCHIP_MASK_ON_SUSPEND does. Not more, not less. See commit d209a699a0b for more ugly details. You might be looking for a different functionality. Can you explain what you need? Thanks, tglx -- 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: OMAP2+: mux: add support for PAD wakeup event handler
OMAP mux now parses active wakeup events from pad registers and calls
corresponding handler, if handler is not registered - corresponding
hwmod ISRs once a wakeup is detected.
This is useful for cases when routing wakeups to corresponding hwmod
ISRs complicates those ISRs handlers (for example, ISR handler may
not know who the interrupt source is)
Signed-off-by: Ruslan Bilovol
---
arch/arm/mach-omap2/mux.c| 14 +--
arch/arm/mach-omap2/omap_hwmod.c | 29 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h |4 +++
3 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 9fe6829..2918638 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -372,6 +372,7 @@ static bool omap_hwmod_mux_scan_wakeups(struct
omap_hwmod_mux_info *hmux,
int i, irq;
unsigned int val;
u32 handled_irqs = 0;
+ bool retval = false;
for (i = 0; i < hmux->nr_pads_dynamic; i++) {
struct omap_device_pad *pad = hmux->pads_dynamic[i];
@@ -384,8 +385,15 @@ static bool omap_hwmod_mux_scan_wakeups(struct
omap_hwmod_mux_info *hmux,
if (!(val & OMAP_WAKEUP_EVENT))
continue;
- if (!hmux->irqs)
- return true;
+ if (hmux->wakeup_handler && hmux->wakeup_handler[i]) {
+ hmux->wakeup_handler[i](hmux);
+ continue;
+ }
+
+ if (!hmux->irqs) {
+ retval = true;
+ continue;
+ }
irq = hmux->irqs[i];
/* make sure we only handle each irq once */
@@ -397,7 +405,7 @@ static bool omap_hwmod_mux_scan_wakeups(struct
omap_hwmod_mux_info *hmux,
generic_handle_irq(mpu_irqs[irq].irq);
}
- return false;
+ return retval;
}
/**
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 6ca8e51..9a41d65 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3656,6 +3656,35 @@ int omap_hwmod_pad_route_irq(struct omap_hwmod *oh, int
pad_idx, int irq_idx)
}
/**
+ * omap_hwmod_pad_wakeup_handler - add wakeup handler for an I/O pad wakeup
+ * @oh: struct omap_hwmod * containing hwmod mux entries
+ * @pad_idx: array index in oh->mux of the hwmod mux entry to handle wakeup
+ * @wakeup_handler: the wakeup_handler function to trigger on wakeup
+ */
+int omap_hwmod_pad_wakeup_handler(struct omap_hwmod *oh, int pad_idx,
+ int (*wakeup_handler)(struct omap_hwmod_mux_info *hmux))
+{
+ might_sleep();
+
+ if (!oh || !oh->mux || pad_idx < 0 ||
+ pad_idx >= oh->mux->nr_pads_dynamic)
+ return -EINVAL;
+
+ if (!oh->mux->wakeup_handler) {
+ /* XXX What frees this? */
+ oh->mux->wakeup_handler =
+ kzalloc(sizeof(*(oh->mux->wakeup_handler)) *
+ oh->mux->nr_pads_dynamic, GFP_KERNEL);
+
+ if (!oh->mux->wakeup_handler)
+ return -ENOMEM;
+ }
+ oh->mux->wakeup_handler[pad_idx] = wakeup_handler;
+
+ return 0;
+}
+
+/**
* omap_hwmod_init - initialize the hwmod code
*
* Sets up some function pointers needed by the hwmod code to operate on the
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 6132972..5c2bcc7 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -110,6 +110,7 @@ struct omap_hwmod_mux_info {
int nr_pads_dynamic;
struct omap_device_pad **pads_dynamic;
int *irqs;
+ int (**wakeup_handler)(struct
omap_hwmod_mux_info *hmux);
boolenabled;
};
@@ -646,6 +647,9 @@ int omap_hwmod_no_setup_reset(struct omap_hwmod *oh);
int omap_hwmod_pad_route_irq(struct omap_hwmod *oh, int pad_idx, int irq_idx);
+int omap_hwmod_pad_wakeup_handler(struct omap_hwmod *oh, int pad_idx,
+ int (*wakeup_handler)(struct omap_hwmod_mux_info *hmux));
+
extern void __init omap_hwmod_init(void);
const char *omap_hwmod_get_main_clk(struct omap_hwmod *oh);
--
1.7.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: [PATCH v9] can: c_can: Add runtime PM support to Bosch C_CAN/D_CAN controller
Hi Kevin,
On Sat, Sep 08, 2012 at 02:31:22, Kevin Hilman wrote:
> "AnilKumar, Chimata" writes:
>
> > Hi Kevin,
> >
> > On Fri, Sep 07, 2012 at 05:07:56, Kevin Hilman wrote:
> >> AnilKumar Ch writes:
> >>
> >> > Add Runtime PM support to C_CAN/D_CAN controller. The runtime PM
> >> > APIs control clocks for C_CAN/D_CAN IP and prevent access to the
> >> > register of C_CAN/D_CAN IP when clock is turned off.
> >> >
> >> > Signed-off-by: AnilKumar Ch
> >>
> >> I'm not familar with the CAN specifics here, but some comments on the
> >> runtime PM implementation.
> >
> > Thanks for the comments.
> >
> >>
> >> > ---
> >> > This patch has been tested on AM335X EVM. Due to lack of hardware
> >> > I am not able to test c_can functionality. I appreciate if anyone
> >> > can test c_can functionality with this patch.
> >> >
> >> > This patch is based on "can-next/master"
> >> >
> >> > Changes from v8:
> >> > - corrected the return path sequence in c_can_probe()
> >> >
> >> > Changes from v7:
> >> > - Incorporated Marc's comments on v7
> >> >* changed device pointer to c_can_priv pointer
> >> >
> >> > Changes from v6:
> >> > - Incorporated Marc's comments on v6
> >> >* changed dev pointer to priv
> >> >* removed platform_device.h include from c_can.c
> >> >
> >> > Changes from v5:
> >> > - Incorporated Marc's comments on v5
> >> >* changed runtime pm calls in c_can driver to handle
> >> > the drivers which are not using platform drivers.
> >> >* added device pointer protection in c_can driver if
> >> > not passed from platform/pci driver.
> >> >
> >> > Changes from v4:
> >> > - Incorporated Vaibhav H review comments on v4.
> >> >* Moved pm_runtime put/get_sync calls to appropriate positions.
> >> > - This patch is from "Add DT support to C_CAN/D_CAN controller"
> >> >patch series. Rest of the patches in this series were applied
> >> >so this v5 contains only this patch.
> >> >
> >> > drivers/net/can/c_can/c_can.c | 24 +++-
> >> > drivers/net/can/c_can/c_can.h |1 +
> >> > drivers/net/can/c_can/c_can_platform.c | 11 +--
> >> > 3 files changed, 33 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/drivers/net/can/c_can/c_can.c
> >> > b/drivers/net/can/c_can/c_can.c
> >> > index 4c538e3..966d318 100644
> >> > --- a/drivers/net/can/c_can/c_can.c
> >> > +++ b/drivers/net/can/c_can/c_can.c
> >> > @@ -34,6 +34,7 @@
> >> > #include
> >> > #include
> >> > #include
> >> > +#include
> >> >
> >> > #include
> >> > #include
> >> > @@ -201,6 +202,18 @@ static const struct can_bittiming_const
> >> > c_can_bittiming_const = {
> >> > .brp_inc = 1,
> >> > };
> >> >
> >> > +static inline void c_can_pm_runtime_get_sync(struct c_can_priv *priv)
> >> > +{
> >> > +if (priv->device)
> >> > +pm_runtime_get_sync(priv->device);
> >> > +}
> >> > +
> >> > +static inline void c_can_pm_runtime_put_sync(struct c_can_priv *priv)
> >> > +{
> >> > +if (priv->device)
> >> > +pm_runtime_put_sync(priv->device);
> >> > +}
> >>
> >> IMO, these extra helpers are rather unsightly, and should not be needed.
> >> The driver should just be directly doing get_sync/put_sync. If
> >> priv->device isn't presnt, then runtime PM should just never be enabled.
> >>
> >
> > In case of c_can driver we have two drivers one is generic c_can.c driver,
> > provides the basic functionality of CAN. Another two drivers
> > c_can_platform.c
> > and c_can_pci.c, which uses core c_can.c driver by exporting some platform
> > specific ops like read/write.
> >
> > priv->device pointer is passed from c_can_platform.c by this means
> > "priv->device = &pdev->dev;" (see below) but not for c_can_pci.c
> >
> > The purpose of check here is for *_pci.c driver which do not have runtime pm
> > implemented yet so we should do and get_sync/put_sync. In case of *_pci.c
> > driver there is no pm_runtime_enable/disable once that is implemented then
> > this check will be removed.
>
> Then you should probably move the pm_runtime_enable/disable into the
> common code (where the get_sync/put_sync) are. Then you could simply
> avoid the pm_runtime_enable() if there is no priv->device.
>
Thanks for the comments
I got your point, will move pm_runtime_enable/disable to common code.
Thanks
AnilKumar
--
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 v4 06/14] dt: Add empty of_find_node_by_name() function
This commit adds an empty of_find_node_by_name() function for !CONFIG_OF
builds.
Signed-off-by: Peter Ujfalusi
---
include/linux/of.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/of.h b/include/linux/of.h
index 1b11632..5c7a158 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -315,6 +315,12 @@ static inline const char* of_node_full_name(struct
device_node *np)
return "";
}
+static inline struct device_node *of_find_node_by_name(struct device_node
*from,
+ const char *name)
+{
+ return NULL;
+}
+
static inline bool of_have_populated_dt(void)
{
return false;
--
1.7.12
--
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 v4 11/14] ASoC/MFD: twl4030: Remove set_hs_extmute callback from platform data
We no longer have users for the set_hs_extmute callback which has been
replaced by hs_extmute_gpio so the codec driver can handle the external
mute if it is needed by the board.
Signed-off-by: Peter Ujfalusi
---
include/linux/i2c/twl.h| 2 --
sound/soc/codecs/twl4030.c | 6 --
2 files changed, 8 deletions(-)
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 2040309..a4885a6 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -667,8 +667,6 @@ struct twl4030_codec_data {
unsigned int check_defaults:1;
unsigned int reset_registers:1;
unsigned int hs_extmute:1;
- void (*set_hs_extmute)(int mute); /* Deprecated, use hs_extmute_gpio and
-hs_extmute_disable_level */
int hs_extmute_gpio;
};
diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c
index 5fc271a..27ccea4 100644
--- a/sound/soc/codecs/twl4030.c
+++ b/sound/soc/codecs/twl4030.c
@@ -767,9 +767,6 @@ static void headset_ramp(struct snd_soc_codec *codec, int
ramp)
if (pdata && pdata->hs_extmute) {
if (gpio_is_valid(pdata->hs_extmute_gpio)) {
gpio_set_value(pdata->hs_extmute_gpio, 1);
- } else if (pdata->set_hs_extmute) {
- dev_warn(codec->dev, "set_hs_extmute is deprecated\n");
- pdata->set_hs_extmute(1);
} else {
hs_pop |= TWL4030_EXTMUTE;
twl4030_write(codec, TWL4030_REG_HS_POPN_SET, hs_pop);
@@ -808,9 +805,6 @@ static void headset_ramp(struct snd_soc_codec *codec, int
ramp)
if (pdata && pdata->hs_extmute) {
if (gpio_is_valid(pdata->hs_extmute_gpio)) {
gpio_set_value(pdata->hs_extmute_gpio, 0);
- } else if (pdata->set_hs_extmute) {
- dev_warn(codec->dev, "set_hs_extmute is deprecated\n");
- pdata->set_hs_extmute(0);
} else {
hs_pop &= ~TWL4030_EXTMUTE;
twl4030_write(codec, TWL4030_REG_HS_POPN_SET, hs_pop);
--
1.7.12
--
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 v4 13/14] ASoC: twl4030: Add pointer to pdata within the private data
Access the pdata via a pointer within the twl4030_priv structure.
In preparation for DeviceTree support.
Signed-off-by: Peter Ujfalusi
---
sound/soc/codecs/twl4030.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c
index 413e698..8b13d50 100644
--- a/sound/soc/codecs/twl4030.c
+++ b/sound/soc/codecs/twl4030.c
@@ -153,8 +153,7 @@ struct twl4030_priv {
u8 predrivel_enabled, predriver_enabled;
u8 carkitl_enabled, carkitr_enabled;
- /* Delay needed after enabling the digimic interface */
- unsigned int digimic_delay;
+ struct twl4030_codec_data *pdata;
};
/*
@@ -348,7 +347,7 @@ static void twl4030_init_chip(struct snd_soc_codec *codec)
if (!pdata)
return;
- twl4030->digimic_delay = pdata->digimic_delay;
+ twl4030->pdata = pdata;
reg = twl4030_read_reg_cache(codec, TWL4030_REG_HS_POPN_SET);
reg &= ~TWL4030_RAMP_DELAY;
@@ -749,9 +748,9 @@ static int aif_event(struct snd_soc_dapm_widget *w,
static void headset_ramp(struct snd_soc_codec *codec, int ramp)
{
- struct twl4030_codec_data *pdata = codec->dev->platform_data;
unsigned char hs_gain, hs_pop;
struct twl4030_priv *twl4030 = snd_soc_codec_get_drvdata(codec);
+ struct twl4030_codec_data *pdata = twl4030->pdata;
/* Base values for ramp delay calculation: 2^19 - 2^26 */
unsigned int ramp_base[] = {524288, 1048576, 2097152, 4194304,
8388608, 16777216, 33554432, 67108864};
@@ -864,9 +863,10 @@ static int digimic_event(struct snd_soc_dapm_widget *w,
struct snd_kcontrol *kcontrol, int event)
{
struct twl4030_priv *twl4030 = snd_soc_codec_get_drvdata(w->codec);
+ struct twl4030_codec_data *pdata = twl4030->pdata;
- if (twl4030->digimic_delay)
- twl4030_wait_ms(twl4030->digimic_delay);
+ if (pdata && pdata->digimic_delay)
+ twl4030_wait_ms(pdata->digimic_delay);
return 0;
}
@@ -2248,8 +2248,8 @@ static int twl4030_soc_probe(struct snd_soc_codec *codec)
static int twl4030_soc_remove(struct snd_soc_codec *codec)
{
- struct twl4030_codec_data *pdata = dev_get_platdata(codec->dev);
struct twl4030_priv *twl4030 = snd_soc_codec_get_drvdata(codec);
+ struct twl4030_codec_data *pdata = twl4030->pdata;
/* Reset registers to their chip default before leaving */
twl4030_reset_registers(codec);
--
1.7.12
--
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 v4 12/14] ASoC: twl4030: Convert to use devm_kzalloc
Allocate the private data with devm_kzalloc.
Signed-off-by: Peter Ujfalusi
---
sound/soc/codecs/twl4030.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c
index 27ccea4..413e698 100644
--- a/sound/soc/codecs/twl4030.c
+++ b/sound/soc/codecs/twl4030.c
@@ -2231,7 +2231,8 @@ static int twl4030_soc_probe(struct snd_soc_codec *codec)
{
struct twl4030_priv *twl4030;
- twl4030 = kzalloc(sizeof(struct twl4030_priv), GFP_KERNEL);
+ twl4030 = devm_kzalloc(codec->dev, sizeof(struct twl4030_priv),
+ GFP_KERNEL);
if (twl4030 == NULL) {
dev_err(codec->dev, "Can not allocate memory\n");
return -ENOMEM;
@@ -2253,7 +2254,6 @@ static int twl4030_soc_remove(struct snd_soc_codec *codec)
/* Reset registers to their chip default before leaving */
twl4030_reset_registers(codec);
twl4030_set_bias_level(codec, SND_SOC_BIAS_OFF);
- kfree(twl4030);
if (pdata && pdata->hs_extmute && gpio_is_valid(pdata->hs_extmute_gpio))
gpio_free(pdata->hs_extmute_gpio);
--
1.7.12
--
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 v4 14/14] ASoC: twl4030: Support for DT booted kernel
When the kernel has been booted with DT blob the platform data is NULL for
the driver.
We need to construct the pdata based on the DT information for runtime use.
Signed-off-by: Peter Ujfalusi
---
sound/soc/codecs/twl4030.c | 55 +++---
1 file changed, 47 insertions(+), 8 deletions(-)
diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c
index 8b13d50..8405ab9 100644
--- a/sound/soc/codecs/twl4030.c
+++ b/sound/soc/codecs/twl4030.c
@@ -26,6 +26,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -295,13 +297,57 @@ static inline void twl4030_reset_registers(struct
snd_soc_codec *codec)
}
-static void twl4030_init_chip(struct snd_soc_codec *codec)
+static void twl4030_setup_pdata_of(struct twl4030_codec_data *pdata,
+ struct device_node *node)
+{
+ int value;
+
+ of_property_read_u32(node, "ti,digimic_delay",
+&pdata->digimic_delay);
+ of_property_read_u32(node, "ti,ramp_delay_value",
+&pdata->ramp_delay_value);
+ of_property_read_u32(node, "ti,offset_cncl_path",
+&pdata->offset_cncl_path);
+ if (!of_property_read_u32(node, "ti,hs_extmute", &value))
+ pdata->hs_extmute = value;
+
+ pdata->hs_extmute_gpio = of_get_named_gpio(node,
+ "ti,hs_extmute_gpio", 0);
+ if (gpio_is_valid(pdata->hs_extmute_gpio))
+ pdata->hs_extmute = 1;
+}
+
+static struct twl4030_codec_data *twl4030_get_pdata(struct snd_soc_codec
*codec)
{
struct twl4030_codec_data *pdata = dev_get_platdata(codec->dev);
+ struct device_node *twl4030_codec_node = NULL;
+
+ twl4030_codec_node = of_find_node_by_name(codec->dev->parent->of_node,
+ "codec");
+
+ if (!pdata && twl4030_codec_node) {
+ pdata = devm_kzalloc(codec->dev,
+sizeof(struct twl4030_codec_data),
+GFP_KERNEL);
+ if (!pdata) {
+ dev_err(codec->dev, "Can not allocate memory\n");
+ return NULL;
+ }
+ twl4030_setup_pdata_of(pdata, twl4030_codec_node);
+ }
+
+ return pdata;
+}
+
+static void twl4030_init_chip(struct snd_soc_codec *codec)
+{
+ struct twl4030_codec_data *pdata;
struct twl4030_priv *twl4030 = snd_soc_codec_get_drvdata(codec);
u8 reg, byte;
int i = 0;
+ pdata = twl4030_get_pdata(codec);
+
if (pdata && pdata->hs_extmute &&
gpio_is_valid(pdata->hs_extmute_gpio)) {
int ret;
@@ -2284,13 +2330,6 @@ static struct snd_soc_codec_driver soc_codec_dev_twl4030
= {
static int __devinit twl4030_codec_probe(struct platform_device *pdev)
{
- struct twl4030_codec_data *pdata = pdev->dev.platform_data;
-
- if (!pdata) {
- dev_err(&pdev->dev, "platform_data is missing\n");
- return -EINVAL;
- }
-
return snd_soc_register_codec(&pdev->dev, &soc_codec_dev_twl4030,
twl4030_dai, ARRAY_SIZE(twl4030_dai));
}
--
1.7.12
--
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 v4 10/14] ARM: OMAP/ASoC: Zoom2: Let the codec to handle the hs_extmute GPIO
Remove the use of set_hs_extmute callback and let the codec driver to
handle the extmute GPIO.
Signed-off-by: Peter Ujfalusi
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 9 ++---
arch/arm/mach-omap2/include/mach/board-zoom.h | 2 --
sound/soc/omap/zoom2.c| 4
3 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index b797cb2..a7d3b04 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -34,6 +34,7 @@
#include "common-board-devices.h"
#define OMAP_ZOOM_WLAN_PMENA_GPIO (101)
+#define ZOOM2_HEADSET_EXTMUTE_GPIO (153)
#define OMAP_ZOOM_WLAN_IRQ_GPIO(162)
#define LCD_PANEL_ENABLE_GPIO (7 + OMAP_MAX_GPIO_LINES)
@@ -244,12 +245,6 @@ static int zoom_twl_gpio_setup(struct device *dev,
return ret;
}
-/* EXTMUTE callback function */
-static void zoom2_set_hs_extmute(int mute)
-{
- gpio_set_value(ZOOM2_HEADSET_EXTMUTE_GPIO, mute);
-}
-
static struct twl4030_gpio_platform_data zoom_gpio_data = {
.gpio_base = OMAP_MAX_GPIO_LINES,
.irq_base = TWL4030_GPIO_IRQ_BASE,
@@ -279,7 +274,7 @@ static int __init omap_i2c_init(void)
codec_data->ramp_delay_value = 3; /* 161 ms */
codec_data->hs_extmute = 1;
- codec_data->set_hs_extmute = zoom2_set_hs_extmute;
+ codec_data->hs_extmute_gpio = ZOOM2_HEADSET_EXTMUTE_GPIO;
}
omap_pmic_init(1, 2400, "twl5030", INT_34XX_SYS_NIRQ, &zoom_twldata);
omap_register_i2c_bus(2, 400, NULL, 0);
diff --git a/arch/arm/mach-omap2/include/mach/board-zoom.h
b/arch/arm/mach-omap2/include/mach/board-zoom.h
index 775fdc3..2e94869 100644
--- a/arch/arm/mach-omap2/include/mach/board-zoom.h
+++ b/arch/arm/mach-omap2/include/mach/board-zoom.h
@@ -8,5 +8,3 @@
extern int __init zoom_debugboard_init(void);
extern void __init zoom_peripherals_init(void);
extern void __init zoom_display_init(void);
-
-#define ZOOM2_HEADSET_EXTMUTE_GPIO 153
diff --git a/sound/soc/omap/zoom2.c b/sound/soc/omap/zoom2.c
index 920e0d9..df97a41 100644
--- a/sound/soc/omap/zoom2.c
+++ b/sound/soc/omap/zoom2.c
@@ -191,9 +191,6 @@ static int __init zoom2_soc_init(void)
BUG_ON(gpio_request(ZOOM2_HEADSET_MUX_GPIO, "hs_mux") < 0);
gpio_direction_output(ZOOM2_HEADSET_MUX_GPIO, 0);
- BUG_ON(gpio_request(ZOOM2_HEADSET_EXTMUTE_GPIO, "ext_mute") < 0);
- gpio_direction_output(ZOOM2_HEADSET_EXTMUTE_GPIO, 0);
-
return 0;
err1:
@@ -207,7 +204,6 @@ module_init(zoom2_soc_init);
static void __exit zoom2_soc_exit(void)
{
gpio_free(ZOOM2_HEADSET_MUX_GPIO);
- gpio_free(ZOOM2_HEADSET_EXTMUTE_GPIO);
platform_device_unregister(zoom2_snd_device);
}
--
1.7.12
--
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 v4 07/14] MFD: twl4030-audio: Add DT support
Support for loading the twl4030 audio module via devicetree.
Sub devices for codec and vibra will be created as mfd devices once the
core MFD driver is loaded when the kernel is booted with a DT blob.
Signed-off-by: Peter Ujfalusi
---
.../devicetree/bindings/mfd/twl4030-audio.txt | 46 ++
drivers/mfd/twl4030-audio.c| 54 +++---
2 files changed, 93 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/twl4030-audio.txt
diff --git a/Documentation/devicetree/bindings/mfd/twl4030-audio.txt
b/Documentation/devicetree/bindings/mfd/twl4030-audio.txt
new file mode 100644
index 000..414d2ae
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/twl4030-audio.txt
@@ -0,0 +1,46 @@
+Texas Instruments TWL family (twl4030) audio module
+
+The audio module inside the TWL family consist of an audio codec and a vibra
+driver.
+
+Required properties:
+- compatible : must be "ti,twl4030-audio"
+
+Optional properties, nodes:
+
+Audio functionality:
+- codec { }: Need to be present if the audio functionality is used. Within this
+section the following options can be used:
+- ti,digimic_delay: Delay need after enabling the digimic to reduce artifacts
+ from the start of the recorded sample (in ms)
+-ti,ramp_delay_value: HS ramp delay configuration to reduce pop noise
+-ti,hs_extmute: Use external mute for HS pop reduction
+-ti,hs_extmute_gpio: Use external GPIO to control the external mute
+-ti,offset_cncl_path: Offset cancellation path selection, refer to TRM for the
+ valid values.
+
+Vibra functionality
+- ti,enable-vibra: Need to be set to <1> if the vibra functionality is used. if
+ missing or it is 0, the vibra functionality is disabled.
+
+Example:
+&i2c1 {
+ clock-frequency = <260>;
+
+ twl: twl@48 {
+ reg = <0x48>;
+ interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = <&intc>;
+
+ twl_audio: audio {
+ compatible = "ti,twl4030-audio";
+
+ ti,enable-vibra = <1>;
+
+ codec {
+ ti,ramp_delay_value = <3>;
+ };
+
+ };
+ };
+};
diff --git a/drivers/mfd/twl4030-audio.c b/drivers/mfd/twl4030-audio.c
index a48bf3a..58e6c22 100644
--- a/drivers/mfd/twl4030-audio.c
+++ b/drivers/mfd/twl4030-audio.c
@@ -28,6 +28,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -156,15 +158,42 @@ unsigned int twl4030_audio_get_mclk(void)
}
EXPORT_SYMBOL_GPL(twl4030_audio_get_mclk);
+static bool twl4030_audio_has_codec(struct twl4030_audio_data *pdata,
+ struct device_node *node)
+{
+ if (pdata && pdata->codec)
+ return true;
+
+ if (of_find_node_by_name(node, "codec"))
+ return true;
+
+ return false;
+}
+
+static bool twl4030_audio_has_vibra(struct twl4030_audio_data *pdata,
+ struct device_node *node)
+{
+ int vibra;
+
+ if (pdata && pdata->vibra)
+ return true;
+
+ if (!of_property_read_u32(node, "ti,enable-vibra", &vibra) && vibra)
+ return true;
+
+ return false;
+}
+
static int __devinit twl4030_audio_probe(struct platform_device *pdev)
{
struct twl4030_audio *audio;
struct twl4030_audio_data *pdata = pdev->dev.platform_data;
+ struct device_node *node = pdev->dev.of_node;
struct mfd_cell *cell = NULL;
int ret, childs = 0;
u8 val;
- if (!pdata) {
+ if (!pdata && !node) {
dev_err(&pdev->dev, "Platform data is missing\n");
return -EINVAL;
}
@@ -202,18 +231,22 @@ static int __devinit twl4030_audio_probe(struct
platform_device *pdev)
audio->resource[TWL4030_AUDIO_RES_APLL].reg = TWL4030_REG_APLL_CTL;
audio->resource[TWL4030_AUDIO_RES_APLL].mask = TWL4030_APLL_EN;
- if (pdata->codec) {
+ if (twl4030_audio_has_codec(pdata, node)) {
cell = &audio->cells[childs];
cell->name = "twl4030-codec";
- cell->platform_data = pdata->codec;
- cell->pdata_size = sizeof(*pdata->codec);
+ if (pdata) {
+ cell->platform_data = pdata->codec;
+ cell->pdata_size = sizeof(*pdata->codec);
+ }
childs++;
}
- if (pdata->vibra) {
+ if (twl4030_audio_has_vibra(pdata, node)) {
cell = &audio->cells[childs];
cell->name = "twl4030-vibra";
- cell->platform_data = pdata->vibra;
- cell->pdata_size = sizeof(*pdata->vibra);
+ if (pdata) {
+ cell->platform_data = pdata->vibra;
+
[PATCH v4 00/14] MFD/ASoC/Input: twl4030-audio submodule DT support
Hello, Generated on top of: git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/omap Changes since v3: - Added Acked-by from Tony and Dmitry - Removed #ifdef around of_find_node_by_name() in the drivers Changed since v2: - Added commit message to patch 2 (as Tero requested it) - Fixed patch 6 (dt: Add empty...) since the previous patch caused x86_64 build to fail due to missing struct before device_node. Changes since v1: - Get the MCLK frequencey from twl-core driver (via new API) - hs_extmute_disable_level parameter has been removed - empty of_find_node_by_name() in of.h for !CONFIG_OF builds Mark: the extmute GPIO handling (when it is used) remained in the codec driver for now. I can think more on how to add support for this type of mute control. If you can point me to other codec needing this it would help on designing something which is common enough for other users. As for now I have a separate series to add GPIO controlled output amps (hp/spk). I will send that to review soon. Currently this piece of code does not work when booted with device tree since I have done it on n900 which has the GPIO numbers as defines. I need to revisit the aproach on how to do it in a dynamic way. Introl mail from v1: The following series adds DT support for the twl4030 audio submodule which provides audio codec and vibra functionality. The MFD core driver is probed via DT, it will create the needed child devices based on the provided information in the DT blob. Child drivers (vibra, ASoC codec) will parse the core's node if needed to get the needed parameters for their configuration. In the ASoC codec driver the hs_extmute callback (which was used to toggle a GPIO line) has been removed. The codec driver will receive the GPIO number (if it is needed on the platform). If the series is OK (and no objections from the maintainers), it would be good if this can go via audio. Changed files are well contained within the twl4030-audio stack so I do not expect merge issues later. The series has been tested on BeagleBoard (with the McBSP DT series, and with the upcoming DT audio support for BeagleBoard). Regards, Peter --- Peter Ujfalusi (14): MFD: twl4030-audio: Clean up MODULE_* and platform_driver part MFD: twl4030-audio: Convert to use devm_kzalloc MFD: twl4030-audio: Rearange and clean-up the probe function MFD: twl-core: Add API to query the HFCLK rate MFD: twl4030-audio: Get audio MCLK via twl-core API instead of pdata dt: Add empty of_find_node_by_name() function MFD: twl4030-audio: Add DT support Input: twl4030-vibra: Support for DT booted kernel ASoC: twl4030: Move hs_extmute GPIO handling to driver ARM: OMAP/ASoC: Zoom2: Let the codec to handle the hs_extmute GPIO ASoC/MFD: twl4030: Remove set_hs_extmute callback from platform data ASoC: twl4030: Convert to use devm_kzalloc ASoC: twl4030: Add pointer to pdata within the private data ASoC: twl4030: Support for DT booted kernel .../devicetree/bindings/mfd/twl4030-audio.txt | 46 + arch/arm/mach-omap2/board-zoom-peripherals.c | 9 +- arch/arm/mach-omap2/include/mach/board-zoom.h | 2 - drivers/input/misc/twl4030-vibra.c | 18 +++- drivers/mfd/twl-core.c | 32 +++ drivers/mfd/twl4030-audio.c| 105 ++--- include/linux/i2c/twl.h| 3 +- include/linux/of.h | 6 ++ sound/soc/codecs/twl4030.c | 101 sound/soc/omap/zoom2.c | 4 - 10 files changed, 255 insertions(+), 71 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/twl4030-audio.txt -- 1.7.12 -- 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 v4 02/14] MFD: twl4030-audio: Convert to use devm_kzalloc
To clean up the module probe and remove functions.
Signed-off-by: Peter Ujfalusi
---
drivers/mfd/twl4030-audio.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/twl4030-audio.c b/drivers/mfd/twl4030-audio.c
index ac04b4f..efa2d42 100644
--- a/drivers/mfd/twl4030-audio.c
+++ b/drivers/mfd/twl4030-audio.c
@@ -188,7 +188,8 @@ static int __devinit twl4030_audio_probe(struct
platform_device *pdev)
twl_i2c_write_u8(TWL4030_MODULE_AUDIO_VOICE,
val, TWL4030_REG_APLL_CTL);
- audio = kzalloc(sizeof(struct twl4030_audio), GFP_KERNEL);
+ audio = devm_kzalloc(&pdev->dev, sizeof(struct twl4030_audio),
+GFP_KERNEL);
if (!audio)
return -ENOMEM;
@@ -229,22 +230,18 @@ static int __devinit twl4030_audio_probe(struct
platform_device *pdev)
ret = -ENODEV;
}
- if (!ret)
- return 0;
+ if (ret) {
+ platform_set_drvdata(pdev, NULL);
+ twl4030_audio_dev = NULL;
+ }
- platform_set_drvdata(pdev, NULL);
- kfree(audio);
- twl4030_audio_dev = NULL;
return ret;
}
static int __devexit twl4030_audio_remove(struct platform_device *pdev)
{
- struct twl4030_audio *audio = platform_get_drvdata(pdev);
-
mfd_remove_devices(&pdev->dev);
platform_set_drvdata(pdev, NULL);
- kfree(audio);
twl4030_audio_dev = NULL;
return 0;
--
1.7.12
--
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 v4 04/14] MFD: twl-core: Add API to query the HFCLK rate
CFG_BOOT register's HFCLK_FREQ field hold information about the used HFCLK
frequency.
Add possibility for users to get the configured rate based on this
register.
This register was configured during boot, without it the chip would not
operate correctly, so we can trust on this information.
Signed-off-by: Peter Ujfalusi
---
drivers/mfd/twl-core.c | 32
include/linux/i2c/twl.h | 1 +
2 files changed, 33 insertions(+)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 1c32afe..f162b68 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -552,6 +552,38 @@ int twl_get_version(void)
}
EXPORT_SYMBOL_GPL(twl_get_version);
+/**
+ * twl_get_hfclk_rate - API to get TWL external HFCLK clock rate.
+ *
+ * Api to get the TWL HFCLK rate based on BOOT_CFG register.
+ */
+int twl_get_hfclk_rate(void)
+{
+ u8 ctrl;
+ int rate;
+
+ twl_i2c_read_u8(TWL_MODULE_PM_MASTER, &ctrl, R_CFG_BOOT);
+
+ switch (ctrl & 0x3) {
+ case HFCLK_FREQ_19p2_MHZ:
+ rate = 1920;
+ break;
+ case HFCLK_FREQ_26_MHZ:
+ rate = 2600;
+ break;
+ case HFCLK_FREQ_38p4_MHZ:
+ rate = 3840;
+ break;
+ default:
+ pr_err("TWL4030: HFCLK is not configured\n");
+ rate = -EINVAL;
+ break;
+ }
+
+ return rate;
+}
+EXPORT_SYMBOL_GPL(twl_get_hfclk_rate);
+
static struct device *
add_numbered_child(unsigned chip, const char *name, int num,
void *pdata, unsigned pdata_len,
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 7ea898c..ac6488c 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -188,6 +188,7 @@ int twl_i2c_read(u8 mod_no, u8 *value, u8 reg, unsigned
num_bytes);
int twl_get_type(void);
int twl_get_version(void);
+int twl_get_hfclk_rate(void);
int twl6030_interrupt_unmask(u8 bit_mask, u8 offset);
int twl6030_interrupt_mask(u8 bit_mask, u8 offset);
--
1.7.12
--
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 v4 08/14] Input: twl4030-vibra: Support for DT booted kernel
Add support when the kernel has been booted with DT blob. In this case the
pdata is NULL, we need to reach up to the core node and check if the codec
part has been enabled to determine if we need to coexist with the codec or
not.
Signed-off-by: Peter Ujfalusi
Acked-by: Dmitry Torokhov
---
drivers/input/misc/twl4030-vibra.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/input/misc/twl4030-vibra.c
b/drivers/input/misc/twl4030-vibra.c
index fc0ed9b..2194a3c 100644
--- a/drivers/input/misc/twl4030-vibra.c
+++ b/drivers/input/misc/twl4030-vibra.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -194,13 +195,26 @@ static int twl4030_vibra_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(twl4030_vibra_pm_ops,
twl4030_vibra_suspend, twl4030_vibra_resume);
+static bool twl4030_vibra_check_coexist(struct twl4030_vibra_data *pdata,
+ struct device_node *node)
+{
+ if (pdata && pdata->coexist)
+ return true;
+
+ if (of_find_node_by_name(node, "codec"))
+ return true;
+
+ return false;
+}
+
static int __devinit twl4030_vibra_probe(struct platform_device *pdev)
{
struct twl4030_vibra_data *pdata = pdev->dev.platform_data;
+ struct device_node *twl4030_core_node = pdev->dev.parent->of_node;
struct vibra_info *info;
int ret;
- if (!pdata) {
+ if (!pdata && !twl4030_core_node) {
dev_dbg(&pdev->dev, "platform_data not available\n");
return -EINVAL;
}
@@ -210,7 +224,7 @@ static int __devinit twl4030_vibra_probe(struct
platform_device *pdev)
return -ENOMEM;
info->dev = &pdev->dev;
- info->coexist = pdata->coexist;
+ info->coexist = twl4030_vibra_check_coexist(pdata, twl4030_core_node);
INIT_WORK(&info->play_work, vibra_play_work);
info->input_dev = input_allocate_device();
--
1.7.12
--
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 v4 09/14] ASoC: twl4030: Move hs_extmute GPIO handling to driver
The external mute (if it is in use) is handled by a GPIO line. Prepare to
remove the set_hs_extmute callback and replace it with:
hs_extmute_gpio: the GPIO number to use for external mute
When the users of set_hs_extmute has been converted the callback can be removed.
Signed-off-by: Peter Ujfalusi
---
include/linux/i2c/twl.h| 4 +++-
sound/soc/codecs/twl4030.c | 32 ++--
2 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index ac6488c..2040309 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -667,7 +667,9 @@ struct twl4030_codec_data {
unsigned int check_defaults:1;
unsigned int reset_registers:1;
unsigned int hs_extmute:1;
- void (*set_hs_extmute)(int mute);
+ void (*set_hs_extmute)(int mute); /* Deprecated, use hs_extmute_gpio and
+hs_extmute_disable_level */
+ int hs_extmute_gpio;
};
struct twl4030_vibra_data {
diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c
index 391fcfc..5fc271a 100644
--- a/sound/soc/codecs/twl4030.c
+++ b/sound/soc/codecs/twl4030.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -302,6 +303,22 @@ static void twl4030_init_chip(struct snd_soc_codec *codec)
u8 reg, byte;
int i = 0;
+ if (pdata && pdata->hs_extmute &&
+ gpio_is_valid(pdata->hs_extmute_gpio)) {
+ int ret;
+
+ if (!pdata->hs_extmute_gpio)
+ dev_warn(codec->dev,
+"Extmute GPIO is 0 is this correct?\n");
+
+ ret = gpio_request_one(pdata->hs_extmute_gpio,
+ GPIOF_OUT_INIT_LOW, "hs_extmute");
+ if (ret) {
+ dev_err(codec->dev, "Failed to get hs_extmute GPIO\n");
+ pdata->hs_extmute_gpio = -1;
+ }
+ }
+
/* Check defaults, if instructed before anything else */
if (pdata && pdata->check_defaults)
twl4030_check_defaults(codec);
@@ -748,7 +765,10 @@ static void headset_ramp(struct snd_soc_codec *codec, int
ramp)
/* Enable external mute control, this dramatically reduces
* the pop-noise */
if (pdata && pdata->hs_extmute) {
- if (pdata->set_hs_extmute) {
+ if (gpio_is_valid(pdata->hs_extmute_gpio)) {
+ gpio_set_value(pdata->hs_extmute_gpio, 1);
+ } else if (pdata->set_hs_extmute) {
+ dev_warn(codec->dev, "set_hs_extmute is deprecated\n");
pdata->set_hs_extmute(1);
} else {
hs_pop |= TWL4030_EXTMUTE;
@@ -786,7 +806,10 @@ static void headset_ramp(struct snd_soc_codec *codec, int
ramp)
/* Disable external mute */
if (pdata && pdata->hs_extmute) {
- if (pdata->set_hs_extmute) {
+ if (gpio_is_valid(pdata->hs_extmute_gpio)) {
+ gpio_set_value(pdata->hs_extmute_gpio, 0);
+ } else if (pdata->set_hs_extmute) {
+ dev_warn(codec->dev, "set_hs_extmute is deprecated\n");
pdata->set_hs_extmute(0);
} else {
hs_pop &= ~TWL4030_EXTMUTE;
@@ -2230,12 +2253,17 @@ static int twl4030_soc_probe(struct snd_soc_codec
*codec)
static int twl4030_soc_remove(struct snd_soc_codec *codec)
{
+ struct twl4030_codec_data *pdata = dev_get_platdata(codec->dev);
struct twl4030_priv *twl4030 = snd_soc_codec_get_drvdata(codec);
/* Reset registers to their chip default before leaving */
twl4030_reset_registers(codec);
twl4030_set_bias_level(codec, SND_SOC_BIAS_OFF);
kfree(twl4030);
+
+ if (pdata && pdata->hs_extmute && gpio_is_valid(pdata->hs_extmute_gpio))
+ gpio_free(pdata->hs_extmute_gpio);
+
return 0;
}
--
1.7.12
--
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 v4 05/14] MFD: twl4030-audio: Get audio MCLK via twl-core API instead of pdata
twl-core has API to get the boot time configured HFCLK rate which has the
same rate as the audio MCLK.
Signed-off-by: Peter Ujfalusi
---
drivers/mfd/twl4030-audio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/twl4030-audio.c b/drivers/mfd/twl4030-audio.c
index ca2d669..a48bf3a 100644
--- a/drivers/mfd/twl4030-audio.c
+++ b/drivers/mfd/twl4030-audio.c
@@ -175,7 +175,7 @@ static int __devinit twl4030_audio_probe(struct
platform_device *pdev)
return -ENOMEM;
mutex_init(&audio->mutex);
- audio->audio_mclk = pdata->audio_mclk;
+ audio->audio_mclk = twl_get_hfclk_rate();
/* Configure APLL_INFREQ and disable APLL if enabled */
switch (audio->audio_mclk) {
--
1.7.12
--
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 v4 03/14] MFD: twl4030-audio: Rearange and clean-up the probe function
To facilitate the device tree support the probe function need to be rearanged.
Small cleanup in the APLL frequency selection part as well.
Signed-off-by: Peter Ujfalusi
---
drivers/mfd/twl4030-audio.c | 34 --
1 file changed, 16 insertions(+), 18 deletions(-)
diff --git a/drivers/mfd/twl4030-audio.c b/drivers/mfd/twl4030-audio.c
index efa2d42..ca2d669 100644
--- a/drivers/mfd/twl4030-audio.c
+++ b/drivers/mfd/twl4030-audio.c
@@ -169,35 +169,30 @@ static int __devinit twl4030_audio_probe(struct
platform_device *pdev)
return -EINVAL;
}
+ audio = devm_kzalloc(&pdev->dev, sizeof(struct twl4030_audio),
+GFP_KERNEL);
+ if (!audio)
+ return -ENOMEM;
+
+ mutex_init(&audio->mutex);
+ audio->audio_mclk = pdata->audio_mclk;
+
/* Configure APLL_INFREQ and disable APLL if enabled */
- val = 0;
- switch (pdata->audio_mclk) {
+ switch (audio->audio_mclk) {
case 1920:
- val |= TWL4030_APLL_INFREQ_19200KHZ;
+ val = TWL4030_APLL_INFREQ_19200KHZ;
break;
case 2600:
- val |= TWL4030_APLL_INFREQ_26000KHZ;
+ val = TWL4030_APLL_INFREQ_26000KHZ;
break;
case 3840:
- val |= TWL4030_APLL_INFREQ_38400KHZ;
+ val = TWL4030_APLL_INFREQ_38400KHZ;
break;
default:
dev_err(&pdev->dev, "Invalid audio_mclk\n");
return -EINVAL;
}
- twl_i2c_write_u8(TWL4030_MODULE_AUDIO_VOICE,
- val, TWL4030_REG_APLL_CTL);
-
- audio = devm_kzalloc(&pdev->dev, sizeof(struct twl4030_audio),
-GFP_KERNEL);
- if (!audio)
- return -ENOMEM;
-
- platform_set_drvdata(pdev, audio);
-
- twl4030_audio_dev = pdev;
- mutex_init(&audio->mutex);
- audio->audio_mclk = pdata->audio_mclk;
+ twl_i2c_write_u8(TWL4030_MODULE_AUDIO_VOICE, val, TWL4030_REG_APLL_CTL);
/* Codec power */
audio->resource[TWL4030_AUDIO_RES_POWER].reg = TWL4030_REG_CODEC_MODE;
@@ -222,6 +217,9 @@ static int __devinit twl4030_audio_probe(struct
platform_device *pdev)
childs++;
}
+ platform_set_drvdata(pdev, audio);
+ twl4030_audio_dev = pdev;
+
if (childs)
ret = mfd_add_devices(&pdev->dev, pdev->id, audio->cells,
childs, NULL, 0);
--
1.7.12
--
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 v4 01/14] MFD: twl4030-audio: Clean up MODULE_* and platform_driver part
Place the MODULE_* lines in the same block and add MODULE_DESCRIPTION.
Rearange the platform_driver structure at the same time.
Signed-off-by: Peter Ujfalusi
---
drivers/mfd/twl4030-audio.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/twl4030-audio.c b/drivers/mfd/twl4030-audio.c
index 838ce4e..ac04b4f 100644
--- a/drivers/mfd/twl4030-audio.c
+++ b/drivers/mfd/twl4030-audio.c
@@ -250,18 +250,18 @@ static int __devexit twl4030_audio_remove(struct
platform_device *pdev)
return 0;
}
-MODULE_ALIAS("platform:twl4030-audio");
-
static struct platform_driver twl4030_audio_driver = {
- .probe = twl4030_audio_probe,
- .remove = __devexit_p(twl4030_audio_remove),
.driver = {
.owner = THIS_MODULE,
.name = "twl4030-audio",
},
+ .probe = twl4030_audio_probe,
+ .remove = __devexit_p(twl4030_audio_remove),
};
module_platform_driver(twl4030_audio_driver);
MODULE_AUTHOR("Peter Ujfalusi ");
+MODULE_DESCRIPTION("TWL4030 audio block MFD driver");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:twl4030-audio");
--
1.7.12
--
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] ARM: OMAP2+: mux: add support for PAD wakeup event handler
On Mon, Sep 10, 2012 at 4:08 PM, Ruslan Bilovol wrote:
> OMAP mux now parses active wakeup events from pad registers and calls
> corresponding handler, if handler is not registered - corresponding
> hwmod ISRs once a wakeup is detected.
> This is useful for cases when routing wakeups to corresponding hwmod
> ISRs complicates those ISRs handlers (for example, ISR handler may
> not know who the interrupt source is)
>
> Signed-off-by: Ruslan Bilovol
> ---
> arch/arm/mach-omap2/mux.c| 14 +--
> arch/arm/mach-omap2/omap_hwmod.c | 29
> ++
> arch/arm/plat-omap/include/plat/omap_hwmod.h |4 +++
> 3 files changed, 44 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
> index 9fe6829..2918638 100644
> --- a/arch/arm/mach-omap2/mux.c
> +++ b/arch/arm/mach-omap2/mux.c
> @@ -372,6 +372,7 @@ static bool omap_hwmod_mux_scan_wakeups(struct
> omap_hwmod_mux_info *hmux,
> int i, irq;
> unsigned int val;
> u32 handled_irqs = 0;
> + bool retval = false;
>
> for (i = 0; i < hmux->nr_pads_dynamic; i++) {
> struct omap_device_pad *pad = hmux->pads_dynamic[i];
> @@ -384,8 +385,15 @@ static bool omap_hwmod_mux_scan_wakeups(struct
> omap_hwmod_mux_info *hmux,
> if (!(val & OMAP_WAKEUP_EVENT))
> continue;
>
> - if (!hmux->irqs)
> - return true;
> + if (hmux->wakeup_handler && hmux->wakeup_handler[i]) {
> + hmux->wakeup_handler[i](hmux);
> + continue;
> + }
> +
> + if (!hmux->irqs) {
> + retval = true;
> + continue;
> + }
>
> irq = hmux->irqs[i];
> /* make sure we only handle each irq once */
> @@ -397,7 +405,7 @@ static bool omap_hwmod_mux_scan_wakeups(struct
> omap_hwmod_mux_info *hmux,
> generic_handle_irq(mpu_irqs[irq].irq);
> }
>
> - return false;
> + return retval;
> }
>
> /**
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> b/arch/arm/mach-omap2/omap_hwmod.c
> index 6ca8e51..9a41d65 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -3656,6 +3656,35 @@ int omap_hwmod_pad_route_irq(struct omap_hwmod *oh,
> int pad_idx, int irq_idx)
> }
>
> /**
> + * omap_hwmod_pad_wakeup_handler - add wakeup handler for an I/O pad wakeup
> + * @oh: struct omap_hwmod * containing hwmod mux entries
> + * @pad_idx: array index in oh->mux of the hwmod mux entry to handle wakeup
> + * @wakeup_handler: the wakeup_handler function to trigger on wakeup
> + */
> +int omap_hwmod_pad_wakeup_handler(struct omap_hwmod *oh, int pad_idx,
> + int (*wakeup_handler)(struct omap_hwmod_mux_info *hmux))
> +{
> + might_sleep();
> +
> + if (!oh || !oh->mux || pad_idx < 0 ||
> + pad_idx >= oh->mux->nr_pads_dynamic)
> + return -EINVAL;
> +
> + if (!oh->mux->wakeup_handler) {
> + /* XXX What frees this? */
> + oh->mux->wakeup_handler =
> + kzalloc(sizeof(*(oh->mux->wakeup_handler)) *
> + oh->mux->nr_pads_dynamic, GFP_KERNEL);
> +
> + if (!oh->mux->wakeup_handler)
> + return -ENOMEM;
> + }
> + oh->mux->wakeup_handler[pad_idx] = wakeup_handler;
> +
> + return 0;
> +}
> +
> +/**
> * omap_hwmod_init - initialize the hwmod code
> *
> * Sets up some function pointers needed by the hwmod code to operate on the
> diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
> b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> index 6132972..5c2bcc7 100644
> --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
> +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> @@ -110,6 +110,7 @@ struct omap_hwmod_mux_info {
> int nr_pads_dynamic;
> struct omap_device_pad **pads_dynamic;
> int *irqs;
> + int (**wakeup_handler)(struct
> omap_hwmod_mux_info *hmux);
> boolenabled;
> };
>
> @@ -646,6 +647,9 @@ int omap_hwmod_no_setup_reset(struct omap_hwmod *oh);
>
> int omap_hwmod_pad_route_irq(struct omap_hwmod *oh, int pad_idx, int
> irq_idx);
>
> +int omap_hwmod_pad_wakeup_handler(struct omap_hwmod *oh, int pad_idx,
> + int (*wakeup_handler)(struct omap_hwmod_mux_info *hmux));
> +
> extern void __init omap_hwmod_init(void);
>
> const char *omap_hwmod_get_main_clk(struct omap_hwmod *oh);
> --
> 1.7.1
>
This is good idea!
if tero is Ok with this patch ; I will use this for ehci
remote wakeup implementation.
regards
keshava
--
To unsubscribe from this list: send the line "unsubscribe linux-o
Re: Seeking clarity on IRQCHIP_MASK_ON_SUSPEND
Thomas, On Mon, Sep 10, 2012 at 3:58 PM, Thomas Gleixner wrote: > On Mon, 10 Sep 2012, NeilBrown wrote: >> >> The IRQCHIP_MASK_ON_SUSPEND flag seems to be hard to use correctly, so either >> I'm understanding it wrongly, or it could be made easier to use. >> If the first case, I'm hoping that some improvement to documentation might >> result. If the second, then maybe we can fix the code. > ... >> Is anyone able to give a definitive answer on this? Should >> IRQCHIP_MASK_ON_SUSPEND be removed? > > The whole point of IRQCHIP_MASK_ON_SUSPEND is to deal with hardware > designed by geniuses. > > Most SoCs have a way to mark the interrupts which serve as a wake up > source as such. All other interrupts are magically "masked" on entry > to suspend. > Just to support this, IRQCHIP_MASK_ON_SUSPEND does work with quite a few ARM platforms too. OMAP already uses it in mainline and I have seen patches for U500 and Tegra SOCs. Most of these usages are with IRQ chips who doesn't have any driver run time PM supported and the IRQ CHIP itself is shutdown when the CPU/CPU cluster gets power down. So as far as functionality concerned with the flag, it does what it suppose to do. > Now there is hardware which is missing such a control, so we need to > mask the non wakeup interrupts right before going into suspend. > > That's what IRQCHIP_MASK_ON_SUSPEND does. Not more, not less. See > commit d209a699a0b for more ugly details. > > You might be looking for a different functionality. Can you explain > what you need? > Neil's email came from a discussion on the usage of this flag for OMAP GPIO irqchip which I proposed. With the flag, when the lazy check_irq routine is called, the GPIO driver is runtime suspended and hence the late mask/unmask calls take abort(clocks are already gated). GPIO IRQCHIP is secondary IRQCHIP connected to 1 interrupt line per bank(32 GPIOs) to the primary interrupt controller IRQCHIP. Hope this gives bit more clarity to the discussed problem. Regards Santosh -- 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 v3 1/8] ARM/dts: omap2: Add McBSP entries for OMAP2420 and OMAP2430 SoC
Hi Benoit,
On 09/10/2012 11:07 AM, Benoit Cousson wrote:
> Hi Tony,
>
> On 09/08/2012 12:29 AM, Tony Lindgren wrote:
>> * Peter Ujfalusi [120905 04:59]:
>>> +
>>> + ocp {
>>> + mcbsp1: mcbsp@48074000 {
>>> + compatible = "ti,omap2420-mcbsp";
>>> + reg = <0x48074000 0xff>;
>>> + reg-names = "mpu";
>>> + interrupts = <59>, /* TX interrupt */
>>> +<60>; /* RX interrupt */
>>> + interrupt-names = "tx", "rx";
>>> + interrupt-parent = <&intc>;
>>> + ti,hwmods = "mcbsp1";
>>> + };
>>> +
>>> + mcbsp2: mcbsp@48076000 {
>>> + compatible = "ti,omap2420-mcbsp";
>>> + reg = <0x48076000 0xff>;
>>> + reg-names = "mpu";
>>> + interrupts = <62>, /* TX interrupt */
>>> +<63>; /* RX interrupt */
>>> + interrupt-names = "tx", "rx";
>>> + interrupt-parent = <&intc>;
>>> + ti,hwmods = "mcbsp2";
>>> + };
>>> + };
>>
>> Hmm don't you need to specify the interrupt chip and offset for
>> the interrupts here?
>
> Mmm, I'm not sure to get your question, there is the link to the
> interrupt-parent.
>
> The interrupt number is relative to the parent interrupt domain. So even
> if the INTC IRQ offset start at 32 instead of 0, DT IRQ mechanism will
> convert that to the proper hwirq thanks to irqdomain.
> In that case we should always provide interrupt number relative to the
> interrupt controller HW number and not assuming any Linux IRQ number
> offset like before.
>
>
> And in fact the interrupt-parent is not even needed, by default if will
> look to the parent to get the interrupt-controller.
This is true, but it makes the 'code' a bit more readable if I (we) specify
the interrupt-parent.
>
> Extract from [1]
>
> interrupt-parent:
> "Because the hierarchy of the nodes in the interrupt tree might not
> match the device tree, the interrupt-parent property is available to
> make the definition of an interrupt parent explicit.
> The value is the phandle to the interrupt parent. If this property is
> missing from a device, its interrupt parent is assumed to be its device
> tree parent."
>
> [1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf
>
> Regards,
> Benoit
>
--
Péter
--
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 v2] perf: Use pre-empt safe cpu_get/put insted of smp_processor_id
gets rid of below messages with CONFIG_DEBUG_PREEMPT enabled
[ 28.832916] debug_smp_processor_id: 18 callbacks suppressed
[ 28.832946] BUG: using smp_processor_id() in preemptible [] code:
modprobe/1763
[ 28.841491] caller is pwrdm_set_next_pwrst+0x54/0x120
changes in v2:
- rebased on 3.6-rc5
- use put_cpu() immediately after get_cpu() in omap3_pm_idle()
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/clock.c |9 ++---
arch/arm/mach-omap2/pm34xx.c | 12
arch/arm/mach-omap2/powerdomain.c |6 --
3 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index ea3f565..06747b6 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -285,7 +285,8 @@ void omap2_clk_disable(struct clk *clk)
pr_debug("clock: %s: disabling in hardware\n", clk->name);
if (clk->ops && clk->ops->disable) {
- trace_clock_disable(clk->name, 0, smp_processor_id());
+ trace_clock_disable(clk->name, 0, get_cpu());
+ put_cpu();
clk->ops->disable(clk);
}
@@ -339,7 +340,8 @@ int omap2_clk_enable(struct clk *clk)
}
if (clk->ops && clk->ops->enable) {
- trace_clock_enable(clk->name, 1, smp_processor_id());
+ trace_clock_enable(clk->name, 1, get_cpu());
+ put_cpu();
ret = clk->ops->enable(clk);
if (ret) {
WARN(1, "clock: %s: could not enable: %d\n",
@@ -380,7 +382,8 @@ int omap2_clk_set_rate(struct clk *clk, unsigned long rate)
/* dpll_ck, core_ck, virt_prcm_set; plus all clksel clocks */
if (clk->set_rate) {
- trace_clock_set_rate(clk->name, rate, smp_processor_id());
+ trace_clock_set_rate(clk->name, rate, get_cpu());
+ put_cpu();
ret = clk->set_rate(clk, rate);
}
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 05bd8f0..5aa0a11 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -346,18 +346,22 @@ void omap_sram_idle(void)
static void omap3_pm_idle(void)
{
+ unsigned cpu;
+
local_fiq_disable();
if (omap_irq_pending())
goto out;
- trace_power_start(POWER_CSTATE, 1, smp_processor_id());
- trace_cpu_idle(1, smp_processor_id());
+ cpu = get_cpu();
+ put_cpu();
+ trace_power_start(POWER_CSTATE, 1, cpu);
+ trace_cpu_idle(1, cpu);
omap_sram_idle();
- trace_power_end(smp_processor_id());
- trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
+ trace_power_end(cpu);
+ trace_cpu_idle(PWR_EVENT_EXIT, cpu);
out:
local_fiq_enable();
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 69b36e1..138bf86 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -169,7 +169,8 @@ static int _pwrdm_state_switch(struct powerdomain *pwrdm,
int flag)
((state & OMAP_POWERSTATE_MASK) << 8) |
((prev & OMAP_POWERSTATE_MASK) << 0));
trace_power_domain_target(pwrdm->name, trace_state,
- smp_processor_id());
+ get_cpu());
+ put_cpu();
}
break;
default:
@@ -491,7 +492,8 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8
pwrst)
if (arch_pwrdm && arch_pwrdm->pwrdm_set_next_pwrst) {
/* Trace the pwrdm desired target state */
trace_power_domain_target(pwrdm->name, pwrst,
- smp_processor_id());
+ get_cpu());
+ put_cpu();
/* Program the pwrdm desired target state */
ret = arch_pwrdm->pwrdm_set_next_pwrst(pwrdm, pwrst);
}
--
1.7.4.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: [PATCH 0/2] ARM: omap/dts: Add support for Gumstix Overo with Tobi expansion
On 09/10/2012 11:25 AM, Florian Vaussard wrote: > Le 06/09/2012 22:52, Tony Lindgren a écrit : >> * Florian Vaussard [120831 09:07]: >>> The Gumstix Overo is a computer on module using an OMAP3 processor. >>> This module must be plugged into an expansion board. >>> >>> This patchset adds a first device tree support for the Overo, using the >>> Tobi expansion board. The current support is able to boot and mount >>> the rootfs from MMC, with a few extra features. >>> >>> The first patch creates the device tree for both the Overo and the >>> Tobi expansion board, and updates the dtb build target. >>> >>> The second patch updates the omap/dts documentation. >>> >>> This patchset applies on tony's tree [1], devel-dt branch. >> Great, I'm assuming Benoit will pick this up as well. > > What is the status Benoit? Patches looks good to me. I just adding them right now in my for_3.7/dts tree. I've just slightly changed the subjects: Documentation: dt: Update the OMAP documentation with Overo/Toby ARM: dts: OMAP3: Add support for Gumstix Overo with Tobi expansion board If you want to give it a try, here is the branch that contains all the DTS series I already pulled. It includes your gpio-twl4030 patches as well. git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.7/dts Regards, Benoit -- 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] ARM: OMAP5: Enable arch timer support
Benoit, On Mon, Aug 13, 2012 at 4:37 PM, Santosh Shilimkar wrote: > Enable Cortex A15 generic timer support for OMAP5 based SOCs. > The CPU local timers run on the free running real time counter clock. > > Signed-off-by: Santosh Shilimkar > --- > arch/arm/boot/dts/omap5.dtsi |6 ++ > arch/arm/mach-omap2/Kconfig |1 + > arch/arm/mach-omap2/timer.c |7 +++ > 3 files changed, 14 insertions(+) > Missed to copy you on this patch. Your comments/ack on the DT part. Regards Santosh -- 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 0/2] ARM: omap/dts: Add support for Gumstix Overo with Tobi expansion
What is the status Benoit? Patches looks good to me. I just adding them right now in my for_3.7/dts tree. I've just slightly changed the subjects: Documentation: dt: Update the OMAP documentation with Overo/Toby ARM: dts: OMAP3: Add support for Gumstix Overo with Tobi expansion board If you want to give it a try, here is the branch that contains all the DTS series I already pulled. It includes your gpio-twl4030 patches as well. git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.7/dts Great, thank you! I will test your branch on my Overo ASAP. Regards, Florian -- 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] pinctrl: pinctrl-single: Add pinctrl-single,bits type of mux
On 09/07/2012 07:55 PM, Tony Lindgren wrote:
> * Peter Ujfalusi [120907 08:13]:
>> On 09/06/2012 10:10 PM, Tony Lindgren wrote:
>>>
>>> Is it now safe to assume that we always have width of three if
>>> pinctrl-single,bits is specified? The reason I'm asking is..
>>>
@@ -657,18 +664,29 @@ static int pcs_parse_one_pinctrl_entry(struct
pcs_device *pcs,
{
struct pcs_func_vals *vals;
const __be32 *mux;
- int size, rows, *pins, index = 0, found = 0, res = -ENOMEM;
+ int size, params, rows, *pins, index = 0, found = 0, res = -ENOMEM;
struct pcs_function *function;
- mux = of_get_property(np, PCS_MUX_NAME, &size);
- if ((!mux) || (size < sizeof(*mux) * 2)) {
- dev_err(pcs->dev, "bad data for mux %s\n",
- np->name);
+ mux = of_get_property(np, PCS_MUX_PINS_NAME, &size);
+ if (mux) {
+ params = 2;
+ } else {
+ mux = of_get_property(np, PCS_MUX_BITS_NAME, &size);
+ if (!mux) {
+ dev_err(pcs->dev, "no valid property for %s\n",
+ np->name);
+ return -EINVAL;
+ }
+ params = 3;
+ }
>>>
>>> ..because here we could assume the default value for params is 2
>>> if pinctrl-single,pins is specified, and otherwise params is 3
>>> if pinctrl-single,bits is specified for the controller. That would
>>> avoid querying a potentially non-exiting property for each entry.
>>>
@@ -686,6 +704,10 @@ static int pcs_parse_one_pinctrl_entry(struct
pcs_device *pcs,
val = be32_to_cpup(mux + index++);
vals[found].reg = pcs->base + offset;
vals[found].val = val;
+ if (params == 3) {
+ val = be32_to_cpup(mux + index++);
+ vals[found].mask = val;
+ }
pin = pcs_get_pin_by_offset(pcs, offset);
if (pin < 0) {
>>>
>>> Here params too would be then set during probe already.
>>
>> I'm afraid you lost me here...
>> We only know if the user specified the mux configuration with
>> pinctrl-single,pins or pinctrl-single,bits in this function.
>
> Sorry right, yeah we don't know that at probe time currently.
>
> I'd like to have something that specifies the controller type so
> we don't need to mix two types of controllers and test for
> non-existing properties when parsing the pins.
>
> How about we require something specified for the pinctrl driver
> in the "one-bit-per-mux" case like pinctrl-single,bit-per-mux?
>
> And then in the pinctrl-single probe we set params = 3 if
> pinctrl-single,bit-per-mux is specified. And if no
> pinctrl-single,bit-per-mux is specified then set params = 2.
>
> That way pcs_parse_one_pinctrl_entry() can just test for params.
>
> Sorry I don't have a better name in mind than bit-per-mux..
I'm not sure if this would make things more prone to error or make the DTS or
the code more clean in any ways.
Both pinctrl-single,pins and pinctrl-single,bits works on top of the same
pinctrl-single area.
In most cases we are going to use pinctrl-single,pins for the mux
configuration and only in few places we need to fall back to
pinctrl-single,bits.
With this patch we will have maximum of two query to find out which type is
used, while if we add the 'bit-per-mux' property we will always have need to
have two of_get_property() call to figure out what is used.
IMHO in this way we could also have copy-paste errors coming at us when adding
the mux configurations for the pins and at the end we also need to do same
safety/sanity checks if the user really provided the correct type with
correlation to the 'bit-per-mux'.
This would just complicate the code.
The existence of pinctrl-single,pins or pinctrl-single,bits property alone
gives enough information for the number of parameters.
>
>> One thing I could do to make the code a bit better to look at is:
>> int params = 2;
>>
>> mux = of_get_property(np, PCS_MUX_PINS_NAME, &size);
>> if (!mux) {
>> mux = of_get_property(np, PCS_MUX_BITS_NAME, &size);
>> if (!mux) {
>> dev_err(pcs->dev, "no valid property for %s\n",
>> np->name);
>> return -EINVAL;
>> }
>> params = 3;
>> }
>>
>> This might make the code a bit more compact but at the same time one might
>> need to spend few more seconds to understand it.
>
> Yes well there's no need to do of_get_property second guessing
> if we already know params from the pinctrl-single.c probe time.
>
> I think we're safe to assume that we don't need to mix parsing
> two different types of configuration for the same controller
> as they can always be set up as separate controllers.
>
> Regards,
>
> Tony
>
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majo
Re: [PATCH 2/2] ARM: OMAP5: Enable arch timer support
Hi Santosh,
On 08/13/2012 01:07 PM, Santosh Shilimkar wrote:
> Enable Cortex A15 generic timer support for OMAP5 based SOCs.
> The CPU local timers run on the free running real time counter clock.
>
> Signed-off-by: Santosh Shilimkar
> ---
> arch/arm/boot/dts/omap5.dtsi |6 ++
> arch/arm/mach-omap2/Kconfig |1 +
> arch/arm/mach-omap2/timer.c |7 +++
> 3 files changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index 57e5270..9686056 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -73,6 +73,12 @@
> <0x48212000 0x1000>;
> };
>
> + arch-timer {
arch-timer is the ARM specific name, so I guess here it should be named
with the generic timer name.
> + compatible = "arm,armv7-timer";
> + interrupts = <1 14 0x304>;
Could you add some comment, because these hexa value are a little bit
hard to understand.
> + clock-frequency = <614>;
> + };
> +
That node does not even have a base address?
If this is located inside the MPU, it should not be in the OCP node.
Silly question: Don't we have one arch-timer per CPU?
Regards,
Benoit
> gpio1: gpio@4ae1 {
> compatible = "ti,omap4-gpio";
> ti,hwmods = "gpio1";
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 2120f90..53fb77c 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -73,6 +73,7 @@ config SOC_OMAP5
> select ARM_GIC
> select HAVE_SMP
> select SOC_HAS_REALTIME_COUNTER
> + select ARM_ARCH_TIMER
>
> comment "OMAP Core Type"
> depends on ARCH_OMAP2
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 9b17e6c..f74dbb2 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -41,6 +41,7 @@
> #include
> #include
> #include
> +#include
> #include "common.h"
> #include
> #include
> @@ -480,9 +481,15 @@ OMAP_SYS_TIMER(4)
> #ifdef CONFIG_SOC_OMAP5
> static void __init omap5_timer_init(void)
> {
> + int err;
> +
> omap2_gp_clockevent_init(1, OMAP4_CLKEV_SOURCE);
> omap2_clocksource_init(2, OMAP4_MPU_SOURCE);
> realtime_counter_init();
> +
> + err = arch_timer_of_register();
> + if (err)
> + pr_err("%s: arch_timer_register failed %d\n", __func__, err);
> }
> OMAP_SYS_TIMER(5)
> #endif
>
--
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] drm/omap: add more new timings fields
On Mon, Sep 10, 2012 at 12:50 AM, Tomi Valkeinen wrote: > On Fri, 2012-09-07 at 12:59 -0500, Rob Clark wrote: >> From: Rob Clark >> >> Without these, DVI is broken. >> >> Signed-off-by: Rob Clark >> --- >> Greg, it looks like the omapdss changes which added these fields, as >> well as the interlaced field, where merged in Linux 3.5-rc5. So I >> think both this and the 'update for interlaced' patch are needed for >> both 3.6 and 3.5. > > The omapdss timing and interlace changes were merged in 3.6 merge > window, they were not merged in 3.5 merge window (and even less in > 3.5-rc5)... ok, git-log must be playing tricks on me... then these patches are only needed for 3.6 BR, -R > Tomi > -- 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 0/2] ARM: omap/dts: Add support for Gumstix Overo with Tobi expansion
Patches looks good to me. I just adding them right now in my for_3.7/dts tree. I've just slightly changed the subjects: Documentation: dt: Update the OMAP documentation with Overo/Toby ARM: dts: OMAP3: Add support for Gumstix Overo with Tobi expansion board If you want to give it a try, here is the branch that contains all the DTS series I already pulled. It includes your gpio-twl4030 patches as well. git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.7/dts Boot as expected on Gumstix Overo with Tobi expansion board. I will submit a patch to support the blue LED connected to the TWL4030, as the DTS support was merged in your branch. And of course I will continue on getting features to work with devicetree for the Overo. Regards, Florian -- 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] ARM: OMAP5: Enable arch timer support
On Mon, Sep 10, 2012 at 6:17 PM, Benoit Cousson wrote:
>
> Hi Santosh,
>
> On 08/13/2012 01:07 PM, Santosh Shilimkar wrote:
> > Enable Cortex A15 generic timer support for OMAP5 based SOCs.
> > The CPU local timers run on the free running real time counter clock.
> >
> > Signed-off-by: Santosh Shilimkar
> > ---
> > arch/arm/boot/dts/omap5.dtsi |6 ++
> > arch/arm/mach-omap2/Kconfig |1 +
> > arch/arm/mach-omap2/timer.c |7 +++
> > 3 files changed, 14 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> > index 57e5270..9686056 100644
> > --- a/arch/arm/boot/dts/omap5.dtsi
> > +++ b/arch/arm/boot/dts/omap5.dtsi
> > @@ -73,6 +73,12 @@
> > <0x48212000 0x1000>;
> > };
> >
> > + arch-timer {
>
> arch-timer is the ARM specific name, so I guess here it should be named
> with the generic timer name.
>
is "local_timer" name fine then?
> > + compatible = "arm,armv7-timer";
> > + interrupts = <1 14 0x304>;
>
> Could you add some comment, because these hexa value are a little bit
> hard to understand.
>
OK. Will add some comments.
> > + clock-frequency = <614>;
> > + };
> > +
>
> That node does not even have a base address?
> If this is located inside the MPU, it should not be in the OCP node.
>
Its inside MPU and Cp15 control based. No OCP node.
> Silly question: Don't we have one arch-timer per CPU?
>
It is per CPU just like A9 TWD
Regards
santosh
--
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] ARM: OMAP5: Enable arch timer support
On 09/10/2012 03:01 PM, Shilimkar, Santosh wrote:
> On Mon, Sep 10, 2012 at 6:17 PM, Benoit Cousson wrote:
>>
>> Hi Santosh,
>>
>> On 08/13/2012 01:07 PM, Santosh Shilimkar wrote:
>>> Enable Cortex A15 generic timer support for OMAP5 based SOCs.
>>> The CPU local timers run on the free running real time counter clock.
>>>
>>> Signed-off-by: Santosh Shilimkar
>>> ---
>>> arch/arm/boot/dts/omap5.dtsi |6 ++
>>> arch/arm/mach-omap2/Kconfig |1 +
>>> arch/arm/mach-omap2/timer.c |7 +++
>>> 3 files changed, 14 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
>>> index 57e5270..9686056 100644
>>> --- a/arch/arm/boot/dts/omap5.dtsi
>>> +++ b/arch/arm/boot/dts/omap5.dtsi
>>> @@ -73,6 +73,12 @@
>>> <0x48212000 0x1000>;
>>> };
>>>
>>> + arch-timer {
>>
>> arch-timer is the ARM specific name, so I guess here it should be named
>> with the generic timer name.
>>
> is "local_timer" name fine then?
No, *timer* is fine. The point here is to provide the generic name when
it exists. That name is supposed to be the general class of the device.
Potentially you can add a label to give an unique name, but since that
label will not be used elsewhere it is not even needed.
arch-timer: timer { ... }
>
>>> + compatible = "arm,armv7-timer";
>>> + interrupts = <1 14 0x304>;
>>
>> Could you add some comment, because these hexa value are a little bit
>> hard to understand.
>>
> OK. Will add some comments.
>
>>> + clock-frequency = <614>;
>>> + };
>>> +
>>
>> That node does not even have a base address?
>> If this is located inside the MPU, it should not be in the OCP node.
>>
> Its inside MPU and Cp15 control based. No OCP node.
OK, so you must move it inside the CPU node.
>> Silly question: Don't we have one arch-timer per CPU?
>>
> It is per CPU just like A9 TWD
Shouldn't we have two nodes then?
Regards,
Benoit
--
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/1] ARM: dts: OMAP3: Add gpio-twl4030 properties for Overo
Hello, This patch adds the support for the blue LED connected to the LEDB pin of the TWL4030 on the Gumstix Overo when booting from the device tree. Build on top of Benoit's for_3.7/dts tree. Regards, Florian Florian Vaussard (1): ARM: dts: OMAP3: Add gpio-twl4030 properties for Overo arch/arm/boot/dts/omap3-overo.dtsi | 15 +++ 1 files changed, 15 insertions(+), 0 deletions(-) -- 1.7.5.4 -- 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/1] ARM: dts: OMAP3: Add gpio-twl4030 properties for Overo
Support the blue LED connected to the LEDB pin of the TWL4030
on the Gumstix Overo.
Signed-off-by: Florian Vaussard
---
arch/arm/boot/dts/omap3-overo.dtsi | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
b/arch/arm/boot/dts/omap3-overo.dtsi
index d6cc5e2..89808ce 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -13,6 +13,17 @@
/include/ "omap3.dtsi"
+/ {
+ leds {
+ compatible = "gpio-leds";
+ overo {
+ label = "overo:blue:COM";
+ gpios = <&twl_gpio 19 0>;
+ linux,default-trigger = "mmc0";
+ };
+ };
+};
+
&i2c1 {
clock-frequency = <260>;
@@ -40,3 +51,7 @@
&mmc2 {
bus-width = <4>;
};
+
+&twl_gpio {
+ ti,use-leds;
+};
--
1.7.5.4
--
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: Seeking clarity on IRQCHIP_MASK_ON_SUSPEND
On Mon, 10 Sep 2012, Shilimkar, Santosh wrote: > Thomas, > > On Mon, Sep 10, 2012 at 3:58 PM, Thomas Gleixner wrote: > > On Mon, 10 Sep 2012, NeilBrown wrote: > >> > >> The IRQCHIP_MASK_ON_SUSPEND flag seems to be hard to use correctly, so > >> either > >> I'm understanding it wrongly, or it could be made easier to use. > >> If the first case, I'm hoping that some improvement to documentation might > >> result. If the second, then maybe we can fix the code. > > ... > >> Is anyone able to give a definitive answer on this? Should > >> IRQCHIP_MASK_ON_SUSPEND be removed? > > > > The whole point of IRQCHIP_MASK_ON_SUSPEND is to deal with hardware > > designed by geniuses. > > > > Most SoCs have a way to mark the interrupts which serve as a wake up > > source as such. All other interrupts are magically "masked" on entry > > to suspend. > > > Just to support this, IRQCHIP_MASK_ON_SUSPEND does work with quite > a few ARM platforms too. OMAP already uses it in mainline and I have > seen patches for U500 and Tegra SOCs. Most of these usages are with > IRQ chips who doesn't have any driver run time PM supported and > the IRQ CHIP itself is shutdown when the CPU/CPU cluster gets > power down. So as far as functionality concerned with the flag, > it does what it suppose to do. > > > Now there is hardware which is missing such a control, so we need to > > mask the non wakeup interrupts right before going into suspend. > > > > That's what IRQCHIP_MASK_ON_SUSPEND does. Not more, not less. See > > commit d209a699a0b for more ugly details. > > > > You might be looking for a different functionality. Can you explain > > what you need? > > > Neil's email came from a discussion on the usage of this flag for > OMAP GPIO irqchip which I proposed. With the flag, when the > lazy check_irq routine is called, the GPIO driver is runtime suspended > and hence the late mask/unmask calls take abort(clocks are already gated). > GPIO IRQCHIP is secondary IRQCHIP connected to 1 interrupt line > per bank(32 GPIOs) to the primary interrupt controller IRQCHIP. So for this thing you need a IRQCHIP_MASK_BEFORE_SUSPEND variant? -- 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/1] ARM: dts: OMAP3: Add gpio-twl4030 properties for Overo
On 09/10/2012 03:16 PM, Florian Vaussard wrote:
> Support the blue LED connected to the LEDB pin of the TWL4030
> on the Gumstix Overo.
>
> Signed-off-by: Florian Vaussard
> ---
> arch/arm/boot/dts/omap3-overo.dtsi | 15 +++
> 1 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
> b/arch/arm/boot/dts/omap3-overo.dtsi
> index d6cc5e2..89808ce 100644
> --- a/arch/arm/boot/dts/omap3-overo.dtsi
> +++ b/arch/arm/boot/dts/omap3-overo.dtsi
> @@ -13,6 +13,17 @@
>
> /include/ "omap3.dtsi"
>
> +/ {
BTW, I'm just wondering. Cannot we use overo without tobi?
In that case, the model and compatible should probably be used as well:
model = "TI OMAP3 Gumstix Overo";
compatible = "ti,omap3-overo", "ti,omap3";
> + leds {
> + compatible = "gpio-leds";
> + overo {
> + label = "overo:blue:COM";
> + gpios = <&twl_gpio 19 0>;
> + linux,default-trigger = "mmc0";
> + };
> + };
> +};
> +
> &i2c1 {
> clock-frequency = <260>;
>
> @@ -40,3 +51,7 @@
> &mmc2 {
> bus-width = <4>;
> };
> +
> +&twl_gpio {
> + ti,use-leds;
> +};
>
Otherwise, it is fine.
Thanks,
Benoit
--
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/1] ARM: dts: OMAP3: Add gpio-twl4030 properties for Overo
Support the blue LED connected to the LEDB pin of the TWL4030
on the Gumstix Overo.
Signed-off-by: Florian Vaussard
---
arch/arm/boot/dts/omap3-overo.dtsi | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
b/arch/arm/boot/dts/omap3-overo.dtsi
index d6cc5e2..89808ce 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -13,6 +13,17 @@
/include/ "omap3.dtsi"
+/ {
BTW, I'm just wondering. Cannot we use overo without tobi?
In that case, the model and compatible should probably be used as well:
model = "TI OMAP3 Gumstix Overo";
compatible = "ti,omap3-overo", "ti,omap3";
No, it cannot. The Overo needs to be plugged into an expansion board, at
least to get the power. Hence the absence of model and compatible in
omap3-overo.dtsi.
Regards,
Florian
--
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] ARM: OMAP5: Enable arch timer support
On Mon, Sep 10, 2012 at 6:44 PM, Benoit Cousson wrote:
>
> On 09/10/2012 03:01 PM, Shilimkar, Santosh wrote:
> > On Mon, Sep 10, 2012 at 6:17 PM, Benoit Cousson
> > wrote:
> >>
> >> Hi Santosh,
> >>
> >> On 08/13/2012 01:07 PM, Santosh Shilimkar wrote:
> >>> Enable Cortex A15 generic timer support for OMAP5 based SOCs.
> >>> The CPU local timers run on the free running real time counter clock.
> >>>
> >>> Signed-off-by: Santosh Shilimkar
> >>> ---
> >>> arch/arm/boot/dts/omap5.dtsi |6 ++
> >>> arch/arm/mach-omap2/Kconfig |1 +
> >>> arch/arm/mach-omap2/timer.c |7 +++
> >>> 3 files changed, 14 insertions(+)
> >>>
> >>> diff --git a/arch/arm/boot/dts/omap5.dtsi
> >>> b/arch/arm/boot/dts/omap5.dtsi
> >>> index 57e5270..9686056 100644
> >>> --- a/arch/arm/boot/dts/omap5.dtsi
> >>> +++ b/arch/arm/boot/dts/omap5.dtsi
> >>> @@ -73,6 +73,12 @@
> >>> <0x48212000 0x1000>;
> >>> };
> >>>
> >>> + arch-timer {
> >>
> >> arch-timer is the ARM specific name, so I guess here it should be named
> >> with the generic timer name.
> >>
> > is "local_timer" name fine then?
>
> No, *timer* is fine. The point here is to provide the generic name when
> it exists. That name is supposed to be the general class of the device.
>
> Potentially you can add a label to give an unique name, but since that
> label will not be used elsewhere it is not even needed.
>
> arch-timer: timer { ... }
>
Ok. Will use this.
> >
> >>> + compatible = "arm,armv7-timer";
> >>> + interrupts = <1 14 0x304>;
> >>
> >> Could you add some comment, because these hexa value are a little bit
> >> hard to understand.
> >>
> > OK. Will add some comments.
> >
> >>> + clock-frequency = <614>;
> >>> + };
> >>> +
> >>
> >> That node does not even have a base address?
> >> If this is located inside the MPU, it should not be in the OCP node.
> >>
> > Its inside MPU and Cp15 control based. No OCP node.
>
> OK, so you must move it inside the CPU node.
>
OK. Will do.
> >> Silly question: Don't we have one arch-timer per CPU?
> >>
> > It is per CPU just like A9 TWD
>
> Shouldn't we have two nodes then?
>
I need to check this but arch timer DT node should be same
as the twd DT node. May be one node with reference to
each CPU node should do but am not too sure about the DT
nodes and how all that work.
Regards
Santosh
--
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/1] ARM: dts: OMAP3: Add gpio-twl4030 properties for Overo
On 09/10/2012 03:33 PM, Florian Vaussard wrote:
>>> Support the blue LED connected to the LEDB pin of the TWL4030
>>> on the Gumstix Overo.
>>>
>>> Signed-off-by: Florian Vaussard
>>> ---
>>> arch/arm/boot/dts/omap3-overo.dtsi | 15 +++
>>> 1 files changed, 15 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
>>> b/arch/arm/boot/dts/omap3-overo.dtsi
>>> index d6cc5e2..89808ce 100644
>>> --- a/arch/arm/boot/dts/omap3-overo.dtsi
>>> +++ b/arch/arm/boot/dts/omap3-overo.dtsi
>>> @@ -13,6 +13,17 @@
>>>
>>> /include/ "omap3.dtsi"
>>>
>>> +/ {
>>
>> BTW, I'm just wondering. Cannot we use overo without tobi?
>>
>> In that case, the model and compatible should probably be used as well:
>>
>> model = "TI OMAP3 Gumstix Overo";
>> compatible = "ti,omap3-overo", "ti,omap3";
>
> No, it cannot. The Overo needs to be plugged into an expansion board, at
> least to get the power. Hence the absence of model and compatible in
> omap3-overo.dtsi.
OK, cool. I was wondering because we already have a board-overo.c in the
kernel, and there is no mention of tobi.
OK, I'm adding that patch on top of the other then.
Regards,
Benoit
--
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/1] ARM: dts: OMAP3: Add gpio-twl4030 properties for Overo
On 09/10/2012 03:40 PM, Benoit Cousson wrote:
> On 09/10/2012 03:33 PM, Florian Vaussard wrote:
Support the blue LED connected to the LEDB pin of the TWL4030
on the Gumstix Overo.
Signed-off-by: Florian Vaussard
---
arch/arm/boot/dts/omap3-overo.dtsi | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
b/arch/arm/boot/dts/omap3-overo.dtsi
index d6cc5e2..89808ce 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -13,6 +13,17 @@
/include/ "omap3.dtsi"
+/ {
>>>
>>> BTW, I'm just wondering. Cannot we use overo without tobi?
>>>
>>> In that case, the model and compatible should probably be used as well:
>>>
>>> model = "TI OMAP3 Gumstix Overo";
>>> compatible = "ti,omap3-overo", "ti,omap3";
>>
>> No, it cannot. The Overo needs to be plugged into an expansion board, at
>> least to get the power. Hence the absence of model and compatible in
>> omap3-overo.dtsi.
>
> OK, cool. I was wondering because we already have a board-overo.c in the
> kernel, and there is no mention of tobi.
>
> OK, I'm adding that patch on top of the other then.
I'm just going to update the subject to:
ARM: dts: omap3-overo: Add support for the blue LED
regards,
Benoit
--
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: [balbi-usb:gadget 58/62] drivers/usb/gadget/ether.c:113:1: error: expected ')' before '.' token
On 09/10/2012 03:54 PM, Fengguang Wu wrote: tree: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git gadget head: 7a7322b0a5d984025dd4faea9098b8fef07f8d8f commit: 721e2e91945bc2520d57d795dfe1b502ecec567c [58/62] usb: gadget: libcomposite: move composite.c into libcomposite config: x86_64-randconfig-s284 (attached as .config) All related error/warning messages: In file included from drivers/usb/gadget/ether.c:110:0: drivers/usb/gadget/u_ether.c:87:21: error: expected ')' before 'uint' That is the problem. u_ether.c lacks a "#include ". It built here because I had rndis & EEM which included that file… Thanks for finding this so quickly. Felipe, patch on top or do fix up this commit? Sebastian -- 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/1] ARM: dts: OMAP3: Add gpio-twl4030 properties for Overo
BTW, I'm just wondering. Cannot we use overo without tobi? In that case, the model and compatible should probably be used as well: model = "TI OMAP3 Gumstix Overo"; compatible = "ti,omap3-overo", "ti,omap3"; No, it cannot. The Overo needs to be plugged into an expansion board, at least to get the power. Hence the absence of model and compatible in omap3-overo.dtsi. OK, cool. I was wondering because we already have a board-overo.c in the kernel, and there is no mention of tobi. In board-overo.c, the various features of each expansion board are configured using CONFIG_* options, which is not possible when booting with a device tree. Regards, Florian -- 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: [balbi-usb:gadget 58/62] drivers/usb/gadget/ether.c:113:1: error: expected ')' before '.' token
On Mon, Sep 10, 2012 at 04:06:48PM +0200, Sebastian Andrzej Siewior wrote: > On 09/10/2012 03:54 PM, Fengguang Wu wrote: > >tree: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git gadget > >head: 7a7322b0a5d984025dd4faea9098b8fef07f8d8f > >commit: 721e2e91945bc2520d57d795dfe1b502ecec567c [58/62] usb: gadget: > >libcomposite: move composite.c into libcomposite > >config: x86_64-randconfig-s284 (attached as .config) > > > >All related error/warning messages: > > > >In file included from drivers/usb/gadget/ether.c:110:0: > >drivers/usb/gadget/u_ether.c:87:21: error: expected ')' before 'uint' > > That is the problem. u_ether.c lacks a "#include ". It > built here because I had rndis & EEM which included that file… > > Thanks for finding this so quickly. > > Felipe, patch on top or do fix up this commit? Please... It also built for me as I had make allmodconfig :-s -- balbi signature.asc Description: Digital signature
OMAP SSI driver
Hi Carlos, What's the status of the OMAP SSI driver? Do you plan to send updated patches? Any chance they will land in time for 3.7? -- Sebastian signature.asc Description: Digital signature
Re: [PATCH v5 0/8] ARM: OMAP2+: PM: introduce the power domains functional states
On Thu, 2012-08-16 at 11:20 +0530, Shilimkar, Santosh wrote: > Paul, > > On Thu, Aug 16, 2012 at 6:18 AM, Paul Walmsley wrote: > > > > Hi Santosh, > > > > On Wed, 15 Aug 2012, Shilimkar, Santosh wrote: > > > > > On Wed, Aug 15, 2012 at 3:32 PM, Jean Pihet > > > wrote: > > > > > > I didn't find any mention here about why are we going in this path and > > > not > > > in the direction proposed in another RFC [1] > > > I have already given my comments[2] against the introduction of another > > > PD > > > layer which can be avoided easily as demonstrated by the RFC[1]. The > > > comments > > > are still applicable for this series too. > > > > > > We really need to reduce OMAP specific framework overhead and > > > move towards more generic PM frameworks. For me, this series is > > > a step back-ward from that direction. Am really sorry for being critical > > > again but I remain unconvinced about this series and the problem it > > > is trying to solve. > > > > > > May be you have valid reasons not to follow the approach in [1] and in > > > that case, it will be good to clarify that so that some of us get > > > to know your rationale. > > > > I've asked Jean to handle the work of evaluating and/or integrating any > > feedback from you and Rajendra into this series. Jean, has this latest > > series fully considered those issues? Or are there still some areas of > > misalignment / lack of clarity? > > > Thanks for the information. The main objection to this series was to > not add un-necessary glue layer which still remains. > > From our discussion in past on and off list, your main intention for such > a series was - > > 1. Need a way to support OSWR. > - OSWR by definition is a RET with configurable logic and memory states. > Its a true power state from PD point of view and its not a logical state. > Now since we have agreed to make the OSWR as a static definition > (in all products so far OSWR is used as a static definition with logic > lost, memory retained kind of configuration.) > > - The above requirement can be easily fixed by adding the OSWR > as an additional basic power state as demonstrated in RFC. > > - There is no need to add another glue layer for above. > > 2. Locking so that the low level APIs don't race and henec abstracting the > exported API to 1 or 2 and making rest as private functions. > > -- Even before this series, except low level PM code, only one > common API was used to set the PD low power state. > int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 pwrst) > > -- Once we make OSWR as basic power state, we also avoid usage of > pwrdm_set_logic_retst() API. > > -- We implement lock at this API and export only above API + > may be omap_get_pwrdm_state() kind of API based on need. > > -- This solves the second requirement too. > > Even if we have more requirement, they can be addressed > too without need of another layer. > > If you look at the diffstat alone between two approaches, it is > evident how small piece of code is needed to support above. > Am not too much into the lines of code but basic objection we > have is not to add another glue layer. > > Thinking bit loud, for the logical layer for power domain > we should move towards common device power domain > APIs and if needed add/enhance them to support OMAP. >drivers/base/power/domain.c > May be this though is bit premature but the intetion is > to move towards generic linux framework. > > > Anyway. If there's a problem with this process, it sounds like you, > > Rajendra, Jean, Benoît and I should schedule some time to talk over the > > same issues that you discussed with me on the phone. Perhaps next week? > > > We can surely do a call if needed. But the comments given so far and the > RFC makes things more or less clear the contention point against the > $subject series. What is the latest status with this set? This is kind of blocking the omap4 core retention feature also as I am supposed to put the patches on top of this set. Do we have a consensus which way this set should evolve? Or, should I just base the core retention patches on top of baseline and forget about the functional power states for now? -Tero -- 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] leds: leds-gpio: adopt pinctrl support
On Sun, Sep 9, 2012 at 1:44 AM, Domenico Andreoli wrote: > On Fri, Sep 07, 2012 at 11:57:59PM +0200, Linus Walleij wrote: >> >> If all you need to to is to multiplex the pins into GPIO mode, >> then the gpio_get() call on this driver *can* call through to >> pinctrl_request_gpio() which will in turn fall through to the >> above pinmux driver calls (.gpio_request_enable, etc). > > So if the GPIO driver doesn't coordinate with the pinctrl driver, it's > all left to the GPIO user to configure the pin before using it, right? Yes, more or less, or should I say that certain aspects of pinctrl are orthogonal to GPIO and the two mostly do not know of each other due to a separation of concerns. So the driver may need to tie things up and request its pinctrl and GPIOs independently. > I can understand the concerns of Tony, whether a pin must be requested > or not before the gpio then depends on the GPIO driver implementation, > which may or may not call through the pinctrl layer, isn't it?. Yes that is a sematic limitation, indeed. I think the best way of trying to eliminate that is to bring the two subsystems closer (which is some long-term project) but in the meantime we could propose a documentation fixup to make the semantics clear, what about this: >From a92d754367861cf564c09e0b15746e02f0a96f3f Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Mon, 10 Sep 2012 17:22:00 +0200 Subject: [PATCH] pinctrl: document semantics vs GPIO The semantics of the interactions between GPIO and pinctrl may be unclear, e.g. which one do you request first? This amends the documentation to make this clear. Reported-by: Domenico Andreoli Signed-off-by: Linus Walleij --- Documentation/pinctrl.txt | 24 1 file changed, 24 insertions(+) diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index 1479aca..941e783 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -289,6 +289,29 @@ Interaction with the GPIO subsystem The GPIO drivers may want to perform operations of various types on the same physical pins that are also registered as pin controller pins. +First and foremost, the two subsystems can be used as completely orthogonal, +so say that your driver is fetching its resources like this: + +#include +#include + +struct pinctrl *pinctrl; +int gpio; + +pinctrl = devm_pinctrl_get_select_default(&dev); +gpio = devm_gpio_request(&dev, 14, "foo"); + +Here we first request a certain pin state and then request GPIO 14 to be +used. If you're using the subsystems orthogonally like this, always get +your pinctrl handle and select the desired pinctrl state BEFORE requesting +the GPIO. This is a semantic convention to avoid situations that can be +electrically unpleasant, you may certainly want to mux in and bias pins +a certain way before the GPIO subsystems starts to deal with them. + +But there are also situations where it makes sense for the GPIO subsystem +to communicate with with the pinctrl subsystem, using the latter as a +back-end. + Since the pin controller subsystem have its pinspace local to the pin controller we need a mapping so that the pin control subsystem can figure out which pin controller handles control of a certain GPIO pin. Since a single @@ -359,6 +382,7 @@ will get an pin number into its handled number range. Further it is also passed the range ID value, so that the pin controller knows which range it should deal with. + PINMUX interfaces = -- 1.7.11.3 Yours, Linus Walleij -- 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 V3 1/8] ARM: OMAP3: Add debugss HWMOD data
To enable PMU with runtime PM support on OMAP3 devices we need to be able to
dynamically enable and disable the debug sub-system at runtime. By adding HWMOD
data for the debug sub-system for OMAP3, we can build the PMU device using the
debug sub-system HWMOD and control this power domain using runtime PM.
Reviewed-by: Benoit Cousson
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index c9e3820..78a0c2d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -114,6 +114,24 @@ static struct omap_hwmod omap3xxx_iva_hwmod = {
.main_clk = "iva2_ck",
};
+/*
+ * 'debugss' class
+ * debug and emulation sub system
+ */
+
+static struct omap_hwmod_class omap3xxx_debugss_hwmod_class = {
+ .name = "debugss",
+};
+
+/* debugss */
+static struct omap_hwmod omap3xxx_debugss_hwmod = {
+ .name = "debugss",
+ .class = &omap3xxx_debugss_hwmod_class,
+ .clkdm_name = "emu_clkdm",
+ .main_clk = "emu_src_ck",
+ .flags = HWMOD_NO_IDLEST,
+};
+
/* timer class */
static struct omap_hwmod_class_sysconfig omap3xxx_timer_1ms_sysc = {
.rev_offs = 0x,
@@ -2093,6 +2111,13 @@ static struct omap_hwmod_ocp_if omap3xxx_mpu__l3_main = {
.user = OCP_USER_MPU,
};
+/* l3 -> debugss */
+static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_debugss = {
+ .master = &omap3xxx_l3_main_hwmod,
+ .slave = &omap3xxx_debugss_hwmod,
+ .user = OCP_USER_MPU,
+};
+
/* DSS -> l3 */
static struct omap_hwmod_ocp_if omap3430es1_dss__l3 = {
.master = &omap3430es1_dss_core_hwmod,
@@ -3272,6 +3297,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_hwmod_ocp_ifs[]
__initdata = {
&omap3xxx_l3_main__l4_core,
&omap3xxx_l3_main__l4_per,
&omap3xxx_mpu__l3_main,
+ &omap3xxx_l3_main__l4_debugss,
&omap3xxx_l4_core__l4_wkup,
&omap3xxx_l4_core__mmc3,
&omap3_l4_core__uart1,
--
1.7.9.5
--
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 V3 3/8] ARM: OMAP4: Re-map the CTIs IRQs from MPU to DEBUGSS
In order to use the CTI interrupts inconjunction with the DEBUGSS we need to
re-map the CTI IRQs to the DEBUGSS HWMOD. The purpose for doing this is so we
can create a PMU device based upon the DEBUGSS HWMOD and use the CTI interrupts
for routing ARM PMU events for OMAP4430 devices.
This is based upon Benoit Cousson's patch [1].
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/073319.html
Cc: Ming Lei
Cc: Will Deacon
Cc: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
Reviewed-by: Santosh Shilimkar
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 242aee4..7de8fbe 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -480,10 +480,17 @@ static struct omap_hwmod_class
omap44xx_debugss_hwmod_class = {
};
/* debugss */
+static struct omap_hwmod_irq_info omap44xx_debugss_irqs[] = {
+ { .name = "cti0", .irq = 1 + OMAP44XX_IRQ_GIC_START },
+ { .name = "cti1", .irq = 2 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
static struct omap_hwmod omap44xx_debugss_hwmod = {
.name = "debugss",
.class = &omap44xx_debugss_hwmod_class,
.clkdm_name = "emu_sys_clkdm",
+ .mpu_irqs = omap44xx_debugss_irqs,
.main_clk = "trace_clk_div_ck",
.prcm = {
.omap4 = {
@@ -2450,8 +2457,6 @@ static struct omap_hwmod_class omap44xx_mpu_hwmod_class =
{
/* mpu */
static struct omap_hwmod_irq_info omap44xx_mpu_irqs[] = {
{ .name = "pl310", .irq = 0 + OMAP44XX_IRQ_GIC_START },
- { .name = "cti0", .irq = 1 + OMAP44XX_IRQ_GIC_START },
- { .name = "cti1", .irq = 2 + OMAP44XX_IRQ_GIC_START },
{ .irq = -1 }
};
--
1.7.9.5
--
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 V3 5/8] ARM: OMAP2+: PMU: Add runtime PM support
The original implementation of this patch was done by Ming Lei for PMU on OMAP4 [1]. Since then the PM runtime calls have been moved into the ARM PMU code and this greatly simplifies the changes. The another differnce since the original version, is that it is no longer necessary to call pm_runtime_get/put during the PMU initialisation was we are no longer accessing the hardware at this stage. By adding runtime PM support, we can ensure that the appropriate power and clock domains are kept on while PMU is being used. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074153.html Cc: Ming Lei Cc: Will Deacon Cc: Benoit Cousson Cc: Paul Walmsley Cc: Kevin Hilman Signed-off-by: Jon Hunter --- arch/arm/mach-omap2/pmu.c |9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c index 7c137be..03007b6 100644 --- a/arch/arm/mach-omap2/pmu.c +++ b/arch/arm/mach-omap2/pmu.c @@ -13,6 +13,8 @@ * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. */ +#include + #include #include @@ -54,7 +56,12 @@ static int __init omap2_init_pmu(unsigned oh_num, char *oh_names[]) WARN(IS_ERR(omap_pmu_dev), "Can't build omap_device for %s.\n", dev_name); - return IS_ERR(omap_pmu_dev) ? PTR_ERR(omap_pmu_dev) : 0; + if (IS_ERR(omap_pmu_dev)) + return PTR_ERR(omap_pmu_dev); + + pm_runtime_enable(&omap_pmu_dev->dev); + + return 0; } static int __init omap_init_pmu(void) -- 1.7.9.5 -- 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 V3 0/8] ARM: OMAP4: Add PMU Support
This series adds PMU support for OMAP4 devices. This is based upon Will Deacons series [1] and re-based upon the latest arm-soc next/cleanup branch (3.6-rc3) that includes Will's series. It has been re-based upon this series because of the dependency on Sudeep KarkadaNagesha's change (ARM: pmu: remove arm_pmu_type enumeration) [2] that modifies the OMAP PMU code. This series is also dependent upon some clock fixes for OMAP3 [3] and OMAP4 [4] for PMU to operate correctly on OMAP3 and OMAP4. This series also converts OMAP2/3 devices to use HWMOD to create the PMU device and add a new file to mach-omap2 directory called pmu.c where the PMU devices are created. Testing: - Verified that PMU is working on OMAP2420 H4, OMAP3430 Beagle Board, OMAP4430 Panda and OMAP4460 Panda. - Tested on the above boards with CPU-idle enabled to ensure that PMU is working with power management. For OMAP3430 verified that CORE retention state is entered again after stopping PMU events. V3 changes: - Will Deacon has taken the PMU runtime PM adaption patch in his series and so not included here [1]. - Dropped my fix for managing the EMU power domain on OMAP4 in favour of Paul's implementation [4]. Paul is planning to submit for v3.7. - Added HWMOD data for OMAP3 DEBUG sub-system. The DEBUG sub-system was always being enabled on OMAP3 devices when using PMU and hence, hinding the fact that PMU is dependent upon the DEBUG sub-system on OMAP3 for it to work. [1] git://git.kernel.org/pub/sicm/linux/kernel/git/will/linux.git perf/updates [2] http://www.spinics.net/lists/arm-kernel/msg188726.html [3] http://marc.info/?l=linux-omap&m=134333691309305&w=2 [4] http://marc.info/?l=linux-arm-kernel&m=134383567112518&w=2 Cc: Ming Lei Cc: Will Deacon Cc: Benoit Cousson Cc: Paul Walmsley Cc: Kevin Hilman Jon Hunter (6): ARM: OMAP3: Add debugss HWMOD data ARM: OMAP2+: PMU: Convert OMAP2/3 devices to use HWMOD ARM: OMAP4: Re-map the CTIs IRQs from MPU to DEBUGSS ARM: OMAP2+: PMU: Add runtime PM support ARM: OMAP4: Enable PMU for OMAP4460/70 ARM: OMAP2+: PMU: Add QoS constraint Ming Lei (2): ARM: OMAP4430: Create PMU device via HWMOD ARM: OMAP4: Route PMU IRQs to CTI IRQs arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/devices.c | 32 --- arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |6 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 32 +++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 11 +- arch/arm/mach-omap2/pmu.c | 233 arch/arm/plat-omap/include/plat/irqs.h |1 + arch/arm/plat-omap/include/plat/omap44xx.h |3 + 8 files changed, 285 insertions(+), 34 deletions(-) create mode 100644 arch/arm/mach-omap2/pmu.c -- 1.7.9.5 -- 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 V3 7/8] ARM: OMAP4: Enable PMU for OMAP4460/70
OMAP4460 and OMAP4470 devices have dedicated PMU interrupts and so add these
interrupts to the MPU HWMOD so we can use these for PMU events on these
devices. The PMU interrupts need to be the first interrupts in the array of
interrupts as the ARM PMU driver assumes this.
By using these dedicated interrupts we only need to enable the MPU and DEBUG
sub-systems for PMU to work. This is different to OMAP4430 that did not have
dedicated interrupts and required other power domains in addition to the DEBUG
sub-system to be enabled so we could route the PMU events to the CTI interrupts.
Hence, OMAP4460 and OMAP4470 devices can use the same list of HWMODs to create
the PMU device that is using by OMAP3.
Cc: Ming Lei
Cc: Will Deacon
Cc: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 ++
arch/arm/mach-omap2/pmu.c | 17 -
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 7de8fbe..cdf0e05 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2456,6 +2456,8 @@ static struct omap_hwmod_class omap44xx_mpu_hwmod_class =
{
/* mpu */
static struct omap_hwmod_irq_info omap44xx_mpu_irqs[] = {
+ { .name = "pmu0", .irq = 54 + OMAP44XX_IRQ_GIC_START },
+ { .name = "pmu1", .irq = 55 + OMAP44XX_IRQ_GIC_START },
{ .name = "pl310", .irq = 0 + OMAP44XX_IRQ_GIC_START },
{ .irq = -1 }
};
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index 5918098..7fbaa3f 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -118,7 +118,7 @@ static int __init omap4_init_cti(void)
*
* Uses OMAP HWMOD framework to create and register an ARM PMU device
* from a list of HWMOD names passed. Currently supports OMAP2, OMAP3
- * and OMAP4430 devices.
+ * and OMAP4 devices.
*/
static int __init omap2_init_pmu(unsigned oh_num, char *oh_names[])
{
@@ -163,14 +163,9 @@ static int __init omap_init_pmu(void)
* OMAP24xx:mpu
* OMAP3xxx:mpu, debugss
* OMAP4430:l3_main_3, l3_instr, debugss
+* OMAP4460/70: mpu, debugss
*/
- if (cpu_is_omap24xx()) {
- oh_num = ARRAY_SIZE(omap2_pmu_oh_names);
- oh_names = omap2_pmu_oh_names;
- } else if (cpu_is_omap34xx()) {
- oh_num = ARRAY_SIZE(omap3_pmu_oh_names);
- oh_names = omap3_pmu_oh_names;
- } else if (cpu_is_omap443x()) {
+ if (cpu_is_omap443x()) {
r = omap4_init_cti();
if (r)
return r;
@@ -180,8 +175,12 @@ static int __init omap_init_pmu(void)
omap_pmu_data.runtime_suspend = omap4_pmu_runtime_suspend;
oh_num = ARRAY_SIZE(omap4430_pmu_oh_names);
oh_names = omap4430_pmu_oh_names;
+ } else if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
+ oh_num = ARRAY_SIZE(omap3_pmu_oh_names);
+ oh_names = omap3_pmu_oh_names;
} else {
- return 0;
+ oh_num = ARRAY_SIZE(omap2_pmu_oh_names);
+ oh_names = omap2_pmu_oh_names;
}
return omap2_init_pmu(oh_num, oh_names);
--
1.7.9.5
--
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 V3 4/8] ARM: OMAP4430: Create PMU device via HWMOD
From: Ming Lei
For OMAP4430 PMU events are routed to the CPU via the cross trigger interface
(CTI) because there are no dedicated interrupts. In order to route the PMU
events via the CTI IRQs, the following modules must be enabled:
l3_instr, l3_main_3, debugss
Therefore, build the arm-pmu device via these three HWMODs.
Cc: Ming Lei
Cc: Will Deacon
Cc: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
Signed-off-by: Ming Lei
Signed-off-by: Will Deacon
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/pmu.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index 1de52ed..7c137be 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -20,6 +20,7 @@
static char *omap2_pmu_oh_names[] = {"mpu"};
static char *omap3_pmu_oh_names[] = {"mpu", "debugss"};
+static char *omap4430_pmu_oh_names[] = {"l3_main_3", "l3_instr", "debugss"};
static struct platform_device *omap_pmu_dev;
/**
@@ -28,16 +29,16 @@ static struct platform_device *omap_pmu_dev;
* @oh_names: Array of OMAP HWMODS names required to create PMU device
*
* Uses OMAP HWMOD framework to create and register an ARM PMU device
- * from a list of HWMOD names passed. Currently supports OMAP2 and
- * OMAP3 devices.
+ * from a list of HWMOD names passed. Currently supports OMAP2, OMAP3
+ * and OMAP4430 devices.
*/
static int __init omap2_init_pmu(unsigned oh_num, char *oh_names[])
{
int i;
- struct omap_hwmod *oh[2];
+ struct omap_hwmod *oh[3];
char *dev_name = "arm-pmu";
- if ((!oh_num) || (oh_num > 2))
+ if ((!oh_num) || (oh_num > 3))
return -EINVAL;
for (i = 0; i < oh_num; i++) {
@@ -67,6 +68,7 @@ static int __init omap_init_pmu(void)
*
* OMAP24xx:mpu
* OMAP3xxx:mpu, debugss
+* OMAP4430:l3_main_3, l3_instr, debugss
*/
if (cpu_is_omap24xx()) {
oh_num = ARRAY_SIZE(omap2_pmu_oh_names);
@@ -74,6 +76,9 @@ static int __init omap_init_pmu(void)
} else if (cpu_is_omap34xx()) {
oh_num = ARRAY_SIZE(omap3_pmu_oh_names);
oh_names = omap3_pmu_oh_names;
+ } else if (cpu_is_omap443x()) {
+ oh_num = ARRAY_SIZE(omap4430_pmu_oh_names);
+ oh_names = omap4430_pmu_oh_names;
} else {
return 0;
}
--
1.7.9.5
--
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 V3 2/8] ARM: OMAP2+: PMU: Convert OMAP2/3 devices to use HWMOD
Convert OMAP2/3 devices to use HWMOD for creating a PMU device. To support PMU
on OMAP2 devices we only need to use MPU sub-system and so we can simply use
the MPU HWMOD to create the PMU device. To support PMU on OMAP3 devices, we need
to use the MPU and DEBUG sub-systems and so use these HWMODs to create the PMU
device for OMAP3.
The MPU HWMOD for OMAP2/3 devices is currently missing the PMU interrupt and so
add the PMU interrupt to the MPU HWMOD for these devices.
This change also moves the PMU code out of the mach-omap2/devices.c files into
its own pmu.c file as suggested by Kevin Hilman to de-clutter devices.c.
Cc: Ming Lei
Cc: Will Deacon
Cc: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/devices.c | 32
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |6 ++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |6 ++
arch/arm/mach-omap2/pmu.c | 83
arch/arm/plat-omap/include/plat/irqs.h |1 +
6 files changed, 97 insertions(+), 32 deletions(-)
create mode 100644 arch/arm/mach-omap2/pmu.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index f6a24b3..9d533b7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -198,6 +198,7 @@ obj-$(CONFIG_ARCH_OMAP4)+=
omap_hwmod_44xx_data.o
# EMU peripherals
obj-$(CONFIG_OMAP3_EMU)+= emu.o
+obj-$(CONFIG_HW_PERF_EVENTS) += pmu.o
# L3 interconnect
obj-$(CONFIG_ARCH_OMAP3) += omap_l3_smx.o
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 02b9478..2659c7b 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -433,37 +433,6 @@ static void omap_init_mcspi(void)
static inline void omap_init_mcspi(void) {}
#endif
-static struct resource omap2_pmu_resource = {
- .start = 3,
- .end= 3,
- .flags = IORESOURCE_IRQ,
-};
-
-static struct resource omap3_pmu_resource = {
- .start = INT_34XX_BENCH_MPU_EMUL,
- .end= INT_34XX_BENCH_MPU_EMUL,
- .flags = IORESOURCE_IRQ,
-};
-
-static struct platform_device omap_pmu_device = {
- .name = "arm-pmu",
- .id = -1,
- .num_resources = 1,
-};
-
-static void omap_init_pmu(void)
-{
- if (cpu_is_omap24xx())
- omap_pmu_device.resource = &omap2_pmu_resource;
- else if (cpu_is_omap34xx())
- omap_pmu_device.resource = &omap3_pmu_resource;
- else
- return;
-
- platform_device_register(&omap_pmu_device);
-}
-
-
#if defined(CONFIG_CRYPTO_DEV_OMAP_SHAM) ||
defined(CONFIG_CRYPTO_DEV_OMAP_SHAM_MODULE)
#ifdef CONFIG_ARCH_OMAP2
@@ -644,7 +613,6 @@ static int __init omap2_init_devices(void)
omap_init_mcpdm();
omap_init_mcspi();
}
- omap_init_pmu();
omap_init_sti();
omap_init_sham();
omap_init_aes();
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index afad69c..411e2df 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -200,8 +200,14 @@ struct omap_hwmod omap2xxx_l4_wkup_hwmod = {
};
/* MPU */
+static struct omap_hwmod_irq_info omap2xxx_mpu_irqs[] = {
+ { .name = "pmu", .irq = INT_24XX_BENCH_MPU_EMUL },
+ { .irq = -1 }
+};
+
struct omap_hwmod omap2xxx_mpu_hwmod = {
.name = "mpu",
+ .mpu_irqs = omap2xxx_mpu_irqs,
.class = &mpu_hwmod_class,
.main_clk = "mpu_ck",
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 78a0c2d..4a5b8ab 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -92,8 +92,14 @@ static struct omap_hwmod omap3xxx_l4_sec_hwmod = {
};
/* MPU */
+static struct omap_hwmod_irq_info omap3xxx_mpu_irqs[] = {
+ { .name = "pmu", .irq = INT_34XX_BENCH_MPU_EMUL },
+ { .irq = -1 }
+};
+
static struct omap_hwmod omap3xxx_mpu_hwmod = {
.name = "mpu",
+ .mpu_irqs = omap3xxx_mpu_irqs,
.class = &mpu_hwmod_class,
.main_clk = "arm_fck",
};
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
new file mode 100644
index 000..1de52ed
--- /dev/null
+++ b/arch/arm/mach-omap2/pmu.c
@@ -0,0 +1,83 @@
+/*
+ * linux/arch/arm/mach-omap2/pmu.c
+ *
+ * OMAP2 ARM Performance Monitoring Unit (PMU) Support
+ *
+ * Copyright (C) 2012 Texas Instruments, Inc.
+ *
+ * Contacts:
+ * Jon Hunter
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as
[PATCH V3 6/8] ARM: OMAP4: Route PMU IRQs to CTI IRQs
From: Ming Lei
For OMAP4430 there are no dedicate PMU interrupts, however, PMU events can be
routed to via the CTI IRQs. This allows tools such as PERF and OPROFILE to work
on OMAP4430.
The idea is from Woodruff Richard in the disscussion about "Oprofile on
Pandaboard / Omap4" on pandabo...@googlegroups.com.
Ming's original patch was called "arm: omap4: support pmu" [1] and has been
renamed and modified by Jon Hunter. There main differences from the original
patch are ...
1. Instead of only configuring the CTI interrupt once during boot, the
interrupts are configured everytime the the PMU is used. The reason for this
is because during power transitions the CTI logic state will be lost and so
we will need to configure the interrupts everytime they are used. This is
accomplished by using the PM runtime callbacks which will be called whenever
the PMU is used.
2. Assign the PMU events to different cross triggering channels. This prevents
a single PMU event generating interrupts to both CPUs and hence can cause
spurious interrupts to occur. Reported by Ming [2].
[1] http://marc.info/?l=linux-arm-kernel&m=132227620816504&w=2
[2] http://permalink.gmane.org/gmane.linux.linaro.devel/10532
Acked-by: Jean Pihet
Acked-by: Tony Lindgren
Acked-by: Santosh Shilimkar
Cc: Woodruff Richard
Cc: Ming Lei
Cc: Will Deacon
Cc: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
Signed-off-by: Ming Lei
Signed-off-by: Will Deacon
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/pmu.c | 98 +++-
arch/arm/plat-omap/include/plat/omap44xx.h |3 +
2 files changed, 99 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index 03007b6..5918098 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -16,6 +16,7 @@
#include
#include
+#include
#include
#include
@@ -24,6 +25,91 @@ static char *omap2_pmu_oh_names[] = {"mpu"};
static char *omap3_pmu_oh_names[] = {"mpu", "debugss"};
static char *omap4430_pmu_oh_names[] = {"l3_main_3", "l3_instr", "debugss"};
static struct platform_device *omap_pmu_dev;
+static struct arm_pmu_platdata omap_pmu_data;
+static struct cti omap4_cti[2];
+
+/**
+ * omap4_pmu_runtime_resume - PMU runtime resume callback
+ * @devOMAP PMU device
+ *
+ * Platform specific PMU runtime resume callback for OMAP4430 devices to
+ * configure the cross trigger interface for routing PMU interrupts. This
+ * is called by the PM runtime framework.
+ */
+static int omap4_pmu_runtime_resume(struct device *dev)
+{
+ /* configure CTI0 for PMU IRQ routing */
+ cti_unlock(&omap4_cti[0]);
+ cti_map_trigger(&omap4_cti[0], 1, 6, 2);
+ cti_enable(&omap4_cti[0]);
+
+ /* configure CTI1 for PMU IRQ routing */
+ cti_unlock(&omap4_cti[1]);
+ cti_map_trigger(&omap4_cti[1], 1, 6, 3);
+ cti_enable(&omap4_cti[1]);
+
+ return 0;
+}
+
+/**
+ * omap4_pmu_runtime_suspend - PMU runtime suspend callback
+ * @devOMAP PMU device
+ *
+ * Platform specific PMU runtime suspend callback for OMAP4430 devices to
+ * disable the cross trigger interface interrupts. This is called by the
+ * PM runtime framework.
+ */
+static int omap4_pmu_runtime_suspend(struct device *dev)
+{
+ cti_disable(&omap4_cti[0]);
+ cti_disable(&omap4_cti[1]);
+
+ return 0;
+}
+
+/**
+ * omap4_pmu_handle_irq - PMU IRQ Handler
+ * @irqOMAP CTI IRQ number
+ * @devOMAP PMU device
+ * @handlerARM PMU interrupt handler
+ *
+ * Platform specific PMU IRQ handler for OMAP4430 devices that route PMU
+ * interrupts via cross trigger interface. This is called by the PMU driver.
+ */
+static irqreturn_t
+omap4_pmu_handle_irq(int irq, void *dev, irq_handler_t handler)
+{
+ if (irq == OMAP44XX_IRQ_CTI0)
+ cti_irq_ack(&omap4_cti[0]);
+ else if (irq == OMAP44XX_IRQ_CTI1)
+ cti_irq_ack(&omap4_cti[1]);
+
+ return handler(irq, dev);
+}
+
+/**
+ * omap4_init_cti - initialise cross trigger interface instances
+ *
+ * Initialises two cross trigger interface (CTI) instances in preparation
+ * for routing PMU interrupts to the OMAP interrupt controller. Note that
+ * this does not configure the actual CTI hardware but just the CTI
+ * software structures to be used.
+ */
+static int __init omap4_init_cti(void)
+{
+ omap4_cti[0].base = ioremap(OMAP44XX_CTI0_BASE, SZ_4K);
+ omap4_cti[1].base = ioremap(OMAP44XX_CTI1_BASE, SZ_4K);
+
+ if (!omap4_cti[0].base || !omap4_cti[1].base) {
+ pr_err("ioremap for OMAP4 CTI failed\n");
+ return -ENOMEM;
+ }
+
+ cti_init(&omap4_cti[0], omap4_cti[0].base, OMAP44XX_IRQ_CTI0, 6);
+ cti_init(&omap4_cti[1], omap4_cti[1].base, OMAP44XX_IRQ_CTI1, 6);
+
+ return 0;
+}
/**
* omap2_init_pmu - creates and registers PMU platform device
@@ -51,8 +137,8 @@ static int __init
[PATCH V3 8/8] ARM: OMAP2+: PMU: Add QoS constraint
When CPU-idle is enabled, the MPU sub-system will transition to low power
states during idle periods. If the PMU is active and the MPU sub-system
transitions to a low power state, such as retention, then the PMU context
will be lost and PMU events will stop. To prevent this from happening add a
QoS constraint whenever PMU is active to prevent the MPU sub-system from
transitioning to a low power state.
By default the PMU QoS constraint is set to -1 so it will not prevent any low
power states and when the PMU is enabled, it is set to 0, so that only C-state
C0 is allowed. I plan to re-visit this and relax the constraint to allow some
low power states, but for now I just wish to ensure PMU is working.
Cc: Ming Lei
Cc: Will Deacon
Cc: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/pmu.c | 49 +++--
1 file changed, 47 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index 7fbaa3f..ca158f0 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -13,6 +13,7 @@
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*/
+#include
#include
#include
@@ -24,11 +25,41 @@
static char *omap2_pmu_oh_names[] = {"mpu"};
static char *omap3_pmu_oh_names[] = {"mpu", "debugss"};
static char *omap4430_pmu_oh_names[] = {"l3_main_3", "l3_instr", "debugss"};
+static struct pm_qos_request pmu_pm_qos_request;
static struct platform_device *omap_pmu_dev;
-static struct arm_pmu_platdata omap_pmu_data;
static struct cti omap4_cti[2];
/**
+ * omap_pmu_runtime_resume - PMU runtime resume callback
+ * @devOMAP PMU device
+ *
+ * Platform specific PMU runtime resume callback for OMAP devices to
+ * configure the cross trigger interface for routing PMU interrupts.
+ * This is called by the PM runtime framework.
+ */
+static int omap_pmu_runtime_resume(struct device *dev)
+{
+ pm_qos_update_request(&pmu_pm_qos_request, 0);
+
+ return 0;
+}
+
+/**
+ * omap_pmu_runtime_suspend - PMU runtime suspend callback
+ * @devOMAP PMU device
+ *
+ * Platform specific PMU runtime suspend callback for OMAP devices to
+ * disable the cross trigger interface interrupts. This is called by
+ * the PM runtime framework.
+ */
+static int omap_pmu_runtime_suspend(struct device *dev)
+{
+ pm_qos_update_request(&pmu_pm_qos_request, PM_QOS_DEFAULT_VALUE);
+
+ return 0;
+}
+
+/**
* omap4_pmu_runtime_resume - PMU runtime resume callback
* @devOMAP PMU device
*
@@ -38,6 +69,8 @@ static struct cti omap4_cti[2];
*/
static int omap4_pmu_runtime_resume(struct device *dev)
{
+ pm_qos_update_request(&pmu_pm_qos_request, 0);
+
/* configure CTI0 for PMU IRQ routing */
cti_unlock(&omap4_cti[0]);
cti_map_trigger(&omap4_cti[0], 1, 6, 2);
@@ -64,6 +97,8 @@ static int omap4_pmu_runtime_suspend(struct device *dev)
cti_disable(&omap4_cti[0]);
cti_disable(&omap4_cti[1]);
+ pm_qos_update_request(&pmu_pm_qos_request, PM_QOS_DEFAULT_VALUE);
+
return 0;
}
@@ -111,6 +146,11 @@ static int __init omap4_init_cti(void)
return 0;
}
+static struct arm_pmu_platdata omap_pmu_data = {
+ .runtime_resume = omap_pmu_runtime_resume,
+ .runtime_suspend = omap_pmu_runtime_suspend,
+};
+
/**
* omap2_init_pmu - creates and registers PMU platform device
* @oh_num:Number of OMAP HWMODs required to create PMU device
@@ -183,6 +223,11 @@ static int __init omap_init_pmu(void)
oh_names = omap2_pmu_oh_names;
}
- return omap2_init_pmu(oh_num, oh_names);
+ r = omap2_init_pmu(oh_num, oh_names);
+ if (!r)
+ pm_qos_add_request(&pmu_pm_qos_request, PM_QOS_CPU_DMA_LATENCY,
+ PM_QOS_DEFAULT_VALUE);
+
+ return r;
}
subsys_initcall(omap_init_pmu);
--
1.7.9.5
--
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
[GIT PULL] OMAP devicetree for 3.7
Hi Tony, Please pull the following branch. It contains a bunch of devicetree related series. It contains as well a gpio-twl4030 patch acked by Linus W. It is tested on omap4-panda, omap3-beagle, omap3-overo-tobi, am335x-bone, am335x-evm. It is based on your current devel-dt branch (a06ceff6f29e34edff5d6b082885c1c4139a0362). Thanks, Benoit --- The following changes since commit a06ceff6f29e34edff5d6b082885c1c4139a0362: AnilKumar Ch (1): arm/dts: Add tps65217 regulator DT data to am335x-bone.dts are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.7/dts Aneesh V (3): Documentation: dt: device tree bindings for LPDDR2 memories Documentation: dt: emif: device tree bindings for TI's EMIF sdram controller ARM: dts: EMIF and LPDDR2 device tree data for OMAP4 boards Benoit Cousson (3): ARM: dts: OMAP4: Cleanup and move GIC outside of the OCP ARM: dts: omap3-beagle: Add heartbeat and mmc LEDs support ARM: dts: OMAP4: Add reg and interrupts for every nodes Florian Vaussard (5): gpio/twl4030: get platform data from device tree ARM: dts: omap3: Add gpio-twl4030 properties for BeagleBoard and omap3-EVM ARM: dts: OMAP3: Add support for Gumstix Overo with Tobi expansion board Documentation: dt: Update the OMAP documentation with Overo/Toby ARM: dts: omap3-overo: Add support for the blue LED Peter Ujfalusi (9): ARM: OMAP: omap_device: Fix up resource names when booted with devicetree ARM: dts: omap2: Add McBSP entries for OMAP2420 and OMAP2430 SoC ARM: dts: omap2420-h4: Include omap2420.dtsi file instead the common omap2 ARM: dts: omap3: Add McBSP entries ARM: dts: omap4: Add McBSP entries ARM: dts: omap4: Add reg-names for McPDM and DMIC ARM: dts: omap5: Add McBSP entries ARM: dts: omap5: Add McPDM and DMIC section to the dtsi file ARM: dts: omap3-beagle: Enable audio support Santosh Shilimkar (2): ARM: OMAP4: Add L2 Cache Controller in Device Tree ARM: OMAP4: Add local timer support for Device Tree Sourav Poddar (6): ARM: dts: omap5-evm: Add I2C support ARM: dts: omap5-evm: Add tmp102 sensor support ARM: dts: omap5-evm: Add keypad data ARM: dts: omap5-evm: Add bmp085 sensor support ARM: dts: omap4-sdp: Add keypad data Documentation: dt: i2c: trivial-devices: Update for tmp102 Vaibhav Hiremath (3): ARM: OMAP: omap_device: Do not overwrite resources allocated by OF layer ARM: dts: AM33XX: Convert all hex numbers to lower-case ARM: dts: AM33XX: Specify reg and interrupt property for all nodes .../devicetree/bindings/arm/omap/omap.txt |3 + .../devicetree/bindings/gpio/gpio-twl4030.txt |6 + .../devicetree/bindings/i2c/trivial-devices.txt|1 + .../devicetree/bindings/lpddr2/lpddr2-timings.txt | 52 ++ .../devicetree/bindings/lpddr2/lpddr2.txt | 102 +++ .../bindings/memory-controllers/ti/emif.txt| 55 ++ arch/arm/boot/dts/am335x-bone.dts |4 +- arch/arm/boot/dts/am335x-evm.dts |8 +- arch/arm/boot/dts/am33xx.dtsi | 62 ++- arch/arm/boot/dts/elpida_ecb240abacn.dtsi | 67 +++ arch/arm/boot/dts/omap2420-h4.dts |2 +- arch/arm/boot/dts/omap2420.dtsi| 39 arch/arm/boot/dts/omap2430.dtsi| 83 + arch/arm/boot/dts/omap3-beagle.dts | 46 + arch/arm/boot/dts/omap3-evm.dts| 13 ++ arch/arm/boot/dts/omap3-overo.dtsi | 57 ++ arch/arm/boot/dts/omap3-tobi.dts | 35 arch/arm/boot/dts/omap3.dtsi | 69 arch/arm/boot/dts/omap4-panda.dts | 11 ++ arch/arm/boot/dts/omap4-sdp.dts| 81 + arch/arm/boot/dts/omap4.dtsi | 182 arch/arm/boot/dts/omap5-evm.dts| 33 arch/arm/boot/dts/omap5.dtsi | 96 ++ arch/arm/mach-omap2/Makefile.boot |2 +- arch/arm/mach-omap2/omap4-common.c |6 +- arch/arm/mach-omap2/omap_hwmod.c | 27 +++ arch/arm/mach-omap2/timer.c|6 + arch/arm/plat-omap/include/plat/omap_hwmod.h |1 + arch/arm/plat-omap/omap_device.c | 79 +++-- drivers/gpio/gpio-twl4030.c| 82 ++--- 30 files changed, 1220 insertions(+), 90 deletions(-) create mode 100644 Documentation/devicetree/bindings/lpddr2/lpddr2-timings.txt create mode 100644 Documentation/devicetree/bindings/lpddr2/lpddr2.txt create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti/emif.txt create mode 100644 arch/arm/boot/dts/elpida_e
[PATCH] watchdog: Convert twl4030_wdt to watchdog core
Convert the twl4030_wdt watchdog driver to watchdog core.
While at there use devm_kzalloc and set the default timeout in order to be
able test this driver with a simple shell script.
Signed-off-by: Jarkko Nikula
---
drivers/watchdog/Kconfig |1 +
drivers/watchdog/twl4030_wdt.c | 183
2 files changed, 35 insertions(+), 149 deletions(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 53d7571..21f6205 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -232,6 +232,7 @@ config EP93XX_WATCHDOG
config OMAP_WATCHDOG
tristate "OMAP Watchdog"
depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS
+ select WATCHDOG_CORE
help
Support for TI OMAP1610/OMAP1710/OMAP2420/OMAP3430/OMAP4430 watchdog.
Say 'Y'
here to enable the OMAP1610/OMAP1710/OMAP2420/OMAP3430/OMAP4430
watchdog timer.
diff --git a/drivers/watchdog/twl4030_wdt.c b/drivers/watchdog/twl4030_wdt.c
index 249f113..71c283a 100644
--- a/drivers/watchdog/twl4030_wdt.c
+++ b/drivers/watchdog/twl4030_wdt.c
@@ -22,26 +22,12 @@
#include
#include
#include
-#include
#include
#include
-#include
-#include
#include
#define TWL4030_WATCHDOG_CFG_REG_OFFS 0x3
-#define TWL4030_WDT_STATE_OPEN 0x1
-#define TWL4030_WDT_STATE_ACTIVE 0x8
-
-static struct platform_device *twl4030_wdt_dev;
-
-struct twl4030_wdt {
- struct miscdevice miscdev;
- int timer_margin;
- unsigned long state;
-};
-
static bool nowayout = WATCHDOG_NOWAYOUT;
module_param(nowayout, bool, 0);
MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started "
@@ -53,171 +39,71 @@ static int twl4030_wdt_write(unsigned char val)
TWL4030_WATCHDOG_CFG_REG_OFFS);
}
-static int twl4030_wdt_enable(struct twl4030_wdt *wdt)
+static int twl4030_wdt_start(struct watchdog_device *wdt)
{
- return twl4030_wdt_write(wdt->timer_margin + 1);
+ return twl4030_wdt_write(wdt->timeout + 1);
}
-static int twl4030_wdt_disable(struct twl4030_wdt *wdt)
+static int twl4030_wdt_stop(struct watchdog_device *wdt)
{
return twl4030_wdt_write(0);
}
-static int twl4030_wdt_set_timeout(struct twl4030_wdt *wdt, int timeout)
-{
- if (timeout < 0 || timeout > 30) {
- dev_warn(wdt->miscdev.parent,
- "Timeout can only be in the range [0-30] seconds");
- return -EINVAL;
- }
- wdt->timer_margin = timeout;
- return twl4030_wdt_enable(wdt);
-}
-
-static ssize_t twl4030_wdt_write_fop(struct file *file,
- const char __user *data, size_t len, loff_t *ppos)
+static int twl4030_wdt_set_timeout(struct watchdog_device *wdt,
+ unsigned int timeout)
{
- struct twl4030_wdt *wdt = file->private_data;
-
- if (len)
- twl4030_wdt_enable(wdt);
-
- return len;
-}
-
-static long twl4030_wdt_ioctl(struct file *file,
- unsigned int cmd, unsigned long arg)
-{
- void __user *argp = (void __user *)arg;
- int __user *p = argp;
- int new_margin;
- struct twl4030_wdt *wdt = file->private_data;
-
- static const struct watchdog_info twl4030_wd_ident = {
- .identity = "TWL4030 Watchdog",
- .options = WDIOF_SETTIMEOUT,
- .firmware_version = 0,
- };
-
- switch (cmd) {
- case WDIOC_GETSUPPORT:
- return copy_to_user(argp, &twl4030_wd_ident,
- sizeof(twl4030_wd_ident)) ? -EFAULT : 0;
-
- case WDIOC_GETSTATUS:
- case WDIOC_GETBOOTSTATUS:
- return put_user(0, p);
-
- case WDIOC_KEEPALIVE:
- twl4030_wdt_enable(wdt);
- break;
-
- case WDIOC_SETTIMEOUT:
- if (get_user(new_margin, p))
- return -EFAULT;
- if (twl4030_wdt_set_timeout(wdt, new_margin))
- return -EINVAL;
- return put_user(wdt->timer_margin, p);
-
- case WDIOC_GETTIMEOUT:
- return put_user(wdt->timer_margin, p);
-
- default:
- return -ENOTTY;
- }
-
+ wdt->timeout = timeout;
return 0;
}
-static int twl4030_wdt_open(struct inode *inode, struct file *file)
-{
- struct twl4030_wdt *wdt = platform_get_drvdata(twl4030_wdt_dev);
-
- /* /dev/watchdog can only be opened once */
- if (test_and_set_bit(0, &wdt->state))
- return -EBUSY;
-
- wdt->state |= TWL4030_WDT_STATE_ACTIVE;
- file->private_data = (void *) wdt;
-
- twl4030_wdt_enable(wdt);
- return nonseekable_open(inode, file);
-}
-
-static int twl4030_wdt_release(struct inode *inode, struct file *file)
-{
- struct twl4030_wdt *wdt = file->private_data;
- if (nowayout) {
- dev_alert(wdt->miscdev.pa
Re: [PATCH v3 1/8] ARM/dts: omap2: Add McBSP entries for OMAP2420 and OMAP2430 SoC
* Peter Ujfalusi [120910 04:05]:
> Hi Benoit,
>
> On 09/10/2012 11:07 AM, Benoit Cousson wrote:
> > Hi Tony,
> >
> > On 09/08/2012 12:29 AM, Tony Lindgren wrote:
> >> * Peter Ujfalusi [120905 04:59]:
> >>> +
> >>> + ocp {
> >>> + mcbsp1: mcbsp@48074000 {
> >>> + compatible = "ti,omap2420-mcbsp";
> >>> + reg = <0x48074000 0xff>;
> >>> + reg-names = "mpu";
> >>> + interrupts = <59>, /* TX interrupt */
> >>> + <60>; /* RX interrupt */
> >>> + interrupt-names = "tx", "rx";
> >>> + interrupt-parent = <&intc>;
> >>> + ti,hwmods = "mcbsp1";
> >>> + };
> >>> +
> >>> + mcbsp2: mcbsp@48076000 {
> >>> + compatible = "ti,omap2420-mcbsp";
> >>> + reg = <0x48076000 0xff>;
> >>> + reg-names = "mpu";
> >>> + interrupts = <62>, /* TX interrupt */
> >>> + <63>; /* RX interrupt */
> >>> + interrupt-names = "tx", "rx";
> >>> + interrupt-parent = <&intc>;
> >>> + ti,hwmods = "mcbsp2";
> >>> + };
> >>> + };
> >>
> >> Hmm don't you need to specify the interrupt chip and offset for
> >> the interrupts here?
> >
> > Mmm, I'm not sure to get your question, there is the link to the
> > interrupt-parent.
> >
> > The interrupt number is relative to the parent interrupt domain. So even
> > if the INTC IRQ offset start at 32 instead of 0, DT IRQ mechanism will
> > convert that to the proper hwirq thanks to irqdomain.
> > In that case we should always provide interrupt number relative to the
> > interrupt controller HW number and not assuming any Linux IRQ number
> > offset like before.
Yes never mind, I was confused. We have #interrupt-cells = <1> and the
interrupt specifier is just the interrupt offset..
Regards,
Tony
> > And in fact the interrupt-parent is not even needed, by default if will
> > look to the parent to get the interrupt-controller.
>
> This is true, but it makes the 'code' a bit more readable if I (we) specify
> the interrupt-parent.
>
> >
> > Extract from [1]
> >
> > interrupt-parent:
> > "Because the hierarchy of the nodes in the interrupt tree might not
> > match the device tree, the interrupt-parent property is available to
> > make the definition of an interrupt parent explicit.
> > The value is the phandle to the interrupt parent. If this property is
> > missing from a device, its interrupt parent is assumed to be its device
> > tree parent."
> >
> > [1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf
> >
> > Regards,
> > Benoit
> >
>
>
> --
> Péter
--
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/3] arm: omap: hwmod: add a new addr space in otg for writing to control module
Hi,
On Thu, Sep 06, 2012 at 12:56:07PM -0700, Tony Lindgren wrote:
> * Felipe Balbi [120906 10:23]:
> > Hi,
> >
> > On Thu, Sep 06, 2012 at 08:13:03PM +0300, Felipe Balbi wrote:
> > > Hi,
> > >
> > > On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath wrote:
> > > >
> > > >
> > > > On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
> > > > > The mailbox register for usb otg in omap is present in control module.
> > > > > On detection of any events VBUS or ID, this register should be written
> > > > > to send the notification to musb core.
> > > > >
> > > > > Till we have a separate control module driver to write to control
> > > > > module,
> > > > > omap2430 will handle the register writes to control module by itself.
> > > > > So
> > > > > a new address space to represent this control module register is added
> > > > > to usb_otg_hs.
> > > > >
> > > > > Cc: Benoit Cousson
> > > > > Signed-off-by: Kishon Vijay Abraham I
> > > > > ---
> > > > > arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
> > > > > 1 file changed, 5 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > > > b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > > > index 242aee4..02341bc 100644
> > > > > --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > > > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > > > @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space
> > > > > omap44xx_usb_otg_hs_addrs[] = {
> > > > > .pa_end = 0x4a0ab003,
> > > > > .flags = ADDR_TYPE_RT
> > > > > },
> > > > > + {
> > > > > + .pa_start = 0x4a00233c,
> > > > > + .pa_end = 0x4a00233f,
> > > > > + .flags = ADDR_TYPE_RT
> > > > > + },
> > > >
> > > > I do not have any objection/comment here, but I believe this is control
> > > > module address space required for USB module, right?
> > > > I am not sure this is right way of accessing control module space.
> > > > Actually Control Module Access required for drivers is one of the
> > > > blocking issue we have currently.
> > > >
> > > > Also there was some effort put up by 'Konstantine' to convert Control
> > > > module to MFD driver, I haven't seen any further update on it. But it
> > > > would be good to check with him.
> > >
> > > this was an agreement with Benoit since we already lost a couple merge
> > > windows for this patchset. We agreed to wait until -rc4 for SCM driver
> > > and if it wasn't ready, we'd go ahead with this and SCM author would fix
> > > it up on a patch converting users to new SCM driver.
> >
> > Tony, can I get your Acked-by to this patch so I can take it together
> > with the rest of the series ? Thanks
> >
> > ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
> > to merge it into your tree once I apply.
>
> It would be best if this got acked by Benoit and Paul as they may
> have some other patches queued up. I'll ack if they ack ;)
Benoit, care to ack this patch ???
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module
Hi Felipe,
On 09/10/2012 05:58 PM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Sep 06, 2012 at 12:56:07PM -0700, Tony Lindgren wrote:
>> * Felipe Balbi [120906 10:23]:
>>> Hi,
>>>
>>> On Thu, Sep 06, 2012 at 08:13:03PM +0300, Felipe Balbi wrote:
Hi,
On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath wrote:
>
>
> On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
>> The mailbox register for usb otg in omap is present in control module.
>> On detection of any events VBUS or ID, this register should be written
>> to send the notification to musb core.
>>
>> Till we have a separate control module driver to write to control module,
>> omap2430 will handle the register writes to control module by itself. So
>> a new address space to represent this control module register is added
>> to usb_otg_hs.
>>
>> Cc: Benoit Cousson
>> Signed-off-by: Kishon Vijay Abraham I
>> ---
>> arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> index 242aee4..02341bc 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space
>> omap44xx_usb_otg_hs_addrs[] = {
>> .pa_end = 0x4a0ab003,
>> .flags = ADDR_TYPE_RT
>> },
>> +{
>> +.pa_start = 0x4a00233c,
>> +.pa_end = 0x4a00233f,
>> +.flags = ADDR_TYPE_RT
>> +},
>
> I do not have any objection/comment here, but I believe this is control
> module address space required for USB module, right?
> I am not sure this is right way of accessing control module space.
> Actually Control Module Access required for drivers is one of the
> blocking issue we have currently.
>
> Also there was some effort put up by 'Konstantine' to convert Control
> module to MFD driver, I haven't seen any further update on it. But it
> would be good to check with him.
this was an agreement with Benoit since we already lost a couple merge
windows for this patchset. We agreed to wait until -rc4 for SCM driver
and if it wasn't ready, we'd go ahead with this and SCM author would fix
it up on a patch converting users to new SCM driver.
>>>
>>> Tony, can I get your Acked-by to this patch so I can take it together
>>> with the rest of the series ? Thanks
>>>
>>> ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
>>> to merge it into your tree once I apply.
>>
>> It would be best if this got acked by Benoit and Paul as they may
>> have some other patches queued up. I'll ack if they ack ;)
>
> Benoit, care to ack this patch ???
Gosh, that's hard to ack something like that :-)
But considering that the control module driver is not there yet, I have
no choice but accepting that one if we want to have the functionality
we've been waiting for years.
Could you just update the patch with a big disclaimer on top of the
address range to explain that this should not belong here and will be
removed ASAP, when the proper driver will be done.
Then you sign the patch with your blood and that should be fine for me :-).
Thanks,
Benoit
--
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: fix gpio node numbering to match hardware
On AM33xx, the datasheet and TRM refer to four GPIO instances that
are 0-based, GPIO0-3.
Signed-off-by: Matt Porter
---
arch/arm/boot/dts/am33xx.dtsi |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bb31bff..1369bfc 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -62,7 +62,7 @@
reg = <0x4820 0x1000>;
};
- gpio1: gpio@44e07000 {
+ gpio0: gpio@44e07000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio1";
gpio-controller;
@@ -74,7 +74,7 @@
interrupts = <96>;
};
- gpio2: gpio@4804c000 {
+ gpio1: gpio@4804c000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio2";
gpio-controller;
@@ -86,7 +86,7 @@
interrupts = <98>;
};
- gpio3: gpio@481ac000 {
+ gpio2: gpio@481ac000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio3";
gpio-controller;
@@ -98,7 +98,7 @@
interrupts = <32>;
};
- gpio4: gpio@481ae000 {
+ gpio3: gpio@481ae000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio4";
gpio-controller;
--
1.7.9.5
--
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 v3 4/4] arm/dts: Add tps65217 regulator DT data to am335x-bone.dts
On Sat, Sep 08, 2012 at 06:38:21AM +, AnilKumar, Chimata wrote: > On Wed, Sep 05, 2012 at 19:59:54, Koen Kooi wrote: > > > > Op 5 sep. 2012, om 16:24 heeft Matt Porter het volgende > > geschreven: > > > > > On Wed, Sep 05, 2012 at 03:29:30PM +0200, Koen Kooi wrote: > > >> > > >> Op 28 aug. 2012, om 07:34 heeft "AnilKumar, Chimata" > > >> het volgende geschreven: > > >> > > >>> Hi Koen, > > >>> > > >>> On Fri, Aug 24, 2012 at 13:32:17, Koen Kooi wrote: > > > > Op 24 aug. 2012, om 09:56 heeft Koen Kooi > > het volgende geschreven: > > > > > > > > Op 24 aug. 2012, om 09:26 heeft "AnilKumar, Chimata" > > > het volgende geschreven: > > > > > >> Hi Koen, > > >> > > >> On Fri, Aug 24, 2012 at 11:58:34, Koen Kooi wrote: > > >>> > > >>> Op 24 aug. 2012, om 07:50 heeft "AnilKumar, Chimata" > > >>> het volgende geschreven: > > >>> > > Hi Koen, > > > > On Thu, Aug 23, 2012 at 19:43:48, Koen Kooi wrote: > > > > > > Op 21 aug. 2012, om 13:17 heeft AnilKumar Ch > > > het volgende geschreven: > > > > > >> Add tps65217 regulator device tree data to AM335x-Bone by adding > > >> regulator consumers with tightened constraints and > > >> regulator-name. > > >> TPS65217 regulator handle can be obtained by using this regulator > > >> name. > > >> > > >> This patch also add I2C node with I2C frequency and tps65217 PMIC > > >> I2C slave address. > > >> > > >> Signed-off-by: AnilKumar Ch > > > > > > I tried this and the kernel immediately crashes on my beaglebone. > > > Could you upload the complete git tree and .config you used to > > > test this to somewhere public please? > > > > Use this repo to test on beaglebone > > https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-staging-pinctrl > > > > This wiki talks about how to build and use? > > https://github.com/hvaibhav/am335x-linux/wiki/How-To-Use-Upstream-Tree > > > > Note: Enable tps65217 regulator in kernel config. > > >>> > > >>> I used that repo and as a seperate test I rebased that to latest > > >>> mainline, same thing: as soon as I turn on the TPS in the .config > > >>> it crashes on boot. Is the pinctrl repo the *exact* repo you used > > >>> to test the patches on beaglebone? > > >> > > >> I tested on latest mainline after merging to > > >> am335x-upstream-staging-pinctrl (voltage also changing) > > >> > > >> Can you share your .config and uImage? > > > > > > Config: > > > https://github.com/beagleboard/kernel/blob/beaglebone-3.6/patches/configs/beaglebone > > > > > >> My config details:- (After merge) > > >> 1. omap2plus_defconfig > > >> 2. Enable tps65217 MFD driver > > >> 3. Enable tps65217 regulator driver > > > > > > > > > I rebased onto latest mainline and refreshed the base patches from > > > Vaibhav and I now get: > > > > > > [0.246796] tps65217 0-0024: TPS65217 ID 0xf version 1.1 > > > > > > So it boots! I don't know what made it break before, but it's working > > > now :) > > > > *sigh* I'm an idiot: > > > > root@beaglebone:~# uname -a > > Linux beaglebone 3.6.0-rc3-00103-gfd02083 #86 SMP Fri Aug 24 09:45:54 > > CEST 2012 armv7l GNU/Linux > > root@beaglebone:~# zcat /proc/config.gz | grep 217 > > CONFIG_MFD_TPS65217=y > > # CONFIG_REGULATOR_TPS65217 is not set > > > > Will retry with regulator driver actually turned on in a bit. > > >>> > > >>> Is it working after enabling the regulator? > > >> > > >> It took me a while to get back to this problem, but it still isn't > > >> working for me. I did manage to get more info on the error: > > >> > > >> root@bone-mainline:~# insmod tps65217-regulator.ko > > >> [ 32.754419] Unable to handle kernel NULL pointer dereference at > > >> virtual address 00c8 > > >> [ 32.763087] pgd = cea6 > > >> [ 32.765969] [00c8] *pgd=8fbed831, *pte=, *ppte= > > >> [ 32.772617] Internal error: Oops: 17 [#1] SMP THUMB2 > > >> [ 32.777827] Modules linked in: tps65217_regulator(+) ip_tables > > >> x_tables snd_soc_omap snd_soc_core regmap_spi snd_pcm snd_timer snd > > >> soundcore snd_page_alloc ipv6 > > >> [ 32.792976] CPU: 0Not tainted (3.6.0-rc4 #109) > > >> [ 32.798106] PC is at regmap_read+0x8/0x38 > > >> [ 32.802315] LR is at regulator_get_voltage_sel_regmap+0x15/0x38 > > > > > > I just got to this same point last night as I needed this working to > > > test omap_hsmmc with edma dmaengine... > > > > > > The problem is that the tps65217-regulator driver is handing the wrong > > > device to regulator_register() and it contains a null regmap. Th
Re: [PATCH] ARM: dts: AM33XX: fix gpio node numbering to match hardware
+ Tony
Hi Matt,
30 minutes too late for my pull request :-(
There are a couple of am33xx patches under discussion, so I'll take them
and send a for_3.7/dts-part2 pull request if this is not too late for Tony.
On 09/10/2012 06:20 PM, Matt Porter wrote:
> On AM33xx, the datasheet and TRM refer to four GPIO instances that
> are 0-based, GPIO0-3.
Or maybe you should just update the spec to use a 1-based GPIO number
like OMAP :-)
Regards,
Benoit
>
> Signed-off-by: Matt Porter
> ---
> arch/arm/boot/dts/am33xx.dtsi |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index bb31bff..1369bfc 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -62,7 +62,7 @@
> reg = <0x4820 0x1000>;
> };
>
> - gpio1: gpio@44e07000 {
> + gpio0: gpio@44e07000 {
> compatible = "ti,omap4-gpio";
> ti,hwmods = "gpio1";
> gpio-controller;
> @@ -74,7 +74,7 @@
> interrupts = <96>;
> };
>
> - gpio2: gpio@4804c000 {
> + gpio1: gpio@4804c000 {
> compatible = "ti,omap4-gpio";
> ti,hwmods = "gpio2";
> gpio-controller;
> @@ -86,7 +86,7 @@
> interrupts = <98>;
> };
>
> - gpio3: gpio@481ac000 {
> + gpio2: gpio@481ac000 {
> compatible = "ti,omap4-gpio";
> ti,hwmods = "gpio3";
> gpio-controller;
> @@ -98,7 +98,7 @@
> interrupts = <32>;
> };
>
> - gpio4: gpio@481ae000 {
> + gpio3: gpio@481ae000 {
> compatible = "ti,omap4-gpio";
> ti,hwmods = "gpio4";
> gpio-controller;
>
--
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
[balbi-usb:master 33/36] drivers/usb/gadget/serial.c:89:22: sparse: cast truncates bits from constant value (24000000 becomes 0)
tree: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git master
head: d9c88901337158c9f253a7de58a10b5125d61d26
commit: 7a7322b0a5d984025dd4faea9098b8fef07f8d8f [33/36] usb: gadget: remove
usb_gadget_controller_number()
All sparse warnings:
drivers/usb/gadget/f_acm.c:287:9: sparse: advancing past deep designator
drivers/usb/gadget/f_obex.c:60:9: sparse: advancing past deep designator
drivers/usb/gadget/f_serial.c:134:9: sparse: advancing past deep designator
drivers/usb/gadget/serial.c:66:9: sparse: advancing past deep designator
+ drivers/usb/gadget/serial.c:89:22: sparse: cast truncates bits from constant
value (2400 becomes 0)
vim +89 drivers/usb/gadget/serial.c
79 static struct usb_device_descriptor device_desc = {
80 .bLength = USB_DT_DEVICE_SIZE,
81 .bDescriptorType = USB_DT_DEVICE,
82 .bcdUSB = cpu_to_le16(0x0200),
83 /* .bDeviceClass = f(use_acm) */
84 .bDeviceSubClass = 0,
85 .bDeviceProtocol = 0,
86 /* .bMaxPacketSize0 = f(hardware) */
87 .idVendor = cpu_to_le16(GS_VENDOR_ID),
88 /* .idProduct = f(use_acm) */
> 89 .bcdDevice = cpu_to_le16(GS_VERSION_NUM << 16),
90 /* .iManufacturer = DYNAMIC */
91 /* .iProduct = DYNAMIC */
92 .bNumConfigurations = 1,
93 };
94
95 static struct usb_otg_descriptor otg_descriptor = {
96 .bLength = sizeof otg_descriptor,
97 .bDescriptorType = USB_DT_OTG,
98
99 /* REVISIT SRP-only hardware is possible, although
---
0-DAY kernel build testing backend Open Source Technology Centre
Fengguang Wu Intel Corporation
--
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: OMAP baseline test results for v3.6-rc5
Hi Felipe,
On Mon, 10 Sep 2012, Felipe Balbi wrote:
> On Sun, Sep 09, 2012 at 06:15:04PM +, Paul Walmsley wrote:
> > > * 4430ES2 Panda: UART corruption during long transmit buffers
> > > - Presumably due to either a missing hardware workaround or a bug in
> > > the OMAP serial driver
> > >
> > * 3730 Beagle XM: does not serial wake from off-idle suspend when console
> > UART doesn't clock gate ("debug ignore_loglevel")
> > - Not shown in the current test logs; cause unknown
>
> How do you trigger these two ? Can you share whatever script you wrote
> for this to fail ?
The 4430ES2 Panda issue can be seen here:
http://www.pwsan.com/omap/testlogs/test_v3.6-rc5/20120908202511/pm/4430es2panda/4430es2panda_log.txt
That shows the kernel command line, commit ID, sequence of
commands executed, and output. (The transmit buffer corruption can be
found in the section "%% Start retention dynamic idle UART wakeup test"
when it runs "cat /debug/pm_debug/count")
Similarly, the 3730 Beagle XM issue should be reproducible via the same
means as in:
http://www.pwsan.com/omap/testlogs/test_v3.6-rc5/20120908202511/pm/3730beaglexm/3730beaglexm_log.txt
but "debug ignore_loglevel" should be added to the kernel command line
when booting. Will try to add a specific PM test for this case.
Will try to do a few test runs on your series that was merged in tty-next
to see if anything has changed.
> I'm assuming the bugs are only triggered on those two
> particular platforms, so it could just be missing workaround on both
> cases (?)
Hard to say...
- Paul
--
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/3] arm: omap: hwmod: add a new addr space in otg for writing to control module
Hi,
On Mon, Sep 10, 2012 at 06:17:03PM +0200, Benoit Cousson wrote:
> > On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
> >> The mailbox register for usb otg in omap is present in control module.
> >> On detection of any events VBUS or ID, this register should be written
> >> to send the notification to musb core.
> >>
> >> Till we have a separate control module driver to write to control
> >> module,
> >> omap2430 will handle the register writes to control module by itself.
> >> So
> >> a new address space to represent this control module register is added
> >> to usb_otg_hs.
> >>
> >> Cc: Benoit Cousson
> >> Signed-off-by: Kishon Vijay Abraham I
> >> ---
> >> arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
> >> 1 file changed, 5 insertions(+)
> >>
> >> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> >> b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> >> index 242aee4..02341bc 100644
> >> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> >> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> >> @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space
> >> omap44xx_usb_otg_hs_addrs[] = {
> >>.pa_end = 0x4a0ab003,
> >>.flags = ADDR_TYPE_RT
> >>},
> >> + {
> >> + .pa_start = 0x4a00233c,
> >> + .pa_end = 0x4a00233f,
> >> + .flags = ADDR_TYPE_RT
> >> + },
> >
> > I do not have any objection/comment here, but I believe this is control
> > module address space required for USB module, right?
> > I am not sure this is right way of accessing control module space.
> > Actually Control Module Access required for drivers is one of the
> > blocking issue we have currently.
> >
> > Also there was some effort put up by 'Konstantine' to convert Control
> > module to MFD driver, I haven't seen any further update on it. But it
> > would be good to check with him.
>
> this was an agreement with Benoit since we already lost a couple merge
> windows for this patchset. We agreed to wait until -rc4 for SCM driver
> and if it wasn't ready, we'd go ahead with this and SCM author would fix
> it up on a patch converting users to new SCM driver.
> >>>
> >>> Tony, can I get your Acked-by to this patch so I can take it together
> >>> with the rest of the series ? Thanks
> >>>
> >>> ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
> >>> to merge it into your tree once I apply.
> >>
> >> It would be best if this got acked by Benoit and Paul as they may
> >> have some other patches queued up. I'll ack if they ack ;)
> >
> > Benoit, care to ack this patch ???
>
> Gosh, that's hard to ack something like that :-)
btw, that's not different than what's already in tree, the only
difference is that now hwmod knows about it...
> But considering that the control module driver is not there yet, I have
> no choice but accepting that one if we want to have the functionality
> we've been waiting for years.
>
> Could you just update the patch with a big disclaimer on top of the
> address range to explain that this should not belong here and will be
> removed ASAP, when the proper driver will be done.
sure, that's doable... Kishon, can you do this ASAP ? I want to send my
pull requests tomorrow at the latest.
> Then you sign the patch with your blood and that should be fine for me
> :-).
I'm running out of blood already, but maybe there's enough for this last
one... 8-#
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] ARM: dts: AM33XX: fix gpio node numbering to match hardware
On Mon, Sep 10, 2012 at 06:34:20PM +0200, Benoit Cousson wrote:
> + Tony
>
> Hi Matt,
>
> 30 minutes too late for my pull request :-(
>
> There are a couple of am33xx patches under discussion, so I'll take them
> and send a for_3.7/dts-part2 pull request if this is not too late for Tony.
Yeah, believe me, I did a faceplant when I saw your pull request come by
at the same time I discovered this issue. ;) In particular, AnilKumar's
user leds patch would need to be adjusted for this change. I can
resubmit with the user leds dts changes adjusted as well if that
discussion comes to a conclusion and his patches accepted.
> On 09/10/2012 06:20 PM, Matt Porter wrote:
> > On AM33xx, the datasheet and TRM refer to four GPIO instances that
> > are 0-based, GPIO0-3.
>
> Or maybe you should just update the spec to use a 1-based GPIO number
> like OMAP :-)
I am powerless here. :)
-Matt
> > Signed-off-by: Matt Porter
> > ---
> > arch/arm/boot/dts/am33xx.dtsi |8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> > index bb31bff..1369bfc 100644
> > --- a/arch/arm/boot/dts/am33xx.dtsi
> > +++ b/arch/arm/boot/dts/am33xx.dtsi
> > @@ -62,7 +62,7 @@
> > reg = <0x4820 0x1000>;
> > };
> >
> > - gpio1: gpio@44e07000 {
> > + gpio0: gpio@44e07000 {
> > compatible = "ti,omap4-gpio";
> > ti,hwmods = "gpio1";
> > gpio-controller;
> > @@ -74,7 +74,7 @@
> > interrupts = <96>;
> > };
> >
> > - gpio2: gpio@4804c000 {
> > + gpio1: gpio@4804c000 {
> > compatible = "ti,omap4-gpio";
> > ti,hwmods = "gpio2";
> > gpio-controller;
> > @@ -86,7 +86,7 @@
> > interrupts = <98>;
> > };
> >
> > - gpio3: gpio@481ac000 {
> > + gpio2: gpio@481ac000 {
> > compatible = "ti,omap4-gpio";
> > ti,hwmods = "gpio3";
> > gpio-controller;
> > @@ -98,7 +98,7 @@
> > interrupts = <32>;
> > };
> >
> > - gpio4: gpio@481ae000 {
> > + gpio3: gpio@481ae000 {
> > compatible = "ti,omap4-gpio";
> > ti,hwmods = "gpio4";
> > gpio-controller;
> >
>
> --
> 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
--
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] perf: Use pre-empt safe cpu_get/put insted of smp_processor_id
Roger Quadros writes:
> gets rid of below messages with CONFIG_DEBUG_PREEMPT enabled
>
> [ 28.832916] debug_smp_processor_id: 18 callbacks suppressed
> [ 28.832946] BUG: using smp_processor_id() in preemptible [] code:
> modprobe/1763
> [ 28.841491] caller is pwrdm_set_next_pwrst+0x54/0x120
>
> changes in v2:
> - rebased on 3.6-rc5
> - use put_cpu() immediately after get_cpu() in omap3_pm_idle()
>
> Signed-off-by: Roger Quadros
Can you also add what platforms this was tested on?
Otherwise, this looks good, and I'll queue up for v3.7 (since it's not a
regression.)
Thanks,
Kevin
> ---
> arch/arm/mach-omap2/clock.c |9 ++---
> arch/arm/mach-omap2/pm34xx.c | 12
> arch/arm/mach-omap2/powerdomain.c |6 --
> 3 files changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
> index ea3f565..06747b6 100644
> --- a/arch/arm/mach-omap2/clock.c
> +++ b/arch/arm/mach-omap2/clock.c
> @@ -285,7 +285,8 @@ void omap2_clk_disable(struct clk *clk)
> pr_debug("clock: %s: disabling in hardware\n", clk->name);
>
> if (clk->ops && clk->ops->disable) {
> - trace_clock_disable(clk->name, 0, smp_processor_id());
> + trace_clock_disable(clk->name, 0, get_cpu());
> + put_cpu();
> clk->ops->disable(clk);
> }
>
> @@ -339,7 +340,8 @@ int omap2_clk_enable(struct clk *clk)
> }
>
> if (clk->ops && clk->ops->enable) {
> - trace_clock_enable(clk->name, 1, smp_processor_id());
> + trace_clock_enable(clk->name, 1, get_cpu());
> + put_cpu();
> ret = clk->ops->enable(clk);
> if (ret) {
> WARN(1, "clock: %s: could not enable: %d\n",
> @@ -380,7 +382,8 @@ int omap2_clk_set_rate(struct clk *clk, unsigned long
> rate)
>
> /* dpll_ck, core_ck, virt_prcm_set; plus all clksel clocks */
> if (clk->set_rate) {
> - trace_clock_set_rate(clk->name, rate, smp_processor_id());
> + trace_clock_set_rate(clk->name, rate, get_cpu());
> + put_cpu();
> ret = clk->set_rate(clk, rate);
> }
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 05bd8f0..5aa0a11 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -346,18 +346,22 @@ void omap_sram_idle(void)
>
> static void omap3_pm_idle(void)
> {
> + unsigned cpu;
> +
> local_fiq_disable();
>
> if (omap_irq_pending())
> goto out;
>
> - trace_power_start(POWER_CSTATE, 1, smp_processor_id());
> - trace_cpu_idle(1, smp_processor_id());
> + cpu = get_cpu();
> + put_cpu();
> + trace_power_start(POWER_CSTATE, 1, cpu);
> + trace_cpu_idle(1, cpu);
>
> omap_sram_idle();
>
> - trace_power_end(smp_processor_id());
> - trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
> + trace_power_end(cpu);
> + trace_cpu_idle(PWR_EVENT_EXIT, cpu);
>
> out:
> local_fiq_enable();
> diff --git a/arch/arm/mach-omap2/powerdomain.c
> b/arch/arm/mach-omap2/powerdomain.c
> index 69b36e1..138bf86 100644
> --- a/arch/arm/mach-omap2/powerdomain.c
> +++ b/arch/arm/mach-omap2/powerdomain.c
> @@ -169,7 +169,8 @@ static int _pwrdm_state_switch(struct powerdomain *pwrdm,
> int flag)
> ((state & OMAP_POWERSTATE_MASK) << 8) |
> ((prev & OMAP_POWERSTATE_MASK) << 0));
> trace_power_domain_target(pwrdm->name, trace_state,
> - smp_processor_id());
> + get_cpu());
> + put_cpu();
> }
> break;
> default:
> @@ -491,7 +492,8 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8
> pwrst)
> if (arch_pwrdm && arch_pwrdm->pwrdm_set_next_pwrst) {
> /* Trace the pwrdm desired target state */
> trace_power_domain_target(pwrdm->name, pwrst,
> - smp_processor_id());
> + get_cpu());
> + put_cpu();
> /* Program the pwrdm desired target state */
> ret = arch_pwrdm->pwrdm_set_next_pwrst(pwrdm, pwrst);
> }
--
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] ARM: dts: AM33XX: fix gpio node numbering to match hardware
On 09/10/2012 06:52 PM, Matt Porter wrote:
> On Mon, Sep 10, 2012 at 06:34:20PM +0200, Benoit Cousson wrote:
>> + Tony
>>
>> Hi Matt,
>>
>> 30 minutes too late for my pull request :-(
>>
>> There are a couple of am33xx patches under discussion, so I'll take them
>> and send a for_3.7/dts-part2 pull request if this is not too late for Tony.
>
> Yeah, believe me, I did a faceplant when I saw your pull request come by
> at the same time I discovered this issue. ;) In particular, AnilKumar's
> user leds patch would need to be adjusted for this change. I can
> resubmit with the user leds dts changes adjusted as well if that
> discussion comes to a conclusion and his patches accepted.
Yeah, I was wondering if the gpios label were already used somewhere.
I've just added this patch on top of my current series.
So you or Anil should just post the missing patches whenever they'll be
available and accepted.
>> On 09/10/2012 06:20 PM, Matt Porter wrote:
>>> On AM33xx, the datasheet and TRM refer to four GPIO instances that
>>> are 0-based, GPIO0-3.
>>
>> Or maybe you should just update the spec to use a 1-based GPIO number
>> like OMAP :-)
>
> I am powerless here. :)
That's too bad :-(
Benoit
>
> -Matt
>
>>> Signed-off-by: Matt Porter
>>> ---
>>> arch/arm/boot/dts/am33xx.dtsi |8
>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
>>> index bb31bff..1369bfc 100644
>>> --- a/arch/arm/boot/dts/am33xx.dtsi
>>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>>> @@ -62,7 +62,7 @@
>>> reg = <0x4820 0x1000>;
>>> };
>>>
>>> - gpio1: gpio@44e07000 {
>>> + gpio0: gpio@44e07000 {
>>> compatible = "ti,omap4-gpio";
>>> ti,hwmods = "gpio1";
>>> gpio-controller;
>>> @@ -74,7 +74,7 @@
>>> interrupts = <96>;
>>> };
>>>
>>> - gpio2: gpio@4804c000 {
>>> + gpio1: gpio@4804c000 {
>>> compatible = "ti,omap4-gpio";
>>> ti,hwmods = "gpio2";
>>> gpio-controller;
>>> @@ -86,7 +86,7 @@
>>> interrupts = <98>;
>>> };
>>>
>>> - gpio3: gpio@481ac000 {
>>> + gpio2: gpio@481ac000 {
>>> compatible = "ti,omap4-gpio";
>>> ti,hwmods = "gpio3";
>>> gpio-controller;
>>> @@ -98,7 +98,7 @@
>>> interrupts = <32>;
>>> };
>>>
>>> - gpio4: gpio@481ae000 {
>>> + gpio3: gpio@481ae000 {
>>> compatible = "ti,omap4-gpio";
>>> ti,hwmods = "gpio4";
>>> gpio-controller;
>>>
>>
>> --
>> 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
--
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] ARM: dts: AM33XX: fix gpio node numbering to match hardware
* Benoit Cousson [120910 09:35]: > + Tony > > Hi Matt, > > 30 minutes too late for my pull request :-( > > There are a couple of am33xx patches under discussion, so I'll take them > and send a for_3.7/dts-part2 pull request if this is not too late for Tony. Yes please do, it' hard to say when exactly we need to stop merging, but probably we still have a bit more time. Regards, Tony -- 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: [balbi-usb:master 33/36] drivers/usb/gadget/serial.c:89:22: sparse: cast truncates bits from constant value (24000000 becomes 0)
On 09/10/2012 06:40 PM, Fengguang Wu wrote:
tree: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git master
head: d9c88901337158c9f253a7de58a10b5125d61d26
commit: 7a7322b0a5d984025dd4faea9098b8fef07f8d8f [33/36] usb: gadget: remove
usb_gadget_controller_number()
All sparse warnings:
Once again, thank you.
drivers/usb/gadget/f_acm.c:287:9: sparse: advancing past deep designator
drivers/usb/gadget/f_obex.c:60:9: sparse: advancing past deep designator
drivers/usb/gadget/f_serial.c:134:9: sparse: advancing past deep designator
drivers/usb/gadget/serial.c:66:9: sparse: advancing past deep designator
I don't get these. The purpose is an all NULL terminating entry. Could
this be a sparse bug or is the [] / {} switch not really good C code?
+ drivers/usb/gadget/serial.c:89:22: sparse: cast truncates bits from constant
value (2400 becomes 0)
I've sent a patch for this.
Sebastian
--
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] pinctrl: pinctrl-single: Add pinctrl-single,bits type of mux
* Peter Ujfalusi [120910 04:55]: > On 09/07/2012 07:55 PM, Tony Lindgren wrote: > > > > I'd like to have something that specifies the controller type so > > we don't need to mix two types of controllers and test for > > non-existing properties when parsing the pins. > > > > How about we require something specified for the pinctrl driver > > in the "one-bit-per-mux" case like pinctrl-single,bit-per-mux? > > > > And then in the pinctrl-single probe we set params = 3 if > > pinctrl-single,bit-per-mux is specified. And if no > > pinctrl-single,bit-per-mux is specified then set params = 2. > > > > That way pcs_parse_one_pinctrl_entry() can just test for params. > > > > Sorry I don't have a better name in mind than bit-per-mux.. > > I'm not sure if this would make things more prone to error or make the DTS or > the code more clean in any ways. > > Both pinctrl-single,pins and pinctrl-single,bits works on top of the same > pinctrl-single area. > In most cases we are going to use pinctrl-single,pins for the mux > configuration and only in few places we need to fall back to > pinctrl-single,bits. What about hardware that has tons of one-bit-per-mux type of registers? Then we end up trying to find the non-existing property potentially hundreds of times as the pinctrl-single,pins is never specified. > With this patch we will have maximum of two query to find out which type is > used, while if we add the 'bit-per-mux' property we will always have need to > have two of_get_property() call to figure out what is used. > IMHO in this way we could also have copy-paste errors coming at us when adding > the mux configurations for the pins and at the end we also need to do same > safety/sanity checks if the user really provided the correct type with > correlation to the 'bit-per-mux'. Well I think we should specify the binding for the type of the controller, not mix different types of bindings for the same controller. So we should probably have something just like address-cells, gpio-cells and interrupt-cells, although in this case it would be specific to pinctrl-single only and not be called cells. > This would just complicate the code. > The existence of pinctrl-single,pins or pinctrl-single,bits property alone > gives enough information for the number of parameters. Yes but we don't want to allow mixing different kind of registers within the same controller, they should be specified as separate controllers. Regards, Tony -- 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] ARM: OMAP: hwmod: revise deassert sequence
Hi Benoit, On 6 September 2012 10:12, Benoit Cousson wrote: > The sequence is good, I'm just a little bit concern about the > duplication of code compared to _enable sequence. > > That being said, this is the consequence of removing the hardreset > sequence outside of the main _enable/_shutdown sequence. > > So I'm not sure I have any better way of doing that :-( Indeed, it should be exactly the same as putting back the reset sequence into _enable/_shutdown, so with these patches I was expecting we could gather the hard reset users and see if they needed anything else beyond these functions, if not, perhaps just put back the reset code into _enable/_shutdown paths. Thanks, Omar -- 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] leds: leds-gpio: adopt pinctrl support
On 09/10/2012 09:23 AM, Linus Walleij wrote: > On Sun, Sep 9, 2012 at 1:44 AM, Domenico Andreoli wrote: >> On Fri, Sep 07, 2012 at 11:57:59PM +0200, Linus Walleij wrote: >>> >>> If all you need to to is to multiplex the pins into GPIO mode, >>> then the gpio_get() call on this driver *can* call through to >>> pinctrl_request_gpio() which will in turn fall through to the >>> above pinmux driver calls (.gpio_request_enable, etc). >> >> So if the GPIO driver doesn't coordinate with the pinctrl driver, it's >> all left to the GPIO user to configure the pin before using it, right? > > Yes, more or less, or should I say that certain aspects of pinctrl > are orthogonal to GPIO and the two mostly do not know of each > other due to a separation of concerns. > > So the driver may need to tie things up and request its pinctrl > and GPIOs independently. That seems like exactly what we were trying to avoid when we added the possibility for GPIO to call into pinctrl. Documentation/gpio.txt already contains: > For GPIOs that use pins known to the pinctrl subsystem, that subsystem should > be informed of their use; a gpiolib driver's .request() operation may call > pinctrl_request_gpio(), and a gpiolib driver's .free() operation may call > pinctrl_free_gpio(). The pinctrl subsystem allows a pinctrl_request_gpio() > to succeed concurrently with a pin or pingroup being "owned" by a device for > pin multiplexing. In order to resolve this, shouldn't we simply change the "should" at the end of the first line I quoted to "must"? That way, there'd never be any need to use pinctrl if you're only relying on gpiolib APIs. (and I'd argue that the text was already meant to say "must", so this isn't actually a change to the intent, just a clarification). -- 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] perf: Use pre-empt safe cpu_get/put insted of smp_processor_id
On 09/10/12 04:30, Roger Quadros wrote:
> gets rid of below messages with CONFIG_DEBUG_PREEMPT enabled
>
> [ 28.832916] debug_smp_processor_id: 18 callbacks suppressed
> [ 28.832946] BUG: using smp_processor_id() in preemptible [] code:
> modprobe/1763
> [ 28.841491] caller is pwrdm_set_next_pwrst+0x54/0x120
>
> changes in v2:
> - rebased on 3.6-rc5
> - use put_cpu() immediately after get_cpu() in omap3_pm_idle()
>
> Signed-off-by: Roger Quadros
> ---
> arch/arm/mach-omap2/clock.c |9 ++---
> arch/arm/mach-omap2/pm34xx.c | 12
> arch/arm/mach-omap2/powerdomain.c |6 --
> 3 files changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
> index ea3f565..06747b6 100644
> --- a/arch/arm/mach-omap2/clock.c
> +++ b/arch/arm/mach-omap2/clock.c
> @@ -285,7 +285,8 @@ void omap2_clk_disable(struct clk *clk)
> pr_debug("clock: %s: disabling in hardware\n", clk->name);
>
> if (clk->ops && clk->ops->disable) {
> - trace_clock_disable(clk->name, 0, smp_processor_id());
> + trace_clock_disable(clk->name, 0, get_cpu());
> + put_cpu();
Why are you doing this? Why not just use raw_smp_processor_id()? Do you
really care about the CPU number? get_cpu() and put_cpu() are about
non-preemptible sections where you want to ensure the CPU the code is
operating on is actually on that CPU.
How about just put 0 all the time because the CPU number is already part
of the trace event?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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] OMAP GPIO - don't wake from suspend unless requested.
"Shilimkar, Santosh" writes: > On Sat, Sep 8, 2012 at 3:07 AM, Kevin Hilman > wrote: >> Hi Neil, >> >> NeilBrown writes: >> >>> On Thu, 6 Sep 2012 11:18:09 +0530 "Shilimkar, Santosh" >>> wrote: >>> On Thu, Sep 6, 2012 at 8:35 AM, NeilBrown wrote: > On Mon, 3 Sep 2012 22:59:06 -0700 "Shilimkar, Santosh" > wrote: >>> >> After thinking bit more on this, the problem seems to be coming >> mainly because the gpio device is runtime suspended bit early than >> it should be. Similar issue seen with i2c driver as well. The i2c issue >> was discussed with Rafael at LPC last week. The idea is to move >> the pm_runtime_enable/disable() calls entirely up to the >> _late/_early stage of device suspend/resume. >> Will update this thread once I have further update. > > This won't be late enough. IRQCHIP_MASK_ON_SUSPEND takes effect after > all > the _late callbacks have been called. > I, too, spoke to Rafael about this in San Diego. He seemed to agree > with me > that the interrupt needs to be masked in the ->suspend callback. any > later > is too late. > Thanks for information about your discussion. Will wait for the patch then. Regards santosh >>> >>> I already sent a patch - that is what started this thread :-) >>> >>> I include it below. >>> You said "The patch doesn't seems to be correct" but didn't expand on why. >>> Do you still think it is not correct? I wouldn't be surprised if there is >>> some case that it doesn't handle quite right, but it seems right to me. >>> >>> Thanks, >>> NeilBrown >>> >>> >>> From: NeilBrown >>> Subject: [PATCH] OMAP GPIO - don't wake from suspend unless requested. >>> >>> Current kernel will wake from suspend on an event on any active >>> GPIO even if enable_irq_wake() wasn't called. >>> >>> There are two reasons that the hardware wake-enable bit should be set: >>> >>> 1/ while non-suspended the CPU might go into a deep sleep (off_mode) >>> in which the wake-enable bit is needed for an interrupt to be >>> recognised. >>> 2/ while suspended the GPIO interrupt should wake from suspend if and >>>only if irq_wake as been enabled. >>> >>> The code currently doesn't keep these two reasons separate so they get >>> confused and sometimes the wakeup flags is set incorrectly. >>> >>> This patch reverts: >>> commit 9c4ed9e6c01e7a8bd9079da8267e1f03cb4761fc >>> gpio/omap: remove suspend/resume callbacks >>> and >>> commit 0aa2727399c0b78225021413022c164cb99fbc5e >>> gpio/omap: remove suspend_wakeup field from struct gpio_bank >>> >>> and makes some minor changes so that we have separate flags for "GPIO >>> should wake from deep idle" and "GPIO should wake from suspend". >>> >>> With this patch, the GPIO from my touch screen doesn't wake my device >>> any more, which is what I want. >> >> I think the direction is right here. We never should've separated the >> handling of idle vs suspend wakeups. However, I have a few >> questions/doubts below... >> > I thought irq_set_wake() is suspend only wakeup functionality. In idle, the > driver IRQs are not disabled/masked so there no need of any special > wakeup calls for idle. More ever patch is adding the suspend hooks > for wakeups. > > I have no objection on the subject patch, but the suspend wakeup > facility is easy enough to implement for IRQCHIPS and that is > what I was proposing it. Infact the mask on suspend patch almost > works and it fails only because the GPIO driver is suspended earlier > than the IRQ framework expect it to be. That is a pretty big problem to overcome. :) That being said, I don't see how simply using MASK_ON_SUSPEND can work for GPIO. AFAICT, that flag is for the whole irq_chip, not for individual IRQs. We really need to keep track at the bank/IRQ level, as in the proposed patch from Neil (actually, we used to have this featur, but I screwed up by not catching this removal when reviewing the GPIO cleanup/reorg series.) Because of retention/off in idle, we set *all* GPIOs with IRQ triggering to be wakeup enabled so they will cause wakeups during idle. During suspend, we only want the irq_set_wake() ones to cause wakeups. > Anyways I step back here since the proposed patch already fixes > the issue seen. Assuming the IRQCHIP mask on suspend doesn't > seems to work well with drivers as Neil mentioned, the $subject patch > seems to be the right option. OK thanks, I'll queue this up for v3.6-rc as this should qualify as a regression. Also, the IRQCHIP mask feature seems to have been designed for IRQ chips without the control registers to handle this. We have the control registers to handle it, so I believe it's better to keep this handled in the driver itself. Kevin -- 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: [GIT PULL] OMAP devicetree for 3.7
* Benoit Cousson [120910 08:49]: > Hi Tony, > > Please pull the following branch. It contains a bunch of devicetree related > series. > > It contains as well a gpio-twl4030 patch acked by Linus W. > > It is tested on omap4-panda, omap3-beagle, omap3-overo-tobi, am335x-bone, > am335x-evm. > > It is based on your current devel-dt branch > (a06ceff6f29e34edff5d6b082885c1c4139a0362). Thanks pulling into devel-dt branch. Tony -- 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] OMAP GPIO - don't wake from suspend unless requested.
NeilBrown writes:
[...]
> Yes, I see that now. Thanks.
>
> follow patch folds those to fixes in.
>
> NeilBrown
>
> From bd9d5e9f8742c9cdc795e3d9b895f74defddb6d9 Mon Sep 17 00:00:00 2001
> From: NeilBrown
> Date: Mon, 10 Sep 2012 14:09:06 +1000
> Subject: [PATCH] OMAP GPIO - don't wake from suspend unless requested.
>
> Current kernel will wake from suspend on an event an any active
> GPIO event if enable_irq_wake() wasn't called.
>
> There are two reasons that the hardware wake-enable bit should be set:
>
> 1/ while non-suspended the CPU might go into a deep sleep (off_mode)
> in which the wake-enable bit is needed for an interrupt to be
> recognised.
> 2/ while suspended the GPIO interrupt should wake from suspend if and
>only if irq_wake as been enabled.
>
> The code currently doesn't keep these two reasons separate so they get
> confused and sometimes the wakeup flags is set incorrectly.
>
> This patch reverts:
> commit 9c4ed9e6c01e7a8bd9079da8267e1f03cb4761fc
> gpio/omap: remove suspend/resume callbacks
> and
> commit 0aa2727399c0b78225021413022c164cb99fbc5e
> gpio/omap: remove suspend_wakeup field from struct gpio_bank
>
> and makes some minor changes so that we have separate flags for "GPIO
> should wake from deep idle" and "GPIO should wake from suspend".
>
> With this patch, the GPIO from my touch screen doesn't wake my device
> any more, which is what I want.
>
> Cc: Kevin Hilman
> Cc: Tony Lindgren
> Cc: Santosh Shilimkar
> Cc: Benoit Cousson
> Cc: Grant Likely
> Cc: Tarun Kanti DebBarma
> Cc: Felipe Balbi
> Cc: Govindraj.R
>
> Signed-off-by: NeilBrown
>
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 4fbc208..79e1340 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -57,6 +57,7 @@ struct gpio_bank {
> u16 irq;
> int irq_base;
> struct irq_domain *domain;
> + u32 suspend_wakeup;
> u32 non_wakeup_gpios;
> u32 enabled_non_wakeup_gpios;
> struct gpio_regs context;
> @@ -522,11 +523,9 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int
> gpio, int enable)
>
> spin_lock_irqsave(&bank->lock, flags);
> if (enable)
> - bank->context.wake_en |= gpio_bit;
> + bank->suspend_wakeup |= gpio_bit;
> else
> - bank->context.wake_en &= ~gpio_bit;
> -
> - __raw_writel(bank->context.wake_en, bank->base + bank->regs->wkup_en);
> + bank->suspend_wakeup &= ~gpio_bit;
> spin_unlock_irqrestore(&bank->lock, flags);
>
> return 0;
> @@ -1157,6 +1156,49 @@ static int __devinit omap_gpio_probe(struct
> platform_device *pdev)
> #ifdef CONFIG_ARCH_OMAP2PLUS
>
> #if defined(CONFIG_PM_RUNTIME)
> +
> +#if defined(CONFIG_PM_SLEEP)
> +static int omap_gpio_suspend(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct gpio_bank *bank = platform_get_drvdata(pdev);
> + void __iomem *base = bank->base;
> + unsigned long flags;
> +
> + if (!bank->mod_usage ||
> + !bank->regs->wkup_en ||
> + !bank->context.wake_en)
nit: the context->wake_en check isn't really needed here.
> + return 0;
> +
> + spin_lock_irqsave(&bank->lock, flags);
> + _gpio_rmw(base, bank->regs->wkup_en, 0x, 0);
> + _gpio_rmw(base, bank->regs->wkup_en, bank->suspend_wakeup, 1);
I know we had the duplicate read/modify/writes here before, but that causes
a bunch of unnecessary register accesses. Simply writing
bank->suspend_wakeup should suffice here...
> + spin_unlock_irqrestore(&bank->lock, flags);
> +
> + return 0;
> +}
> +
> +static int omap_gpio_resume(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct gpio_bank *bank = platform_get_drvdata(pdev);
> + void __iomem *base = bank->base;
> + unsigned long flags;
> +
> + if (!bank->mod_usage ||
> + !bank->regs->wkup_en ||
> + !bank->context.wake_en)
> + return 0;
> +
> + spin_lock_irqsave(&bank->lock, flags);
> + _gpio_rmw(base, bank->regs->wkup_en, 0x, 0);
> + _gpio_rmw(base, bank->regs->wkup_en, bank->context.wake_en, 1);
...similarily, simply writing context.wake_en should suffice here (after
removing the check for non-zero wake_en above so that we're sure that
the setting of suspend_wakeup is undone.)
Kevin
> + spin_unlock_irqrestore(&bank->lock, flags);
> +
> + return 0;
> +}
> +#endif /* CONFIG_PM_SLEEP */
> +
> static void omap_gpio_restore_context(struct gpio_bank *bank);
>
> static int omap_gpio_runtime_suspend(struct device *dev)
> @@ -1386,11 +1428,14 @@ static void omap_gpio_restore_context(struct
> gpio_bank *bank)
> }
> #endif /* CONFIG_PM_RUNTIME */
> #else
> +#define omap_gpio_suspend NULL
> +#define omap_gpio_resume NULL
> #define omap_gpio_runtime_suspend NULL
> #define omap_gpio_runtime_resume NULL
> #endif
>
> static const st
Re: [PATCH] ARM: OMAP2+: mux: add support for PAD wakeup event handler
* Ruslan Bilovol [120910 03:39]: > OMAP mux now parses active wakeup events from pad registers and calls > corresponding handler, if handler is not registered - corresponding > hwmod ISRs once a wakeup is detected. > This is useful for cases when routing wakeups to corresponding hwmod > ISRs complicates those ISRs handlers (for example, ISR handler may > not know who the interrupt source is) The mux code in arch/arm/mach-omap2 will be going away and replaced by device tree based pinctrl-single. It's not a good idea to add more dependencies to custom frameworks as that just makes the transition harder on us. Regards, Tony -- 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] pinctrl: pinctrl-single: Add pinctrl-single,bits type of mux
* Linus Walleij [120910 00:11]: > On Wed, Sep 5, 2012 at 11:01 AM, Peter Ujfalusi wrote: > > > With pinctrl-single,bits it is possible to update just part of the register > > within the pinctrl-single,function-mask area. > > This is useful when one register configures mmore than one pin's mux. > > > > pinctrl-single,bits takes three parameters: > > > > > > Signed-off-by: Peter Ujfalusi > > Do we have a conclusion on this patch 2/2? > > I'm holding it back until Tony explicitly ACKs it for now. I don't like the idea of mixing different types of controllers here, so let's wait a little bit on 2/2. Tony -- 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] ARM: OMAP4: wakeupgen: remove duplicate AUXCOREBOOT* read/write
* Shilimkar, Santosh [120908 01:20]: > > Will you able to pick up these couple of wakeupgen fixes from here or > do you want me to send you a pull request for 3.6-rc5/6 I can pick them into fixes-noncritical. But if the second one is a major bug for the -rc series, the patch should be describe what breaks (regression? oops?). Regards, Tony -- 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: [RFC PATCH v2] OMAPDSS: Fix IRQ unregister race
On Monday 10 September 2012 10:49:05 Tomi Valkeinen wrote:
> On Sat, 2012-09-08 at 18:05 +0300, Dimitar Dimitrov wrote:
> > Very rare kernel crashes are reported on a custom OMAP4 board. Kernel
> > panics due to corrupted completion structure while executing
> >
> > dispc_irq_wait_handler(). Excerpt from kernel log:
> > Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP
> > Unable to handle kernel paging request at virtual address 00400130
> > ...
> > PC is at 0xebf205bc
> > LR is at __wake_up_common+0x54/0x94
> > ...
> > (__wake_up_common+0x0/0x94)
> > (complete+0x0/0x60)
> > (dispc_irq_wait_handler.36902+0x0/0x14)
> > (omap_dispc_irq_handler+0x0/0x354)
> > (handle_irq_event_percpu+0x0/0x188)
> > (handle_irq_event+0x0/0x64)
> > (handle_fasteoi_irq+0x0/0x10c)
> > (generic_handle_irq+0x0/0x48)
> > (asm_do_IRQ+0x0/0xc0)
> >
> > DISPC IRQ executes callbacks with dispc.irq_lock released. Hence
> > unregister_isr() and DISPC IRQ might be running in parallel on different
> > CPUs. So there is a chance that a callback is executed even though it
> > has been unregistered. As omap_dispc_wait_for_irq_timeout() declares a
> > completion on stack, the dispc_irq_wait_handler() callback might try to
> > access a completion structure that is invalid. This leads to crashes and
> > hangs.
> >
> > Solution is to divide unregister calls into two sets:
> > 1. Non-strict unregistering of callbacks. Callbacks could safely be
> >
> > executed after unregistering them. This is the case with unregister
> > calls from the IRQ handler itself.
> >
> > 2. Strict (synchronized) unregistering. Callbacks are not allowed
> >
> > after unregistering. This is the case with completion waiting.
> >
> > The above solution should satisfy one of the original intentions of the
> > driver: callbacks should be able to unregister themselves.
> >
> > Also fix DSI IRQ unregister which has similar logic to DISPC IRQ
> > handling.
> >
> > Signed-off-by: Dimitar Dimitrov
> > ---
> >
> > WARNING: This bug is quite old. The patch has been tested on v3.0. No
> > testing has been done after rebasing to v3.6. Hence the RFC tag.
> > Hopefully someone will beat me in testing with latest linux-omap/master.
> >
> > Changes since v1 per Tomi Valkeinen's comments:
> > - Don't rename omap_dispc_unregister_isr, just introduce nosync
> > variant. - Apply the same fix for DSI IRQ which suffers from the same
> > race condition.
>
> I made a quick test and works for me, although I haven't encountered the
> problem itself.
This issue is very rarely seen during normal operation. You may not hit it
even after days of stress testing. To speed up reproducing an artificial delay
in the IRQ routine could be used while stress-testing DSS, e.g.:
@@ -3462,6 +3462,8 @@ static irqreturn_t omap_dispc_irq_handler(int irq, void
*a
spin_unlock(&dispc.irq_lock);
+ { static int iii; if ((iii++ % 10) == 0) mdelay(100); }
+
for (i = 0; i < DISPC_MAX_NR_ISRS; i++) {
isr_data = ®istered_isr[i];
>
> Some mostly cosmetic comments below.
>
> This seems to apply cleanly to v3.4+ kernels, but not earlier ones. Do
> you want to make the needed modifications and mail this and the modified
> patches for stable kernels also? I can do that also if you don't want
> to.
I can do the rebase and cleanup. I'll send the modified patch per your
comments in the next hour.
Currently I cannot test, though. I hope to have a working setup by end of week
in order to send sanity-tested patches for stable kernels.
>
> > drivers/staging/omapdrm/omap_plane.c |2 +-
> > drivers/video/omap2/dss/apply.c |2 +-
> > drivers/video/omap2/dss/dispc.c | 45
> > +- drivers/video/omap2/dss/dsi.c
> > | 19 ++
> > include/video/omapdss.h |1 +
> > 5 files changed, 61 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/staging/omapdrm/omap_plane.c
> > b/drivers/staging/omapdrm/omap_plane.c index 7997be7..8d8aa5b 100644
> > --- a/drivers/staging/omapdrm/omap_plane.c
> > +++ b/drivers/staging/omapdrm/omap_plane.c
> > @@ -82,7 +82,7 @@ static void dispc_isr(void *arg, uint32_t mask)
> >
> > struct omap_plane *omap_plane = to_omap_plane(plane);
> > struct omap_drm_private *priv = plane->dev->dev_private;
> >
> > - omap_dispc_unregister_isr(dispc_isr, plane,
> > + omap_dispc_unregister_isr_nosync(dispc_isr, plane,
> >
> > id2irq[omap_plane->ovl->id]);
> >
> > queue_work(priv->wq, &omap_plane->work);
> >
> > diff --git a/drivers/video/omap2/dss/apply.c
> > b/drivers/video/omap2/dss/apply.c index 0fefc68..9386834 100644
> > --- a/drivers/video/omap2/dss/apply.c
> > +++ b/drivers/video/omap2/dss/apply.c
> > @@ -847,7 +847,7 @@ static void dss_unregister_vsync_isr(void)
> >
> > for (i = 0; i < num_mgrs; ++i)
> >
> > mask |= dispc_mgr_get
[PATCH v3] OMAPDSS: Fix IRQ unregister race
Very rare kernel crashes are reported on a custom OMAP4 board. Kernel
panics due to corrupted completion structure while executing
dispc_irq_wait_handler(). Excerpt from kernel log:
Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP
Unable to handle kernel paging request at virtual address 00400130
...
PC is at 0xebf205bc
LR is at __wake_up_common+0x54/0x94
...
(__wake_up_common+0x0/0x94)
(complete+0x0/0x60)
(dispc_irq_wait_handler.36902+0x0/0x14)
(omap_dispc_irq_handler+0x0/0x354)
(handle_irq_event_percpu+0x0/0x188)
(handle_irq_event+0x0/0x64)
(handle_fasteoi_irq+0x0/0x10c)
(generic_handle_irq+0x0/0x48)
(asm_do_IRQ+0x0/0xc0)
DISPC IRQ executes callbacks with dispc.irq_lock released. Hence
unregister_isr() and DISPC IRQ might be running in parallel on different
CPUs. So there is a chance that a callback is executed even though it
has been unregistered. As omap_dispc_wait_for_irq_timeout() declares a
completion on stack, the dispc_irq_wait_handler() callback might try to
access a completion structure that is invalid. This leads to crashes and
hangs.
Solution is to divide unregister calls into two sets:
1. Non-strict unregistering of callbacks. Callbacks could safely be
executed after unregistering them. This is the case with unregister
calls from the IRQ handler itself.
2. Strict (synchronized) unregistering. Callbacks are not allowed
after unregistering. This is the case with completion waiting.
The above solution should satisfy one of the original intentions of the
driver: callbacks should be able to unregister themselves.
Also fix DSI IRQ unregister which has similar logic to DISPC IRQ handling.
Cc: stable
Signed-off-by: Dimitar Dimitrov
---
Changes since v2:
- Fix formatting per Tomi Valkeinen's comments.
- Restored accidental removal of EXPORT_SYMBOL for omap_dispc_register_isr.
drivers/staging/omapdrm/omap_plane.c |2 +-
drivers/video/omap2/dss/apply.c |2 +-
drivers/video/omap2/dss/dispc.c | 34 +-
drivers/video/omap2/dss/dsi.c| 15 +++
include/video/omapdss.h |1 +
5 files changed, 51 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_plane.c
b/drivers/staging/omapdrm/omap_plane.c
index 7997be7..8d8aa5b 100644
--- a/drivers/staging/omapdrm/omap_plane.c
+++ b/drivers/staging/omapdrm/omap_plane.c
@@ -82,7 +82,7 @@ static void dispc_isr(void *arg, uint32_t mask)
struct omap_plane *omap_plane = to_omap_plane(plane);
struct omap_drm_private *priv = plane->dev->dev_private;
- omap_dispc_unregister_isr(dispc_isr, plane,
+ omap_dispc_unregister_isr_nosync(dispc_isr, plane,
id2irq[omap_plane->ovl->id]);
queue_work(priv->wq, &omap_plane->work);
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 0fefc68..9386834 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -847,7 +847,7 @@ static void dss_unregister_vsync_isr(void)
for (i = 0; i < num_mgrs; ++i)
mask |= dispc_mgr_get_framedone_irq(i);
- r = omap_dispc_unregister_isr(dss_apply_irq_handler, NULL, mask);
+ r = omap_dispc_unregister_isr_nosync(dss_apply_irq_handler, NULL, mask);
WARN_ON(r);
dss_data.irq_enabled = false;
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index ee9e296..6032252 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3320,7 +3320,8 @@ err:
}
EXPORT_SYMBOL(omap_dispc_register_isr);
-int omap_dispc_unregister_isr(omap_dispc_isr_t isr, void *arg, u32 mask)
+/* WARNING: callback might be executed even after this function returns! */
+int omap_dispc_unregister_isr_nosync(omap_dispc_isr_t isr, void *arg, u32 mask)
{
int i;
unsigned long flags;
@@ -3352,6 +3353,37 @@ int omap_dispc_unregister_isr(omap_dispc_isr_t isr, void
*arg, u32 mask)
return ret;
}
+EXPORT_SYMBOL(omap_dispc_unregister_isr_nosync);
+
+/*
+ * Ensure that callback will NOT be executed after this function
+ * returns. Must be called from sleepable context, though!
+ */
+int omap_dispc_unregister_isr(omap_dispc_isr_t isr, void *arg, u32 mask)
+{
+ int ret;
+
+ ret = omap_dispc_unregister_isr_nosync(isr, arg, mask);
+
+ /*
+* Task context is not really needed. But if we're called from atomic
+* context, it is probably from DISPC IRQ, where we will deadlock.
+* So use might_sleep() to catch potential deadlocks.
+*/
+ might_sleep();
+
+ /*
+* DISPC IRQ executes callbacks with dispc.irq_lock released. Hence
+* unregister_isr() and DISPC IRQ might be running in parallel on
+* different CPUs. So there is a chance that a callback is executed
+* even though it has been unregistered. Add a barrier, in order to
+*
Re: [PATCH v2] leds: leds-gpio: adopt pinctrl support
On Mon, Sep 10, 2012 at 7:41 PM, Stephen Warren wrote: > On 09/10/2012 09:23 AM, Linus Walleij wrote: > That seems like exactly what we were trying to avoid when we added the > possibility for GPIO to call into pinctrl. > > Documentation/gpio.txt already contains: > >> For GPIOs that use pins known to the pinctrl subsystem, that subsystem should >> be informed of their use; a gpiolib driver's .request() operation may call >> pinctrl_request_gpio(), and a gpiolib driver's .free() operation may call >> pinctrl_free_gpio(). The pinctrl subsystem allows a pinctrl_request_gpio() >> to succeed concurrently with a pin or pingroup being "owned" by a device for >> pin multiplexing. > > In order to resolve this, shouldn't we simply change the "should" at the > end of the first line I quoted to "must"? That way, there'd never be any > need to use pinctrl if you're only relying on gpiolib APIs. > > (and I'd argue that the text was already meant to say "must", so this > isn't actually a change to the intent, just a clarification). It should deal with all the simple muxing use cases yes. And I am uncertain about the scope for this patch, if it only pertains to muxing, and in that case it would be solved by adding a proper GPIO backend to pinctrl-single.c. But it doesn't help with some real-world usecases if I'm not mistaken. If you want to set up a certain GPIO pin as pull-down (I guess this could be the case for a LED array), this cannot be done through any of these functions: extern int pinctrl_request_gpio(unsigned gpio); extern void pinctrl_free_gpio(unsigned gpio); extern int pinctrl_gpio_direction_input(unsigned gpio); extern int pinctrl_gpio_direction_output(unsigned gpio); So either we have to use a pin config hog to do this, or we have to use devm_pinctrl_get_select_default(&pdev->dev); from the driver (as this patch does). Either way it is using the pinctrl system orthogonally to the GPIO system, it doesn't happen from pinctrl_request_gpio() or so. An alternative solution would be to add functions for controlling pinconfig and whatnot to the GPIO glue, which in turn would require adding frontends all over which in turn was the thing that Grant nixed to I got started with pinctrl instead... But I'm open to any other suggestions. Would it be possible for pinctrl_request_gpio() to activate a pin config in the map for example? Currently it can only do muxing. It's also possible to have the driver do something custom behind the back of pinctrl altogether as a response to pinctrl_request_gpio() but it wouldn't be any elegant... Yours, Linus Walleij -- 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] leds: leds-gpio: adopt pinctrl support
On Sat, Sep 1, 2012 at 10:16 AM, AnilKumar Ch wrote:
> Adopt pinctrl support to leds-gpio driver based on leds-gpio
> device pointer, pinctrl driver configure SoC pins to GPIO
> mode according to definitions provided in .dts file.
>
> Signed-off-by: AnilKumar Ch
So looking back at this after Stephen posed a real good
question, when you say "configure SoC pins to GPIO
mode", does that mean anything else than to mux them into
GPIO mode?
In that case, have you considered augmenting
pinctrl-single.c to implement .gpio_request_enable()
.gpio_disable_free() and maybe also .gpio_set_direction()
in its struct pinmux_ops pinmux backend?
If not, why?
Currently it looks like this:
static int pcs_request_gpio(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range, unsigned offset)
{
return -ENOTSUPP;
}
static struct pinmux_ops pcs_pinmux_ops = {
.get_functions_count = pcs_get_functions_count,
.get_function_name = pcs_get_function_name,
.get_function_groups = pcs_get_function_groups,
.enable = pcs_enable,
.disable = pcs_disable,
.gpio_request_enable = pcs_request_gpio,
};
Yours,
Linus Walleij
--
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
