* [GIT PULL] dmtimer changes for v3.2 merge window
From: Arnd Bergmann @ 2011-09-30 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110930204319.GM6324@atomide.com>
On Friday 30 September 2011, Tony Lindgren wrote:
> How about a branch called driver?
>
> There are still lots of pieces of code under arch/arm that should
> be eventually moved to live under drivers. For example the mux
> code and most of PM code can eventually be under drivers.
Yes, good idea! For the omap/voltage series, I currently plan to
group that with pm changes for that I got for the other socs
this time, but if there was less of it, that could also be drivers.
> But before that can be done some preparation is often needed,
> the actual move to live under drivers should be handled then
> by the driver and subsystem maintainers.
I think in some cases we first need to nominate a subsystem
maintainer who can take the drivers, but that's a different
issue.
Arnd
^ permalink raw reply
* [GIT PULL] OMAP: more omap_device preparations for DT
From: Kevin Hilman @ 2011-09-30 20:55 UTC (permalink / raw)
To: linux-arm-kernel
Tony,
Please pull the following omap_device series that finishes up the
preparation the rest of the device tree work from Benoit.
Kevin
The following changes since commit 0f9b8dd0120cca55b73620c2a6e0dd8c1575f677:
Merge branches 'cleanup', 'voltage' and 'dmtimer' into dt-base (2011-09-30 11:13:29 -0700)
are available in the git repository at:
git://github.com/khilman/linux-omap-pm.git for_3.2/omap_device-2
Benoit Cousson (8):
ARM: OMAP3: beagle-board: Use the omap_hwmod_name_get_dev API
ARM: OMAP2+: pm: Use hwmod name instead of dev pointer
ARM: OMAP2+: pm: Remove static devices variable for mpu, dsp, iva and l3 PM
ARM: OMAP: omap_device: Create a default omap_device_pm_latency
ARM: OMAP2+: devices: Remove all omap_device_pm_latency structures
of: Add helpers to get one string in multiple strings property
ARM: OMAP: omap_device: Add omap_device_[alloc|delete] for DT integration
ARM: OMAP: omap_device: Add a method to build an omap_device from a DT node
Nishanth Menon (1):
ARM: OMAP: omap_device: Add omap_device_get_by_hwmod_name
.../devicetree/bindings/arm/omap/omap.txt | 43 +++
arch/arm/mach-omap2/board-omap3beagle.c | 4 +-
arch/arm/mach-omap2/devices.c | 46 +---
arch/arm/mach-omap2/display.c | 11 +-
arch/arm/mach-omap2/dma.c | 11 +-
arch/arm/mach-omap2/gpio.c | 12 +-
arch/arm/mach-omap2/hsmmc.c | 18 +-
arch/arm/mach-omap2/hwspinlock.c | 12 +-
arch/arm/mach-omap2/mcbsp.c | 11 +-
arch/arm/mach-omap2/pm.c | 69 ++---
arch/arm/mach-omap2/serial.c | 25 +--
arch/arm/mach-omap2/sr_device.c | 11 +-
arch/arm/mach-omap2/usb-musb.c | 11 +-
arch/arm/plat-omap/i2c.c | 10 +-
arch/arm/plat-omap/include/plat/omap_device.h | 1 +
arch/arm/plat-omap/omap_device.c | 313 +++++++++++++++++---
drivers/of/base.c | 84 ++++++
include/linux/of.h | 18 ++
18 files changed, 448 insertions(+), 262 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/omap.txt
^ permalink raw reply
* [GIT PULL] omap cleanup part3 for v3.2 merge window
From: Arnd Bergmann @ 2011-09-30 20:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110930195642.GL6324@atomide.com>
On Friday 30 September 2011, Tony Lindgren wrote:
> Please pull omap cleanup part3 into cleanup from:
>
> git://github.com/tmlind/linux.git cleanup-part3
>
> If you did not already pull the earlier updated
> cleanup, pulling this is enough and will bring that
> in too.
Ok, I've ended up replacing the merge into the next/cleanup
branch to get a cleaner history, so the cleanup-part2
no longer shows up there.
Thanks!
Arnd
^ permalink raw reply
* [PATCH v5 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices
From: Kevin Hilman @ 2011-09-30 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317363153-10259-3-git-send-email-abhilash.kv@ti.com>
Abhilash K V <abhilash.kv@ti.com> writes:
> From: Abhilash K V <abhilash.kv@ti.com>
>
> In case of AM3517 & AM3505, SmartReflex is not applicable so
> we must not enable it. So omap3_twl_init() is now not called
> when the processor does not support SR.
This still isn't right.
The reason to skip the TWL PMIC init is not because SR is not available
(TWL PMICs are quite usable without SR). The reason to skip TWL PMIC
init is because the PMIC is not present.
Instead, we need to fix up the TWL/PMIC init so that TWL-specifics are
only registered if a TWL driver is registered.
So, please drop hunk #2 from this patch, and just make this patch add a
new feature for the existence of SmartReflex. Removing the assumptions
and init for the existence of the TWL is a separate problem.
Kevin
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> Signed-off-by: Abhilash K V <abhilash.kv@ti.com>
> ---
> arch/arm/mach-omap2/id.c | 2 +-
> arch/arm/mach-omap2/pm.c | 3 ++-
> arch/arm/plat-omap/include/plat/cpu.h | 2 ++
> 3 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> index d27daf9..b7e3082 100644
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
> @@ -188,7 +188,7 @@ static void __init omap3_check_features(void)
> if (cpu_is_omap3630())
> omap_features |= OMAP3_HAS_192MHZ_CLK;
> if (!cpu_is_omap3505() && !cpu_is_omap3517())
> - omap_features |= OMAP3_HAS_IO_WAKEUP;
> + omap_features |= (OMAP3_HAS_IO_WAKEUP | OMAP3_HAS_SR);
>
> omap_features |= OMAP3_HAS_SDRC;
>
> diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
> index 0844e2e..6835198 100644
> --- a/arch/arm/mach-omap2/pm.c
> +++ b/arch/arm/mach-omap2/pm.c
> @@ -250,7 +250,8 @@ postcore_initcall(omap2_common_pm_init);
> static int __init omap2_common_pm_late_init(void)
> {
> /* Init the OMAP TWL parameters */
> - omap3_twl_init();
> + if (omap3_has_sr())
> + omap3_twl_init();
> omap4_twl_init();
>
> /* Init the voltage layer */
> diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h
> index 2f90269..cc6fcd3 100644
> --- a/arch/arm/plat-omap/include/plat/cpu.h
> +++ b/arch/arm/plat-omap/include/plat/cpu.h
> @@ -413,6 +413,7 @@ extern u32 omap_features;
> #define OMAP4_HAS_MPU_1GHZ BIT(8)
> #define OMAP4_HAS_MPU_1_2GHZ BIT(9)
> #define OMAP4_HAS_MPU_1_5GHZ BIT(10)
> +#define OMAP3_HAS_SR BIT(11)
>
>
> #define OMAP3_HAS_FEATURE(feat,flag) \
> @@ -429,6 +430,7 @@ OMAP3_HAS_FEATURE(isp, ISP)
> OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK)
> OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP)
> OMAP3_HAS_FEATURE(sdrc, SDRC)
> +OMAP3_HAS_FEATURE(sr, SR)
>
> /*
> * Runtime detection of OMAP4 features
^ permalink raw reply
* [PATCH v4 0/7] add initial imx6q support
From: Arnd Bergmann @ 2011-09-30 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317200808-6275-1-git-send-email-shawn.guo@linaro.org>
On Wednesday 28 September 2011, Shawn Guo wrote:
>
> This patch series adds the initial support for imx6q, which is a
> Cortex-A9 Quad Core based SoC.
>
> We chose to add imx6q support into mach-imx other than mach-mx5 or
> a new mach-mx6, because we intend to merge mach-mx5 into mach-imx, so
> that we have only mach-imx for imx family.
>
> It's based on linux-next-20110926 with some prerequisite patches
> not showing up on linux-next applied.
How should we best proceed on this series? Sascha, do you want to
take the next version into your tree once Shawn has addressed the
remaining comments, or should I just take the patches with your
Ack?
Shawn, what are the current dependencies? I will have to pull
in the other branches that this depends on into the next/soc
tree and then wait for those to get merged first before I send
this to Linus.
Arnd
^ permalink raw reply
* [GIT PULL] OMAP: more omap_device preparations for DT
From: Tony Lindgren @ 2011-09-30 21:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87y5x5hhsr.fsf@ti.com>
* Kevin Hilman <khilman@ti.com> [110930 13:21]:
> Tony,
>
> Please pull the following omap_device series that finishes up the
> preparation the rest of the device tree work from Benoit.
Thanks, this is now in dt branch.
Tony
^ permalink raw reply
* [PATCH v5 3/3] OMAP2+: voltage: add check for missing PMIC info in vp init
From: Kevin Hilman @ 2011-09-30 21:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317363153-10259-4-git-send-email-abhilash.kv@ti.com>
Abhilash K V <abhilash.kv@ti.com> writes:
> From: Abhilash K V <abhilash.kv@ti.com>
>
> If PMIC info is not available in omap_vp_init(), abort.
>
> Signed-off-by: Abhilash K V <abhilash.kv@ti.com>
Looks good.
After minor fixup below, adding to the next round of voltage cleanups
(branch: for_3.2/voltage-cleanup-2.)
> ---
> arch/arm/mach-omap2/vp.c | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
> index 66bd700..0ed3d13 100644
> --- a/arch/arm/mach-omap2/vp.c
> +++ b/arch/arm/mach-omap2/vp.c
> @@ -41,6 +41,13 @@ void __init omap_vp_init(struct voltagedomain *voltdm)
> u32 val, sys_clk_rate, timeout, waittime;
> u32 vddmin, vddmax, vstepmin, vstepmax;
>
> + if (!voltdm->pmic || !voltdm->pmic->uv_to_vsel) {
> + pr_err("%s: PMIC info requried to configure VP for "
> + "vdd_%s not populated.Hence cannot initialize VP\n",
Added space after '.'
Thanks,
Kevin
> + __func__, voltdm->name);
> + return;
> + }
> +
> if (!voltdm->read || !voltdm->write) {
> pr_err("%s: No read/write API for accessing vdd_%s regs\n",
> __func__, voltdm->name);
^ permalink raw reply
* [GIT PATCH] OMAP: Add initial support for DT on OMAP3 & OMAP4
From: Tony Lindgren @ 2011-09-30 21:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E86298E.4080007@ti.com>
* Cousson, Benoit <b-cousson@ti.com> [110930 13:08]:
> Hi Tony,
>
> Please pull the initial OMAP device tree support for v3.2.
Great, thanks. And thanks for updating the two patches below
to say ARM: OMAP2+: in the subject :)
This is now in dt branch. Will merge into linux-omap master
branch and send all the dt changes to Arnd within few days.
Regards,
Tony
> Thanks,
> Benoit
>
>
> The following changes since commit 1c3543a34a8ce3e050d7706135bdffd5921c42f5:
> Tony Lindgren (1):
> Merge branch 'for_3.2/omap_device-2' of git://github.com/khilman/linux-omap-pm into dt
>
> are available in the git repository at:
>
> git://gitorious.org/omap-pm/linux.git for_3.2/3_omap_devicetree
>
> Benoit Cousson (10):
> arm/dts: Add initial device tree support for OMAP4 SoC
> arm/dts: Add support for OMAP4 PandaBoard
> arm/dts: Add support for OMAP4 SDP board
> arm/dts: Add initial device tree support for OMAP3 SoC
> arm/dts: Add support for OMAP3 Beagle board
> OMAP2+: board-generic: Add DT support to generic board
> OMAP2+: board-generic: Add i2c static init
> OMAP2+: l3-noc: Add support for device-tree
> arm/dts: OMAP4: Add a main ocp entry bound to l3-noc driver
> arm/dts: OMAP3+: Add mpu, dsp and iva nodes
>
> Documentation/devicetree/bindings/arm/omap/dsp.txt | 14 ++
> Documentation/devicetree/bindings/arm/omap/iva.txt | 19 +++
> .../devicetree/bindings/arm/omap/l3-noc.txt | 19 +++
> Documentation/devicetree/bindings/arm/omap/mpu.txt | 27 ++++
> arch/arm/boot/dts/omap3-beagle.dts | 29 ++++
> arch/arm/boot/dts/omap3.dtsi | 63 ++++++++
> arch/arm/boot/dts/omap4-panda.dts | 29 ++++
> arch/arm/boot/dts/omap4-sdp.dts | 29 ++++
> arch/arm/boot/dts/omap4.dtsi | 103 +++++++++++++
> arch/arm/mach-omap2/Kconfig | 8 +-
> arch/arm/mach-omap2/board-generic.c | 156 +++++++++++++++-----
> arch/arm/mach-omap2/devices.c | 5 +
> arch/arm/mach-omap2/omap_l3_noc.c | 23 +++-
> arch/arm/mach-omap2/pm.c | 3 +-
> 14 files changed, 480 insertions(+), 47 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/omap/dsp.txt
> create mode 100644 Documentation/devicetree/bindings/arm/omap/iva.txt
> create mode 100644 Documentation/devicetree/bindings/arm/omap/l3-noc.txt
> create mode 100644 Documentation/devicetree/bindings/arm/omap/mpu.txt
> create mode 100644 arch/arm/boot/dts/omap3-beagle.dts
> create mode 100644 arch/arm/boot/dts/omap3.dtsi
> create mode 100644 arch/arm/boot/dts/omap4-panda.dts
> create mode 100644 arch/arm/boot/dts/omap4-sdp.dts
> create mode 100644 arch/arm/boot/dts/omap4.dtsi
^ permalink raw reply
* [GIT PULL] omap cleanup part3 for v3.2 merge window
From: Tony Lindgren @ 2011-09-30 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109302256.39035.arnd@arndb.de>
* Arnd Bergmann <arnd@arndb.de> [110930 13:22]:
> On Friday 30 September 2011, Tony Lindgren wrote:
> > Please pull omap cleanup part3 into cleanup from:
> >
> > git://github.com/tmlind/linux.git cleanup-part3
> >
> > If you did not already pull the earlier updated
> > cleanup, pulling this is enough and will bring that
> > in too.
>
> Ok, I've ended up replacing the merge into the next/cleanup
> branch to get a cleaner history, so the cleanup-part2
> no longer shows up there.
Great thanks!
Tony
^ permalink raw reply
* [PATCH] ARM: tegra: Make earlyprintk choose a UART at runtime.
From: Stephen Warren @ 2011-09-30 22:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317061425-1030-1-git-send-email-dianders@chromium.org>
Doug Anderson wrote at Monday, September 26, 2011 12:24 PM:
> With this change we automatically detect which UART to use for
> earlyprintk (and for printing during decompression). The
> detection involves coordination with the bootloader: it's expected
> that the bootloader will leave a 'D' (for [D]ebug) in the UART
> scratchpad register for whichever UART we should use for debugging.
This works fine on Tegra20; there, even if the UART clock is off and/or
the UART is in reset, you can still read the UART_SCR register (and get
a bogus value) without the system hanging.
However, I just tested on Tegra30, and the behavior has changed; if either
a UART is in reset /or/ the UART clock is stopped, then the system hangs
when UART_SCR is read.
As such, this change will cause Tegra30 to fail to boot. I'd rather it
was augmented to check the clock enable and module reset bits as well
as the scratch register value in all cases.
Yes, I know mainline doesn't support Tegra30 yet, but we're very close
to posting the first few patches to start enabling it, and I wouldn't
want to break it right before that!
--
nvpublic
^ permalink raw reply
* [PATCH v5 3/3] OMAP2+: voltage: add check for missing PMIC info in vp init
From: Kevin Hilman @ 2011-09-30 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1109301240070.12185@utopia.booyaka.com>
Hi Paul,
Paul Walmsley <paul@pwsan.com> writes:
> On Fri, 30 Sep 2011, Abhilash K V wrote:
>
>> From: Abhilash K V <abhilash.kv@ti.com>
>>
>> If PMIC info is not available in omap_vp_init(), abort.
>>
>> Signed-off-by: Abhilash K V <abhilash.kv@ti.com>
>> ---
>> arch/arm/mach-omap2/vp.c | 7 +++++++
>> 1 files changed, 7 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
>> index 66bd700..0ed3d13 100644
>> --- a/arch/arm/mach-omap2/vp.c
>> +++ b/arch/arm/mach-omap2/vp.c
>> @@ -41,6 +41,13 @@ void __init omap_vp_init(struct voltagedomain *voltdm)
>> u32 val, sys_clk_rate, timeout, waittime;
>> u32 vddmin, vddmax, vstepmin, vstepmax;
>>
>> + if (!voltdm->pmic || !voltdm->pmic->uv_to_vsel) {
>> + pr_err("%s: PMIC info requried to configure VP for "
>> + "vdd_%s not populated.Hence cannot initialize VP\n",
>> + __func__, voltdm->name);
>> + return;
>> + }
>> +
>
> Just wondering about the intent of this patch. Is the goal here to not
> call omap_vp_init() for chips that don't have a VP IP block? If so, then
> implementing code that does that directly seems like a better approach
> than using the PMIC data? Because it seems likely that even SoCs without
> VP IP blocks will have PMICs on the board, right?
You're right, this isn't really relevant for this series since AM35x
doesn't have VP, and hence shouldn't even be calling omap_vp_init().
However, this does fix a bug on devices that do have VP where the VP is
initialized before PMIC info has been registered.
So, I'll queue this patch as a fix for the voltage layer, but it should
not have been included in the AM35x series.
Kevin
^ permalink raw reply
* ARM SoC tree: OMAP PM dependency on tip irq/core
From: Kevin Hilman @ 2011-09-30 22:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87aa9mm8ts.fsf@ti.com>
Hi Arnd,
Kevin Hilman <khilman@ti.com> writes:
> The upcoming OMAP4 PM series from Santosh[1] that we're planning to
> queue for v3.2 has a dependency[2] on a patch currently queued for v3.2
> in the irq/core branch of Thomas' tip tree[3].
>
> In the past, I noticed you merged external trees like this to solve
> dependencies.
>
> Could you pull the irq/core branch into your tree to meet this
> dependency?
On second thought, since Santosh's branch is the only one with this
dependency (and we also have a dependency on Russell's devel-stable)
I'll just build up a branch for Santosh's series that includes
rmk/devel-stable and tglx/irq-core.
You (or Tony) can then pull this one instead of manually managing the
dependencies.
Kevin
^ permalink raw reply
* Porting linux to Stellaris Cortex-M3
From: Fernando Endo @ 2011-09-30 22:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110927205043.GA23944@n2100.arm.linux.org.uk>
2011/9/27 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Tue, Sep 27, 2011 at 09:54:18AM -0300, Fernando Endo wrote:
>> This is the log that I got with printascii bypassing printk:
>>
>> <5>Linux version 2.6.33-arm1 (fernando at fernando-POS-MIG31AG) (gcc
>> version 4.5.2 (Sourcery G++ Lite 2011.03-41) ) #127 Tue Sep 27
>> 09:14:21 BRT 2011
>> CPU: ARMv7-M Processor [412fc230] revision 0 (ARMv?(11)M)
>> CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
>> Machine: Stellaris LM3S9B96
>> <7>On node 0 totalpages: 2048
>> <7>free_area_init_node: node 0, pgdat 600de1e0, node_mem_map 600f6000
>> <7> ?DMA zone: 16 pages used for memmap
>> <7> ?DMA zone: 0 pages reserved
>> <7> ?DMA zone: 2032 pages, LIFO batch:0
>> Built 1 zonelists in Zone order, mobility grouping off. ?Total pages: 2032
>> <5>Kernel command line: init=/bin/busybox console=ttyS mem=8M
>> <6>PID hash table entries: 32 (order: -5, 128 bytes)
>> <6>Dentry cache hash table entries: 1024 (order: 0, 4096 bytes)
>> <6>Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
>> <6>Memory: 8MB = 8MB total
>> <5>Memory: 7168k/7168k available, 1024k reserved, 0K highmem
>> <5>Virtual kernel memory layout:
>> ? ?vector ?: 0x00000000 - 0x00001000 ? ( ? 4 kB)
>> ? ?fixmap ?: 0xfff00000 - 0xfffe0000 ? ( 896 kB)
>> ? ?vmalloc : 0x00000000 - 0xffffffff ? (4095 MB)
>> ? ?lowmem ?: 0x60000000 - 0x60800000 ? ( ? 8 MB)
>> ? ?modules : 0x60000000 - 0x60800000 ? ( ? 8 MB)
>> ? ? ?.init : 0x60008000 - 0x6002f000 ? ( 156 kB)
>> ? ? ?.text : 0x6002f000 - 0x600cb000 ? ( 624 kB)
>> ? ? ?.data : 0x600d6000 - 0x600deb40 ? ( ?35 kB)
>> <6>Hierarchical RCU implementation.
>> <6>NR_IRQS:54
>> <6>console [ttyS0] enabled
>> <6>Calibrating delay loop... <c>3.82 BogoMIPS (lpj=19136)
>> Mount-cache hash table entries: 512
>> <6>Switching to clocksource timer3
>> <6>ttyS0 at MMIO 0x4000c000 (irq = 5) is a LM3S9B96 UARTx Port
>> <6>Freeing init memory: 156K
>> <3>BUG: scheduling while atomic: init/1/0xffff0003
>> [<60032b6d>] (unwind_backtrace+0x1/0x88) from [<600a1379>] (dump_stack+0xd/0x10)
>> [<600a1379>] (dump_stack+0xd/0x10) from [<60034ea5>] (__schedule_bug+0x35/0x40)
>> [<60034ea5>] (__schedule_bug+0x35/0x40) from [<600a17b1>] (schedule+0x2d1/0x2f4)
>> [<600a17b1>] (schedule+0x2d1/0x2f4) from [<6002f791>] (ret_slow_syscall+0x1/0xc)
>
> Hmm, this doesn't look good. ?What this is showing is that it's the
> call to schedule() in the code dealing with returning to userspace.
> The preempt count shouldn't be this wrong here - it suggests that
> something is returning with wrong preempt status.
>
> The problem is it's not possible at this point to work out from the
> information you've supplied whether it's a data abort, prefetch abort,
> or SWI (SVC) call (and actually we don't have any tracking of that.)
>
> If I had to guess I'd suggest that there was something fishy with
> the IRQ handling - but without knowing what mods you've made to the
> stock kernel, that's about as much speculation that I can give.
>
Hello again, now I have good news!
Our port is working fine, we got the linux prompt today.
I don't know exactly the influence of the changes I've done, but just
to help people facing the same situation:
(... after crazy attempts)
1) I was using "for" instructions inside a /init test program to make
a led blink
2) I've replaced them by sleep(1), then things seemed to be much
better, no more crashes
3) As sleep(1) didn't take 1s, I fixed that
4) I've started debugging printf, as suggests busybox.net/FAQ.html#init
5) Finally, after finding and fixing a bug on my uart_isr, I was able
to see printf messages
(I didn't know that the kernel may use uart interruptions after
switching to the user space)
6) The prompt came after creating init scripts read by Busybox
I think the first one was somehow messing the user space...
Att,
Fernando Akira Endo
^ permalink raw reply
* [PATCH v5 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices
From: Kevin Hilman @ 2011-09-30 23:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87r52xhhkb.fsf@ti.com>
Abhilash,
Kevin Hilman <khilman@ti.com> writes:
> Abhilash K V <abhilash.kv@ti.com> writes:
>
>> From: Abhilash K V <abhilash.kv@ti.com>
>>
>> In case of AM3517 & AM3505, SmartReflex is not applicable so
>> we must not enable it. So omap3_twl_init() is now not called
>> when the processor does not support SR.
>
> This still isn't right.
>
> The reason to skip the TWL PMIC init is not because SR is not available
> (TWL PMICs are quite usable without SR). The reason to skip TWL PMIC
> init is because the PMIC is not present.
>
> Instead, we need to fix up the TWL/PMIC init so that TWL-specifics are
> only registered if a TWL driver is registered.
>
Below is a test patch that is a first pass at implementing what I
suggested above. I tested this (along with your patch 3/3) on a
3430/n900 after removing the omap_pmic_init() call frome the board file.
Can you let me know if this solves the problem you're seeing on
platforms that don't have TWL PMICs?
After digging into this more, I'm increasingly aware that the way we're
managing the init of PMIC stuff is a mess. Guess I need another round
of voltage layer cleanups to fix that up.
Kevin
^ permalink raw reply
* [PATCH v2 3/5] iommu/exynos: Add iommu driver for Exynos4 Platforms
From: KyongHo Cho @ 2011-09-30 23:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110930120652.GP2138@amd.com>
On Fri, Sep 30, 2011 at 9:06 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
> First comment: Pleas remove the 'inline' annotations in this patch. It
> is better to let the compiler decide what to inline and what not.
Ok. Thanks :)
>
> Hmm, may it make sense to store data directly in dev->arch.iommu? This
> will save you the list traversals to get the information.
>
That looks better.
However, adding features to dev_archdata of ARM is actively discussed
in Linaro-mm-sig and the features also include iommu_domain.
On the other hand,
I was not able to determine what will be accepted to the mainline kernel
between Linaro's one that is suggested by Marek and Ohad's one.
>> +
>> +static inline bool set_sysmmu_active(struct sysmmu_drvdata *data)
>> +{
>> + ? ? ? /* return true if the System MMU was not active previously
>> + ? ? ? ? ?and it needs to be initialized */
>> +
>> + ? ? ? data->activations++;
>
> Is this variable only accessed under a lock? If not it should be an
> atomic.
>
All 'sysmmu' functions must be called under a lock because a System MMU
(Samsung's IOMMU) is a shared resource.
I the first patch, I declared the 'data->activations' as atomic_t but
Russell King pointed
that atomic operations on data->activations is not helpful for
preventing to become
a System MMU enabled when its data->activations is 0.
>> + ? ? ? return data->activations == 1;
>
> Is that right? Shouldn't it be 'data->activations > 0'?
>
The value returned by set_sysmmu_active() means "The System MMU must be
initialized".
System MMU is initialized when its state is changed from
'inactive(disabled)' to active(enabled).
If data->activations++ becomes 2 or more, the System MMU is already enabled and
must not be initialized again.
>> +static inline void __set_fault_handler(struct sysmmu_drvdata *data,
>> + ? ? ? ? ? ? ? ? ? ? ? int (*handler)(enum S5P_SYSMMU_INTERRUPT_TYPE itype,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? unsigned long pgtable_base,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? unsigned long fault_addr))
>
> Please typedef the function signature.
>
Ok. thanks.
>> +static int exynos_iommu_domain_init(struct iommu_domain *domain)
>> +{
>> + ? ? ? struct exynos_iommu_domain *priv;
>> +
>> + ? ? ? priv = kzalloc(sizeof(*priv), GFP_KERNEL);
>> + ? ? ? if (!priv)
>> + ? ? ? ? ? ? ? return -ENOMEM;
>> +
>> + ? ? ? priv->pgtable = (unsigned long *)__get_free_pages(GFP_KERNEL,
>> + ? ? ? ? ? ? ? (S5P_LV1TABLE_ENTRIES * sizeof(unsigned long)) >> PAGE_SHIFT);
>
> For __get_free_pages you can't just pass in the number of pages, you
> need the order. Please use get_order.
>
Oh! Thank you.
I didn't notice the problem.
It allocated too large memory so far.
>> + ? ? ? if (!priv->pgtable) {
>> + ? ? ? ? ? ? ? kfree(priv);
>> + ? ? ? ? ? ? ? return -ENOMEM;
>> + ? ? ? }
>> +
>> + ? ? ? memset(priv->pgtable, 0, S5P_LV1TABLE_ENTRIES * sizeof(unsigned long));
>> + ? ? ? pgtable_flush(priv->pgtable, priv->pgtable + S5P_LV1TABLE_ENTRIES);
>> +
>> + ? ? ? spin_lock_init(&priv->lock);
>
> No init for the page-table lock?
>
Thank you. I forgot that.
>> +static void exynos_iommu_domain_destroy(struct iommu_domain *domain)
>> +{
>> + ? ? ? struct exynos_iommu_domain *priv = domain->priv;
>> +
>> + ? ? ? free_pages((unsigned long)priv->pgtable,
>> + ? ? ? ? ? ? ? (S5P_LV1TABLE_ENTRIES * sizeof(unsigned long)) >> PAGE_SHIFT);
>
> Same here, please use get_order.
>
True. I will fix that immediately.
>> +static int __init exynos_iommu_init(void)
>> +{
>> + ? ? ? l2table_cachep = kmem_cache_create("SysMMU Lv2 Tables",
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? S5P_LV2TABLE_SIZE, S5P_LV2TABLE_SIZE, 0, NULL);
>
> Any reason you allocate a seperate slab-cache? It doesn't have a
> constructor so it would be merged into the kmalloc-slabs anyway (at
> least with SLUB).
>
I found that kmalloc(SZ_1K) returned an address that is not aligned by SZ_1K.
I did not understand why it happened and I changed it to the slab cache.
I will try it again with kmalloc().
Regards,
KyongHo
^ permalink raw reply
* [PATCH v2 2/5] ARM: S5P: Remove system MMU driver from arm/plat-s5p
From: KyongHo Cho @ 2011-09-30 23:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110930134243.GR2138@amd.com>
On Fri, Sep 30, 2011 at 10:42 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
> On Fri, Sep 30, 2011 at 03:30:57AM -0400, Kukjin Kim wrote:
>> From: KyongHo Cho <pullip.cho@samsung.com>
>>
>> Due to Ohad Ben-Cohen gathered IOMMU drivers in drivers/iommu directory,
>> System MMU driver is moved to drivers/iommu directory and removed
>> from arch/arm/plat-s5p directory.
>>
>> Please see
>> https://lkml.org/lkml/2011/6/8/69
>>
>> Signed-off-by: KyongHo Cho <pullip.cho@samsung.com>
>> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
>> ---
>> ?arch/arm/plat-s5p/Kconfig ? ? ? ? ? ? ? | ? ?8 -
>> ?arch/arm/plat-s5p/Makefile ? ? ? ? ? ? ?| ? ?1 -
>> ?arch/arm/plat-s5p/include/plat/sysmmu.h | ? 95 ----------
>> ?arch/arm/plat-s5p/sysmmu.c ? ? ? ? ? ? ?| ?312 -------------------------------
>
> You can use 'git mv' to just move the file. This ensures bisectability
> of your patches. No need to delete the code in one patch and re-add it
> in the next one (which breaks bisectability).
>
Thanks.
I will do that
Regards,
KyongHo.
^ permalink raw reply
* [PATCH v2 5/5] iommu/exynos: Use bus_set_iommu instead of register_iommu
From: KyongHo Cho @ 2011-09-30 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110930134643.GS2138@amd.com>
On Fri, Sep 30, 2011 at 10:46 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
> On Fri, Sep 30, 2011 at 03:31:49AM -0400, Kukjin Kim wrote:
>> From: KyongHo Cho <pullip.cho@samsung.com>
>>
>> This replaces register_iommu() with bus_set_iommu() according to the
>> suggestion of Joerg Roedel.
>
> This should be part of patch 3 already when the bus_set_iommu() change
> is merged. Otherwise it breaks bisectability too.
>
Ok.
Should I include fault handling feature (patch 4) in the patch 3 also?
Thanks.
KyongHo.
^ permalink raw reply
* [PATCH v3 2/3] ARM: OMAP: TI814X: Add cpu type macros and detection support
From: Pedanekar, Hemant @ 2011-10-01 0:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1109291443160.26728@utopia.booyaka.com>
Hi Paul,
Paul Walmsley wrote on Friday, September 30, 2011 2:17 AM:
> Hello Hemant,
>
> a few comments:
>
> On Thu, 29 Sep 2011, Hemant Pedanekar wrote:
>
>> This patch adds cpu type, macros for identification of TI814X device.
>>
>> Note that following update to common OMAP data structures is made:
>>
>> cpu_mask and RATE_IN_XXX flags have crossed 8 bit hence struct
>> clksel_rate.flags, struct prcm_config.flags and cpu_mask are changed to
>> u16 from u8.
>>
>> Signed-off-by: Hemant Pedanekar <hemantp@ti.com>
>
> Also, the opp2xxx.h change looks spurious, is that really needed?
>
I changed prcm_config.flags to accommodate cpu_mask change, as cpu_mask
is used with prcm_config.flags (mostly) in clkt2xxx_virt_prcm_set.c as
below:
prcm->flags & cpu_mask
And flags is assigned in opp2420_data.c (e.g., RATE_IN_242X)
But yes, these are already defined RATE_INs and do not cross 8-bits,
so no warnings even if flags is 8-bit and cpu_mask changed to 16-bit.
What is your suggestion?
I see you mentioned "Also" in the above comment, but didn't see any
comment preceeding.
> Could you please split the clock-related changes into a
> separate patch?
> Then this patch would just be the id.c and cpu.h changes.
>
> Other than that, the patch looks okay to me.
>
>
> - Paul
Will do that.
Thanks.
Hemant
^ permalink raw reply
* [GIT PULL] ARM: CSR: cleanup some minor coding-style issues for 3.2
From: Barry Song @ 2011-10-01 1:47 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
The following changes since commit d93dc5c4478c1fd5de85a3e8aece9aad7bbae044:
Linus Torvalds (1):
Linux 3.1-rc7
are available in the git repository at:
git at gitorious.org:sirfprima2-kernel/sirfprima2-kernel.git fixes
Barry Song (4):
ARM: CSR: timer: do not initialise statics to 0 or NULL
ARM: CSR: timer: space required before the open parenthesis '('
ARM: CSR: prima2: fix trailing whitespace
ARM: CSR: clock: Fix indentation
arch/arm/mach-prima2/clock.c | 4 ++--
arch/arm/mach-prima2/prima2.c | 2 +-
arch/arm/mach-prima2/timer.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
2011/10/1 Arnd Bergmann <arnd@arndb.de>:
> On Friday 23 September 2011, Barry Song wrote:
>> Barry Song (4):
>> ? ARM: CSR: timer: do not initialise statics to 0 or NULL
>> ? ARM: CSR: timer: space required before the open parenthesis '('
>> ? ARM: CSR: prima2: fix trailing whitespace
>> ? ARM: CSR: clock: Fix indentation
>>
>> ?arch/arm/mach-prima2/clock.c ?| ? ?4 ++--
>> ?arch/arm/mach-prima2/prima2.c | ? ?2 +-
>> ?arch/arm/mach-prima2/timer.c ?| ? ?4 ++--
>> ?3 files changed, 5 insertions(+), 5 deletions(-)
>
>
> Hi Barry,
>
> Sorry for the late reply. This series and the one before all look good
> to me, but I fear I'm losing track of the patches.
>
> Can you send me pull requests for each set (fixes, cleanups, other
> changes) so I can be sure I get everything? If you have trouble
> with git.kernel.org still being down, I can apply the patches
> manually and let you double-check them, but that would be more
> work for both of us I think.
>
> ? ? ? ?Arnd
-barry
^ permalink raw reply
* [GIT PULL] ARM: CSR: l2x0 init cleanup for 3.2
From: Barry Song @ 2011-10-01 2:32 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
Since the l2x0 cleanup of prima2 depends on the following two patches
in rmk's tree:
[1]Rob Herring
ARM: 7009/1: l2x0: Add OF based initialization
http://www.spinics.net/lists/arm-kernel/msg131123.html
it has been in rmk/for-next
[2]Barry Song
ARM: 7009/1: CACHE-L2X0: filter start address can be 0 and is often 0
http://www.spinics.net/lists/arm-kernel/msg140126.html
it has been in rmk/for-next
I have rebased the l2x0-cleanup branch to "ARM: 7009/1: CACHE-L2X0:
filter start address can be 0 and is often 0". this might cause some
issues to you. if that is difficult to you, i guess you can pich the
commmit and apply it when your tree has been ready.
The following changes since commit 513d47a3d953e44d79c29077f6c428a017f8af62:
Barry Song (1):
ARM: 7090/1: CACHE-L2X0: filter start address can be 0 and is often 0
are available in the git repository at:
git://gitorious.org/sirfprima2-kernel/sirfprima2-kernel.git l2x0-cleanup
Barry Song (1):
ARM: CSR: call l2x0_of_init to init L2 cache of SiRFprimaII
arch/arm/boot/dts/prima2-cb.dts | 5 +++-
arch/arm/mach-prima2/l2x0.c | 46 +++++++-------------------------------
2 files changed, 13 insertions(+), 38 deletions(-)
Thanks
barry
^ permalink raw reply
* [PATCH] drivers: create a pin control subsystem v8
From: Linus Walleij @ 2011-10-01 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACxGe6v19pZ0i-+ksYZbG2ZvGT30UkXEHTzpZMBTB4RNUV5bnA@mail.gmail.com>
2011/9/30 Grant Likely <grant.likely@secretlab.ca>:
>?I'm not convinced that the sysfs approach is
> actually the right interface here (I'm certainly not a fan of the gpio
> sysfs i/f), and I'd rather not be putting in unneeded stuff until the
> userspace i/f is hammered out.
Actually, thinking about it I cannot see what would be wrong
with /dev/gpio0 & friends in the first place.
Using sysfs as swiss army knife for custom I/O does not
seem like it would be long-term viable so thanks for this
observation, and I think we need /dev/gpio* put on some
mental roadmap somewhere.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v4 3/7] arm/imx: add gic_handle_irq function
From: Shawn Guo @ 2011-10-01 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110929142729.GM19318@S2100-06.ap.freescale.net>
On Thu, Sep 29, 2011 at 10:27:30PM +0800, Shawn Guo wrote:
> On Thu, Sep 29, 2011 at 10:34:09AM +0100, Russell King - ARM Linux wrote:
> > On Wed, Sep 28, 2011 at 05:06:44PM +0800, Shawn Guo wrote:
> > > +#ifdef CONFIG_SMP
> > > + else if (irqnr < 16) {
> > > + writel_relaxed(irqstat, gic_cpu_base_addr +
> > > + GIC_CPU_EOI);
> > > + do_IPI(irqnr, regs);
> > > + }
> > > +#endif
> > > +#ifdef CONFIG_LOCAL_TIMERS
> > > + else if (irqnr == 29) {
> > > + writel_relaxed(irqstat, gic_cpu_base_addr +
> > > + GIC_CPU_EOI);
> > > + do_local_timer(regs);
> > > + }
> > > +#endif
> >
> > As I've said for similar patches. neither of these two functions are
> > designed to be called from another C function (because they're marked
> > __exception or __exception_irq_entry). Both of these markers tell the
> > unwinder that a struct pt_regs is located directly above the functions
> > stack frame.
> >
> I'm also wondering the consequence of not doing so, because we are
> seeing icip_handle_irq() and ichp_handle_irq() (arch/arm/mach-pxa/irq.c)
> are doing the same thing, and we are not running into any problem with
> above code.
>
Sorry. Please ignore the above.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH v6 01/16] OMAP2+: hwmod: Add API to enable IO ring wakeup.
From: Rajendra Nayak @ 2011-10-01 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317380495-584-1-git-send-email-govindraj.raja@ti.com>
On Friday 30 September 2011 04:31 PM, Govindraj.R wrote:
> Add API to enable IO pad wakeup capability based on mux dynamic pad and
> wake_up enable flag available from hwmod_mux initialization.
>
> Use the wakeup_enable flag and enable wakeup capability
> for the given pads. Wakeup capability will be enabled/disabled
> during hwmod idle transition based on whether wakeup_flag is
> set or cleared.
>
> Call the omap_hwmod_set_ioring_wakeup from hwmod_wakeup_enable/disable.
>
> Signed-off-by: Govindraj.R<govindraj.raja@ti.com>
> ---
> arch/arm/mach-omap2/omap_hwmod.c | 59 ++++++++++++++++++++++++++++++++++++++
> 1 files changed, 59 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> index 84cc0bd..e751dd9 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -2062,6 +2062,34 @@ static int __init omap_hwmod_setup_all(void)
> core_initcall(omap_hwmod_setup_all);
>
> /**
> + * omap_hwmod_set_ioring_wakeup - enable io pad wakeup flag.
> + * @oh: struct omap_hwmod *
> + * @set: bool value indicating to set or clear wakeup status.
> + *
> + * Set or Clear wakeup flag for the io_pad.
> + */
> +static int omap_hwmod_set_ioring_wakeup(struct omap_hwmod *oh, bool set_wake)
> +{
> + struct omap_device_pad *pad;
> + int ret = -EINVAL, j;
> +
> + if (oh->mux&& oh->mux->enabled) {
> + for (j = 0; j< oh->mux->nr_pads_dynamic; j++) {
> + pad = oh->mux->pads_dynamic[j];
> + if (pad->flags& OMAP_DEVICE_PAD_WAKEUP) {
> + if (set_wake)
> + pad->idle |= OMAP_WAKEUP_EN;
> + else
> + pad->idle&= ~OMAP_WAKEUP_EN;
I think apart from enabling/disabling the IO wakeup's at the pad
level, there is also a need to trigger the IO daisy chain control
(Wu clock) by programming the PRCM.PM_WKEN_WKUP[16] EN_IO_CHAIN
bit and waiting on the PRCM.PM_WKST_WKUP[16] ST_IO_CHAIN) bit,
which is done by the omap3_enable/disable_io_chain function.
This is still done in the cpuidle path, but it makes sense to
move that over here, since it should be done every time a pad
level wakeup is enabled or disabled.
See section 3.5.7.2.2 I/O Wake-Up Mechanism of 36xx TRM revA.
"The I/O wake-up scheme is enabled by triggering the I/O daisy chain
control (Wu clock) by
programming a dedicated register (PRCM.PM_WKEN_WKUP[16] EN_IO_CHAIN) in
the PRCM module.Software must wait for the I/O daisy chain to complete
before it transitions the PER domain to a
nonfunctional state. This is done by polling a dedicated status bit in
the PRCM module
(PRCM.PM_WKST_WKUP[16] ST_IO_CHAIN). This status bit must be cleared by
software when the bit is
read to 1."
> + ret = 0;
> + }
> + }
> + }
> +
> + return ret;
> +}
> +
> +/**
> * omap_hwmod_enable - enable an omap_hwmod
> * @oh: struct omap_hwmod *
> *
> @@ -2393,6 +2421,35 @@ int omap_hwmod_del_initiator_dep(struct omap_hwmod *oh,
> {
> return _del_initiator_dep(oh, init_oh);
> }
> +/**
> + * omap_hwmod_enable_ioring_wakeup - Set wakeup flag for iopad.
> + * @oh: struct omap_hwmod *
> + *
> + * Traverse through dynamic pads, if pad is enabled then
> + * set wakeup enable bit flag for the mux pin. Wakeup pad bit
> + * will be set during hwmod idle transistion.
> + * Return error if pads are not enabled or not available.
> + */
> +int omap_hwmod_enable_ioring_wakeup(struct omap_hwmod *oh)
> +{
> + /* Enable pad wake-up capability */
> + return omap_hwmod_set_ioring_wakeup(oh, true);
> +}
> +
> +/**
> + * omap_hwmod_disable_ioring_wakeup - Clear wakeup flag for iopad.
> + * @oh: struct omap_hwmod *
> + *
> + * Traverse through dynamic pads, if pad is enabled then
> + * clear wakeup enable bit flag for the mux pin. Wakeup pad bit
> + * will be set during hwmod idle transistion.
> + * Return error if pads are not enabled or not available.
> + */
> +int omap_hwmod_disable_ioring_wakeup(struct omap_hwmod *oh)
> +{
> + /* Disable pad wakeup capability */
> + return omap_hwmod_set_ioring_wakeup(oh, false);
> +}
>
> /**
> * omap_hwmod_enable_wakeup - allow device to wake up the system
> @@ -2419,6 +2476,7 @@ int omap_hwmod_enable_wakeup(struct omap_hwmod *oh)
> v = oh->_sysc_cache;
> _enable_wakeup(oh,&v);
> _write_sysconfig(v, oh);
> + omap_hwmod_enable_ioring_wakeup(oh);
> spin_unlock_irqrestore(&oh->_lock, flags);
>
> return 0;
> @@ -2449,6 +2507,7 @@ int omap_hwmod_disable_wakeup(struct omap_hwmod *oh)
> v = oh->_sysc_cache;
> _disable_wakeup(oh,&v);
> _write_sysconfig(v, oh);
> + omap_hwmod_disable_ioring_wakeup(oh);
> spin_unlock_irqrestore(&oh->_lock, flags);
>
> return 0;
^ permalink raw reply
* [PATCH v6 02/16] OMAP2+: hwmod: Add API to check IO PAD wakeup status
From: Rajendra Nayak @ 2011-10-01 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317380495-584-2-git-send-email-govindraj.raja@ti.com>
On Friday 30 September 2011 04:31 PM, Govindraj.R wrote:
> Add API to determine IO-PAD wakeup event status for a given
> hwmod dynamic_mux pad.
>
> Wake up event set will be cleared on pad mux_read.
Are these api's even getting used in this series?
>
> Signed-off-by: Govindraj.R<govindraj.raja@ti.com>
> ---
> arch/arm/mach-omap2/mux.c | 30 ++++++++++++++++++++++++++
> arch/arm/mach-omap2/mux.h | 13 +++++++++++
> arch/arm/mach-omap2/omap_hwmod.c | 7 ++++++
> arch/arm/plat-omap/include/plat/omap_hwmod.h | 1 +
> 4 files changed, 51 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
> index 655e948..fb75aae 100644
> --- a/arch/arm/mach-omap2/mux.c
> +++ b/arch/arm/mach-omap2/mux.c
> @@ -351,6 +351,36 @@ err1:
> return NULL;
> }
>
> +/**
> + * omap_hwmod_mux_get_wake_status - omap hwmod check pad wakeup
> + * @hmux: Pads for a hwmod
> + *
> + * Gets the wakeup status of given pad from omap-hwmod.
> + * Returns true if wakeup capability is set and wakeup event occurred.
> + * Returns false if wakeup event has not occurred or pads are not available.
> + */
> +bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux)
> +{
> + int i;
> + unsigned int val;
> + u8 ret = false;
> +
> + for (i = 0; i< hmux->nr_pads; i++) {
> + struct omap_device_pad *pad =&hmux->pads[i];
> +
> + if (pad->flags& OMAP_DEVICE_PAD_WAKEUP) {
> + val = omap_mux_read(pad->partition,
> + pad->mux->reg_offset);
> + if (val& OMAP_WAKEUP_EVENT) {
> + ret = true;
> + break;
> + }
> + }
> + }
> +
> + return ret;
> +}
> +
> /* Assumes the calling function takes care of locking */
> void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state)
> {
> diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
> index 2132308..8b2150a 100644
> --- a/arch/arm/mach-omap2/mux.h
> +++ b/arch/arm/mach-omap2/mux.h
> @@ -225,8 +225,21 @@ omap_hwmod_mux_init(struct omap_device_pad *bpads, int nr_pads);
> */
> void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state);
>
> +/**
> + * omap_hwmod_mux_get_wake_status - omap hwmod check pad wakeup
> + * @hmux: Pads for a hwmod
> + *
> + * Called only from omap_hwmod.c, do not use.
> + */
> +bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux);
> #else
>
> +static inline bool
> +omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux)
> +{
> + return 0;
> +}
> +
> static inline int omap_mux_init_gpio(int gpio, int val)
> {
> return 0;
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> index e751dd9..a8b24d7 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -2724,3 +2724,10 @@ int omap_hwmod_no_setup_reset(struct omap_hwmod *oh)
>
> return 0;
> }
> +
> +int omap_hwmod_pad_get_wakeup_status(struct omap_hwmod *oh)
> +{
> + if (oh&& oh->mux)
> + return omap_hwmod_mux_get_wake_status(oh->mux);
> + return -EINVAL;
> +}
> diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> index 0e329ca..9a6195c 100644
> --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
> +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> @@ -607,6 +607,7 @@ u32 omap_hwmod_get_context_loss_count(struct omap_hwmod *oh);
>
> int omap_hwmod_no_setup_reset(struct omap_hwmod *oh);
>
> +int omap_hwmod_pad_get_wakeup_status(struct omap_hwmod *oh);
> /*
> * Chip variant-specific hwmod init routines - XXX should be converted
> * to use initcalls once the initial boot ordering is straightened out
^ permalink raw reply
* [PATCH v4] ARM: cache-l2x0: add resume entry for l2 in secure mode
From: Russell King - ARM Linux @ 2011-10-01 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317375773-7229-1-git-send-email-Barry.Song@csr.com>
On Fri, Sep 30, 2011 at 02:42:53AM -0700, Barry Song wrote:
> From: Barry Song <Baohua.Song@csr.com>
>
> we save the l2x0 registers at the first initialization, and platform codes
> can get them to restore l2x0 status after wakeup.
>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Signed-off-by: Barry Song <Baohua.Song@csr.com>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Tested-by: Shawn Guo <shawn.guo@linaro.org>
This looks fine, thanks Barry.
The one remaining issue is whether we use this or use Lorenzo's patches.
I feel that Barry's version is a lot simpler and easier to use, so this
is my preference. Anyone else got another opinion between the two?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox